On Pentesting, Professionalism, & “Chill”

September 13th, 2016 by Patrick Thomas

After a recent penetration test report-out call with a client, I asked my interns if anything from the call surprised them. ChillOne of them noted that he was surprised how “chill” the call was. That was interesting to me because it reminded me that I had thought the exact same thing when I first got into consulting and pentesting. It’s easy to see how a readout call could be an incredibly tense, combative affair but in my experience the best pentesters manage to not only avoid that but reverse it.

The mood of the report-out call is an excellent barometer for something that’s critical, and often lacking, in our industry: a constructive relationship between the red team and blue team. While critical, it’s also subtle, and creating the conditions for a good relationship is a process that requires real work and empathy for everyone at the table. My advice: Start Early, Be Meticulously Professional, and Remember the Goal.

Start Early

If the goal is a relaxed, productive, (even “fun”) readout call, then the groundwork must start early. While there are other things that come before it, a detailed kickoff is really the first big chance to get moving in the right direction. As a tester your goal should be to make sure that everyone is clear and comfortable with what’s about to happen, and what exactly the client hopes to get out of it. The behavior ends up being a combination of a lot of standard questions, and sniffing around for any hint that there are either concerns or complexities going unaddressed. It’s also important at this point to really understand context from the client’s view. What’s a critical vs. a high or medium? What do they care less about than you might expect them to? Why? The more understanding you have now, the more that the entire report can be placed in context. If it feels like you’re facilitating a group therapy session where the clients are sharing their (security-relevant) hopes and their fears, then you’re probably doing something right. My team literally asks questions like “what keeps you up at night?” and “what’s the scariest thing we could do here?” Asking the big questions frankly and early helps take the elephant out of the room and moves toward productive discussion of the big questions rather than tentatively working up to them through peripheral issues.

Aside from the kickoff meeting itself, “start early” means start doing things well now so that you have a buffer of goodwill to draw on later. I’ve heard it called an “emotional bank account”: make people feel good about you, make a deposit; let them down, make a withdrawal. Ideally you always want that balance going up, but when something happens (and it’s definitely going to), you want to make sure that you’ve got a nice buffer of goodwill so that it’s understood that it was a blip in an otherwise solid relationship. Neil Gaiman once explained that people keep working because their work is good, they’re pleasant to work with, and because they deliver on time. But the secret, he says, is that it only takes two out of the three. Different people are going to be able to take a different two for granted, but know that if you always shoot for all three you’ve bought yourself some leeway if something happens.

Be Meticulously Professional

Beyond simply good will, one of the important reasons clients call in pentesters (or consultants of any kind) is to get that feeling that they’re in good hands; that someone is going to make sure that messy, complex things get taken care of properly. We’re expected to drop into situations where deadlines, resources, or nerves are already in trouble and provide some useful answers and confidence that the “Right Things” are being done. So, standard consulting practices like “Communicate well and often”, and “Don’t surprise people” apply, of course.  

But one area that security folks sometimes struggle with is ego. There typically are already plenty of personalities and internal politics involved; that makes it critical for us as outsiders to not bring further ego into the situation.

This ego can take a few forms. The first is a tendency toward fearmongering and overselling findings; wanting to be perceived as one of those “scary hacker types”. That can be helpful (to a point) for establishing technical credibility but it’s important to realize that being cool isn’t in the job description. Likewise, neither is taking credit or passing blame. Remember: Amateurs get credit, professionals get paid. The rule for blame is similar: as in the airport in Fight Club, never imply ownership of the bug. If the goal is to make something more secure, it’s rarely relevant who exactly created a bug when it’s likely process, tooling, or training that really needs to change.   

Remember The Goal

This leads into another place that unhelpful ego pops up: security absolutism.

I hear security absolutism in language like “Windows sucks because…” or “Well, actually there’s no point in fixing that because hackers could still…” (or really anytime someone starts handwaving about esoteric TLS attacks or Van Eck phreaking … you know the type).  

Real professionals need to be able to set aside the hacker mindset long enough to have productive, nuanced discussions about how to fix things. There are rarely perfect solutions, and the imperfect ones come with tradeoffs. We should all be willing to be as pragmatic on defense as we are on offense. The perception that security people are going to naysay or ridicule every suggestion hurts all of us, and makes us less effective as an industry. The “Nick Burns” mentality is a self-reinforcing stereotype we need to fight against at each encounter. Similarly, there’s an odor of superiority that often comes off some pentesters when they break a thing and speak about it publicly, as if that somehow demonstrates that they are smarter than the person who designed it. Sometimes a thing is *so* bad that an example must be made, but for my tastes those instances are far more rare than twitter and blogs would make you think.    

