Saturday, 19 November 2016

Keep Trying Harder (PWK/OSCP)

I have been preparing for the OSCP certification exam for a good portion of the second half of 2016; which culminated in the OSCP 24 hour (23hr 15min) challenge last weekend.

I began the challenge at 1400hrs and worked constantly for 18 hours, by which time I had one root and two low privilege shells. Unfortunately this didn't change for the remainder of the challenge.
As a result, I failed.

Looking back, I realise a number of mistakes I made in tackling the challenge.
First of all, I got one root and two low privilege shells well within the first 5 hours. I then spent the next 17 hours going in circles, becoming more and more frustrated, more tired, clock watching and becoming more worried that I wouldn't pass.
This clearly isn't the best technique.

I have found that half of the challenge appears to be time management. I was determined to power through the sleep deprivation, believing that I could cheat the performance degradation that tiredness brings; as it turns out, I'm not super human.

The tiredness itself impacted my memory. I look back and realise that I was repeating the same (privilege escalation) steps over and over again, the definition of madness...


With the clarity and soberness of a rested mind, I look back and realise that I missed some significant and obvious clues. For what appears to be one reason: The challenge itself is difficult, and rightly celebrated for that fact. As a result, I believe I had convinced myself that it would require all of the enumeration-exploitation-privilege escalation-Fu that I could summon to master it. Now I'm sure an element of that is true, however I believe I missed a big portion of what is being tested: prioritisation, time management, effective and concise analysis.

I also realise I scripted too much. I read many blog posts and forum posts written by other students that had tackled the challenge, almost all of which featured a significant amount of scripting.
Of course, I have used custom scripts constantly throughout the PWK labs, however I decided to write a monster enumeration script of epic-ness especially for the exam, I think this was a mistake.
I had forgotten that in the labs I had popped some of the most challenging machines without the use of this script. I had thrown away a tried and tested methodology for an unproven enumeration script that did the 'analysis' for me.
Although my script helped me to quickly get low privilege shells on two machines, I had robbed myself of valuable human analysis that may well have given me the edge in later privilege escalation. For which, I payed the price.

So for my own peace of mind, and potentially to the benefit of others, here is a list of what I recommend:

[1] Develop a definitive time-line and stick to it. Limit the effects of tiredness and tunnel vision as much as possible.

[2] Do not prejudge how technically difficult the challenge is. Pursue clues that you are given; don't dismiss them in the belief that it cannot be that simple.

[3] Do not repeat the exact same exploits/techniques expecting a different outcome, unless new information comes to light that changes the vector.

[4] Initial enumeration - exploitation - low priv shell - secondary enumeration - privilege escalation - root/system. It works. stick to it.

[5] Do not over script enumeration. Unless your coding up some immense machine-learning analytical script of awesomeness, no script can beat human analysis and pattern recognition.

[6] Enjoy the experience. Don't worry about failure. If I hadn't failed, I wouldn't know everything I've just written.

The OSCP challenge is, like the labs, a learning experience. Even though I am bitterly disappointed that I failed it this time; I know that it is making me a better penetration tester and that is very valuable indeed.

Saturday, 5 November 2016

Black Hat Europe 2016

This year, the Black Hat Europe conference moved from Amsterdam to a larger venue in London.
Continuing on from last year (and many years previously); Black Hat offered 100 students the opportunity to apply for free admission to the conference. I took them up on this opportunity, and for the second year running, I was lucky enough to be awarded the Black Hat Europe student scholarship.

Much like last year, I found the briefings to be exceptional. Of particular note was 'Ghost in the PLC: Designing an undetectable programmable logic controller rootkit' by Ali Abbasi and Majid Hashemi,  'Another Brick off the Wall: Deconstructing web application firewalls using automata learning' by George Argyros and Ioannis Stais as well as 'Ego Market: When people's greed for fame benefits large-scale botnets' by Masarah Paquet-Clouston and Olivier Bilodeau.

I have come away from Black Hat Europe feeling inspired and freshly reminded that there are many, many individuals who are also so incredibly enthusiastic and passionate about technology and security.

Black Hat have been so generous for the past 2 years to fund me to attend their conference and I look forward to attending next year. Although, Considering this is my final academic year, its probably about time I paid my own way (or have a generous employer who would do so on my behalf)!

