Interesting Event codes

Some Interesting IR eventCodes are:

Login: 4624
Service install : 4697 ,7045
Service Start Type changed: 7040
New Process created: 4688

Cyber Security Frameworks

Here is the list of some of the very helpful Cybersecurity frameworks for aligning security endeavors in the organization

• Attack Matrix for Enterprise
  URL: https://attack.mitre.org/
  Purpose: Break up attack sequence in parts and list tools and relevant details for each. Identify Attack milestones, help identify gaps and align defense strategy
  Tags: BlueTeam,  Strategy
• Attack Eval for Enterprise
  URL: https://attackevals.mitre.org/
  Purpose: Evaluate how tools fit in overall defense strategy. Product Evaluations
  Tags: BlueTeam, Product evaluations
• Effectiveness ScoreCard - Cyber Kill Chain, Lockheed Martin
  URL: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html
  https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1493920778.pdf
   
  
  Purpose: Measure control effectiveness, where and how the controls fit in. Identify control gaps
  Tags: BlueTeam, Analyst, Strategy
  
• PCI Forensics Investigation report Template
  URL: https://www.pcisecuritystandards.org/documents/Final_PFI_Report_v2.1.pdf?agreement=true&time=1552226789177
  Tags: Reporting Template 

More WireShark

This is going to be a more of working notes style of post for various filters I use in WireSkark for different use cases and references to awesome material.

• Potential Flash Malware download:
  http.content_type == "application/x-shockwave-flash"
• Potential executable download:
  frame contains "DOS mode"
• Find hostname frames:
  nbns.nb_flags.group == 0
• Http Methods:
  http.request.method == "POST"
• Http Redirects
  http.response.code gt 300 && http.response.code lt 400
• Find Usernames in Kerberos tickets:
  kerberos.cname_string == 1
• IRC traffic
  tcp.port == 6666 || tcp.port == 6667 || tcp.port == 6668 || tcp.port == 6669
• DNS query: dns.qry.name
• Multiple Dns Answers : dns.count.answers gt 5
  
• Custom Fields:
• http.header.True-Client-IP
• http.header.WL-Proxy-Client-IP
• kerberos.CNameString

Pcap analysis - packettotal, security onion

References:

https://www.wiresharkbook.com/studyguide.html

https://www.wiresharkbook.com/troubleshooting.html

WireShark Malware Analysis basics

I was going through some of the pcap challenges on https://www.malware-traffic-analysis.net. There I stumbled upon a some very good posts for getting stared with wireshark which are mentioned in the reference below.

HTTP

Some columns can be set in wireshark which help in http traffic investigations:

• Src Port

• Dest Port 

• Host 

• User-Agent 

• Request URI 

• Content-Type 

• Status Code
• Location (302) [Heplful when SSL com starts]
• Referer

Tshark:

 tshark -r “/file.pcap"  -T fields -e dns.qry.name -e ip.src -e ip.dst  -e _ws.col.Info | grep “mydomain\|10.10.10.15\|10.10.10.16"
 





Reference:

• Changing the column display in Wireshark

• Adding HTTPS server names to the column display in Wireshark

• Identifying a host on the network

• Examining Tor traffic

SetUp CGI perl on CentOS apache

Setup apache webserver on CentOS

sudo yum install httpd

To make this web server available from lan or we need to whitelist our interfaces as Listen *:80

in /etc/httpd/conf/httpd.conf 

Now, we setup CGI execution, change the directory settings in httpd.conf

Before restarting httpd we have to change one more thing inside /etc/httpd/conf/httpd.conf:

<Directory "var/www/html">
    Options +ExecCGI
    AddHandler cgi-script .cgi .pl
</Directory>

Change permissions to allow for CGI to execute

And this one got me stuck a lot! Don't overlook this!

You need to tell your server that these CGI scripts are allowed to be executed as programs.

chmod 705 *.cgi

Or you can target individual CGI scripts.

chmod 705 hello.cgi

Put cgi files in /var/www/cgi-bin/ and run as  http://serverip/cgi-bin/script.cgi

cat /etc/httpd/conf/httpd.conf | grep ScriptAlias should have something like this in the output

ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

This is enough to run a test cgi script.

In case aces you might need to install more packages for a particular script such as MD5 digest.

# sudo yum install perl-Digest-MD5 -y

Now Reboot Apache : sudo apachectl stop, sudo apachectl start

Blind Sqli, Data retrieval from logs

Search string

Find files with particular string in file name

• find / -name "*.err"
  / - starting from / to all sub directories.
• Specify file type with find type = d (directory) , f (file)
• Find SUID files
  find / -perm /u=s
• To find all the files which are modified more than 50 days back and less than 100 days.
  # find / -mtime +50 –mtime -100
•  To find all the files which are changed in last 1 hour.
  # find / -cmin -60
• To find all the files which are modified in last 1 hour.
  # find / -mmin -60
• To find all the files which are accessed in last 1 hour.# find / -amin -60

Find String inside files and print file name

• grep -rnw '/path/to/somewhere/' -e 'pattern'
  /path/to/somewhere/ - Starting directory
  -r or -R is recursive,
  -n is line number, and
  -w stands for match the whole word.
  -l (lower-case L) can be added to just give the file name of matching files.
   
• ack 'text-to-find-here'

 
Redirect errors to Stdout

• 2&>1
• Now you can grep out the errors
  find / -name "*.err" 2&>1 | grep -v denied
  
   

XSS, CSRF and SOP Mythbuster

I was asked if reflected Cross site scripting (XSS) in POST would be stopped or mitigated by Same origin policy(SOP)? Hmmm...interesting question. As far as I could recall, I answered, simple post submission by html forms are not stopped by SOP.

