Sort()ing out a Nerdsnipe

October 1st, 2016 by Patrick Thomas

First, a disclaimer: this is really stupid stuff, and basically the opposite of work worth doing. But still, I got nerdsniped and the resulting rabbit hole went somewhere interesting, so I figured I’d write it up.

Update 10/2: Someone else got bit by the same bug. @swisshttp took a deeper dive, into the implementation details of different scripting engines.

The new security startup Latacora uses a small piece of javascript to randomize the names of the founders in the first paragraph. It seems like a reasonable & egalitarian thing to do, but after idly hitting F5 a few times (like you do…) I noticed that it’s not really random.


So, I went looking for the code that does the randomizing. It’s at the bottom and looks like:


Now, these are the same folks who put together the Matasano Crypto challenges and, so something like that would not at all be out of the realm of possibility. And, whether intentional or not (hey, I said this whole rabbit hole was dumb), if test it (Gist)we find that the results are anything but random.



So, what gives? Is it in the call(s) to Math.random as the comment teases, or elsewhere? The code is really simple looking. Now, we hold as an article of faith that you cannot trust Javascript’s Math.random() (thanks @ropnop for the pointer), but there doesn’t seem to be any funny business with the seed or anything that might suggest actually messing with the generator. Plus, we’re not looking for a small bias, we’re looking for something really significant.

Could the issue be in the anonymous function passed to sort? Nope, not really. It correctly fulfills the contract expected by a custom sort function (return negative, 0, or positive number based on intended ordering of the compared values) , and the body of the function does what it says (implies) on the tin: returns each of those values close-enough-to-randomly, regardless of input.

Could it be something weird in the use of “ceil” to integerize the random number? That could create a small bias given the domain of Math.random, but again we’re looking for something that causes a huge bias.

Spoilers below – if you want to reason through this yourself, go ahead and do it, then come back.

No, the actual cause is both more subtle and more interesting. It’s actually in interaction of the implementation of Array.sort and the anonymous compare function. Several things are going on here:

  • the sort implementation (either quicksort or insertion sort in Chrome – I’m assuming insertion sort for an array this small and based on the observed behavior below ) assumes that the custom sort function passed into it does a sane comparison
  • the sort implementation moves left to right through the array
  • each comparison between two elements has 3 possible values (-1, 0, 1)
  • the sort operation is unstable (edit: this operation is stable. I misinterpreted the docs and how stability interacts with the random comparator. Thanks @fzzfzzfzzz)

So, there is no “correct” ordering of the array: the sorting algorithm isn’t checking to ensure that compares have a transitive property (nor should it). The result is not so much a true “sort” as a series of probabilistic changes of position.

I refactored the code a little bit to do a poor-man’s implementation of instrumenting the sort function (Gist). Here are three runs of it. Notice that that the only way Erin *doesn’t* get bumped is if she “loses” the first compare. A “win” (compare result of -1) does not result in a swap because of the intent of the sort function, and a “tie” (compare result of 0) is never rechecked because the sort implementation does not guarantee a stable result.


In effect: Someone starting in a given position has (1/3)^n chance of being bumped “n” positions in the array.

So, that explains why Erin gets to be first more often than expected, and why Thomas gets to be second. Here’s the breakdown of that math:


(1/3)^1 = .33333 ~= % of time Erin is bumped to position 1
(1/3)^2 = .11111 ~= % of time Erin is bumped to position 2

As expected, the pattern holds up if we add a “Dummy” to the end of the list:


(1/3)^3 = .037 ~= % of time Erin is bumped to position 3


So… there you have it. It’s a (probably unintended) nerdsnipe that nonetheless took us into some interesting territory. Hope you had fun. Did I miss something or explain it wrong? Lemme know in the comments or on twitter (@coffeetocode).

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.


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:

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?