The S3 Bucket Problem - The Latest Vuln to Become Popular

Yes, yes, I'm late to the party, I know. Poorly secured Amazon S3 buckets have been a thing for a while now, but recently there's been a large uptick again as some awesome tools were written to help find these misconfigured buckets. Let's chat a little about the problem at hand and show-off some cool tools!

Why all the drama about S3 Buckets?

For the uninitiated, Amazon Web Services offers a service called S3. S3, for lack of a better definition, is a web-based storage solution. It's not a database. It's not a key-value store. It's literally a place to store files (Amazon calls it a cloud object storage). In fact, it's closer to Google Drive and Dropbox than anything else.

So, this leads the question - "So, what?" I'm glad you asked... You see, AWS is a very popular platform to host all sorts of things (servers, applications, storage, you name it and Amazon probably has an AWS service for it). For the longest time, AWS had very poor default permissions on a newly created S3 Bucket (an S3 instance is called a bucket). This meant anyone with a web browser and the ability to guess what you named your S3 Bucket could view, download, and even add new files to your S3 Bucket.

Organizations were hosting all sorts of interesting files in their S3 buckets. We've seen everything from flat-files (CSVs, Documents, Excel Sheets) to full database backup files. The only thing protecting someone from having their files stolen was guessing the name of their bucket. Once people got wind of this, we started seeing a handful of dictionary-based bruteforcers then the intelligent bruteforcers and now tools that detect when a bucket is created due to the HTTPS certificate being created. The InfoSec community really brought their A-Game to this party.

You mentioned tools...?

We'll start basic and move our way up. If you're a bug hunter or just dabble in bug bounties in your spare time, I would highly suggest looking into S3 Bucket problems (especially if the target uses AWS to host their application).

Bruteforce tools. These are nothing out of the ordinary. They take a dictionary and bruteforce if that word has an associated S3 Bucket (and will see if it is configured wrong). I've tried my best to be language agnostic with these tools, so pick the language of your choice.

• https://github.com/gwen001/s3-buckets-finder (PHP?? Yeah, that's still a thing)
• https://github.com/Ucnt/aws-s3-bruteforce (Python)
• https://github.com/nahamsec/lazys3 (Ruby)

Certificate scanning tools. These watch for new HTTPS certificates being created (thank you, CertStream) and filter everything out except for S3 Buckets. They then test if the S3 Bucket is world-readable. They're truly magical.

• https://github.com/eth0izzle/bucket-stream (Python)
• https://github.com/bbb31/slurp (Go)

Obviously, in specific engagements there are upsides to testing a curated dictionary of words, but in other situations, it may be more interesting to see a real-time stream of new insecure buckets being created. I'm willing to bet Threat Intelligence companies will be eating this data and alerting based on keywords in the near future.

Fixing insecure buckets

Like all of my previous posts, I always try to include a section on remediating the discussed risk. So, let's do just that.

You will need access to your organization's AWS management console and an account with enough permission to administrate your S3 buckets.

1. Sign into your AWS management console
2. Navigate to Amazon S3 (using search or the option under the millions of services)
3. In the bucket listing, ensure none say Public under Access
4. For a bucket you want to remove public access, click the bucket name, then click the Permissions tab
5. Under Public Access, ensure there are no permissions granted (refer to image below)
   

Conclusions

"The cloud" can be truly revolutionary, but we've got to work on better default configurations so it is harder for people to make these mistakes. I have always been a big fan of stricter default security policies - Yes, I know this may make some users frustrated that they need to configure your product instead of just install and go. But consider the security implications of a 3-Letter agency letting classified information be leaked due to a poorly configured S3 Bucket (Source: https://www.upguard.com/breaches/cloud-leak-inscom). Yes, that did indeed happen.

Thanks for making it this far -- Got something to say or wanna correct my inane rambling? Post it below.

Subdomain Takeover - Preventing the PR Disaster

I've been meaning to write about this for a while now, but I never took the time to make it happen. So, here we go... Hope it turns out like I was expecting!

What is Subdomain Takeover?

Subdomain takeover has become a popular security topic due to the increasing prevalence of Bug Bounties and how easy it is to detect. Plenty of people have written scripts to check for this issue:

• https://github.com/nahamsec/HostileSubBruteforcer
• https://github.com/haccer/subjack
• https://github.com/michenriksen/aquatone

