Bruteforcing Full Drive Encryption
B

SecPro #29:OWASP 2022 #1 Security Risk Deep Dive; Bruteforcing Full Drive Encryption

It was a big funding week for security startups!

  • Armis raised $300 million
  • Panther raised $120 million at Series B giving them a valuation of $1.4 billion
  • ReliaQuest raised funding through KKR giving them a valuation of $1 billion
  • CyCognito raised $100 million at Series C
  • Cycode raised $56 million at Series B

In today’s issue:

  • OWASP’s #1 Security Risk for 2022 – A Deep Dive
  • Brute-Forcing Full Drive Encryption
  • The Attack on the IT Sector
  • Secret Knowledge: Building Your Security Arsenal

Vulnerabilities

A Deep Dive into OWASP’s #1 Security Risk for 2022

After no changes since 2017, the Open Web Application Security Project (OWASP) Foundation has finally given the Top 10 Web Application Security Risks a much-needed shake-up. These changes really show the changes in the threat landscape, especially seeing that Broken Access Control and Cryptographic Failures have jumped up to the top spots.

There are new entries, changed rankings, and a bit of redefining for one or two of the previous edition’s Top 10 issues. But what is the new application weakness that is causing security teams the most trouble?

OWASP’s Most Critical Security Risks for 2021

  1. Server-Side Request Forgery (SSRF)
  2. Security Logging and Monitoring Failures
  3. Software and Data Integrity Failures
  4. Identification and Authentication Failures
  5. Vulnerable and Outdated Components
  6. Security Misconfiguration
  7. Insecure Design
  8. Injection
  9. Cryptographic Failures
  10. Broken Access Control

OWASP Top 10 changes for 2021

A Deep Dive into Broken Access Control

Having moved up from position 5 in the previous Top 10 list, Broken Access Control (BAC) is now the biggest security risk for IT teams battling against the adversary. But what does OWASP count as access control that has been broken?

What is Broken Access Control?

Broken Access Controls are when Access Control Lists (ACLs) can be circumvented and sensitive data is exposed. Generally, the information that leaks should only be accessible through the user’s account and passwords or other security methods that restrict access fail.

There are multiple ways to exploit these vulnerabilities, but some of the most (in)famous forms of broken or missing access controls include:

  • Client caching exploitations
  • API misuse to access controls for POST, PUT, and DELETE
  • SQL injection attacks
  • Path traversal vulnerabilities

How Prevalent Are Broken Access Controls?

With over 318,000 cases of BAC in applications and over 19,000 individual CVEs (as well as 34 mapped CWEs), this has been the most common set of security vulnerabilities in applications in the OWASP dataset.

How Can I Defend Against Access Control Failures?

Checking your access controls requires thorough penetration testing to know that sensitive data is secured and that your systems deny access to the adversary.

OWASP presented an 8-point plan for securing your access controls and restricting access to an unauthenticated user (including stopping regular user accounts from gaining admin rights!)

  1. DENY is the default state for all non-public resources; double-check this to avoid embarrassing oversights that lead to the adversary bypassing access control checks.
  2. Implement access control mechanisms once and re-use them throughout the application; OWASP also advises minimizing Cross-Origin Resource Sharing (CORS) usage.
  3. Aim to enforce record ownership in place of accepting CREATE, READ, UPDATE, and DELETE user rights for any record.
  4. Enforce application limit requirements through domain models.
  5. Limit leaks through web roots by disabling webserver directory listing and keeping file metadata away from prying eyes.
  6. Log access control failures and link admin alerts to attempts on sensitive files.
  7. Rate limit API and controller access to stop attack tools that rely on automation.
  8. Minimize the attack window by invalidating stateful session identifiers on logout.

Running Penetration Tests For Broken Access Controls

Pentesting your access controls is always the best way to really understand your security posture. Running a three-pronged process to test access control can be facilitated through the following methods:

Manual Testing – SAST & DAST

