Shelldon
- 1 июн. 2023 г.
- 3 мин. чтения

Writeup for RemoteApp [PART 1]

Few days ago I have created a remote app for preparing for OSED exam. Now let's hack it!

Tools I used:

Windows x64/x86 VM
Kali linux
pwntools library for python
IDA/IDA PRO
Windbg (you could use any debugger)
Motivatoin

Default port is 9999.

Windows VMs IP: 192.168.1.2

Kali VMs IP: 192.168.1.8

I have opened a binary in Windbg, so let's start from reversing.

Reversing

There are two vulns that you need to use in the exploitation process. First one is a leak. You can use leak for bypassing ASLR. Second one is a buffer overflow. Let's find it.

The very first blog starts calling WSAStartup and initialising Winsock so that to use WS2_32.dll library.

if WSAStartup() function is successfully initialized, we go to socket() function. After socket we create call a bind() function and setting up a bind for IP and port.

If bind setting up successfully we call accept() function to accept a connection from user. As you can see bind() function in while loop so that we could connect and send/receive data many times.

Also, there is handleConnection function. Let's look at that.

First blog calls memset to create a buffer with 0x4000 bytes size and fill it with 0. Than it calls send() function to send a data to user. In this we should get "REMOTE APP VERSION: 1.0" and "Type something" message.

As I said, I have created a buf variable to store a recieved data.

There is cmp() function that compare 0x11223344 value with something from buf. Let's look what is it. Also there xor operation.

The first value is 0x65 which equals to 100 (size of user data) and the second value is 0x41414141 which equals to (AAAA). Now we now that size should xored with the first value of payload. We have a final result value: 0x11223344. Let's update exploit.

Now exploit looks like that. Let's test.

The received data length equal to 4001, not 4000. So, That happens in a lot of binary. To be equals to 4000, we should subtract 1 from the of payload.

Just like that. Let's see.

Now eax equals to correct value.

The second check after canary is comparing al register with 0x41 (A). Let's from which part of buf the values will compare.

A value for al register equals to 0x41 (A) and it will take from the begging of buffer. Here we passed second check. Let's see what happening next.

The third checks also al register. In that case it should be equals to 0x42 (B). Let's modify exploit.

I added 'A' and 'B' after canary.

We can see the first value of ebp-4027 is 42 ('B) and also al regist equals to 42. It means that we passed third check.

After passing all checks we have another cmp() function. There used some opcodes.

There three opcodes. 900, 901 and 902 in decimal values. 901 opcode calles Function2 functoin, 900 opcodes calles Function1 and 903 calls Function3.

2. Memory leak

Let's look Function1.

Now exploit looks like that.

As you see eax equals to 900 (0x384).

Now this is Function1 functoin. There is memset function and memcpy function. There could be a memory coruption vulnerability. Let's check.

The first thing is calling memset and filling this buffer with 0. The size equals to 0x4000.

The second thingis calling memcpy and copy user data to new buffer.

The first value is Destination buffer (new buffer), second value is Source buffer (user data) and third value is the size. There is no memory coruption vuln, because we are copying 0x4000 bytes to buffer that has 0x4000 size. So Function1 is not vulnerable.

Let's look to Function2 function with 901 opcode.

Function2 in IDA.