Thursday, December 15, 2016

Pentesting Rsync

Pentesting rsync.. is what I googled when I first saw it reported as an open service from Nessus. I hadn't seen it much and most available documentation about it was just a short usage manual. Rsync (Remote Sync) is an open source utility that provides fast incremental file transfer. Rsync copies files either to or from a remote host, or locally on the current host. It is commonly found on *nix systems and functions as both a file synchronization and file transfer program.

According to There are two different ways for rsync to contact a remote system: using a remote-shell program as the transport (such as ssh or rsh) or contacting an rsync daemon directly via TCP. The remote-shell transport is used whenever the source or destination path contains a single colon (:) separator after a host specification. Contacting an rsync daemon directly happens when the source or destination path contains a double colon (::) separator after a host specification, OR when an rsync:// URL is specified.

So how do we detect rsync and take advantage of it during a pentest? During a recent test one of the Nessus results was plugin 11389 which is rsync service detection. Furthermore each of the hosts in the “Hosts” section had a list of rsync modules with their name, description, and access rights.

The default port you will typically find an rsync daemon running on is 873 and also potentially 8873. If you aren’t using nessus a simple nmap scan of those ports will let you know if either port is open. Once you have determined an rsync service is running you can use the metasploit module auxiliary/scanner/rsync/modules_list which lists the names of the modules the same way the Nessus plugin did.

Alternatively you can also use the nmap script rsync-list-modules to get a list of rsync modules.

nmap --script=rsync-list-modules <ip> -p 873

Once you have the list of modules you have a few different options depending on the actions you want to take and whether or not authentication is required. If authentication is not required you can copy all files to your local machine via the following command:

rsync -av /data/tmp

This recursively transfers all files from the directory “module_name_1” on the machine into the /data/tmp directory on the local machine. The files are transferred in "archive" mode, which ensures that symbolic links, devices, attributes, permissions, ownerships, etc. are preserved in the transfer. Happy dumpster diving!

But… what if authentication is required? Some modules on the remote daemon may require authentication. If so, you will receive a password prompt when you connect. As a pentester you still have options! There is a NSE script called rsync-brute which performs brute force password auditing against the rsync remote file syncing protocol.


Tuesday, February 2, 2016

Burp Suite Extension: Burp Importer

Burp Importer is a Burp Suite extension written in python which allows users to connect to a list of web servers and populate the sitemap with successful connections. Burp Importer also has the ability to parse Nessus (.nessus), Nmap (.gnmap), or a text file for potential web connections. Have you ever wished you could use Burp’s Intruder to hit multiple targets at once for discovery purposes? Now you can with the Burp Import extension. Use cases for this extension consist of web server discovery, authorization testing, and more!

Click here to download source code


  1. Download Jython standalone Jar:
  2. In the Extender>Options tab point your Python Environment to the Jython file.
  3. Add Burp Importer in the Extender>Extensions tab.

General Use

Burp Importer is easy to use as it’s fairly similar to Burp’s Intruder tool. The first section of the extension is the file load option which is optional and used to parse Nessus (.nessus), Nmap (.gnmap), or a list of newline separated URLs (.txt). Nessus files are parsed for the HTTP Information Plugin (ID 24260). Nmap files are parsed for open common web ports from a predefined dictionary. Text files should be a list of URLs which conform to the format and separated by a newline. After the files are parsed a list of generated URLs will be added to the URL List box.

The URL List section is almost identical to Burp Intruder’s Payload Options. Users have the ability to paste a list of URLs, copy the current list, remove a URL from the list, clear the entire list, or add an individual URL. A connection to each item in the list will be attempted using the class and Burp makeHttpRequest method.

Gnamp file parsed example:

Nessus file parsed example:

The last section of the extension provides the user a checkbox option to follow redirects, run the list of URLs, and a run log. Redirects are determined by 301 and 302 status codes and based on the ‘Location’ header in the response. The run log displays the same output which shows in the Extender>Extensions>Output tab. It shows basic data any time you run the URL list such as successful connections, number of redirects (if enabled), and a list of URLs which are malformed or have connectivity issues.