Simply put, subdomain takeover is a type of DNS misconfiguration where a DNS entry (a CNAME record) points to another site where that domain is no longer registered. For example, let's assume you own myimportantbusiness.com and your important business has a blog. Your blog is located at blog.myimportantbusiness.com but is hosted on Google's Blogger platform. Your business decides you'd rather switch over to Wordpress (cause Wordpress is what everyone else in the industry is using) and your important business blog is now located at wordpress.myimportantbusiness.com.

Your network administrator never removed blog.myimportantbusiness.com but instead just made a new DNS entry. Your web content team deleted the old Blogger blog and migrated the content to Wordpress. Now when you navigate to blog.myimportantbusiness.com you see a Blogger error stating that blog is not registered.

This is where the problem lies. Anyone else on the internet can now go re-register your company's old blog and now technically owns blog.myimportantbusiness.com. They can post whatever rude, malicious, or potentially incriminating content under your the guise of your domain.

How do we exploit this?

Unfortunately, this is the complicated part. Not all dangling subdomains can be exploited as it requires the target service to allow you to re-register the old entry. For example, many CDNs won't let you re-register a service without proving you own the domain. The short answer is: You need to check out where the subdomain is pointing to and determine if you can re-register the old entry. Not a great answer, I know.

The good part though: Others have already made lists of common services which people tend to leave old DNS entries for and can even automatically re-register the entry to your account. A few examples:

• AWS Cloudfront
• Heroku
• Zendesk
• Tumblr/Blogger/Wordpress.com

I linked to a collection of tools above which can assist in determining if a subdomain is vulnerable.

How do we fix these problems?

Quick Solution: Remove the DNS entry -- This works for most situations

Longer Term Solution: Define a policy where whomever manages DNS at your organization performs a regular audit of your DNS entries. Yes, this can be tedious, but it can ensure your DNS records are up-to-date.

Conclusions

While subdomain takeover isn't anything sexy or technically complicated or cool, it is a serious problem facing organizations large and small. Just go search Google for "site:hackerone.com subdomain takeover" - Check out all the results.

Thanks for making it this far. Did I miss something? Let me know below.

CSAW CTF 2017 - Web 150 Write-Up [Shia Labeouf-off!]

It was about time for something a little bit different around here, so here's my write-up for the CSAW CTF 2017 -- Web 150 challenge titled Shia Labeouf-off! Hope it's as enjoyable to read as I enjoyed solving it.

From the start, we are given very little as many CTFs do. We're directed to a URL running a rather ridiculous webapp about the man, the myth, the legend... Shia Labeouf...

The Strategy

I clicked all the links and watched the traffic in Burp Suite to see if anything interesting was taking place. For the most part, everything was rather boring. I began fuzzing random input in the ad-lib generator when I stumbled upon the first clue, a Django debug page.

Based on the error, I figured we were dealing with SSTI (Server-Side Template Injection). I have read posts prior to this on Flask Jinja template injection, but I had never read anything about Django's template system being injectable. In fact, I was under the impression Django was pretty solid (as a web framework goes...).

After digging through this debug page, I noticed the load pools_extras statement on line 3 of the debug output. I had no idea what that line did, so I started digging into the Django docs. That digging led me to finding this Django doc: https://docs.djangoproject.com/en/1.11/howto/custom-template-tags/

Turns out you can define custom template tags in Django and then use them once you've loaded that specific module. The problem is that you need the source code from the custom template tag module to know what the name of the custom tags are.

The Solution

This led me down a horrible side-path that went absolutely nowhere. I tried finding a .git directory assuming there might be a git repository we needed to use to find something else. This was a complete waste of time, but it allowed me to accidentally find another Django error page which was helpful. The polls section of the web app numbers each poll. If you specify a poll number greater than 2, you get a very helpful error page.

Scrolling down this page, you eventually find an exception that occurs in pools_extras.py which is the file we need to see the source code for. Django kindly allows you to expand the source code of the problematic code and now we have the info we need!

We can see there are a few custom template tags that are defined for us: getme, checknum, listme. Based on the Django docs earlier, these tags can be used in the ad-lib generator to potentially get us somewhere. The problem is that when you go back and re-read the docs, you can only apply a custom tag to a predefined Django Template Context variable. Again, I hit the wall... 

The example from the Django docs. Custom tags are applied to a predefined variable via the pipe character. Ughhhh...

I began pouring over the original Django error page again and found something rather odd. See if you can notice it as well.

