Hver dag står it-kriminelle og andre ondsindede aktører verden over bag mere eller mindre alvorlige sikkerhedshændelser. Heldigvis arbejder mange gode sikkerhedsfolk på at identificere og udbedre sårbarheder i software – selvom det med stor sandsynlighed ville være en bedre forretning at sælge deres research til højestbydende. Man skal tage sikkerheden alvorligt, også når ingen kigger.
Interview med: Claus Vesthammer, COO og Security Advisor hos Improsec ApS
Improsec er specialister i pragmatisk IT-sikkerhed og er netop flyttet ind i på Univate (en del af Symbion) for blandt andet at være tæt på de mange interessante tech-virksomheder, der til dagligt holder til i iværksættermiljøet. Improsec foretager vurderinger af virksomheders forsvarsmekanismer og rådgiver om prioritering og implementering af organisatoriske såvel som tekniske tiltag.
Læs mere her.
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 setting 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.
Klumme: Stærke passwords, der ikke kan hackes, er en mangelvare i danske virksomheder. Men det kan der gøres noget ved. Her er syv skridt til virkelig gode passwords.
Jeg ser ofte implementerede kontroller omkring password kompleksitet. Formålet med disse kontroller er at sikre, at brugere anvender et stærkt password. Altså et password som en angriber ikke vil kunne udnytte og benytte i et angreb i mod virksomheden.
Det er min påstand, at klassiske adgangskodepolitikker med et krav om 8-10 karakterer, store og små bogstaver, tal eller specieltegn, ikke fungerer til at sikre, at brugere benytter et stærkt password.
Læs mere her: https://www.computerworld.dk
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.
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