Monday, 17 October 2016

The Internet of Threats

Since late September there has been no shortage of blog posts, articles and comments written about the Mirai botnet DDoS of the security journalist Brian Krebs's website; So one more surely cant hurt!

Much has been made of the threats posed by quickly and cheaply developed IoT hardware. After the slices given to R&D, marketing and others there isn't much of the pie left for security.
None the less, these devices are streaming into (and streaming data out of) consumers homes by the metric truck load.

Not since before the mid 2000's(ish) have so many insecure devices been connected to the internet; arguably back when attacking systems was considerably easier.
The rise of IoT devices is a wonderful throwback to simpler times for hackers of all stripes, where an entire class of networked devices fall into the 'easy pickings' basket; the Mirai botnet is one example of the manifestation of this fact.

IoT by nature is an excellent modus operandi for DDoS as evidenced by the 620Gbps through put achieved by Mirai. It is claimed that the Mirai botnet featured 380,000 devices all of which were popped with a simple dictionary of 62 default creds.

I think its as clear as it has ever been; IoT is going to keep us busy for quite some time.

Saturday, 15 October 2016

3 Weeks until 24 hours (PWK/OSCP)

The clock is ticking until I attempt the OSCP exam. I have 3 weeks of preparation left until I undertake a challenge which I have looked forward to for a very long time. I have taken every opportunity to prepare, including, but not limited to; selecting an exam date featuring my lucky number.

Im now in the process of polishing the lab/course report and having a report template ready to go for the exam. Other than that; I have scripts at the ready and a well rehearsed methodology ready to be deployed.

Inbetween now and the exam I will be attending BlackHat Europe, which surely will serve as a source of inspiration.

All things going well; I look forward to ending the year as a newly minted Offensive Security Certified Professional!

Sunday, 17 July 2016

Examinations (PWK/OSCP)

Since completing the 'end of year' examinations at the half way point of my degree, I have begun the process of completing Offensive Security's PWK course, with the intention of taking the OSCP exam at the end of the summer.

Offensive Security require any individual taking the PWK course to remain 'tight lipped' with regards to the detail of the course and the associated labs. That said, I feel compelled to write about the quality of the course so far.

I will soon reach the end of the PWK guided course material, at which point I will begin the 'lab' section of the process. I have so far found the course material to be exceptional. The course itself covers a broad range of disciplines in a concise and methodical way, with a mixture of videos and a course hand book. Both of which are very well produced and provide an excellent resource.

I had heard and read a great deal about the PWK course and OSCP certification prior to beginning it, most, if not all of which, was extremely positive; I am pleased to state that I wholeheartedly concur.

I now look forward to completing the rest of the course/labs. I intend to be fully prepared as I approach the OSCP examination and I anticipate that it will (happily) continue to consume a substantial amount of my time; leaving little room for extracurricular activities, such as writing posts!..

All in the true spirit of trying harder.

Tuesday, 15 March 2016

The Futility of Internet Connection Records

The Draft Investigatory Powers Bill was debated for the first time in the House of Commons today. Unfortunately the majority of the debate did not mention the fundamental issues with Internet Connection Records (ICRs).

Part 4 of the Bill outlines the power of the Home Secretary to require a "telecommunications operator" to retain the Internet Connection Records of all of its customers for no longer than 12 months. A natural question to follow is what constitutes an ICR? This is inadequately answered in Part 4, Sec.71 (9) of the Bill, it states:

In this Part “relevant communications data” means communications data which may be used to identify, or assist in identifying, any of the following— 
(a) the sender or recipient of a communication (whether or not a person), 
(b) the time or duration of a communication, 
(c) the type, method or pattern, or fact, of communication, 
(d) the telecommunication system (or any part of it) from, to or through which, or by means of which, a communication is or may be transmitted, 
(e) the location of any such system, or 
(f) the internet protocol address, or other identifier, of any apparatus to which a communication is transmitted for the purpose of obtaining access to, or running, a computer file or computer program. 
In this subsection “identifier” means an identifier used to facilitate the transmission of a communication.

For the learned colleagues among us, this is essentially the header of a packet traversing a public network in the United Kingdom.

