Another security conference has come and gone and I surprisingly do not feel the doom and gloom of knowing that my data is being utterly owned. Two of the more interesting talks focused on protecting environments through Powershell and how to thoroughly test applications with more than just limited security automated tools.
Defending with Powershell
Sean Metcalf presented an interesting approach to using Powershell. In order to properly protect a system, one must understand how an attacker may abuse the tool. Therefore, both defense and attacking techniques were presented.
The latest version of Powershell, v5, comes equipped with numerous tools to help administer and secure systems. One such method of detecting malicious scripts is to enable script block logging. This feature helps prevent obfuscation and encoding, usually used to evade antivirus or security checks, by displaying commands as they are interpreted. Also with this set, when dynamic code is used, the additional applications leveraging the scripts are also logged.
One method of attacking a system using Powershell is to run a malicious tool, mimikatz strictly in memory. Doing so avoids standard means of detection and prevention. To counteract this attack, the newest Powershell version can apply a feature called Constrained Language Mode, which prevents Powershell from running certain applications in memory. This list is limited by Windows Defender and Antivirus protections.
However, the battle between red and blue teams (attackers and defenders) is iterative and by performing dll hijacking, attackers may compromise the Defender rules to add mimikatz to the whitelist where it is then believed to be a vetted application. Sean’s presentation included a tweet from Matt Graeber where the code to bypass Windows 10 Antimalware Scanning Interface (AMSI) fit within the 150 character limit. This worked by exploiting calls to earlier versions of Powershell and initiated several more rounds of battle between attack and defense:
Defense: Remove Powershell prior to v5.
Attack: Obfuscate malicious scripts
Defense: Perform character analysis based on standard deviations of characters within code
The last method is a work in progress to counteract the latest malicious Powershell tool developed last month. Normal code should not have its most common characters be {, }, ‘, or “ and any script using these values is likely to be obfuscated and should not be executed.
It is an ever ongoing battle between attack and defense, forcing information security professionals to learn, use, and adapt with each tool as they evolve over time.
More than Automated Scans
Many companies consider security testing complete once an automated scan is complete. This stance is inherently flawed as there are significant limitations in the scope and capabilities of the tools used to perform automation scans.
Zack Meyers and Andrew McNicol offered a strong approach to improve vulnerability assessment techniques following an automated scan. Automated scanners are great at discovering features and locating potential sources for further exploitation. However, these tools cannot identify all vulnerabilities and rarely test the legitimacy of a finding through exploitation. In a 2014 DHS study, 67% of their vulnerability findings were made through manual testing as opposed to automated testing.
One of the examples of a vulnerability identified through manual testing that was missed in an automated scan came from an unvalidated POST request for an application’s Contact Us page. This request included the subject line, message, target email address, and sender’s email address. Where a scanner was unable to understand the danger of passing these parameters, a manual test revealed an abuse case in which the Contact Us feature sent custom emails. By controlling the email address of the sender, and sending this from the application’s email server, this vulnerability transformed the email server into an attack vector for crafting phishing emails.
Another weakness of automated scans is that they have difficulty combining several low findings to create a high vulnerability. One of the low findings allowed for username enumeration. When a user attempted to login with a valid username as opposed to an invalid username, there was a 0.1 second difference in response time. This exploit can be used to create a list of valid usernames. Additionally, there were low findings for both a lack of anti-automation controls (CAPTCHA) and insufficient account lockout. By combining all three of these low vulnerabilities, valid usernames can be identified and brute force password cracking can be applied to guess legitimate passwords.
The talk’s overall advice is to incorporate automated scanning as a necessary first step for security testing. However, these must be supplemented with intelligent manual tests.
Overall, the talks at the 2016 B-Sides DC conference presented a series of steps to improve the security of tools running on a server and how to apply new methods in searching for vulnerabilities.
