Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 570 Vote(s) - 3.51 Average
  • 1
  • 2
  • 3
  • 4
  • 5
"Shellshock" bash exploit + temporary patch

#1
tl;dr everyone has aids

Yesterday, a serious bug affecting all versions of GNU bash was disclosed. The bug is in parsing of functions inside environment variables. Specifically, bash does not stop parsing functions at the end of the function. It will continue to execute whatever code it was given. This is remotely exploitable through any condition that allows a user to set environment variables and run bash.

An example would be HTTP headers being sent before running a CGI script. Web servers pass these headers through environment variables, therefore nearly all Linux systems running CGI on webservers are vulnerable at this moment.

The simplest way of getting execution through this bug is to send a malformed bash function as your user agent, like this one:
PHP Code:
() { :;}; YOUR COMMANDS HERE 
Here is a local way to check if you are vulnerable.
PHP Code:
env "x=() { :;}; echo vuln;" bash 

There is only a partial patch available at the time of this writing. To fully work around this bug for now, you'll have to set a Bourne-compatible shell as your system shell, like so:

PHP Code:
cd /binrm shln -s dash sh
# DO NOT DO THIS WITHOUT DASH INSTALLED. YOU WILL MESS UP YOUR SYSTEM. 

EDIT: Just making it clear that HTTP is not the only way to exploit this. If you are running bash on or before September 25th, 2014, you are exploitable somehow. Period. DHCP clients are affected, webservers are affected, anything that calls system() is affected, your cron scripts are potentially affected, your init scripts are potentially affected and SSHd is affected, allowing for bypass of ForceCommand directives. Even your Macbook is vulnerable. This is serious shit.
Reply

#2
great post as usual. I know we've been taking measures since this was announced
Reply

#3
Thanks Roger. I had a nice all-night run "patching" this (setting dash as system shell and running intrusion checks) on about 50 machines >.>
Reply

#4
Quote:(09-25-2014, 04:23 PM)Reiko Wrote:

[To see links please register here]

Thanks Roger. I had a nice all-night run "patching" this (setting dash as system shell and running intrusion checks) on about 50 machines >.>
That's a shit ton of machines. I saw a writeup of this vuln yesterday, and my jaw dropped.

Here's one of the first exploits in the wild:
I'm on OSX, and Rieko's test code didn't work on me, but this one did

Hidden Content
You must

[To see links please register here]

or

[To see links please register here]

to view this content.

Remember, any patch you guys put on right now, isn't a full patch and as Rieko said, a partial patch meaning that there is still a chance of exploitation.

3 Public sploits from exploit-db:

[To see links please register here]

[To see links please register here]

[To see links please register here]

Reply

#5
Even setting dash as system shell doesn't 100% fix this. It just greatly limits your exposure. If you have CGI scripts that actually depend on bash, and specifically depend on bash, you're still hosed.

For routers, at least routers running DD-WRT, it can be worked around by forcing authentication on all pages. The HTTP daemon asks for auth before it ever serves or executes a CGI page. This doesn't mean that an evil or compromised ISP can't still pwn you via DHCP though.

In case you haven't noticed yet, this one's really, really bad.
Reply

#6
Quote:(09-25-2014, 05:10 PM)Reiko Wrote:

[To see links please register here]

Even setting dash as system shell doesn't 100% fix this. It just greatly limits your exposure. If you have CGI scripts that actually depend on bash, and specifically depend on bash, you're still hosed.

For routers, at least routers running DD-WRT, it can be worked around by forcing authentication on all pages. The HTTP daemon asks for auth before it ever serves or executes a CGI page. This doesn't mean that an evil or compromised ISP can't still pwn you via DHCP though.

In case you haven't noticed yet, this one's really, really bad.

Darn, and I decided to take this week off for vacation :p
Reply

#7
Quote:(09-25-2014, 05:56 PM)Eclipse Wrote:

[To see links please register here]

Wow, this is pretty big. Lucky for me I don't have any servers right now. I'll just sit here with popcorn and watch the drama unfold.

You have a router in your house. If it's not a cheap piece of trash VxWorks router, you're vulnerable too.
Reply

#8
Wow, this is pretty big. Lucky for me I don't have any servers right now. I'll just sit here with popcorn and watch the drama unfold.
Reply

#9
Quote:(09-25-2014, 05:27 PM)roger_smith Wrote:

[To see links please register here]

Darn, and I decided to take this week off for vacation :p

You picked a good week for it. Yesterday when I was notified of this via SMS by a friend, my response was "DONT CARE SLEEPING ALSO GRSEC AND MOD_SECURITY" just like that, in all caps. After I woke up I read it again and freaked out.
Reply

#10
Quote:(09-25-2014, 05:59 PM)Reiko Wrote:

[To see links please register here]

You have a router in your house. If it's not a cheap piece of trash VxWorks router, you're vulnerable too.

Well then fuck. It's a D-Link running default firmware. I really need an upgrade...


EDIT: Nice addition to OP.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through