Archive for the ‘Uncategorized’ Category

Netgear r7000 Command Injection Temporary Workaround

Sunday, December 11th, 2016

On Friday CERT issued a warning about the Netgear r7000 and R6400 lines of routers. They are vulnerable to a trivial, unauthenticated command injection via the internal-facing HTTP administrative interface.

proof_of_vuln

Yeah, that’s almost as bad as it gets.

There’s plenty of other reporting for confirmation, exploit info, and further details. However, CERT’s official guidance is, well, not all that practical for a lot of people:

The CERT/CC is currently unaware of a practical solution to this problem and recommends the following workaround: Discontinue use”

Since Netgear is so far mum on when they’re going to issue a patch, and not everyone has the luxury of getting a new router or doing without indefinitely, there are a couple of workarounds. The first is to use the vulnerability itself to kill the admin web interface; that appears to work, though the router will become vulnerable again next time it reboots.

A better solution is to migrate clients to a network that has no access to the admin interface. The r7000 at least (I can’t speak for other lines) has the ability to make guest wireless networks; since the guest networks have no access by default to the admin web interface, clients on those networks can’t be used to exploit it. This won’t work to isolate clients that physically plug into the router. Also, if you’re currently using the guest network feature for isolating some machines from others, then you all get to be on one network until a patch comes out.

So, as a temporary workaround, we can rename and hide the “main” network and create a new guest network using the same configuration options as the old main network. Clients will see the new one and migrate to it.

Step 1: Physically Connect to the Router

Physically plug your machine into the back of the router; we’re going to be messing with the wireless networks, you don’t want to lose access in the middle. Access the admin console (http://[router-address]/, where your router address is probably 192.168.1.1 or 10.0.0.1), and log in using your credentials (admin/password if you haven’t changed it… which you should have).

Step 2: Record The Configuration

Browse to the “Wireless” tab on the left and copy down details of your primary wireless network. You’ll use these to configure the new guest network.

Step 3: Disable Main Wireless Network

Still on the Wireless tab, change the “Name (SSID)” of the network(s) (both if you’re using both 2.4GHz and 5GHz) to something like DONOTUSE. It’s not necessary, but unchecking “Enable SSID Broadcast” will prevent it from cluttering up your network view. Hit apply, and wait for the change to apply and the page to reload.

disable_primary_network

Step 4: Configure and Enable Guest Networks

Browse to the “Guest Network” tab on the left and fill in the details you copied down from the primary page. Ensure that “Enable Guest Network” is checked, and “Allow guests to see eachother and access my local network” is unchecked.  Hit apply, and wait for the change to apply and the page to reload.

guest_network_config

 

Now, any clients will transparently migrate to the new guest networks, and clients on those networks won’t be able to exploit the vulnerability.

So, it’s something, but keep watching for an official patch.

Sort()ing out a Nerdsnipe

Saturday, October 1st, 2016

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. https://swisshttp.blogspot.ch/2016/10/latacora-riddle.html


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.

latacora_home

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

original_javascript

Now, these are the same folks who put together the Matasano Crypto challenges and Starfighters.io, 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.

test-code

test-results

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.

instrumented_sort

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:

test-results

(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:

test-results-with4

(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”

Tuesday, September 13th, 2016

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.