Having delivered security consultancy as part of Portcullis/Cisco for over 15 years, I’ve seen a variety of shades of broken. Since I recently spent some time on secondment to one of our customers to help them design, build and operationalise security as part of their digital transformation programme, I got to thinking: what would I do if I wanted to get projects delivered right? With apologies to grsec, Jericho Forum, BeyondCorp and Trusted Computing, what followed was part philosophy, part technical brain dump, the result being my take on security engineering and how to build defensible systems. This talk includes the following hits:

• Helping the blue team – a case study in 3 parts…
• Blue doesn’t have the man power to adopt gift wrapped improvements let alone offensive research thrown over the wall
• Static passwords – why the hell are we still using them?
• Vulnerability management – didn’t we say blacklists were bad?
• Forget about penetration testing – what are your controls?
• Is there another way to report – why don’t businesses listen to us?
• Monetising MITRE – can we make money out of CVEs?

SEAMFDS.pdf
June 28, 2019

311.8 KiB
MD5 hash: 185701fbc113ca2a676e802b61df53e2
Details

Date:

June 28, 2019

The post Security Engineering – A manifesto for defensive security appeared first on Portcullis Labs.

Background to Active Directory integration solutions

Having seen an uptick in unique UNIX infrastructures that are integrated into customers’ existing Active Directory forests, the question becomes, “Does this present any concerns that may not be well understood?” This quickly became “What if an adversary could get into a UNIX box and then breach your domain?”
Within a typical Active Directory integration solution (in this case SSSD), the solution shares a striking similarity to what a user might see on Windows. Notably, you have:

• DNS – Used for name resolution
• LDAP – Used for “one-time identification” and assertion of identity
• Kerberos – Used for ongoing authentication
• SSSD – Like LSASS
• PAM – Like msgina.dll or the more modern credential providers

You can see a breakdown of this process here. Unlike Windows, there is no Group Policy for the most part (with some exceptions), so policies for sudo et al. are typically pushed as flat files to hosts.

Our research

Realistically, the threat models associated with each part of the implementation should be quite familiar to anyone securing a heterogeneous Windows network. Having worked with a variety of customers, it becomes apparent that the typical UNIX administrator who does not have a strong background in Windows and Active Directory will be ill-equipped to handle this threat. While we’ve been talking about successful attacks against components such as LSASS and Kerberos for quite some time, Mimikatz dates back to at least April 2014, and dumping hashes has been around even longer. Pwdump, which dumped local Windows hashes, was published by Jeremy Allison in 1997). However, no one has really taken a concerted look at whether these attacks are possible on UNIX infrastructure, nor how a blue team might spot an adversary performing them.

As a result of this research, we were able to develop tactics, tools, and procedures that might further assist an attacker in breaching an enterprise, and we began documenting and developing appropriate strategies to allow blue teams to appropriately detect and respond to such incursions. The Black Hat EU slides can be found here and whilst the tools we developed can be found on our GitHub repo.

The post An offensive introduction to Active Directory on UNIX appeared first on Portcullis Labs.

Over the past fifteen years there’s been an uptick in “interesting” UNIX infrastructures being integrated into customers’ existing AD forests. Whilst the threat models enabled by this should be quite familiar to anyone securing a heterogeneous Windows network, they may not be as well understood by a typical UNIX admin who does not have a strong background in Windows and AD. Over the last few months we’ve spent some time looking a number of specific Active Directory integration solutions (both open and closed source) for UNIX systems and documenting some of the tools, tactics and procedures that enable attacks on the forest to be staged from UNIX.

This talk describes the technical details regarding our findings. It includes Proof of Concepts (PoC) showing real-world attacks against AD joined UNIX systems. Finally, potential solutions or mitigation controls are discussed that will help to either prevent those attacks or at the very least to detect them when they occur.

Tools referenced in this talk include:

• Linikatz
• JohnTheRipper dynamic.conf rules
• metasploit-framework post-exploitation modules
• auditd policies
• fuzzers

eu-18-Wadhwa-Brown-Where-2-worlds-collide-Bringing-Mimikatz-et-al-to-UNIX.pdf
December 6, 2018

724.9 KiB
MD5 hash: cc712c5e46b16fbff22a2566b1248a91
Details

Date:

December 6, 2018

The post Where 2 worlds collide: Bringing Mimikatz et al to UNIX appeared first on Portcullis Labs.

Building on my blog post on Cisco’s security blog entitled The Importance of Logs, I put together a presentation that picks apart some of the practical aspects of building a successful logging capability focusing on the need to document “good” and curate “bad”.

The purpose of this talk is not to help you build a SOC in 30 minutes, rather it looks at how logging can go wrong and how to plan in order to get it right. The talk includes some composite case studies which highlight some of the challenges that we’ve seen over the years (particularly when responding in customer breaches) and makes some suggestions on where interested organisations should focus their efforts next.

