What is Penetration Testing?
Penetration Testing, often abbreviated to PenTesting, is a method of testing the security of a system through attempting to discover and actively exploit vulnerabilities within the system. It is amongst the most effective methods of determining the actual risk posed by a system. This is due to the fact that the risk of present vulnerabilities is not estimated but they are exploited to determine how much leverage they would offer an attacker.
HTML5: Cross Domain Messaging (PostMessage) Vulnerabilities
HTML5 PostMessages (also known as: Web Messaging, or Cross Domain Messaging) is a method of passing arbitrary data between domains. However if not implemented correctly it can lead to sensitive information disclosure or cross-site scripting vulnerabilities as it leaves origin validation up to the developer!
HTML5: Cross Origin Resource Sharing (CORS) Vulnerabilities
So by default SOP won’t allow bi-directional communications between two separate origins, however as applications scale up there may be a requirement to allow this kind of thing. Think of companies such as Google, who also owns YouTube – or Microsoft who also owns Outlook and Skype. They may well want inter-origin communications.
An Introduction to PenTesting Azure
I recently wrote an introduction to PenTesting an AWS Environment. A sensible place to start given that I included that in Q1 of 2018 Amazon holds a 33% market share in cloud whereas Microsoft only holds 13%. However I did want to add a few notes that are specific to PenTesting within Azure environments here.
Many of the concepts are the same however, in my AWS article I broke the perspective a penetration tester could take of a cloud environment down into testing “on the cloud”, “in the cloud”, and “testing the cloud console.” That concept remains the same, which is:
Spoofing Packets and DNS Exfiltration
Following a successful penetration test, you may have large amounts of data to exfiltrate from an environment specifically hardened to make it difficult to exfiltrate data. For example, the network might have a firewall that explicitly blocks common exfiltration methods – such as SSH, HTTPS, HTTP.
It is common that you can still exfiltrate data from these networks by using DNS. For example you could make a request to a domain name that you control where the subdomain contains some information to be exfiltrated. Such as sensitive-data-here.attacker.example.com. DNS is a recursive system, such that if you send this request to a local DNS server, it will forward it on and on until it reaches the authoritative server. If you control the authoritative server, you can simply read the sensitive data from the DNS logs.
An Introduction to Penetration Testing AWS
When penetration testing Amazon Web Services (AWS) environments there are different perspectives the assessment could consider, some are very similar to external infrastructure/web application assessments and some are different.
I’ll separate the things that are the same from the things that are different to traditional penetration testing by considering the following types of cloud testing and then breaking each one down into the kinds of testing that could take place:
A Quick Malware Teardown
A follower sent me a suspicious looking file recently to get my opinion on its behavior and to see if I could pull out a little detail on how it’s working. “Suspicious looking” because at the time, it was getting a zero score on VirusTotal but it appeared to be doing something just a little dodgy in the background. I wanted to post some notes around my quick tear down of the malware show that since so much malware is poorly written and obfuscated you can often do a large amount of analysis of a file’s behaviour in a short period of time.
HTTP Header Injection
HTTP Header Injection vulnerabilities occur when user input is insecurely included within server responses headers. Specifically they are based around the idea that an attacker can cause the server to generate a response which includes carriage-return and line-feed characters (or %0D and %0A respectively in their URI encoded forms) within the server response header the attacker may be able to add crafted headers themselves. Header Injection can allow for attacks such as response splitting, session fixation, cross-site scripting, and malicious redirection.
PrivEsc: DLL Hijacking
I posted earlier about Privilege Escalation through Unquoted Service Paths and how it’s now rare to be able to exploit this in the real world due to the protected nature of the C:\Program Files and C:\Windows directories. It’s still possible to exploit this vulnerability, but only when the service executable is installed outside of these protect directories which in my experience is rare. Writing that post though got me thinking about another method of privilege escalation which I think is a little more common to see – DLL Hijacking.
Windows Desktop Breakout
Many organisations “lock-down” their desktop environments to reduce the impact that malicious staff members and compromised accounts can have on the overall domain security. Many desktop restrictions can slow down an attacker but it’s often possible to “break-out” of the restricted environment. Both assessing and securing these desktop environments can be tricky, so I’ll run you through how I assess them here, highlight some of the tricks and the methodology that I use with the intention that both breakers and defenders can get a better look at their options.
Linux PrivEsc: Abusing SUID
Recently during a CTF I found a few users were unfamiliar with abusing setuid on executable on Linux systems for the purposes of privilege escalation. If an executable file on Linux has the “suid” bit set when a user executes a file it will execute with the owners permission level and not the executors permission level. Meaning if you find a file with this bit set, which is owned by a user with a higher privilege level than yourself you may be able to steal their permissions set.
Web Application Defence: Filtering User Input
Effectively filtering user input is one of the best ways to prevent an awful lot of web application vulnerabilities. There are several ways to approach this, each with their own pros and cons so I’ll run through them here an then you can think of the best way to combine them for your context. It’s important to remember though, that filters are context specific, there is not one filter that will work for a whole application and that’s what can make writing an effective filter tricky.
Custom Rules for John the Ripper
Whilst Hashcat is often provable faster than John the Ripper, John is still my favourite. I find it simple to use, fast and the jumbo community patch (which I recommend highly) comes packed with hash types making it a versatile tool.
One of the features of these tools, which is often unknown or at least under appreciated is the ability to create custom “rules” for teaching the tool how to dynamically generate potential passwords. Since Microsoft implemented “Password Complexity” and this was enforced around the globe, user have made the jump from a password of: password, to the [sarcasm] much more secure [/sarcasm]: Password1.
An Introduction to Hardware Hacking
I’m currently writing up a series on hardware hacking fundamentals, and before I get into the specifics – I thought it sensible to add a piece on why hardware security is important and to lay out the major themes of what I’ll be discussing.
Firstly, with physical devices, the attackers have more options when it comes to attacking the devices and it should be noted that breaking a specific device might not be the final aim. As an attacker over the internet, I only have exposed network services to “play” with, but if I’m testing a physical device the attack surface can be much wider. With options including network services, radio frequency input/output, on-chip debugging, exposed serial ports, memory extraction, etc, etc.