Even if a client is a pain to work with, doesn’t take good advice, and fights you on everything, they made at least one smart call: they asked for help. The better we’re able to appreciate that, understand their perspective, and work toward improving the system, the better the relationship and better the results. I’ll feel happier about our industry when dev and ops actually look forward to their calls with security folks, and I’ll tell you this: life’s a lot better when we look forward to them too. So remember; be professional, be empathetic, be helpful — and be chill.

How I Use Firefox as a Web App Pentesting Browser

April 3rd, 2016 by Patrick Thomas

I’m spending more of my time these days helping other people be effective at security testing applications, and as part of that I’m a huge fan of “over the shoulder” mentoring. Some of the most useful things that I’ve learned from others are not things they thought to mention, but rather those moments of “hey, back up a second — what was that thing you just did?“. Sometimes it’s commands or small utility tools, shortcut keys or capabilities of a program I didn’t know about, or just some quick and dirty technique that someone uses all the time but doesn’t think is special enough to talk about.

To that end, here’s a quick walkthrough of the broad strokes of how I set up Firefox for use in testing. My preferred testing setup is Firefox through Burp: the simplest setup is going to be useful, but there are a lot of small configuration details that can help a stock Firefox become even more of a pentesting asset.

Use Profiles

To test authentication and authorization issues you’re really going to need two browsers open at the same time, in different principal contexts (such “User”/”Admin”, “Tenant1″/”Tenant2″, and the ever populated “Unauthenticated”). Then, when you notice something that might have horizontal or vertical privilege issues, you can simple paste the request into the other browser, or swap cookies between your two active browsers. I prefer to run both through the same Burp instance so that I can easily diff or replay between equivalent requests/responses for different principals.

That’s where profiles come in. Normally when you launch Firefox it’ll give you multiple windows that share a common profile; however, if you launch with special command line flags, you can run two completely separate profiles at the same time. To create and manage profiles, launch Firefox Profile manager by adding the Profile Manager flag:

firefox -no-remote -ProfileManager

After creating different profiles, you can create shortcuts to launch them directly, eg:

"C:\path\to\firefox.exe" -no-remote -profile "C:\path\to\Mozilla\Firefox\Profiles\Assess1"
"C:\path\to\firefox.exe" -no-remote -profile "C:\path\to\Mozilla\Firefox\Profiles\Assess2"

To keep track of which is which, both visually and in Burp, I add a contrasting color themes (such as blue and red) and use a plugin to ensure that each sends an identifying header (see plugins section).

firefox testing config

As a sidenote to auth testing, I’m really excited about the AuthMatrix Burp Plugin. I haven’t gotten to properly put it through its paces yet, but more info to come when I have an informed opinion.

Plugins

Firefox Add-On collection that includes a lot of tools mentioned below and that you may find useful during a penetration test.

Some specific plugins you’ll definitely want:

And a couple other pieces of functionality which can be filled by various plugins:

  • Manage proxy settings:
    • FoxyProxy
    • ProxySelector
  • Change User Agents
    • UserAgentSwitcher
  • Simplify JS and JSON
    • JSONView
    • Javascript Deminifier
  • Passively detect remote technologies:
    • Wappalyzer
  • Fetch lots of content at once:
    • DownThemAll!
  • Interact with REST services:
  • RESTClient (although Chrome’s Postman is better, SoapUI is quite serviceable, and Burp will also work)

For Foxyproxy, I like to just blacklist a bunch of domains right in the browser so that they’ll never get passed to the proxy. This keeps the Burp request history cleaner and means I don’t have to make too many assumptions in Burp about what hosts an application will talk to (It also means you won’t have to reconfigure Firefox for each engagement to keep it clean). If the browser is too chatty through Burp you risk losing some valuable information when you rely on “Show only in-scope items”.
foxyproxy blacklist

 

When advertising and tracking domains are out of scope, you can also load large lists of advertisers and blacklist those from your proxy to keep the burp state even trimmer.

I use the ModifyHeaders plugin to send a unique header from each browser profile (eg, “BrowserProfile: AssessRed”). This helps me keep track in Burp during my testing, and it can also seriously help with potential client issues when they can easily identify and (hopefully) rule out your traffic as a potential cause of a problem.

Disable Chatty Features

Speaking of chatty features, you’ll probably want to disable a bunch of automatic/implicit traffic that could bloat your Burp state or create red herrings in testing: https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections

You’ll also want to tweak some settings in about:config to prevent both chatty traffic and sending potentially sensitive client URLs to public antimalware lists:

browser.safebrowsing.enabled -> false
browser.safebrowsing.malware.enabled -> false

A Few Words on Chrome

