crazylazy.info

txt

Forensics in pentesting?

Many people in pentesting have got incident response background. You saw systems being compromised, saw them failing, analyzed attacks and afterwards you were able reconstruct them. Very often attacks share a same pattern - you could say - need a common denominator of technical tricks. Of course this common denominator changes constantly. And that's were nowadays forensic science comes in handy.

Going through Windows Registry entries, something normally no one does, suddenly becomes essential. Searching for new hidden Autorun elements, reading the Logs. To be able to write and fight Malware the focus is on the raw backend functions. Recently a new book by Harlan Carvey has been published. He reveals lots of tricks about Windows Registry design and how to successfully take advantage of the many information, that are stored in there. I was shocked that it's so easy and so much. It seems for performance optimization and usability improvements modern operating systems store a lot about what the user does.
The book is sold with a CD, that contains small sample Perl-parsers to extract Memory segments. The problem is, that it's Windows 2000 based, and it seems Microsoft changed the memory architecture in XP, Vista, and maybe Windows 7. So you need to rewrite the parsers or use volatility. In every case you'll find a lot of helpful information in the source. Even the demo videos are Windows 2000 based, and that makes them kind of useless nowadays for realistic adaption.

You don't need lots of imagination to see that the information an operating system more or less secretly stores about a user's behavior have got a certain value. As long as he doesn't know that statistics are made.
Encrypted data are the one thing, but if there's a list of recently accessed files, that often reveals enough to be an entry point. Analyzing the running processes, listing them, dumping their address space and searching for rawly stored passwords, variables, and authentication tokens is easy since the Cold Boot attacks were published and lots of software has been written to ease this.

What makes forensics interesting for pentesting purposes doesn't necessarily just lie in the post-exploitation methodologies; or in incident analysis or response. Many software-errors are exactly there, where there's no GUI, no input-validation, and no user expected. - Feeding applications with potentially dangerous data, fuzzing, is only effective if you know where to do that. - Targeting in general becomes more easy if you're somewhere where you are not expected - be it on the network or on the system.
And that's exactly where forensics is, and where today's Malware is. That's not just a coincidence: they want the data. Of course for different purposes, but that's not the point. Both target the user and not the system. That's what makes them effective.

Clean it up or isolate it - how to avoid a local Charie-like pwnage

Todays software is vulnerable. It's not that we need Pwn2Own on CanSecWest to know that. Every good software developer knows that his code has certain weak points. - It's just: eliminating the errors is like hunting a fox: you've to dig down deeply and send a dog into the ground. Shooting it isn't the issue. But finding it.
Because of the fact that software-development is expensive but necessary for modern features, time consuming tasks like just bug-finding aren't as prioritized as they should be. Furthermore a deadline is a deadline is a deadline. And last but not least: in some cases it is highly unlikely that the particular weak-point in code is abuse-able. If it's just causing some performance gaps or causing errors at runtime - that's not necessarily important. And even if - from a security standpoint - abusing it is possible, there's isolation.
The architecture of modern operating systems contains different feature-sets to sandbox running processes: Windows has got syscall-ACLs, Linux - ptrace, MacOS has sandbox-exec, FreeBSD has got systrace... it's not used very often. I guess it's a good idea to start to do so now. Sandboxie, to mention a Windows chroot, works very fine.
- What just bugs me: why does no browser do this by default? All vendors talk about hilarious security features like Private Surf-Mode or shiny base64-encrypted Password-Managers. It seems they don't concentrate on effective security measures.

Twitter politely

I don't get it: people use Twitter to complain about their jobs. And get problems. Use twitter like you mom is going to read it. Seriously: it's a nice tool to share links and short descriptions - but it's everything else than private and trustworthy. All your tweets are belong to us. Or less geeky: the best way t use it is to be aware. Not to use it means not being aware.

Whooops - SMM exploit for Intel. Hardest exploit ever!

I'm not sure. That's scary... and brilliant at once as it seems. Here it is. The Invisible Things Lab just makes my day. They even published the code - maybe it's real. Maybe it isn't. But if it is, that's not just another exploit:
It targets the Intel caching mechanisms and jumps from the Hypervisor at Domain 0 up a level to SMM mode. Detection? Forget it!
The only way to detect this kind of low level compromisation is by disassembling processes at runtime and to scan through the opcode - with signatures if you have got these. There's no way someone can do that on a production machine. Compromising SMM allows to communicate with services at lower rings - for rootkits, etc, likely giving the ability to even hide the activity from the Hypervisor.

Hopefully Intel now reacts - and I want to remind the C2D Errata, Kirs Kaspersky's Microcode exploits at HITB con and several other flaws mentioned in the research paper.

Have fun,
wishi