SSWTIOLYWSWYDL.pdf
October 31, 2018

463.7 KiB
MD5 hash: 390c1d8b29e74f2c15df434b4d0d9f99
Details

Date:

October 31, 2018

The post The importance of logs: You won’t see what you don’t log appeared first on Portcullis Labs.

What’s a W^X policy, anyway?

W^X is an exploit mitigation tactic in which memory pages that are, or have ever been, marked as writable can never be marked as executable during the process lifetime. The old exploit tactic of putting your exploit payload on the stack (or heap) and calling it directly was killed off with no-execute (NX, also known as hardware DEP on Windows) support, which made ret2libc/ROP approaches much more popular. ROP involves finding small pieces of existing executable code in the application and its libraries, chaining them together using the stack, with the goal of calling an API or two to allocate some executable memory for the payload to be copied into. On Windows this is usually done with a ROP chain to the VirtualAlloc() API, passing PAGE_EXECUTE_READWRITE() in order to allow for both writing the data in and executing it afterwards.

Enforcing a W^X policy breaks this approach, as an exploit cannot allocate memory as RWX, or as RW and then later executable. Applications in Windows 8.1 and later can opt into a W^X policy, enforced by the kernel, this using the SetProcessMitigationPolicy() API with the ProcessDynamicCodePolicy() argument. Of course, this is also the boring way (at least for this article).

The small print

I’m not going to make you read a sixty-eight page EULA and sign your life away on the dotted line, but there are things you should know before you gallivant away with some source code and a dream of securing your applications:

1. I am a terrible C++ programmer. You should absolutely not use my code in production
2. This is a proof-of-concept, so you still absolutely should not use it in production. And probably not any other context than “I want to learn how this works” or “I want to torture my eyes by reading wonky code”
3. While some effort has been made to make the PoC thread-safe, there are some race conditions (probably security-critical ones) that exist and I haven’t done anything to fix for reasons of keeping the code fairly simple
4. Only VirtualAlloc(), VirtualProtect(), and VirtualFree() are hooked. There are ways to get around this (e.g. calling `ntdll` functions directly, or using `Ex` suffix variants) so, again, don’t expect any concrete security from this
5. In case you didn’t already get the memo, implementing this kind of security feature from usermode is colossally silly, particularly when the OS offers a proper version that is enforced in the kernel. An attacker who expects this usermode “protection” can tailor their exploit to bypass it in most cases
6. Just like the kernelmode version, this breaks any application that uses JIT compilation. So that means all browsers, anything that uses Java, .NET, or a modern JavaScript engine. It also means things that embed a web frame

Caveat emptor, and all that.

How does this thing work?

The actual approach is fairly simple:

1. Hook APIs
2. Reject calls that would result in a page being writable and executable at the same time
3. Track calls that result in a page being writable, and deny future calls that would make those pages executable

The grunt work involved with hooking APIs is fairly boring, so I enlisted the help of the mhook library by Marton Anka. This library provides a really intuitive way of hooking APIs:

Mhook_SetHook((PVOID*)&OriginalVirtualAlloc,   HookedVirtualAlloc);
Mhook_SetHook((PVOID*)&OriginalVirtualProtect, HookedVirtualProtect);
Mhook_SetHook((PVOID*)&OriginalVirtualFree,    HookedVirtualFree);

Each call to Mhook_SetHook() takes a pointer to the original API as the first parameter, and a pointer to the hooked version you want to replace it with.

VirtualAlloc hook

The VirtualAlloc hook checks if flProtect is either PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY. The former is the general-case RWX protection, and the latter is used when the segment of memory is a memory-mapped file. If either of these protection options are detected, the operation is failed with an access denied error.

Next, we perform the requested VirtualAlloc() call via OriginalVirtualAlloc. If this succeeds, we check to see if the requested allocation contained a writable flag (e.g. PAGE_READWRITE or PAGE_WRITECOPY) and, if so, add that allocation’s page address and allocation size to a tracking list. This allows us to later reject requests to make these pages executable, as they have been tainted with the writable mark.

VirtualProtect hook

The VirtualProtect hook is the most involved. As with VirtualAlloc it first rejects RWX protections outright. It then checks to see if the requested protection is executable and, if so, checks if the page exists within the boundary of a tracked writable allocation, i.e. if it starts within one, ends within one, or starts before and ends after one. This prevents tricks like allocating a small chunk of writable memory inside a larger readonly block, then calling VirtualProtect() over the whole block to make it all executable.

In order to protect against abuse of writable memory that was pre-allocated by the loader (e.g. the .data section) the code also calls VirtualQuery() to test the existing protection status of the memory, just in case we aren’t tracking it.

Another case we need to handle is similar to the VirtualAlloc() call. If the call is making memory writable, we need to track it. First we check if the exact allocation is already present in our tracked list, then if it isn’t we add it. It doesn’t matter if we have overlapping tracking metadata for writable allocations – we handle this case in our hooked VirtualFree(). Speaking of which…