Sorry to ruin the surprise if you didn't catch it, but what the actual hell is mrpoopy which is defined in the RequestContext object. Rick and Morty always seems to randomly appear lately... So, what the hell is inside this object?? Let's use one of those fancy custom template tags to find out, shall we?

The payload: {{ mrpoopy|listme }}

So, it appears there are a few attributes of mrpoopy and they are: Woohoo, __doc__, __flag__, __module__. I'm sure you can see where this is going at this point. We have the flag right in front of our faces! Sure enough, there's another custom tag to get an attribute, so let's see what happens...

The payload: {{ mrpoopy|getme:"__flag__" }}

And there you have it, SSTI of Custom Django Template Tags leads us to obtaining a flag. The hardest part of this one was figuring out the syntax for applying a custom tag. It's really quite odd.

Hope you enjoyed the play-by-play of solving Web 150 of CSAW 2017. I hope to do more of these as time permits!

Getting that RCE When Filtering Gets in Your Way

Another quickly thrown together blog post. Life's been busy, and therefore the blog has unfortunately been thrown on the back burner. But fear not, I had a fun run-in with some remote command execution that lead me down a horrible rabbit hole. I figured if I spent a ton of time on it, others might get similarly stuck. So, without further ado... Let's jump into this madness.

The Scenario

You find yourself in a situation where you KNOW you have command injection / command execution, but a WAF or the code itself is stripping a subset of characters. In my situation, I was having all forms of slashes (/ and \) being removed from my request. At the same time, ModSecurity was blocking obnoxiously long payloads as well. So, why was this a problem? In order to bump the severity of the command execution, I NEEDED a reverse shell. No one cares if you can inject a boring sleep 99 command, and I realized this.

Fun fact, a lot of reverse shells rely on slash characters. And when you're a useless hacker like myself, you have a go-to cheatsheet: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

Shout out to pentestmonkey for keeping that reference alive. It has given me so many reverse shells in the past that I can't thank them enough.

The Exploit

I spent quite a bit of time trying whip out my bash-fu and do some in-line slash replacement. Turns out this is messier than some of those reverse shells (looking at you PERL). Also, it never worked. In fact, never ever try it. It's just a bad idea. But that in-line slash replacement did lead me down an interesting path that created the AHA moment. That AHA moment was when I found myself base64 encoding the slash character to perform that nasty in-line replacement junk.

My face when I realized that base64 was the answer...

It took a second of screwing about until I realized, why not just base64 encode the bloody reverse shell payload?!?!?! Needless to say, this worked quite elegantly. I did realize after the fact that I got lucky my payload didn't contain a slash as base64 can contain slashes, but you can also hex encode your payload as well. Shown below is my multiple hours of fumbling about and the payload that ended up working.

If base64 is not available for whatever reason, you can also use xxd with a hex-encoded payload to the exact same effect.

Hope someone found this interesting and potentially helpful. Feel free to post questions below!

Checking NuGet Packages for Security Vulnerabilities

Another quick post on scanning projects for vulnerabilities using a quick and easy tool. End of the day, these are super quick wins for a security audit as you can identify packages that either need to be removed or should be updated to a newer version. Lame? Maybe. However, these are the small problems that can be chained with a worse vulnerability to lead to a potential critical vulnerability. I personally try my best to never lose sight of the low-hanging fruit (aka never forget the low severity issues, they matter too!).

So, let's get into the actual interesting part of this post. I'm going to outline a scenario for when using this workflow might make sense, but this likely isn't the ONLY situation when this workflow will be useful.

The Scenario

You've been asked to do a security review of a new .NET web project. You've been given the source code, and you're expected to get a security review done ASAP. One of the easiest wins is to check whether the packages being used contain known vulnerabilities. If so, that's sure as hell a finding!

Technical Details