Running a list of hosts:

Items imported into the sitemap:

Use Case – Discovery

One of the main motivations for creating this extension was to help the discovery phase of an application or network penetration test. Parsing through network or vulnerability scan results can be tedious and inefficient which is why automation is a vital part of penetration testing. This extension can be utilized as just a file parser which generates valid URLs to use with other tools and can also be used to gain quick insight into the web application scope of a network. There are many ways to utilize this tool from a discovery perspective, which include:

  • Determine the web scope of an environment via successful connections added to the sitemap.
  • Search or scrape for certain information from multiple sites. An example of this would be searching multiple sites for e-mail addresses or other specific information.
  • Determine the low-level vulnerability posture of multiple sites or pages via spidering then passive or active scanning.

Use Case – Authorization Testing

Another way to use this extension is to check an application for insecure direct object references. This refers to restricting objects or pages only to users who are authorized. To do this requires at least one set of valid credentials or potentially more depending on how many user roles are being tested. Also, session handling rules must be set to use cookies from Burp’s cookie jar with Extender.

The following steps can then be performed:

  1. Authenticate with the highest privileged account and spider/discover as many objects and pages as possible. Don’t forget to use intruder to search for hidden directories as well as convert POST requests to GET which can also be used to access additional resources (if allowed by the server of course).
  2. In the sitemap right click on the host at the correct path and select ‘Copy URLs in this branch.’ This will give you a list of resources which were accessed by the high privileged account.
  3. Logout and clear any saved session information.
  4. Login with a lower privileged user which could also be a user with no credentials or user role at all. Be sure you have an active session with this user.
  5. Open the Burp Importer tab and paste the list of resources retrieved from the higher privileged account into the URL List box. Select the ‘Enable: Follow Redirects’ box as it helps you know if you are being redirected to a login or error page.
  6. Analyze the results! A list of ‘failed’ connections and the number of redirects will automatically be added to the Log box. These are a good indicator if the lower privileged session was able to access the resources or if they were just redirected to a login/error page. The sitemap should also be searched to manually verify if any unauthorized resources were indeed successfully accessed. Entire branches of responses can be searched using regex and a negative match for the ‘Location’ header to find valid connections.
Here we can see the requests made to the DVWA application while logged in as 'admin' were not able to connect and redirected to the login page after the original administrative session was logged out of and killed. During this use case the DVWA application was not vulnerable to insecure direct object references.

There are many other uses for this extension just use your imagination! If you come up with any cool ideas or have any comments please reach out to me.

Tuesday, May 19, 2015

Cross-Site Request Forgery Detection with Burp and Regex

Cross-Site Request Forgery (CSRF) is an attack where a malicious person tries to force an authenticated user to execute some action. This attack can be caused by a GET or POST request where the server doesn’t validate the request is created by the correct authenticated user. To prevent CSRF, OWASP suggests using CSRF tokens by stating “The ideal solution is to only include the CSRF token in POST requests and have actions with state changing affect to only respond to POST requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then there is no need to include the token in GET requests.” During web application penetration tests it is very common for only POST requests to modify state, so my goal is usually to find POST requests which execute a state-changing action and doesn’t have any CSRF protection such as a unique token. It’s very possible that even if CSRF protection is implemented, it’s done so incorrectly or in an incomplete manner. I thought of a nice little trick using Burp search and regular expressions (regex) which I think could be very useful in quickly determining if an application is potentially vulnerable.

Inefficient Detection

Burp Suite Proxy does have CSRF detection as an option in the active scanner engine, however I have found it to be inaccurate at times. Burp also has a ‘Generate CSRF PoC’ function which I do use after my regex search, however in a large application it isn’t realistic to manually look at all POST requests and generate a PoC for each one. A third option is Burp’s pro extension ‘CSRF Scanner’ which almost does what I need, as it lets me passively scan a branch in the site map for requests with a negative match on specific strings (such as unique token names). The biggest downside to this is it does not allow me to specify only a POST request, so I end up with a list of hundreds of requests in the Scanner Results tab.

