Certification Authority Authorization (CAA) is a used to specify which Certificate Authorities may issue certificates for the domain. Whilst lack of CAA does not constitute a vulnerability itself, it may be used to harden the transport layer security of an application by reducing the risk of certificates being mis-issued. Additionally, it can be used to notify the application owner when a mis-issue is detected and prevented through CAA.

Major outages in major public cloud providers such as Azure and AWS are rare, but they do happen. Today OVH had a major incident: “OVH datacenter burns down knocking major sites offline” and they’re not the only ones to experience these issues, for example Amazon had a major outage in November and Microsoft had one in September.

This prompted me to write up an article on Akimbo’s recent work building resilience into our platform, so today I’m going to talk a little bit about a couple of the features of AWS that allow for significant resilience and I’m going to do that by running you through my recent experiments on our platform which can be roughly summarised as “Turning things off to see what breaks.”

Out-of-band exploitation refers to exploits where the extracted information is received over a connection other than the one the payload was delivered over. It can be used to bypass defensive technologies as well as complicating the detection and response capability. SQL Injection can be exploited out-of-band through protocols such as DNS in order to extract database contents. This is particularly useful as an alternative to Time-based exploitation where it can allow for faster extraction. If you're new to this vulnerability, it's worth starting at SQL Injection  basics first, before reading this article.

The idea behind out-of-band exploitation is fairly simple, instead of inferring content in the database through something like Boolean logic, you can request the target system transmit the information over protocols such as HTTP, SMB or DNS.

When performing security tests, we very often come across weak passwords. We often see dictionary words with suffixes such as Welcome1, Password123, or Lockdown2020. We also see "leet" substitutions, such as P@55w0rd, 3l3ph@nt, or L0ckd0wn. We've previously shown how quickly password cracking can be performed. With passwords like the above they would be cracked easily. Simple protections such as "Password complexity" don't solve the problem on their own, for example complexity enforces the requirement for three of the following: uppercase, lowercase, numbers, and symbols - which all of the weak options above meet.

In a previous article we discussed how bruteforcing Windows accounts is often easier than people expect. In this post - we'll cover some steps to harden these accounts.

The Observation Window

When configuring an account lockout threshold on a Domain another setting is suggested, the observation window. This setting effectively reduces the protection of the account lockout by setting a timer. For example, a lockout threshold of 5 and an observation window of 30 minutes has the impact of meaning that if an attacker attempts 5 incorrect passwords within 30 minutes the account will lock - but four passwords would not cause it to lock.

Therefore, an attacker could attempt 4 passwords every 30 minutes - or 192 per account per day, without locking any accounts.

We recently discussed how to break WPA2 keys very quickly using cloud computing. We've also looked at how to use a Rogue AP to capture user credentials from a network using PEAP (MSCHAP).

In this article we'll look at hardening Enterprise wireless networks from these attacks.

The most secure option is to utilise mutual authentication (where both the server and the client authenticate to each other) using digital certificate based authentication, such as offered by EAP-TLS. However, there can be more administrative overhead involved in the deployment of these networks and therefore PEAP may be offer a balance of security and overhead.

To be clear, we recommend the use of EAP-TLS wherever possible - but if you must use PEAP, we offer the following hardening steps:

SQL Injection is a vulnerability that occurs where user supplied input is insecurely concatenated into an SQL query. We showed how easy can be to detect in our Finding SQL Injection article, and we’ve run through exploitation in many posts such as our post on Exploiting Error-based SQL Injection.

However, in this post, we’re looking at fixing it. The fix is quite a simple code change. As the issue described is user input insecurely concatenated into a query, the remediation for SQL injection is fairly simple: don’t build queries through string concatenation. Instead, it’s more secure to use “Prepared Statements”, often called “Parameterized Queries”. All modern languages support this type of query either directly or through a framework; here we will supply a PHP example to show the difference.