The purpose of this post is not to lament already well documented and publicised criticisms of this section of the proposed Bill. It is however, to highlight one (of many) glaring issues with the utility of this power.

I have created a vastly simplified diagram of the typical use of a commercial VPN to better illustrate (to those without the requisite knowledge) how ICRs could be rendered useless. I have found that verbally describing this process does not have the impact I would hope. As a result I hope this post will serve as an aid in this respect.
The diagram shows two requests, one without the use of a VPN and one with.

In the latter, through an encrypted tunnel, the ISP forwards the HTTP request to the VPN provider
and creates an ICR of that request. The ISP can only see the destination as the address of the VPN provider, therefore the ICR only contains the address of the VPN provider. The VPN provider receives the request and processes it on behalf of the user located at 203.0.113.253. At no point is the ISP (or any other entity) able to view or record any details contained in the encrypted tunnel.

VPNs make ICRs useless. Especially if the VPN provider is located outside the jurisdiction of British law.

This is one argument of many against the utility of ICRs. It would appear that the valid arguments of government over-reach and the negative impact on the privacy of millions of people gains little traction.. so it seems necessary to start challenging the many flaws in the practical application of this power.

In a future post I plan to discuss the significant issue of safely storing massive volumes of intimately personal data of millions of people.

Tuesday, 23 February 2016

Apple's Crypto Battle

On the 16th of February 2016, Apple published a letter to its customers by their CEO Tim Cook. In the much publicised letter, Apple stated that it had taken the decision to oppose an "order" to produce an alternative 'law enforcement' version of the iPhone iOS software which can be used to circumnavigate encryption in the iPhone or facilitate the cracking of encryption within the iPhone (this remains unclear).

This 'order' or possibly a court writ (this is unclear) has stemmed from an investigation by the Federal Bureau of Investigation into the the San Bernardino terrorist attack of the 2nd of December 2015. In this attack 14 people were murdered and 22 seriously injured from a mass shooting and attempted bombing at a local government training event/Christmas party at a San Bernardino conference centre.

Since the release of the first iPhone, Apple has included to varying degrees, some form of encryption in its devices. Since the launch of the A7 processor (iPhone 5s) the iPhone has featured a co-processor known as the "secure enclave". This co-processor is a hardware implementation of various cryptographic functions that the iPhone uses to secure a significant amount (if not all) the user data on the device.

The secure enclave features a dedicated hardware implemented AES 256bit crypto engine with a dedicated path to the NAND mass storage. Each iPhone has a Unique ID (UID) which is "fused" into the co-processor at the time of manufacture. The UID is an AES 256-bit key that is not linked to any other identifier on the device. Apple states that it, nor any third party, stores the UID. Apple also states that it is impossible to retrieve the UID from the co-processor (however it is unclear exactly how this is the case).

The UID is used within the secure enclave to encrypt and decrypt the entire file system of the iPhone on the fly. Implementing this key in hardware means that if the NAND chips are stripped from the logic board it would be impossible to crack the file system encryption (due to the necessity of the co-processor to decrypt it, and its UID). Meaning all decryption must be done on the original device itself.

The actual act of encryption and decryption is achieved through the use of a passcode created on the device. In iOS 9, when the device is first activated, a 6 digit passcode must be created by the user to progress through the set up and to use the device.
The passcode is used in conjunction with the UID and put through a PBKDF2-AES function in the secure enclave which produces a passcode key. This passcode/UID key is actually what is passed when unlocking (decrypting) the device. Also, a time limitation is implemented in the co-processor to prevent rapid brute forcing of the passcode (a user can also activate an option for the file system keys to be wiped if the passcode it entered incorrectly 10 times, making the encrypted data irretrievable).

There appears to be at least 3 points of potential failure trust in relation to Apple's implementation of encryption in iOS devices:

  • Trusting Apple and Samsung (the manufacturer) that they are not recording the UIDs of the processors.
  • Trusting Apple to adequately verify and sign the firmware of its devices.
  • Trusting Apple to produce firmware which does not provide a method of exfiltrating the UID from the co-processor or in some way circumnavigating the passcode/UID key or facilitate brute forcing of the passcode.