VirtualFree hook

This hook is fairly simple. We just iterate over every item in the tracked allocations and remove them if they cover the address being freed.

Testing

The initial driver for me writing this code, before I decided to implement a full W^X policy with it, was to test for cases where an application under test would attempt to allocate RWX buffers, and if they actually needed those buffers to be executable (i.e. swap RWX for RW and see if you get a crash). For fun, I injected this DLL into a bunch of different programs. Many (e.g. notepad, calc) just work without problems, as they don’t rely on RWX memory at all. A number of others (e.g. Chrome, Spotify) crash due to JIT code that runs inside the process. It was quite fun to watch these allocations occur in realtime via debug messages.

Bypasses

There are a number of ways to bypass the PoC as it stands. I thought about eliminating them, but I think it’s more fun to go through the code and identify the problems.

The first and most obvious way is to ROP to GetModuleHandle() and find the original APIs that way, totally bypassing the checks. It is possible to fix this to some extent by hooking GetModuleHandle() and similar APIs, but this mostly ends up as a cat-and-mouse game. This is why you should implement this stuff in kernelmode.

The second way is a race condition. In both VirtualAlloc and VirtualProtect hooks we call the original function, then lock the tracking list and add the new allocation to the tracked list. It is possible to call either of these functions twice. This can be fixed with a global allocation mutex.

There’s also a potential TOCTOU race condition in our VirtualProtect hook, where we check the page protection using VirtualQuery and later potentially call VirtualAlloc based on the result. However, the attacker would have to get the application to call the unhooked VirtualProtect in order to exploit this particular issue.

Finally there’s a really interesting case – marking a page as writable, filling it with data, freeing it, then re-allocating as read-execute and hoping that you get the same page back before it gets reset to zeroes by the OS. In fact, when I thought of this issue, I wondered whether I might have stumbled across a potential mitigation bypass in the real W^X implementation for Windows, and my eyes turned into dollar signs. Thankfully (or sadly) the clever folks at Microsoft thought of this already, and forced every released page to be reset.

Closing words

I hope that this ham-fisted approach to implementing W^X has been of some educational use, at least in terms of thinking about how the protection can be implemented in practice. If you’d like to follow along at home, the code can be found in the WXPolicyEnforcer project on the Portcullis Labs GitHub. It is released under MIT license.

The post Enforcing a write-xor-execute memory policy from usermode appeared first on Portcullis Labs.

Why?

If you take a look over our advisories page, over the last couple of years I’ve spent a good deal of time dealing with vendors who, for one reason or another have shipped binaries where it is possible to inject untrusted code into privileged processes, notably but not exclusively via DT_RPATH.

What’s the fix?

More often than not, the underlying issue is an empty element within the DT_RPATH header or equivalent. Sometimes it’s not, but even in those cases, it is largely that one or more elements isn’t qualified (i.e. it doesn’t start with /). The patch I have circulated fixes this, by causing the runtime linker to ignore any elements of DT_RPATH and LD_LIBRARY_PATH that do not start with a /, and/or junk any use of dlopen() where the filename is likewise unqualified.

Won’t this break stuff?

Maybe (certainly it is means a change to glibc behavior), but more often than not, the fact that a given binary currently works in an unsafe way is a bug – and an exploitable one at that. Moreover, Solaris has had a similar sanity check (in their case only for privileged setUID binaries) for a good number of years without serious incident. I believe we should be fixing software that exhibits the behavior I’ve described, but this patch will (I think) kill the bug class irrespective of that.

I’ve already had some useful feedback about non-privileged use cases that would be affected by the change. It would be dead easy only to use the part of the patch that rejects unsafe linker paths for setUID binaries only. However, as I have said, that offers less protection. I’d like to make the patch consumable and indeed, I’m leaning towards having $RELATIVE (new) and $ORIGIN honoured when the binary isn’t setUID.

Further thoughts?

The patch I have submitted is the most robust variant I’ve produced in that it kills unqualified linker paths, irrespective of the privileges with which the affected binary is executed. We could kill the checks for non-setUID binaries or we could add some additional errors in such cases. I did experiment with only checking a subset of cases (namely where LD_LIBRARY_PATH itself is set) if the process wasn’t privileged, but in the end, I concluded that the loading of any unqualified linker path could provide an exploit vector (if the non-setUID binary is executed from a privileged process etc) and so erred on the side of caution. A useful variant of my patch for auditors is one that logs dangerous conditions rather than reject them outright, but I’m unconvinced that it is helpful for the masses.

The next step will be (once I have digested the views of the oss-security community) to submit it directly to the glibc maintainers. Sharing it with security folk (who may well wear slightly more positive hats to begin with) seemed like a safe place to start but a fix that no one uses does not offer any real value.

The post Fixing the links: Hardening the linker appeared first on Portcullis Labs.