In our article LLMNR and NetBIOS-NS Spoofing with Responder we stepped you through how to exploit a very common issue on Windows networks. In this one, we’re going to cover how to fix it.

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS-Name Service (NBT-NS) are name resolution protocols that are enabled by default on Windows machines. They’re both used as a fallback for DNS. If a machine requests a hostname, such as when attempting to connect to a file-share, and the DNS server doesn’t have an answer – either because the DNS server is temporarily unavailable or the hostname was incorrectly typed – then an LLMNR request will be sent, followed by an NBT request. LLMNR is a multicast protocol and NBT-NS is a broadcast protocol.

Whilst Reflected and Stored XSS can generally be addressed through server-side user input encoding (such as through the PHP htmlentities() function) or with browser protections such as Content-Security-Policy – this is not sufficient for DOM-XSS.

Where a dangerous function is used, user input into that function should be limited through user input filtering. An allow-list approach of restricting user input to only known-good input should be used. For example, limiting input to the smallest number of characters possible (such as alphanumerics only) and checking the expected data type (such as limiting input to integers only). This is in contrast to a block-list of known-bad inputs being blocked, which is often less effective due to the large degree of flexibility that JavaScript allows. For a good example of this flexibility, consider something like JScrewIt.

This issue comes about where user supplied input is included within server responses without filtration or encoding.

One very effective method of preventing this attack is to use an allow-list (sometimes called a whitelist) which will allow only known good content. For example if your expected input is an integer and the user supplies anything other than an integer you can simply reject that input – and perhaps supply a message to inform the user what the issue is, without including the original payload.

We covered extracting domain hashes with Mimikatz previously, but that's not always the best approach - for example where anti-virus is getting in the way. However there are other options for the same goal. This time around we'll take a look at using Vssadmin, a built-in Windows tool. VSSAdmin is the Volume Shadow Copy Administrative  command-line tool and it can be used to take a copy of the NTDS.dit file - the file that contains the active directory domain hashes.

XML Entity Injection is a powerful vulnerability that can allow for confidential data theft and in rare cases command execution. It was also often overlooked for a while - but now it features in the OWASP Top 10 as A4 it's a lot more well known. The issue comes about within XML parsers where external entities are processed which can allow for URIs to be loaded.

Wait, back up. What's an entity? An easy way to think of entities is like a variable. It can hold strings, so an entity can be used in XML to hold text content - or it can be used with a URI to load remote content.

Breaking into Penetration Testing can be a daunting career move; so in this article we talked about ways you can make your first move towards a career in this industry. To be clear, this isn't a definitive guide to the industry - it's just our opinion on what has worked for our team and what we like to look for when hiring. So, when interviewing for a position as a junior penetration tester - what makes you stand out from the crowd?

Whilst it's certainly useful to know how to use common security testing tools, it's better if you can understand what's going on under the hood. It's also just as important to know how to remediate the issues found. For example, knowing which flags to use when executing Responder is good; but it's better if you can talk about the underlying protocols such as Link Local Multicast Name Resolution and why it can lead to significant vulnerabilities.

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS-Name Service (NBT-NS) are name resolution protocols that are enabled by default on Windows machines. They’re both used as a fallback for DNS. If a machine requests a hostname, such as when attempting to connect to a file-share, and the DNS server doesn’t have an answer – either because the DNS server is temporarily unavailable or the hostname was incorrectly typed – then an LLMNR request will be sent, followed by an NBT request. LLMNR is a multicast protocol and NBT-NS is a broadcast protocol.

Therefore, an attack can take place where an attacker responds to these requests with illegitimate requests. For example, directing the requesting user to connect to the attacker's machine where an authentication attempt will be made – disclosing hashed credentials for the targeted user.

We recently published an article on using Incognito for privilege escalation as part of a short series on using Metasploit. In this article we’ll cover an alternative approach for privilege escalation – extracting plaintext credentials. Whilst incognito is generally easier to use, Mimikatz is powerful and flexible.

In this part we’re just going to look at password extraction; but Mimikatz can be used for many other attacks – such as extracting domain hashes from a domain controller. As before, password extraction is really a post-exploitation steps and is very useful for escalating from local administrator access to domain administrator access. As this is a post-exploitation step, we’ll be starting with a SYSTEM shell through PsExec for this demonstration. As an example of when these steps could be deployed, they could be a step taken after successfully performing an attack to gain an initial foothold such as LLMNR and NBT-NS Spoofing, which we covered previously.