Using your organization’s SAST and DAST tools is the most basic test you should run.

Test access controls early and often in the development process and you will be able to stamp out admin page misconfigurations or access control flaws before they become a bigger problem in your pipeline.

Note: this method is not 100% reliable with most SAST/DAST tools. More sophisticated security tests are necessary.

Manually Testing Your APIs

Going beyond automated tooling, manually attempting to access the admin APIs is the next step.

This is probably the most important way to find out if your application is vulnerable to unauthorized information disclosure – accessing account A and then modifying user names, user IDs, etc. is the easiest way to find out broken methods to access resources, albeit a time-consuming approach.

Burp Intruder

Burp Intruder is a powerful tool that should be used to automatically run brute force attacks against your access controls. There are two ways to get the most out of Burp:

  • Running automated tests on user profiles, such as targetting user ID from 1-100 and trying to hope from authorized access to unauthorized
  • Sniffing for hidden APIs, e.g. attempting to find /profile/admin that is usually hidden and then backward engineering a payload to attack over the exposed admin API

This tool is best used in conjunction (not as a replacement for!) manually testing your APIs – remember, even the best automation sometimes needs a little extra push in the right direction!

Restrict Access to Broken Access Controls

As the high riser of the OWASP Top 10 for 2021, effective Access Control List management is the hot topic for security teams right now. Understanding how you can prevent Broken Access Controls from leaking out into the world is the first step to effectively integrating these tests into your day-to-day security workflow.

Even when your ACLs are properly secured, working through the OWASP Top 10 and following the prevention tips is key to strengthening your security posture. Use the published advice to harden your systems and shut off the adversary before they find new vulnerabilities and exploits in your defenses.

Tutorial

Brute-Forcing Full Drive Encryption

By Karl Gilbert

BitLocker Drive Encryption is an FDE (Full Disk Encryption) feature that is built into the Windows OS and is used to address data theft and exposure scenarios. BitLocker provides the best protection when it is used in conjunction with a Trusted Platform Module (TPM). TPM is a hardware component installed in many new computers and it works alongside BitLocker to protect data and to ensure that the system has not been tampered with while it was offline.

Bruteforcing Full Drive Encryption

In the first part of this tutorial, we will look at brute-forcing BitLocker full drive encryption:

1-  Let’s create a BitLocker-protected drive with an easy-to-guess password for our brute force demon. Here we have a drive F: where we are implementing BitLocker:

2- Next, we will be creating a Disk image of our BitLocker drive using the..

Continue Reading Here…

Emerging Attacks & Analysis

The Attack on the IT Sector
By Joe Anich

Microsoft has observed numerous threat actors in the world attempting to steal customer credentials by targeting IT services companies, giving them the ability to attack further. The IT companies in the crosshairs of this are likely the providers for customers of interest. It seems that most of these IT companies are based in India, Israel, and the UAE. The groups being tracked are DEV-0228 and DEV-0056, both with similar activity from July to September of this year.

Back in July of this year, DEV-0228 compromised an IT provider in the Middle East and in the following months, several organizations in Israel’s IT, defense, energy, and law sectors with relations to the compromised IT provider were compromised. Check out the public article released by Microsoft Threat Intelligence Center (MSTIC) and Microsoft Digital Security Unit (DSU), to learn more about the activity surrounding this attack.

One example of downstream attacks came when a law firm in Israel had their on-premises network compromised. The account used was managed by the IT provider via a tool called PAExec, which is a redistributable and open source version of Microsoft’s PsExec. Leveraging tools like this they went for persistence to then dump LSASS. The article above also references the IOC’s for the tools often seen being staged, which are also detected across Microsoft security products as the following:

  • Defender AV
    • Backdoor:MSIL/ShellClient.A
    • Backdoor:MSIL/ShellClient.A!dll
    • Trojan:MSIL/Mimikatz.BA!MTB
  • Alerts with the following titles in the security center:
    • DEV-0228 actor activity
    • DEV-0056 actor activity

