Tech Blog
This is the second blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.
In this blog post I will tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.
This is the first blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.
In these blog posts I will be a bit verbose and give insights into the process. Concrete exploitation steps and code is listed at the bottom.
The past week I have been fortunate enough to present at both Black Hat USA and DEF CON. My topic was on leveraging Write-What-Where vulnerabilities for Windows 10 Creators Update. You can find the slides here. In my DEFCON talk I mentioned additional KASLR bypasses, one of those use the field Win32ThreadInfo from the TEB to leak a pointer to ntoskrnl.exe. This pointer can be used to achieve arbitrary kernel mode code execution as explained in my presentation.
A couple of months ago I did a blogpost on data only attacks in kernel exploitation, which you can find here. I used the tagWND object to locate the EPROCESS of the current thread, while that technique is still perfectly valid, I wanted to present another way of doing it which does not involve creating a tagWND object.
When IBM promised to release a workaround for the vulnerability we found in their product, I truly expected such a widely respected company to release an enterprise-ready workaround, and not just a manual approach to set registry permissions in the GUI.
A few months back, my good friend Flemming Riis and I found a fundamental security vulnerability in the IBM Tivoli Storage Manager (TSM) client, while researching IBM TSM’s handling of authentication ("Node ID" and "Node Password") and unsafe implementations of TSM, which we covered in a few blogposts Backdoors and data compromise via Backup Systems (in danish only) and Protecting your secrets.
We couldn't believe our own eyes when we, in very little time, found a pretty important – and incredibly trivial – security vulnerability in the TSM product.
We then initiated a Responsible Disclosure process with the IBM Product Security Incident Response Team (PSIRT), which I will describe further below, as it illustrates how important it is for researchers to set requirements and insist on deadlines being met.
This blog post was a submission to Microsoft Bypass Bug Bounty program, but was not eligible to the scope of the program. Thus I am releasing a blog post on the technique which is based on leaking the stack address and overwriting the structured exception handler, thus turning a use-after-free into a structured exception handler overwrite.
To facilitate this bypass, I have again chosen to use vulnerability for Internet Explorer 11 which was patched in MS16-063 in June of 2016 and written about by the company Theori and I’ve previously used in CFG bypass posts here and here.
This blog post is an addendum to the three blog posts about Windows kernel shellcode I posted based on the techniques by Cesar Cerrudo. You can find the previous blog posts here, here and here.
An assumption in my previous blog posts was the ability to execute arbitrary assembly code in kernel context. While it is possible to obtain this from a write-what-where vulnerability condition and often from a pool overflow, it does require both a kernel read/write primitive and a KASLR bypass to some kernel driver. If we limit ourselves to using the read/write primitive to perform a data only attack, we can omit the KASLR bypass. This blog post describes how each of the three methods can be converted to a data only attack instead of an actual shellcode.
This blog post is the third in the series on Windows kernel shellcode and rounds off the methods described by Cesar Cerrudo at Black Hat in 2012. You can find part 1 here and part 2 here. This time we focus on the privileges in the process token.
This blog post is the second in the series on Windows kernel shellcode and picks up the nulling out ACLs method described by Cesar Cerrudo at Black Hat in 2012. You can find part 1 here.
The same assumptions as in the previous blog post apply here, that being the exploit has gained arbitrary kernel mode code execution and we can handcraft the assembly code to run. I see the ACL NULL technique used almost as much as the token replacement one. The idea is to locate the SecurityDescriptor, or in effect the ACL, of a privileges process and replace it with NULL. This value tells Windows that no permissions have been assigned for the process and hence everyone has full access to it. In Windows 10 Anniversary a mitigation for this has been implemented as noted by Nettitude Labs
When creating Windows kernel exploits the goal is often to somehow gain higher privileges, often SYSTEM. This part of the exploit writing is normally the very last part, and often not very discussed since so many steps come before it. The most common ways I’ve seen that done are either by stealing a process token of a privileged process or by removing the ACL of a privileged process. In essence the techniques I normally come across and use myself are derived and often referenced from the Black Hat presentation by Cesar Cerrudo in 2012. It is a great presentation and white paper and should definitely be read. There are however two issues when trying to use the methods from the white paper; firstly, it does not supply the actual shellcode only the technique in theory and secondly, it was written prior to the release of Windows 8.1 much less Windows 10.
Sammen med min gode ven og kollega, Flemming Riis, har jeg på det seneste undersøgt opsætningen af nogle udbredte backupsystemer, herunder hvordan de potentielt kan misbruges af angribere.
Tanken er ikke at »male fanden på væggen«, men at gøre opmærksom på en reel problemstilling, som i følge vores erfaring er noget overset.
Læs mere her: https://www.version2.dk
In the last couple of years I have had an interest in application whitelisting bypasses and avidly followed the work of Casey Smith (@subtee) and Matt Graeber (@mattifestation). The major conclusion from their work is that application whitelisting has to be locked down to avoid trusted application launching attacker code. While it seems quite clear that on Windows 7 and 8.1 Powershell is an easy way to bypass application whitelisting through reflective PE injection, Windows 10 is a different story. With the activation of Powershell Constrained Language Mode along with AppLocker in Windows 10 this avenue seems closed. While Casey Smith has a lot of research on bypassing application whitelisting in other ways here, they all assume prior code execution on the victim machine. I am a great fan of PowerShell Empire by Veris Group as an attack framework, and I really like the HTML Application attack vector. As I will show below this attack does not work out of the box when Powershell Constrained Language Mode is enabled. But then I got to thinking whether using prior public research and code would it make it possible to make the attack vector viable again. This blog post describes how I did that though a lot of nested techniques and code.
Usage of Windows kernel exploits have been on the rise, and are often used to break out of a browser sandbox. Many of the vulnerabilities found over the years have been in the driver win32k.sys, which handles system calls from gdi32.dll and user32.dll. To try and mitigate many of these vulnerabilities proactively Microsoft has implemented what is call Win32 Syscall Filter in Windows 10. The overall idea is to be able to block many System calls to win32k.sys for an entire process, such that unknown vulnerabilities cannot be taken advantage of. I have not been able to find many details about the implementation and how effective it really is, the only discussion I’ve found is the presentation Rainbow Over the Windows by Peter Hlavaty.
When I started out tinkering with exploit development, I would have loved to receive some help on how to set up a good exploit development environment. For those of you who have tried exploit development before, know that there is a lot of trial and error, hence repeating actions as fast as possible and with as little manual work makes the process much more effective. In this blog post I want to share my exploit development environment and explain how I have configured it.
About two weeks ago a blog post was issued from the Windows Offensive Security Research Team (OSR) about hardening Windows 10 against kernel exploitation:
Kernel exploitation on Windows 10 almost always requires a kernel read and/or write primitive. So OSR reported on how Windows 10 Anniversary Update has been hardened to mitigate usage of one of the commonly used primitives. The primitive in question is comes from the tagWND object, which is the kernel mode representation of a window. While reading the blog post, I remembered back to October of last year and some research I did at the time. About two weeks before Black Hat Europe 2016, I was looking into using the tagWND object as a read/write primitive on exactly Windows 10 Anniversary Update. But before I got around to writing up anything about my findings the Attacking Windows By Windows talk from Yin Liang and Zhou Li came out at Black Hat Europe.
This blog post is part two of Bypassing Control Flow Guard in Windows 10. It is also the result of some research I did back in July of 2016, but did not have the possibility to publish before now. The same Internet Explorer vulnerability is used with the same original proof of concept by Theori. This blog post will present another method of bypassing CFG, which also still works on Internet Explorer, but not in Microsoft Edge, due to suppressed API’s. It is assumed that the reader has read the previous blog post, so the details of CFG are not explained, and I jump right to the point of having an arbitrary read/write primitive.
This blog post is the result of some research I did back in July of 2016, but did not have the possibility to publish before now. In June of 2016 Theori published a blog post on an Internet Explorer vulnerability which was patched in MS16-063, the exploit they wrote was for Internet Explorer 11 on Windows 7, and as their own blog post indicates the exploit will not work on Windows 10 due to the mitigation technology called Control Flow Guard. This blog post describes how I ported the exploit to Windows 10 and bypassed CFG, in fact I found another method, which will be posted in an upcoming blog post.
Klumme: Mange virksomheder overlader it-sikkerheden til en enkelt solid mur og bedagede passwords. Men det er ikke moderne it-beskyttelse.
Jeg har flere år bag mig som it-sikkerhedsrådgiver, og jeg ser gang på gang, at der primært fokuseres på skalsikring - altså fokus på perimeteren.
Selv i it-revisionsrapporter kan man stadig finde argumenter som "da serveren ikke har adgang til internettet, ses det ikke som værende en risiko". Her er det altså de personer, som virksomhedslederne lytter til, der endnu ikke har indstillet sig på den virkelighed, som findes.
Det er som om, at vores mentalitet er blevet tilbage i middelalderen. Hvis man dengang havde en kiste med guld i, byggede man en stor mur omkring den for at beskytte den.
Men man havde stadig samme problem, som man har i nutidens it-systemer. Når en angriber kommer igennem muren, mister man hele kisten med guld. Det gav god mening dengang, men i dag er det altså muligt at beskytte hver enkelt guldmønt for sig.
Læs mere her: http://www.computerworld.dk
Servicekonti i Active Directory er ekstraordinært udsatte og sårbare overfor en bestemt type angreb, som ofte viser sig yderst effektivt til at opnå fulde administratorrettigheder i domænet. Man lykkes med det igen og igen under penetrationstest og intet afholder ondsindede angribere fra at gøre det samme.
Med en almindelig phishing mail og tilhørende simpel malware, eventuelt bare i form af et script, kan man i løbet af meget kort tid opnå Domain Admin rettigheder eller tilsvarende, med begrænset risiko for at blive opdaget. Den lidt nysgerrige interne bruger kan med lidt teknisk snilde gøre det samme.
Denne angrebsvektor har efter min mening slet ikke fået nok opmærksomhed, og helt nye værktøjer gør angrebet endnu lettere at gennemføre, hvorfor dette blogindlæg har fået prioritet over andre i bunken.
Yderligere er det noget, som man rent faktisk kan gøre noget ved, forholdsvis enkelt, og opnå væsentlige forbedringer af virksomhedens forsvarsmekanismer. Der er lavthængende frugter at plukke!
Læs mere her: https://www.version2.dk/blog/spn-1020590
Jeg er så småt ved at være tilbage mentalt efter lidt over en uges tid i Las Vegas, hvor jeg igen i år deltog på Black Hat og DEF CON konferencerne, nu fjerde år i træk.
Først fire dage med et fremragende kursus i offensiv PowerShell scripting med Veris Group, derefter to dage med Black Hat briefings, og så tre dage på den berygtede DEF CON konference.
Jeg burde nok skrive et mere detaljeret indlæg om alt det jeg lærte undervejs, hvad der var godt og hvad der var skidt, alle de dygtige mennesker man møder osv., men jeg vil i stedet her fokusere på den besynderlige kontrast, jeg som "IT-sikkerheds-nørd" oplevede til "resten" af Las Vegas. Den verden der upåvirket pulserede støjende afsted, mens hackere fra hele verden midlertidigt, tilsyneladende i al ubemærkethed, havde opbygget et blomstrende hovedkvarter i dens midte.
Læs mere her: https://www.version2.dk/blog/bhdc-902530
