Podcasts for Fun and Profit

So, let’s talk about Shadow Brokers... Only kidding! So much has been written in the past few weeks about the Shadow Brokers release(s) that it seems impossible to not at least mention the recent happenings. So I will leave it with the following: Everything I could possibly write has already been written, several hundred times, so I will not add to the noise. I have instead decided to write about something potentially of more use...

Like any budding security professional I am always on the look-out for good sources of security/hacking knowledge, through books, blogs, websites, videos, podcasts, online periodicals and other content types. Over time I have managed to build a reasonably healthy list, which I believe reflects the effort exerted in compiling it.

Often, colleagues wish to compare notes on these sources, attempting to identify any gems that we each may have missed. Through these conversations, I have noticed a trend: many find it particularly challenging to identify quality security/hacking podcasts.

In addition to being a great source of security news, podcasts provide an avenue to hear discussion between experienced security professionals on current topics; dissecting vulnerabilities, security practices and training, often highlighting differing points of view and revealing the present state of the industry. It’s rare that I don’t learn something new when I listen to any of the podcasts present in my podcast player of choice (overcast).
It’s not all industry though, most podcasts feature an enthusiast hacker narrative, or at least a balance between enthusiast and industry: after all, aren't we all enthusiasts at heart?

So here they are:

-----------------------------------------------------------

 Risky Business  risky.biz/netcasts/risky-business/ 

A long running podcast hosted by journalist Patrick Gray, now over 451 episodes deep. This is a comprehensive review of security news over the previous week, lots of commentary and opinion mixed in with a fair bit of humour. Risky Biz is one of the podcasts I look forward to hearing the most.
The podcast often features sponsor interviews, which I mostly find very interesting and not excessively vendor-y.

 Defensive Security Podcast  defensivesecurity.org/ 

Another well-established podcast, hosted by Jerry Bell and Andrew Kalat - both seasoned information security professionals. The podcast primarily features recent happenings in the security world and discusses them in an industry context. The podcast comes across as welcomingly informal, with lots of educated opinion and debate.

 Paul's Security Weekly  securityweekly.com/ 

Paul's Security Weekly is a titan of information security podcasts, running since 2006 - The intro alone will indicate to you exactly what to expect. The show is presented by Paul Asadoorian and often features regular guests Joff Thyer and Carlos Perez. This podcast is comprehensive, covering news with very knowledgeable and highly informed opinion and lively debate. It is fair to say I have learnt a lot about the information security industry by listening to this podcast.
The show is available in audio form, but I strongly recommend watching the videos, as the show often features technical demonstrations. Plus, you also get to see hackers defying the stereotype, one cigar at a time. This one is an absolute must-listen/watch.

 Security Now  twit.tv/shows/security-now 

The podcast/video cast legend that is Leo Laporte presents Security Now with computer scientist, developer and security researcher: Steve Gibson (Steve may even be the gibson in the phrase "hack the gibson"). This podcast is expertly produced (as one would expect from the TWiT network). Leo expertly asks the questions we are all wondering, while Steve explains various aspects of recent security news. Educational and very enjoyable.

 Brakeing Down Security Podcast  brakeingsecurity.com/ 

I am relatively new to Brakeing Down Security, I was drawn to listening to this podcast through the book written by Amanda Berlin and Lee Brotherston: ‘Defensive Security Handbook’. Amanda is a co-host of Brakeing Down Security with Bryan Brake and Brian Boettcher. All extremely competent professionals eager to impart knowledge to anyone who cares to listen. This podcast appears to be more education than commentary. Very worthwhile.

 Social-Engineer Podcast  social-engineer.org/category/podcast/ 

I’m also a new comer to the Social-Engineer Podcast. As a new-comer I am just about qualified to provide the official blurb: "The Social-Engineer Podcast is about humans. Understanding how we interact, communicate and relay information can help us protect, mitigate and understand social engineering attacks." - So far, I have found this podcast fascinating. This podcast is produced by Chris Hadgany's Social Engineer Inc.: Hadgany is the author of the excellent book 'Social Engineering: The Art of Human Hacking' and founder of DEFCON SEvillage and SECTF - all of which should be ample evidence of the podcast's credentials.

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.

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)!

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.

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!

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.

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.

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/