As always, we will cover some of the mitigations provided by Microsoft across the M365 stack. The first of these mitigations would be to enable multifactor authentication (MFA) for all accounts. That extra layer of identity verification can help prevent credentials from being compromised. Furthermore, you can enhance when MFA is required by using conditional access, with trusted locations as an example. Read more about Azure MFA here – Azure AD Multi-Factor Authentication overview | Microsoft Docs

Next and as always, Attack Reduction Surface Rules (ASR). In this case, we are talking about the rule called “Block credential stealing from the Windows local security authority subsystem (lsass.exe)”. This rule locks down the local security authority subsystem service or LSASS. The helps mitigate against credential stealing and dumping of the LSASS service. If you use Security Recommendations in the M365 Defender portal, found here Security recommendations – Microsoft 365 security, you’ll see this rule and additional information about it as it pertains to your environment if you have devices not using it. See the figure below for an example.  While you are there, check out all of the recommendations and start planning out how you can get them implemented, it’s a great place to the gaps you have and what impact you may have when closing them.

Security Recommendations
Another protection that falls in line here is the Credential guard, which uses virtualization-based security to protect and store secrets. See the illustration below.

Credential Guard
Wrapping up let us cover a few more recommendations that can help with these types of attacks. Exchange online access policies should be something to consider if you are leveraging Exchange online. In particular, the “Block ActiveSync Clients” policy. It prevents ActiveSync clients from bypassing conditional access policies. Disabling basic authentication has been recommended for some time, but some customers still have not done it. This should also be something to consider, as it forces all client access requests to use modern authentication.

Those are just a few things that you can do to put yourself in a better position, of course, we could list 20 more things to do however we wanted to focus on protections that help in the context of the scenario discussed at the beginning.

To close out, I will throw some Kusto queries you can use in advanced hunting, these are the same queries provided in the MSTIC and DSU referenced article above. They are there for you to quickly check for exploitation activity as it relates to this.

Surface use of PAExec in your environment

  • Look for PAExec.exe process executions in your environment. Run query

DeviceProcessEvents
| where FileName =~ “paexec.exe” or ProcessVersionInfoOriginalFileName =~ “paexec.exe”
| where not(ProcessCommandLine has_any(“program files”, “-service”))

Surface files created in the Windows\Tapi directory

  • Look for files created in the Windows\Tapi directory. Run query

DeviceFileEvents
| where FolderPath has @”C:\Windows\TAPI”

Suspicious PowerShell commands

  • Look for suspicious PowerShell process execution in your environment potentially related to this threat. Run query

DeviceProcessEvents
| where ProcessCommandLine has_any(“/q /c color f7&”, “Net.We$()bClient”, “$b,15,$b.Length-15”) or
(ProcessCommandLine has “FromBase64String” and ProcessCommandLine has_all(“-nop”, “iex”, “(iex”))

As always, thanks for tuning in for another weekly read as we discuss the current threat landscape and what’s trending within it!

Secret Knowledge: Building Your Security Arsenal

Discover useful security resources, cheatsheets, hacks, and open-source CLI/web tools.

New & Trending

Security Audit & Monitoring

  • auditd – Provides a way to track security-relevant information on your system.
  • Lynis – Battle-tested security tool for systems running Linux, macOS, or Unix-based operating system.
  • ossec – Actively monitoring all aspects of system activity with file integrity monitoring.
  • OSQuery – SQL-powered operating system instrumentation, monitoring, and analytics framework.

The SecPro is a weekly security newsletter to help you stay sharp and upgrade your skills with trending threat insights, practical tutorials, hands-on labs, and useful resources. Build skills in as little as 10 minutes.

Stay up to date with the latest threats

Our newsletter is packed with analysis of trending threats and attacks, practical tutorials, hands-on labs, and actionable content. No spam. No jibber jabber.