Efficient Detection with Burp Search and Regex

Burp’s built-in Search is decent but lacking in a lot of areas. It doesn’t let users specify things like type of requests (GET, POST, etc.), ignore duplicate resources, multiple strings in one request, etc. However, Burp’s search does allow us to use regex which means a lot of this functionality we can do and it will help us detect potential CSRF.
Starting with a simple regex search to get an idea of how it works, we see an expression which matches an entire request/response pair:

So let’s create a regex which will help us find potential CSRF. We want a list of all POST requests which don’t have a unique token called ‘CSRF_Token’. To do this we use the regex ^POST((?!CSRF_Token).)*$

Excellent! We now have a comprehensive list of POST requests without a ‘CSRF_Token’ parameter. This will be sufficient for most applications. But what if there are multiple parameters or cookies used to protect against CSRF? Just make a simple modification to the regex and use ^POST((?!CSRF_Token|Cookie: CSRF_Cookie=).)*$. We can add as many keywords to do a negative match against as we want. Just add a pipe ‘|’ character followed by the keyword. To wrap this up here are some quick steps you can do to use this method:

  1. Map out an application by spidering as much of it as you can.
  2. Use Burp’s automated form submission spider option or manually submit forms throughout the application to get as many POST requests in your site map as possible.
  3. Figure out which CSRF defenses are being implemented. Usually I just see one POST parameter as a unique token but sometimes cookies, headers, viewstate, etc. are also used.
  4. Search your target from the sitemap:
  5. Select the regex checkbox and input your desired expression based on step 3. Here is an example format:
  6. Look at the list of requests to confirm they are candidates for CSRF. Find a request with a high impact (ex: Add an administrative user) and use Burp’s ‘Generate CSRF PoC’ function in Engagement tools.
  7. Open and submit the CSRF PoC as the authenticated victim and confirm if the action completed successfully.

Done! Hopefully this post helps you identify potential CSRF candidates. If you have any questions or comments please feel free to share.


Monday, February 2, 2015

Physical Home Security with Wireless IP Cameras and Monitoring Software

I see a lot of people who want a cheap and custom security system for their apartment, home, or business. I recently accomplished this and want to share how. Hopefully this will inspire people to be proactive in protecting their property.

Click here to view a PDF of this post

My security solution consists of:

Most of these things can be changed with alternatives such as the cameras, software, DNS host, online storage, etc. This was the setup which I found to work best for me.

So for about $240 total I have the following features:
  • Cameras for pictures and video recording capable of good quality night vision.
  • Motion detection to determine when to record video.
  • E-mail and text message alerts based off motion detection.
  • Remotely monitor the cameras from anywhere.
  • Online backup of all pictures and video in real time.

Step 1 - Configure Wireless IP Cameras

  • Plug in each camera to an outlet for power and connect it to your home network (router) with the provided ethernet cable.
  • Use the IP Camera Tool to find the IP address of the cameras. This tool can be found on the included CD or downloaded here:
  • Type the IP into your browser and connect over port 88, it will probably be something like
  • Login with the default 'admin' user and no password. You should then create a strong password for this account, with a max of 12 characters. I suggest using a password manager or similar to create a complex password. Once logged in you can go to Basic Settings>User Accounts to delete the 'admin' username and create your own.
  • Login to each camera and disable DHCP and assign each one its own static IP address. This makes it easy to unplug the camera when you don't need to use it and power it back on when you do.
  • Enter and save your network information in Network>Wireless Settings. This is assuming the cameras will be used wirelessly and not always connected via an ethernet cable.