Clearly the FBI is pursuing the last of these points to gain access to the iPhone in question. It would appear that either Apple is being 'ordered' to produce firmware which they adequately sign and will run on the co-processor which could reveal the UID of the device (they have stated this is impossible) or in some way could remove the requirement to provide a passcode to decrypt the device (which seems unlikely due to the blending of the passcode and the UID). Therefore it would seem (at least to me) that the only logical option is that the FBI wants Apple to produce firmware which enables brute forcing the passcode (fairly trivial 10^6 maximum possibilities) in a reasonable amount of time.

This should be of concern to every user of an iOS device. The FBI needs Apple to produce this firmware due to the signing of the firmware and co-processor verification of that signature at boot. Apple's argument appears to be that it does not trust the FBI (probably more accurately the American Government and its intelligence services as a whole) with this capability if it were to produce it, as this hypothetical firmware, or a close derivative of it, would likely work on many iOS devices (if not all).

I believe that Apple's resistance to this "order" is not without merit. It is easy to imagine that the FBI could quickly hand over this firmware to other intelligence services.
This could cause many concerns for Apple, one of which could be that multiple governments from around the world could demand similar capability, possibly even some disagreeable governments, with less than a clean track record when it comes to the protection of Human Rights and the freedom of the press.

The result of this on-going dispute will have implications for many iPhone and iOS device users, not to mention the debate over the use of encryption as a whole.


Sources and Further Reading:

David Schuetz, "A (not so) quick primer on iOS encryption". darthnull.org: http://www.darthnull.org/2014/10/06/ios-encryption

Andrey Belenko, Dmitry Sklyarov, "Evolution of iOS Data Protection and iPhone Forensics". BlackHat Abu Dhabi 2011 presentation
https://media.blackhat.com/bh-ad-11/Belenko/bh-ad-11-Belenko-iOS_Data_Protection.pdf

Matthew Green, "Why can't Apple decrypt your iPhone?". blog.cryptographyengineering.com:
http://blog.cryptographyengineering.com/2014/10/why-cant-apple-decrypt-your-iphone.html

Apple, "iOS Security". apple.com: 
https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Apple, "A Message to Our Customers". apple.com: 
https://www.apple.com/customer-letter/

Saturday, 13 February 2016

Write Up: PRIMER 1.0.1 (chp. 8, 9 + 10)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found hereIf you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!
------------------------------------------------------------------------------------------------------

PART 3/CHAPTER 8, 9 + 10: [TERM]

The final part of this VM (as the title suggests) consists of a simulated terminal in the browser. The use of a simulated terminal is actually more of a story telling device rather than a technical challenge. As a result, I will not be explaining how I completed these chapters, instead I'll briefly discuss the story line and what these chapters entail.

Through out this VM the story line has been a central element, this comes to a head and is mostly resolved in these chapters, and its done in what I can only describe as a wonderful way. This resulted in it feeling more like the final act of a movie than a vulnerable VM (complete with end credits)!

The simulated terminal features a few limited *nix commands that are used to cat some log files and see running processes in order to 'gain access' to each "server/AI" (as the story portrays). It requires some lateral thinking, a dash of detective work, a little bit of googling and tests your hacker movie/book knowledge.

To say any more would serve little purpose other than to spoil the experience of anyone that may wish to complete this VM. Which I recommend you do!

Although I am more interested in the technical, it must be said that this VM was great fun and a great experience, such a unique way of telling a story and a great method of involving the audience. The challenges themselves are fairly simple and will not be taxing for any one with a basic skill level. None the less, regardless of skill, I believe most people would enjoy completing this VM.

Many thanks to Arne Rick for making such a wonderful VM and clearly putting in a ton of effort. I look forward to the next instalment!


On to the next VM..

Wednesday, 10 February 2016

Write Up: PRIMER 1.0.1 (chp. 6 + 7)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found hereIf you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!
------------------------------------------------------------------------------------------------------

CHAPTER 6: [++Q++++++]

Chapter 6, much like chapter 5 begins with a javascript window prompt. Immediately I looked at the debugger to analyse the JS.


No hints to be found in the title of the JS prompt. The code, however was more revealing. It was clear that the JS had been obfuscated in some way, however there was some clear text.