You can do a lot of this with Chrome. It supports profiles, has many approximately equivalent plugins, and can be configured to not use the system proxy by installing proxy manager plugins. That said, it feels like you have to work harder to make Chrome play nice in a pentesting environment. YMMV.

Burp Testing Profile

Although it’s not related to Firefox, one thing that I notice biting a lot of people is that they don’t load a consistent profile. Every single new test I do starts with a standard, clean burp state file with all of my preferences loaded in it. I just copy “InitialEngagementBurpState.burp” into my notes directory, load it in, and know that I’m getting all my standard preferences such as autosave (every hour (!) and into a directory that I can regularly clean up), logging, plugin config, etc. I’ve seen colleagues forget this on back to back tests and lose their first day of testing each time because they didn’t manually enable the autosave and hit a crash. (Update Sept 2016: this is less relevant now with Burp’s new project file feature. I’m still figuring out if there are any gotchas in it, but it really helps persisting defaults and making it harder to be dumb.)

What about you?

What did I miss? Some favorite plugin, or special approach? What’s unique about your own setup that you take some pride in?

 

BlackHat USA Multipath TCP Tool Release & Audience Challenge

August 6th, 2014 by Patrick Thomas

(Crossposting & backdating some content from the Neohapsis blog, which will soon be defunct)

We hope everyone found something interesting in our talk today on Multipath TCP. We’ve posted the tools and documents mentioned in the talk at:

https://github.com/Neohapsis/mptcp-abuse

Update (Aug 12, 2014): We’ve now also added the slides from the talk.


At the end we invited participants to explore MPTCP in a little more depth via a PCAP challenge.

Without further ado, here’s the PCAP: neohapsis_mptcp_challenge.pcapng

It’s a simple scenario: one MPTCP-capable machine sending data to another. The challenge is “simply” to reassemble and recover the original data. The data itself is not complex so you should be able to tell if you’re on the right track, but getting it exactly right will require some understanding of how MPTCP works.

If you think you have it, tweet us and follow us (@secvalve and @coffeetocode) and we’ll PM you to check your solution. You can also ask for questions/clarifications on twitter; use #BHMPTCP so others can follow along. Winner snags a $100 Amazon gift card!

Hints #0:

  • The latest version of Wireshark supports decoding mptcp options (see “tcp.options.mptcp”).
  • The scapy version in the git repo is based on Nicolas Maitre’s and supports decoding mptcp options. It will help although you don’t strictly need it.
  • The is an mptcp option field to tell the receiver how a tcp packet fits into the overall logical mptcp data flow (what it is and how it works is an exercise for the user🙂 )
  • It’s possible to get close with techniques that don’t fully understand MPTCP (you’ll know you’re close). However the full solution should match exactly (we’ll use md5sum)

Depending on how people do and questions we get, we’ll update here with a few more hints tonight or tomorrow. Once we’ve got a winner, we’ll post the solution and code examples.

Update: Winners and Solution

We have some winners! Late last night @cozinuzo contacted us with a correct answer, and early this morning @darkfiberiru got it too.

The challenge was created using our fragmenter PoC tool, pushing to a netcat opened socket on an MPTCP-aware destination host:

python mptcp_fragmenter.py -n 9 --file=MPTCP.jpg --first_src_port 46548 -p 3000 192.168.1.33

The key to this exercise was to look at the mechanism that MPTCP uses to tell how a particular packet fits into the overall data flow. You can see that field in Wireshark as tcp.options.mptcp.dataseqno, or in mptcp-capable scapy as packet[TCPOption_MP].mptcp.dsn.

mptcp_wireshark_column

 

 

The mptcp-capable scapy in our mptcp-abuse git repo can easily do the reassembly across all the streams using this field.

Here’s the code (or as a Gist):

# Uses Nicolas Maitre's MPTCP-capable scapy impl, so that should be
# on the python path, or run this from a directory containing that "scapy" dir
from scapy.all import *

packets = rdpcap("pcaps/neohapsis_mptcp_challenge.pcap")
payload_packets = [p for p in packets if TCP in p
                   and p[IP].src in ("192.168.1.26", "192.168.1.33")
                   and TCPOption_MP in p
                   and p[TCPOption_MP].mptcp.subtype == 2
                   and Raw in p]

f = open("out.jpg", "w")

for p in sorted(payload_packets, key=lambda p: p[TCPOption_MP].mptcp.dsn):
 f.write(p.load)
f.close()

These reassemble to create this image:

 

mptcp

 

 

The md5sum for the image is 4aacab314ee1a7dc5d73a030067ae0f0, so you’ll know you’ve correctly put the stream back together if your file matches that.

Thanks to everyone who took a crack at it, discussed, and asked questions!