That was easy! After you do this for each of your cameras you are pretty much done with setting them up. Go through each page and configure them how you like, but remember all motion detection and alarms will be done with the Blue Iris software (which is not a necessity, just my preference because of the many options). You could set up detection, alarms, and remote monitoring with just the Foscam cameras without Blue Iris software however there are drastically less configurable options.

Step 2 - Configure Blue Iris Software

At the time of writing this the current version of Blue Iris is It's still fairly new, with some people reporting bugs which is why I am waiting to update, plus my current setup works just fine. A very helpful resource is the help page and search which has pretty good documentation about the different features of Blue Iris. If you ever get stuck, use this:
  • Add a camera by clicking the '+' button in the top right corner of the Camera’s window.
  • Add the settings for the type of camera you own. There is a large drop down list to choose many different cameras. The user and password are the credentials you used to set up the cameras in step 1.
  • Now that the camera is added and connected to Blue Iris you can configure various motion detection and alarm options. Some of these options may take some trial and error to find which settings fit your desired security solution best.
  • These are my settings for motion detection and what actions are taken once motion is detected. I have it recording video and taking snapshots once any detection happens.
  • These are my alerts settings. I immediately get a text message and e-mail with snapshot if the motion detection is triggered.
At this point you have your cameras set up with the correct detection, recording, and alert settings. Currently recorded media is being saved to the local hard drive of the laptop or whatever device you are running Blue Iris on. The only thing left to do is online backup/storage just in case an intruder were to steal your laptop, thus losing all of the evidence, as well as accessing the cameras remotely (optional). I'm going to go over setting up Google Drive to automatically sync all of the recorded video and pictures since it's free and you get 15GB. Any good security solution should always have some type of online backup.

Step 3 - Create Online Backup

That's pretty much it! Test it out by dragging files into the folders to make sure they sync immediately. I like to have Google Drive boot on system startup so it's one less thing I have to do before I start Blue Iris.

Step 4 (Optional) - Configure Remote Access

Remote access consists of two things, the Blue Iris web server and a DNS host. Be aware this does increase the attack surface of your network so always use strong passwords and understand that nothing is ever completely secure. If you aren’t actively using your security system or planning on remotely accessing your cameras I would not run the Blue Iris web server unless you absolutely have to.
  • Go to Blue Iris options and select the Web Server tab. Use the 'Find address now' button or Google to find your public IP address. Choose a port number which is not being used on your laptop. I like to choose something not obvious (80, 443, etc.) however this is just an obfuscation technique and is not truly security. Add your local and external IP address as well.
  • Create a Blue Iris user and strong password which you can use to login remotely:
  • Login to your router and forward the port number you just configured for the web server: You should now be able to remotely access the Blue Iris login page from the external IP and port you configured previously. What if your public IP changes? Use dynamic DNS. There are many good free DNS options out there, I chose FreeDNS.
  • Create an account at FreeDNS, add a subdomain, and download a dynamic DNS client such as FreeDNS Update. Add your FreeDNS account information in the settings tab. You will want this running whenever you want to remotely access your cameras.

    You can now remotely access the Blue Iris login page remotely from your own domain on the port you configured in the Web Server tab:

Done! So before I leave the house I turn on the system by using the 'traffic signal' in Blue Iris and setting it to green. There is an option in Blue Iris to define the amount of time before motion detection and recording occurs. I have that option set to around 5 minutes so it doesn't start recording me leaving the house and send unnecessary sms and e-mail alerts. So before I leave my house I have my laptop running Blue Iris, Google Drive, and FreeDNS Update. I usually try to put the laptop in a place which isn't obvious so there is less chance of it being stolen if someone did break in. My laptop uses a Core i5-2410M CPU at 2.3GHz and usually runs around 10-30% load with everything running. Because of this you want to make sure your laptop is always plugged in and its power settings are configured to never sleep, hibernate, or shut down the hard drive.

I now have a custom security solution which was a fairly cheap investment. Please let me know if you have any questions, comments, or if this was helpful.