There seems to be a misconception that POST cross domain request are not allowed due to SOP and that XSS in POST is only exploited in cases of stored XSS. Also that, reflected XSS is exploitable only is GET cases.

Oh well, why believe what anyone says, lets test it out. To test this I will set up a simple html page on victim server(10.211.55.2),  lets call it input page which  takes a comment and post it to post.php page. The post.php page suffers from a serious case of reflected XSS.

<form action="post.php" method="post">
 <input type="text" name="comment" value="">
 <input type="submit" name="submit" value="Submit">
</form>

post.php

<?php
echo $_POST["comment"];

Now lets create a simple html page to exploit it. I was too lazy to create one myself so i decided burp should do it for me. We can call it, test.html.

<html>

  <!-- Simple Post submissions are not blocked by Same origin policy-->

  <body>

  <script>history.pushState('', '', '/')</script>

    <form action="http://10.211.55.2/xss/post.php" method="POST">

      <input type="hidden" name="comment" value="testw&lt;script&gt;alert&#40;12345&#41;&lt;&#47;script&gt;wxvu2" />

      <input type="hidden" name="submit" value="Submit" />

      <input type="submit" value="Submit request" />

    </form>

  </body>

</html>

Now for the sake of this proof of concept to proceed, let us assume an attacker was able to redirect users to his malicious web server, serving test.html, or just sends this html page as an attachment.

User visits the malicious website(10.211.55.5) on windows and opens test.html...

...and submits the post form to execute XSS which is hosted on 10.211.55.2.

Taking it a step further so that we can call a javascript to "click" the submit button. Javascripts can be used to simulate a post form submission.

<!DOCTYPE html>

<html>

  <!-- Simple Post submissions are not blocked by Same origin policy-->

  <body>

  <script>history.pushState('', '', '/')</script>

    <form action="http://10.211.55.2/xss/post.php" method="POST">

      <input type="hidden" name="comment" value="testw&lt;script&gt;alert&#40;12345&#41;&lt;&#47;script&gt;wxvu2" />

      <input type="hidden" name="submit" value="Submit" />

      <input type="submit" id ="ert" value="Submit request" />

    </form>

  </body>

<script>

document.getElementById("ert").submit();

</script>

</html>

This happens because "The same origin policy is not enforced for all requests. Among others the <script>- and <img>-tags may fetch resources from any domain. Posting forms and linking to other domains is possible, too. "

We can easily extend this to malicious CSRF form submissions. 

So in essence we can conclude:

1. Reflected POST xss can be exploited the same as POST xss, i.e. sending the user to malicious link and use javascript to auto submit the xss post form.

2. Same origin policy does not apply to Cross domain POST form submissions, hence SOP is not a mitigating factor for POST XSS or CSRF. 

References:

https://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important
https://www.sitepoint.com/php-security-cross-site-scripting-attacks-xss/
https://w-shadow.com/blog/2008/11/20/cross-domain-post-with-javascript/

SOP & CORS

SOP

Origin - Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages.

Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.

Assume you are logged into Facebook and visit a malicious website in another browser tab. Without the same origin policy JavaScript on that website could do anything to your Facebook account that you are allowed to do.

But of course Facebook wants to use JavaScript to enhance the user experience. So it is important that the browser can detect that this JavaScript is trusted to access Facebook resources. That's where the same origin policy comes into play: If the JavaScript is included from a HTML page on facebook.com, it may access facebook.com resources.

The origin of a JavaScript file is defined by the domain of the HTML page which includes it. So if you include the Google Analytics code with a <script>-tag, it can do anything to your website but does not have same origin permissions on the Google website.

The same origin policy is not enforced for all requests. Among others the <script>- and <img>-tags may fetch resources from any domain.

HTTP cookies are dependent on the Same Origin Policy to ensure that sensitive information held about a certain user's activity pertains only to one site.

CORS

This cross-origin sharing standard is used to enable cross-site HTTP requests for:

• Invocations of the XMLHttpRequest or Fetch APIs in a cross-site manner, as discussed above.
• Web Fonts (for cross-domain font usage in @font-face within CSS)
• Images/video frames drawn to a canvas using drawImage.
• Stylesheets (for CSSOM access).

The Cross-Origin Resource Sharing standard works by adding new HTTP headers that allow servers to describe the set of origins that are permitted to read that information using a web browser.

Simple request

Some requests don’t trigger a CORS preflight. Those are called “simple requests” in this article. A request that doesn’t trigger a CORS preflight—a so-called “simple request”—is one that meets all the following conditions:

• The only allowed methods are:
• GET
• HEAD
• POST

The only allowed values for the Content-Type request header for simple requests are:

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

.......and more

Preflighted request

Unlike “simple requests” (discussed above), "preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send.

Sudo

What access do I have?
$ sudo -l

What access do other users have?
$ sudo -U username -l

Run a Command as Another User
Use the -u flag
$ sudo -u [username] [command] 
Enter your password, not the root password

Run a Command as Another Group
Use the -g flag
$ sudo -g operator dump 
$ sudo -g #5 dump

Rules processed in order; Last matching rule wins

Dangers of Wildcards (Check by sudo -l or access to sudoers file)
Pete ALL=/bin/cat /var/log/messages*
So you can view all the /var/log/messages archives...
$ sudo cat /var/log/messages /etc/shadow or
$ sudo cat /var/log/messages/../../../etc/shadow
 ...and all the other files in the system

And many More...


References:

http://repository.root-me.org/Administration/Unix/EN%20-%20sudo%20:%20you're%20doing%20it%20wrong.pdf