"Someone didn't bother reading my carefully prepared memo on commonly-used passwords. Now, then, as I so meticulously pointed out, the four most-used passwords are: love, sex, secret, and... - The Plague"


A reference to the timeless and ever accurate movie "Hackers". The four most common passwords (according to the movie) are love, sex, secret.. " Don't forget god, system operators love to use god, it's that whole male ego thing" as cereal killer says.

Well what a hint! I enter god then GOD and Im through. However thats not much fun. So I had a look at that more interesting obfuscated JS.

So I began by going to jsbeautifier.org to make use of their unpacking and deobfuscating tools. From scan reading the code, I noticed some escaped hex character codes which jsbeautifier can also take care of.


Suddenly all nice and at least readable. Theres still a large amount of obfuscated code, but none the less, allot to work with. The first var is an array of strings. At this point I guessed that the strings in this array are being used throughout the obfuscated code in some way, due to their nature; "location", "addEventListener" "DOMContentLoaded" etc.

I then read through the code, almost 500 lines, but fortunately I could gloss over most of it due to it being mostly garbage. However, at the end I discovered the function Im looking for, the window prompt function.


It appears that this is using the array thats declared on line 1 ( _0x5cf4) is key in this function.
The user input string is hashed using MD5 (on line 474) and then compared to the 9th element of _0x5cf4. If true, the window prompt is removed. 

I then went back to line 1 of the code and looked through the array for the 9th element. There I found the string "0d28cba0bd4f26e16d766000d27e49fa". This looked like an MD5 hash.
From reading the window prompt function, its clear that an un-hashed version of this string needs to be entered for it then to be hashed and compared against the relevant element in the array.

In order to reverse the hash, I navigated to hashkiller.co.uk to make use of their MD5 cracking tool. I entered the hash and got a result:


0d28cba0bd4f26e16d766000d27e49fa MD5 : GOD

This corresponds to the earlier "Hackers" hint, so it must be correct! I entered it into the window prompt and I was through.

CHAPTER 7: [KS(x)<=|(x)+4]

The story continues, the text on this page had some revealing hints. 


"There was a pattern in the path she had taken through the network. An artificial pattern, la[i]d out by someone or something. There was no hint, no obvious step. Finding the next node would be the challenge, or maybe more like a test."

This appeared to me to be hinting at the pattern of the URLs. I looked at the previous URLS, they all appeared to be MD5 hashes as well.
I again navigated to hashkiller.co.uk to crack the hashes. I entered them in the order that I had solved them. The following results were returned;

c81e728d9d4c2f636f067f89cc14862c MD5 : 2
eccbc87e4b5ce2fe28308fd9f2a7baf3 MD5 : 3
e4da3b7fbbce2345d7772b0674a318d5 MD5 : 5
8f14e45fceea167a5a36dedd4bea2543 MD5 : 7
6512bd43d9caa6e02c990b0a82652dca MD5 : 11
c51ce410c124a10e0db5e4b97fc2af39 MD5 : 13
70efdf2ec9b086079795c442636b55fb MD5 : 17


2, 3, 5, 7, 11, 13, 17.

I could immediately disregard the first number as the story also stated "It had been there since the second node".
I began to form a pattern, it quickly became apparent that there was a pattern of offsets between the numbers;

3  (+ 2)  5  (+ 2)  7  (+ 4)  11  (+ 2)  13  (+ 4)  17

2, 2, 4, 2, 4... ?2, 2, 4, 2, 4...?

:- 17 + 2 = 19


The next step was to hash the result.


I then prepended 8_ to the hash to adhere to the URL scheme and entered it into the browser. Success! On to Part 3, the final chapter!...

Tuesday, 9 February 2016

Write Up: PRIMER 1.0.1 (chp. 4 + 5)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found hereIf you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!
------------------------------------------------------------------------------------------------------

CHAPTER 4: [:()[:|:&};:]

In chapter 4 I was met by a continuation of the story, and a link to Chapter 5 (the start of Part 2). EOF.


PART 2/CHAPTER 5: [0xC00007B]

Following the link landed me on a page with a javascript window prompt. No continuation of the story here!
 

So I opened up the browser debugger to inspect the javascript. In doing so I actually saw the hidden HTML on the page which revealed the URL for chapter 6. I ignored it and decided to complete this little JS challenge anyway.


