Slashdot Mirror

should only be surprised that it took this long for this sort of steaming pile to be breached. Or in a way that left enough breadcrumbs for someone to notice, anyway.

Yep, it's really not that hard.

Hack a computer just by typing? Absolutely.

What was the name of this source and what was the name of the computer facility where this breach occurred? ref

No hack would ever result in that kind of control

Disagree.

Lets face it the reality is lots and lots of BIG companies use things like Active Directory. Lots of this BIG companies might even have only a tiny handful of Enterprise Admins, who may even be very good at what they do. Chances are they have centralized and integrated the authentication against AD. Its not uncommon for Network infrastructure administrative interfaces to use an authentication gateway like say NPS (RAIDUS for AD).

So if you could get that Enterprise Admin access, well it might be a house cards from there. Given the recently published MS14-068 it might not even be that hard: https://www.trustedsec.com/dec...

So if you can get your foot in the door, however you do it just grabbing some tools off git hub and few blogs can get you near total ownage without having to do much of anything in the way of exploit development on your own. Consider this vuln was an off cycle patch put out in November, think there ~4 weeks on there are some big orgs that have lead times to get Windows patches applied to DCs longer than that? I would bet so, think an org like Sony stands a chance against a vuln like that when its an unpublished zero day? So get any access to the network at all, brute force one password for basically any user account crack a hash sniffed off the wire etc, and boom your a member of any windows groups you want!

Frankly I would not be surprised given the timing if MS14-068 was involved in the breach and I would not be surprised to hear of other major compromises thru leveraging it.

Not just CGI, also DHCP became vulnerable: https://www.trustedsec.com/sep...
as pointed out by markus_baertschi above.
So it is relevant for the average end-user.

Here the definition of the system() function call often used to run external commands:

system() executes a command specified in command by calling /bin/sh -c command

/bin/sh is linked to /bin/bash and vulnerable. Executing external commands through system(), and therefore bash, is by far the easiest method, so it is widely used. It is sufficient to trick the server or daemon.

Here a proof of concept where a dhcp server tricks a dhcp client into running an arbitrary command. https://www.trustedsec.com/sep...

Markus

Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash. Apparently DHCP does this: https://www.trustedsec.com/sep...

You have it somewhat wrong. The arguments to the shell are irrelevant as several mention below. However the program must set an environment variable to unchecked user input, something everybody seems to be missing. According to the advisory, DHCP has this bug in that it copies strings in the request (or at least the string identified by "114") to environment variables.

Not every program that calls system() sets environment variables to arbitrary text from the user, so not every program that calls system() is vulnerable, unlike a lot of people here are saying.

It's not the only botnet being constructed, see my comment here - already 653 exploited servers there right now.
This is quite bad - as long as a bash CGI script is found by probing, exploiting only require putting a bash command in a header such as "Cookie:" for it to be executed. And this is only through HTTP - there are also aready other proof of concepts exploiting this through other bash-using services (DHCP servers for example).
You can check if you've been scanned for exploitable CGIs using something like (adjust apache logs path accordingly):

grep cgi /var/log/apache2/access*|egrep "};|}\s*;"

And you can check if your bash is vulnerable using:

env x='() { :;}; echo vulnerable' bash -c 'echo Testing...'

If 'vulnerable' appears, it is.

The NIST page indicates that DHCP could be used to exploit it.

Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash. Apparently DHCP does this: https://www.trustedsec.com/sep...

The only saving grace in this bug is that it's relatively easy to patch on client and server machines.

But there are a lot of things that aren't client and server machines that run linux and use bash. Routers, cable modems... all kinds of embedded systems. These things generally lag behind everything else. Firewalls will no-doubt be getting upgraded as we speak, but routers? Ultrasound machines in hospitals?

There is a lot of hard-to-patch hardware out there, and while I'm sure manufacturers are working on getting fixes out, it's going to be a long, hard, expensive process to ensure they're implemented.

We're incredibly fortunate that this bug is pretty easily fixable, but there may well be additional lurking issues, and there is always the chance we are going to find something that can't be easily fixed without breaking existing bash functionality. The probability of that is low, but the consequences would be enormously bad.

We've all heard the saying, "If builders built buildings the way programmers wrote programs the first woodpecker to come along would destroy civilization." This has given us a glimpse of what a woodpecker might look like.

Make no mistake, the security issues are very serious, but it sounds like the claim about accessing 70,000 records was misunderstood.

can you imagine a better target than servers holding everyone's tax returns?

Yes, healthcare.gov.

Read in horror: https://www.trustedsec.com/files/CONGRESS_Hearing_HealthCareSEC_FINAL_v1.1.pdf

Or, if you aren't keen on long reading, note that the website actually advertises the fact that it is the target of SQL injection attacks via it's search function: http://www.redstate.com/2013/11/18/healthcare-gov-site-advertising-sql-injection-attacks/