In general, most .NET projects (C#, Visual C++, ASP.NET, etc) use Nuget to handle external dependency management. Simply put, Nuget is like PIP for Python, SBT for Scala, NPM for NodeJS, and the list goes on. Like all package management systems, there's absolutely no auto-updating of dependencies because THAT MIGHT BREAK THE BUILD. So, how do we audit the external dependencies of a .NET project? Let me introduce you to DevAudit.

DevAudit offers a TON of options, but I specifically use it to audit Nuget packages for .NET applications. You're highly encouraged to check out the other features of DevAudit, but for the purpose of this post, I will be focusing on the Nuget audit features.

Auditing a Project

NOTE: For once, I will be making a huge assumption you are using Powershell on a newer version of Windows. DevAudit, in my tests, runs best on Windows. You can get it to work on Linux, but you will need to figure out .NET Core shenanigans which has arguably gotten easier as of lately.

Grab the latest version of DevAudit from their releases section of Github. Open up your trusty Powershell console, and run the following command.

That little snippet will add the DevAudit directory to your Powershell path so it's less painful to run the program. Using Powershell, navigate into your project's directory and locate the Packages.config file. This is the file that contains the list of Nuget packages used in the project and the version used. This also happens to be the file DevAudit needs to audit the project. Be sure to be in the same directory as the Packages.config file.

Now simply run, devaudit.exe nuget . -- I've included some sample output from a random project I pulled off Github.

That simple. The report is color-coded, but Github Gists can't capture that. Sorry. Overall, I found this tool to be incredibly easy to use and provided incredibly helpful output for a recent assessment. Hopefully someone else benefits from using this tool.

Suggestions, comments? Post 'em below!

Auditing Your NodeJS Packages for Security Vulns

I know, another post so soon after the previous. I am just as shocked as you are. But all nonsense aside, let's talk about some fun tools to audit the packages in a NodeJS application in search of publicly known security vulnerabilities.

I was recently tasked with auditing a NodeJS application and like all technologies I'm not terribly comfortable with, I immediately look for the low-hanging fruit to start. I knew of npm (Node Package Manager), but I wasn't really sure how NodeJS apps laid out their required packages. Needless to say, I learned quickly that packages are typically stored in a package.json / npm-shrinkwrap.json in the root of the project directory.

But I ran into a snag. The package.json file was huge for this project. This led to the inevitable question of how can I possibly review every single one of these packages?? And kids, this is where automation is your friend. I did some searching, and I found two pretty solid tools that will automatically scan your NodeJS packages and search for packages with known vulnerabilities. It's so simple, one of them includes steps on how to integrate with your CI system (if desired).

Enter the tools...

For the purpose of this post, I will be covering two separate tools used to audit NodeJS packages.

• snyk (https://snyk.io/) - Snyk requires that you install all packages for the project, and then it will scan them looking for known CVEs and advisories using their curated database
• nsp (https://nodesecurity.io/) - NSP scans your project's package.json file and searches for known vulnerabilities using their curated database

In my tests, Snyk seemed to be more accurate likely because I was forced to install the packages which pulls down everything needed (including dependencies of dependencies), but NSP runs much quicker as you don't need to install all the dependencies for a project first.

Using Node Security Platform (nsp)

Using Snyk

Conclusions

In my opinion, the output of Snyk seems to work better for my situations. I like the Snyk vulnerability database links as they always seem to contain very helpful information in all the cases I've used it. Also, I hope you like the Asciinema casts. I've seen them around before, but I never thought to use them until now. 

Feel free to share your thoughts or questions in the comments below.

Deep Dive: Cross-Site Scripting (XSS)

It's been a while since I've written up a new post, so I thought I'd start a new series where I do deep dives into common web application security topics. The thought is to cover a lot of the things you'd typically find in a bug bounty program so that others can jump into them and be successful. I'd love to hear your feedback, so please let me know what you'd like to see more of.

What even is Cross-Site Scripting (XSS)?

There's plenty of definitions floating around on the internet, and you're encouraged to do research of your own. I'm going to try to do my best to simplify the many overly technical definitions down to something straightforward. XSS is when a web server returns user-input in the web response without properly encoding/escaping it. So, you might ask, why is it bad to include user-defined input in a web response? Well, a user can include arbitrary HTML or Javascript in their input which would then get rendered back to the user. This means a malicious user can control what content another user gets rendered back to them when viewing parts of a website. Definitely a scary thought.

What is the impact of XSS?

Since we just learned that a user can control parts of a web response, what can we do from there? Well, a malicious user can take advantage of an XSS issue to do a variety of things which I'll outline below.

• Steal / manipulate browser cookies
• If a cookie does not specify the HTTPOnly flag, Javascript can view the contents of this cookie and then ship that data off to an attacker's server allowing the attacker to impersonate a user.
• Perform actions on the user's behalf
• Javascript can make arbitrary web requests, so an XSS vulnerability could send targeted web requests that perform sensitive actions on the user's behalf (since the user's session cookie is sent along in Javascript web requests). CSRF mitigation would help stop these kinds of attacks.
• DOS a website
• I don't make take a server down with numerous requests, but that has already been done with nasty Javascript before. You can use malicious Javascript to redirect a user away from a website effectively DOS'ing their website.

At the end of the day, you are limited by what Javascript can do which based on the BeEF toolkit is essentially anything at this point.

Finding an XSS Issue

There's a handful of tools out there to assist you in finding XSS issues in a website, but knowing how to find them by hand can save you when you are without tools or your engagement doesn't allow automated tooling. Some automated tools are:

• OWASP ZAP
• XSSpy
• w3af

In general, you are looking for a situation where user-input is being directly reflected back in the response. A web proxy is incredibly helpful in this situation, so you can see exactly what the web server is returning in every response. A few notable web proxies are:

• Burp Suite
• Fiddler
• OWASP ZAP

Now what? Well, you want to see if you can sneak in special HTML characters into a response. I typically try with a strange string like < > ; " ' / 

This will give you an idea of what special characters are being properly encoded, so you can start formulating an attack. In general, you want to be able to inject your own HTML tag or complete an HTML tag and inject a new tag following. Notice in the example below, the user can control the hover text for an image, so you can inject a closing quote / angle bracket and then start your payload.

In other situations, you may be able to control a piece of Javascript in which case you also need to know what characters are being encoded in the response so that you can being formulating an attack. Notice in the example below, a website uses the redirect parameter to define a Javascript redirect. Abusing the redirect parameter allows a malicious user to take full control of the Javascript snippet.

Lastly, my favorite way to get XSS in a website is via SVG images. SVG images are a strange image format that is effectively an XML file containing image data. Fun thing though, you can also define Javascript inside of an SVG as well.

I'm sure you can see where this is going...

If you can find a website that will let you upload an SVG image (and it does NOT process the file), you can typically get free XSS. What do I mean by process the file? Well, if the site does not transform your SVG to a PNG or JPG, you are likely good to go. The only other requirement is that you can force browse to your uploaded image (In Chrome, you right click the image, and choose Open Image in New Tab). If those conditions are met, when you open your malicious image in a new tab you should have had Javascript run. Refer to the snippet below for an example SVG with embedded Javascript.

Now, I fully understand that the examples provided are incredibly basic and not terribly realistic. However, they get the general strategy down and get you thinking about how to start thinking like a malicious user. In most situations, a decent web framework is being used or mod_security will be yelling at you for being rather rude with your web requests. In this case, you always have the OWASP XSS Cheat Sheet. Brutelogic also made a wonderful cheat sheet and a tool for creating an XSS payload.

Fixing an XSS Issue

What recommendations should you make when you submit an XSS bug? Let's be honest, you are an awesome fellow if you include remediation instructions as well as detailed write-up. Resolving XSS isn't always a hard-fast rule. It really depends on a few different factors.

In most cases, encoding all output should resolve most issues. However, what about different encoding schemes? Well, if the user input is being placed in a redirect URL, you should likely URL encode it. If the user input is being placed directly into an HTML tag, you should likely HTML encode it. If by some God awful reason it's being placed into a Javascript snippet, you better Javascript escape it.

Some people like to just remove areas where user-input is being returned in the response. Sometimes this is the easiest fix if the user input does not really need to be returned in the response.

Wrapping Up

After a while, you will start to immediately notice when a website returns back your input in a response. And trust me, you will also find yourself testing special characters in that same website just to see if you should waste your time poking for an XSS issue. End of the day, testing for XSS issues is pretty straightforward when you realize there's a handful of tools and strategies to find these issues quickly.

Why RCE Ruins Days, Weeks, and Products

I was recently testing a product (sorry, can't disclose that part) when I found an issue I've personally never come across before. I've dealt with HTML Injection and SQL Injection (way more common than it should be) before, but I never figured I'd find a project that'd actually give me Code Injection especially in 2016. Oh how wrong I was...

Manually Update Nexus Phone to Android Nougat (7.0)

So what's the big deal with this Android 7.0 Nougat nonsense anyway?? I'm honestly not sure, but I spent about an hour updating two phones this evening. I figured I'd share the steps to sideload the latest Android update in case you are as impatient as I am.

Let's Get Started...

First off, you need a Nexus phone that is actually getting the update. Those are listed below.

• Nexus 5X & 6P
• Nexus 6
• Nexus Player
• Nexus 9 (WiFi / LTE)
• Pixel C

Next, you need to download the OTA (Over-the-Air) image for your respective device. Hop on over to the Android developers page (https://developers.google.com/android/nexus/ota) and download the Android 7.0.0 image for your device.

NOTE: Some links aren't posted yet but are live. Please refer to the Android Police article where they are posting download links to the OTA images on google's servers. (http://www.androidpolice.com/2016/08/23/flash-all-the-things-full-android-7-0-nougat-nexus-ota-roundup/)

Setup ADB

Next, you will need ADB (Android Debug Bridge) which allows your computer to communicate with your phone.

Mac

• Grab Homebrew (http://brew.sh/)
• RUN: brew install android-platform-tools

Windows

Download the minimal ADB/fastboot executable from XDA Developers (http://forum.xda-developers.com/showthread.php?t=2317790)

Prep Your Phone

These steps are specific for the Nexus 5X/6P. Do a quick google search on how to get your respective device into Recovery Mode if the instructions below don't work.

• Power down your phone
• Hold Volume Down, then press and hold the Power button
• Your phone should boot into the bootloader
• Hit Volume Down until you see Recovery Mode selected
• Press the Power button
• Wait for the android with a red exclamation mark to appear
• Hold the Power button and hit Volume Up
• A new recovery screen should show up
• Hit Volume Down until you select Apply update from ADB
• Press the Power button
• Plug your phone into your computer
• Open terminal / command prompt (Windows users, you may need to cd into the directory where the minimal ADB package is located)
• RUN: adb sideload

You should see a progress percentage on your computer and phone. Just wait for everything to finish up, then choose the option to reboot your phone when it completes. And there ya go, Android 7.0 without the wait. Hope it helped or at least kept those of you that are impatient satisfied.

The Wonderful World of SMB/AFP Shares

I was recently involved in a 3-Day Vulnerability Assessment where I had quite literally no idea where to start. I suppose that's to be expected when you're the new guy and thrown into something, but I honestly wasn't sure what to even look for. I fell onto my past knowledge and decided to just wreck anything Windows related (my previous job was a Windows-only environment). I got a few corporate IP-ranges, and I set off... I quite literally nmap'd anything in that corporate IP-range (woops...).

The Recurring Theme

Non-windows boxes had SSH open but locked down enough that I didn't care to dig further. Developers had random HTTP ports open but most were the default Apache page.

 That page mocked me for all 3 days of the event...

But of course, that has nothing to do with the post title, so that can't be why I'm writing this. Look at you, astute reader. Port 445 and 548 were the recurring theme, better yet, an intense nmap scan will even point out that it detected an SMB/AFP share with its associated permissions. How nice! As you can imagine, this was the beginning of the wild ride of internal incident reports and vulnerability findings.

Abusing Open SMB/AFP Shares

The next obvious question is the usual So What? Well, let's jump into some potential pivot tactics one can take with an open SMB/AFP share.

Placing malicious files onto an individual's machine

This should be obvious, but if you have write access to an SMB/AFP share, you can place files onto that person's or server's hard drive. Depending on what files are being shared, you can attempt to swap out binaries that are typically run by Windows/Mac OSX with a meterpreter payload, swap out common programs a user would run with a meterpreter payload, or place an innocuous file on their desktop. The last option would require some social engineering to get the user to run the payload but no doubt still possible.

DOS-ing via hard drive space consumption

Interested in truly ruining someone's day? Well, an open SMB/AFP share with write access gives you the opportunity to fill their hard drive with cat memes until they can't meme no more...

Sensitive information disclosure

Log files, hidden metadata files, and others are juicy even when the SMB/AFP share doesn't have write access. Make copies of any dotfiles or other log files and sift through them later. I'm not going to confirm that I obtained a private key during this exercise, but I will say that they are one of the things you find with this method.

It Gets Even Better

Now that you know a few things you can do with an open SMB/AFP share, let's talk about why this is even worth mentioning. I mean, aren't most SMB/AFP shares on your internal network? Why even worry? Well, glad you asked... Over 90% of the open SMB/AFP shares I found weren't on servers, they were on employee's personal laptops. This means when Jane Smith, employee of Acme Inc., takes their laptop to Starbucks on Sunday that same SMB/AFP share will be hanging out on the network. And we all know that no one at Starbucks is malicious...

The typical Starbucks WiFi user. Kind, fluffy, and obviously not out to steal your dataz.

Wrapping Up

SMB/AFP shares can expose sensitive internal information to the whole wide world when an employee decides to share a folder off their laptop. Also, those internal network shares are only an Ethernet connection away from being stolen as well, so always be sure to lock down open SMB/AFP shares on your internal network. And of course, writable SMB/AFP shares are the definition of asking to be pwned. Creating a system to monitor for file shares is a great mitigation strategy. Using Windows AD/Group Policy to not allow user's to create shares from their laptop is another strategy. General awareness that this is something worth monitoring is really the big takeaway here, so I hope you consider this in your next red team engagement. I'm hoping to put together a tool that allows for efficient scanning of SMB/AFP shares on your network and spewing out a list of open shares with associated permissions. Keep an eye out for that in the coming weeks.

Mobile - Proxying Your Mobile Traffic

Taking a bit of a break from Classic ASP comes mobile security auditing. In this post, I will be showing you how to hook-up Burp Suite to your phone and begin proxying your mobile traffic. This allows a security professional to analyze from a black-box perspective how an app works with its internal API counterpart (and more importantly what can we break with said internal API).

Getting Started

First things first, go snag the free copy of Burp Suite if you don't already have it. This is not a tutorial on using Burp Suite, but I personally swear by it. Do yourself the justice of learning its quirks and grabbing a few must-have extensions. It is a wonderful tool.

Setting Up Burp Suite

Next, let's get Burp listening on another port (which we direct our phone to). Open Burp, click the Proxy tab, then click the Options sub-tab. Click the Add button under Proxy Listeners.

In the pop-up, pick an open port to bind your proxy to (I use 8082). Then select Bind on All Interfaces. On Windows, you may get a firewall warning. Be sure to allow Burp Suite to bind to this network port (otherwise you will go down a whole 'nother firewall rabbit-hole).

Setting Up The Phone (Android)

I will preface this section with the fact that I'm using Android 6.0 for my examples. Older versions of Android have some of these options in different places. Remember, Google is your friend if you need to find that one obscure setting I mention.

First things first, make sure your PC and phone are on the same network (it's okay if one is wired as long as their isn't a subnet difference you should be good). On your phone, open the WiFi menu (Settings > Wi-Fi). If you're already connected to your WiFi, forget the network!

Choose your network, enter the password, and tap Advanced Options. Set the Proxy option to Manual. Enter the IP address of the computer running Burp, enter the port you chose before, and then tap connect.

You should now be connected. You should start seeing traffic in Burp under the Proxy > HTTP History tab. However. the fun doesn't end here! You can only see HTTP traffic as the Burp certificate isn't installed on your phone. Time for the next wrinkle...

Open a browser on your phone and type: http://burp -- If everything is working, you will be presented with a fairly simple Burp Suite page. Tap the link for CA Certificate. Make sure that downloads to your device.

Now, navigate to Settings > Security > Install from Storage. From here, select the certificate you just downloaded. Android may get angry and leave an ever present warning saying your traffic can now be monitored. This is normal. You are snooping on your traffic, soo... They're not far off.

NOTE: In my testing, I needed to rename the cert.der that I obtained from http://burp. The cert file needed to be renamed to cert.cer for the Android certificate manager to understand it as a certificate. You can grab any file manager (I prefer ES File Manager) in order to rename the downloaded file.

Setting Up The Phone (iPhone)

More preface... I do not have an iPhone to snag screenshots from. Sorry. This is all from memory from an iDevice at work.

First things first, make sure your PC and phone are on the same network (it's okay if one is wired as long as their isn't a subnet difference you should be good). Open the WiFi menu (Settings App > WiFi). Connect to the appropriate WiFi network. Now tap the blue-colored icon to the right of the WiFi network name.

On this screen, choose to use a proxy. Enter in the IP Address of your PC. Enter in the port chosen earlier.

Now, open Safari, and navigate to http://burp -- Tap the CA Certificate link. You should be immediately redirected to the Install Certificate page. Choose to the install the certificate. And you're done.

Conclusions

When you finish proxying traffic, be sure to revert all the settings you changed from this post. Leaving a Burp Suite certificate installed on your phone is a horrible idea that I hope doesn't need explaining. Remember, every phone is different, so it's likely this guide will not be perfect. I will happily help if you submit questions in the comments below however.