As can be seen from the JS, 

var X is a  user inserted string, var L is some arbitrary string. 
The if conditions are true if the string is null or if a substring (X.substr) of var X is equal to 
var L

Considering the 1st if condition (from testing) is not the desired result, it is the 2nd if condition that needs satisfying.

The parameters of X.substr show that the substring is made using the chars from the second char through to, and ending on seven chars along from the second char of the user inputed string var X.
This means that the var X must contain var L "Ikdf076" prepended with two other arbitrary chars. Such as "00Ikdf076". 


The string was submitted and the second if condition was satisfied. The window prompt was then removed and revealed the underlying HTML.


Another URL to chapter 6.. Until the next post.

Monday, 8 February 2016

Write Up: PRIMER 1.0.1 (chp. 3)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found hereIf you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!
------------------------------------------------------------------------------------------------------

CHAPTER 3: ["[^"\r\n]*"]

This chapter has probably taught me the biggest lesson so far.. don't get carried away. I have spent hours on this chapter, when in fact, its probably the easiest and most simple chapter yet. Instead of hiding my mistake, there might be some comedy valuable learning opportunities in sharing it.

So from the beginning.. I was greeted again by the now expected block of text and little else. This section of the story seemed to offer some hints to the solution. I fell for it hook line and sinker!


As I read the text, the following line stuck out to me ".. slowly d[i]sintegrating with lightspeed, a thousand years each nano second". This sentence appeared to be the only real candidate for a hint in the text, so I went with it...

I looked at the headers. I noticed that (unlike previous chapters) there were "If-Modified-Since" and "Etag" fields in these headers. Aha! this most be what that sentence was hinting at.. time.. "thousand years" etc.


So I jumped into curl to spoof the "If-Modified-Since" field to generate a response from the server. Sure enough, changing the date of the field to "Sun, 25 oct 2015 12:59:55 GMT" produced a 304 Not modified response, However nothing else, no extra field in the header or anything to indicate I had solved the chapter. I must have been missing something.


So I decided to read up more on properties of the "If-Modified-Since" and "Etag" fields. I began by reading rfc2616 section 14 "Header Field Definitions" for any further information. Although very illuminating, I wasn't any closer to solving the chapter. I did some more searching, read some more papers, I spent the best part of 2 hours trying to prise a hint of a way of exploiting this specific feature of HTTP headers, I came out empty handed.

So out of frustration, I thought I would see what happened if I spoofed a header where the "If-Modified-Since" field was in date; that is to say, a fresh copy of the page would be sent as it had been modified since the date I had fabricated in the request header. Sure enough, I got the HTML back, wait.. what does that say?!..


"<meta http-equiv="hint" content="Think, but don't act like a robot."/>"

Why had I not noticed this earlier?! It cant be! seriously? not robots.txt.. it cant be that straight forward?!

Yes it was that straight forward...
The moral of the story, Don't get carried away. I should have simply read the HTML first, like I had in the previous chapters. But what a valuable lesson to learn! Also, I now know quite allot about ETags and If-Modified-Since header fields!

On to chapter 4, a little bit wiser...

Friday, 5 February 2016

Write Up: PRIMER 1.0.1 (chp. 2)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found hereIf you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!
------------------------------------------------------------------------------------------------------

CHAPTER 2: [(α=β)<=>(α<=>β)]

I am progressing through this VM somewhat faster than I originally anticipated, also the chapters are shorter than I imagined, none the less I will continue as intended and post one chapter at a time.
Lets continue.
This chapter, much like the first, features a block of text which continues the vague story littered with small clues.


The most telling of these clues are as follows..

"..needed to penetrate the next circle, blocked of[f] to unauthorized access".

"But she felt a presence of something left behind. Like breadcrums, not intentional, but something forgotten by an incomplete piece of code to handle access".

At this point, my mind first went to cookies... breadcrumbs!
However, more haste, less speed. I first checked the HTML to see if there were any further clues, unfortunately, none to be found there. I then thought to have a quick look at the css and there we have another comment!


This comment confirmed my suspicions. "Clean sessions terminate without leaving things behind..", "Sometimes, an exploit is as simple as changing a simple value in a local file". Yep, definitely cookies!

I then looked at the GET request headers to see what parameters are being passed. There we have it! 


"activeSession=false"

I wonder if it is as simple as changing the active session value to true? Is that all the server is checking for an active session? The clues seem to suggest it.. so I fired up a plugin to edit the cookie and gave it a try.


I found the relevant cookie, altered the value from false to true, saved the now manipulated cookie and reloaded the page.

Sure enough! 302 found, redirect! On to Chapter 3..



Wednesday, 3 February 2016

Write Up: PRIMER 1.0.1 (chp. 1)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here.
What follows is a write up of the first of 7 chapters in this VM. I intend to write about each chapter as I complete them. 

So far this VM is thoroughly enjoyable with a wonderful and unique style of story telling. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!
------------------------------------------------------------------------------------------------------

CHAPTER 1: [__init__]

Once the VM was installed, up and running, I did a quick nmap -sn 192.168.1.*. The -sn flag to skip port scanning, simply to identify which IP the VM had grabbed. This revealed 192.168.127.
Another quick nmap -sV showed ports 22 and 80 running OpenSSH and Apache respectively.

Now I knew a web server was running, I opened up a browser and typed in the IP. A web page dutifully rendered.


 A block of text and a login form. From reading the text, it appears to be a stylistically unusual story. The way it is written is quite vague and loosely tied together. None the less, its enjoyable to read and appears to contain some hints.
The last paragraph appeared to be most relevant..

"There was one spot that attracted her naturally, a point w[h]ere the traces accumulated and forward a connection, a terminal accepting input from the us3rland, a f0rm. This one was of a family very well known to her, easily exploited to grand you access to another level, and that was she needed for now. Reaching in she began to twist the stream, adjust the flow and after a few practiced moves, she felt it, access, the meta, finally moving on."
This is clearly hinting at the login form, requiring some SQL injection. The story itself indicates that this may not be too difficult -".. a few practiced moves..".
To check for any further hints, I inspected the HTML which revealed some hidden text.
This revealed; "Some f0rms are easier than others. This one was just a means to get to the next level so there was no need for her to apply her full set of skills or fake credentials. Manufacturing a boole4n response would probably be en[o]ugh to let her pass."

This reaffirmed my suspicions that this required a simple SQL injection. Clearly just a boolean response was required for this function.
I began with some well established code which would evaluate to TRUE. I only used the Username field, leaving password empty. It was clear from the first attempt that all errors from the SQL server were being caught, there were no prompts or notifications for failed attempts. This meant there was nothing else to go on other than what was provided in the story, effectively educated guesses. I continued and tried a multitude of variations, such as ' OR '1'='1' , ' OR 1=1 -- , 1" OR 1=1 -- etc. Eventually, after a significant amount of attempts ' OR '1'='1' -- was successful. The first ' closes out the single apostrophe encapsulating the variable, OR provides the ability to negate the first statement requirement to evaluate to TRUE. '1'='1' clearly computes to TRUE and the -- (with an important space after it!) then comments out the rest of the query, therefore making the password field redundant.


Once login was pressed, I arrived at the next page. This again included a block of text.


This portion of the story continued the vagueness from the first page. However there were a few notable parts; "..specific string all users transmit.." , "Drifting around the 7th circle of security layers.." , "..this little script just checked for an identifier, a hash, no credentials or secrets..". These hinted at the User Agent Identifier. I then checked the HTML source code for any further hints.

I found a comment! This one reads:

"This bot was looking for a Sosu User Agent Identifier she had cracked weeks ago, easy sauce, just a simple md5 hash of the first 7 digits of pi. It was basically common knowledge to the entities moving in these areas but obscurity does create a, albeit virtual, layer of security".

This clearly indicates that I need to spoof the User Agent Identifier to solve this page. First of all, I need to make the MD5 Hash of 3.141592. md5sum in the terminal produced the required hash:

d483d00d07fcc80319d170ccf07fb5be.

Next I installed a User Agent Switcher ad-on in firefox. I then created a new User Agent profile and input the hash in the user agent field.


I then switched to the new User Agent Profile and reloaded the page - Redirect. It worked! on to the next chapter! ..Coming soon.