Wednesday, September 10, 2008

Automated ActiveX Exploitation with COMikazi

This October i will be presenting at the Tulsa Tech Fest www.tuslatechfest.com . I will be presenting on a new tool currently in development at Bastard Labs called COMikazi. COMikazi is basically what you get when you cross a webcrawler that actively searches for new COM objects on the Internet and a ActiveX fuzzer designed to find security bugs in ActiveX controls. But we couldnt leave it there so we took it a step further and Created an Automatic Exploit Generator that will take the security vulnerabilities found by COMikazi and Automatically Generate working metasploit exploit modules for those security vulnerabilities :). yes thats right with one click COMikazi will scour the Internet looking for vulnerable code and when found automatically pump out 0day exploit modules. thats how we roll at blabs :) Automatic Exploit Generation FTW


ri0t

Monday, July 28, 2008

So simple it's scary....

does your HIP product stop me from tampering with it's system call interception hooks? It does? Can you show me, because I'm not seeing it....


That is all...

Wednesday, May 7, 2008

more xss talk

i think some of the problem with the importance of XSS lies in the availability of quality client side bugs. i read a quote once that said xss is for people that dont have client sides and while i think this is a bit short sighted it does have some merit. If you were attacking a target and you had a choice of where to put your research and development hours between a xss bug that you could do some cool shit with but not quite get shell or a client side stack overflow that you can write an exploit for with very minimal effort (thank you skylined)and gets you full system control? lets face it your average infosec guy and random company doesn't really have the understanding to fully grasp the importance of a vulnerability class they rely on whitehats to do that for them. They look at what people are working on and say oh that must be whats important if this other vuln class was important then there would be alot of people working on it. now while i agree alot of xss work has been done lately (and by lately i mean the last 2 to 3 years or so) i dont think alot of that work has had a chance to filter down to joe blow admin yet. lets face it they have to hear it 19 times before they get it anyway.


ri0t

Tuesday, May 6, 2008

The importance of the lack of importance of XSS

Am I the only one who finds the lack of importance placed on XSS a bit annoying? Can it be the lack of understanding behind the vulnerability for such reasons? I would like to think that most peeps in the security industry would raise a flag on xss issues for more than one reason, but at the very least for shitty coding practices! Thoughts on this?

Wednesday, April 2, 2008

Firewall Appliances

I've always had interest in appliance based firewall/IPS solutions. I'm going to run some tests against several smaller appliances, mostly SOHO solutions. Should include Netscreen, Watchguard, Checkpoint(Sofaware), Cisco PIX 501, and ASA5505 and perhaps a few more. I'll be posting some results here. It should be interesting to see how each responds to various tests etc..

In other news.. Blackhat/DefCon is quickly approaching. The BL crew should be in full force this year.. stay tuned for more info!

Friday, March 21, 2008

I'm not dead.. just busy.. more HIPS FUN..

HIPS.. Hope it protects something... ;-)

As usual I'm digging into various HIPS products and having fun.. I found a bit of time to post more hook exploration...

enjoy...

ZwSetLdtEntries hooked, jump to 00191BCB
ZwSetValueKey hooked, jump to 00191B97
ZwWriteVirtualMemory hooked, jump to 00190105

kernel32.dll
CopyFileA hooked, jump to 00190175
CopyFileExA hooked, jump to 00191B09
CopyFileExW hooked, jump to 0019019F
CopyFileW hooked: f=8BFF558BEC, m=FF2C258557
CreateFileA hooked, jump to 00191AD9
CreateFileMappingA hooked, jump to 00191AA4
CreateFileMappingW hooked: f=8BFF558BEC, m=8AFF368ADB
CreateFileW hooked: f=8BFF558BEC, m=87C92E3E26
CreateMailslotA hooked: f=8BFF558BEC, m=8BC036F3FF
difference at relocated offset 7C834E41 in CreateMailslotW
CreateNamedPipeA hooked: f=8BFF558BEC, m=EB07C0D200
CreateNamedPipeW hooked: f=8BFF558BEC, m=3EF38ADBF2
CreateProcessA hooked: f=8BFF558BEC, m=F30F008CA4
difference at relocated offset 7C81DA9E in CreateProcessInternalA
CreateProcessInternalW hooked, jump to 0019022E
difference at relocated offset 7C802332 in CreateProcessW
CreateRemoteThread hooked, jump to 00191A7E
CreateThread hooked: f=8BFF558BEC, m=90F2653E26
CreateToolhelp32Snapshot hooked, jump to 00191A51
CreateVirtualBuffer hooked: f=8BFF558BEC, m=8D3FC0F600
DebugActiveProcess hooked, jump to 00190251
DeleteFileA hooked, jump to 00191A32
DeleteFileW hooked: f=8BFF558BEC, m=F694A49BF1
DeviceIoControl hooked, jump to 00190286
difference at relocated offset 7C80E016 in DuplicateHandle
DuplicateHandle hooked, jump to 001902BC
GetModuleHandleA hooked, jump to 00191A19
GetModuleHandleW hooked: f=8BFF558BEC, m=653E90F29C
GetProcAddress hooked: f=8BFF558BEC, m=86C08BE467
HeapCreate hooked: f=8BFF558BEC, m=87C96765F2
LoadLibraryA hooked, jump to 001902EB
LoadLibraryExA hooked, jump to 00190310
LoadLibraryExW hooked, jump to 00190344
LoadLibraryW hooked, jump to 001919E2
difference at relocated offset 7C86125E in LoadModule
MapViewOfFile hooked: f=8BFF558BEC, m=FF2C2596B7
MapViewOfFileEx hooked: f=8BFF558BEC, m=87C9902636
MoveFileA hooked: f=8BFF558BEC, m=900FACF900
MoveFileExA hooked: f=8BFF558BEC, m=FF2C25ACD2
MoveFileExW hooked: f=8BFF558BEC, m=2E8D3F9036
MoveFileW hooked: f=8BFF558BEC, m=FF2C256396
MoveFileWithProgressA hooked, jump to 00191969
MoveFileWithProgressW hooked, jump to 00191951
OpenFile hooked, jump to 00190378
difference at relocated offset 7C81E079 in OpenProcess
OpenProcess hooked: f=8BFF558BEC, m=363E2E2EFF
OpenThread hooked: f=8BFF558BEC, m=26F22E36C0
ReadFile hooked, jump to 00191915
ReadFileEx hooked: f=8BFF558BEC, m=F2F3362EFF
ReadProcessMemory hooked: f=8BFF558BEC, m=F694E4CFF1
SetThreadContext hooked, jump to 001918DC
SetUnhandledExceptionFilter hooked, jump to 001918B3
VirtualAlloc hooked: f=8BFF558BEC, m=F266F20FAC
VirtualAllocEx hooked, jump to 00191895
VirtualFree hooked: f=8BFF558BEC, m=90FF2C251D
VirtualFreeEx hooked: f=8BFF558BEC, m=87C96A5567
VirtualProtect hooked: f=8BFF558BEC, m=3666678D34
VirtualProtectEx hooked: f=8BFF558BEC, m=8BC0EB0965
VirtualQuery hooked: f=8BFF558BEC, m=0F86B7EF93
VirtualQueryEx hooked: f=8BFF558BEC, m=8BE436F3EA
WinExec hooked: f=8BFF558BEC, m=900F862997
WriteFile hooked, jump to 00191852
WriteFileEx hooked: f=8BFF558BEC, m=9068C46176
WriteProcessMemory hooked: f=8BFF558BEC, m=86E4EB0F3E
_lcreat hooked, jump to 00191824
_lopen hooked, jump to 001917E7

user32.dll
SendInput hooked, jump to 001917CB
keybd_event hooked: f=8BFF558BEC, m=F2F23EF30F
mouse_event hooked: f=8BFF558BEC, m=3EF3F22EC1


ws2_32.dll
WSAAccept hooked: f=8BFF558BEC, m=68E4819663
difference at relocated offset 71AC0C69 in WSAConnect
WSADuplicateSocketA hooked: f=8BFF558BEC, m=67F3660FBF
WSADuplicateSocketW hooked: f=8BFF558BEC, m=260F8668F7
WSARecv hooked: f=8BFF558BEC, m=3667F2F3E9
difference at relocated offset 71ABF5D6 in WSARecvDisconnect
WSARecvDisconnect hooked: f=8BFF558BEC, m=87C9FF2C25
WSARecvFrom hooked: f=8BFF558BEC, m=6894B14693
WSASend hooked: f=8BFF558BEC, m=FF2C253E62
WSASendDisconnect hooked: f=8BFF558BEC, m=87C9900F86
WSASendTo hooked: f=8BFF558BEC, m=6586C026E9
WSASocketA hooked: f=8BFF558BEC, m=0FA4DD0036
WSASocketW hooked, jump to 00190884
accept hooked: f=8BFF558BEC, m=8D3FEB0590
connect hooked: f=8BFF558BEC, m=87C9FF2C25
recv hooked: f=8BFF558BEC, m=68C4617643
recvfrom hooked: f=8BFF558BEC, m=3E2E0FA4DD
send hooked: f=8BFF558BEC, m=6A7D689F04
sendto hooked: f=8BFF558BEC, m=90F3F22667
socket hooked: f=8BFF558BEC, m=86C03E2EFF
Terminé
psapi.dll

advapi32.dll
ControlService hooked, jump to 00190420
CreateProcessAsUserA hooked: f=8BFF558BEC, m=3E8AFF8DAD
CreateProcessAsUserW hooked: f=8BFF558BEC, m=6766678D74
difference at relocated offset 77E15C9D in CreateProcessWithLogonW
difference at relocated offset 77E15C9F in CreateProcessWithLogonW
CreateServiceA hooked, jump to 00191721
CreateServiceW hooked, jump to 0019170B
ElfClearEventLogFileA hooked, jump to 00190472
ElfClearEventLogFileW hooked, jump to 001916C8
InstallApplication hooked: f=8BFF558BEC, m=2E3EFF2C25
LogonUserA hooked: f=8BFF558BEC, m=90656894B1
LogonUserW hooked: f=8BFF558BEC, m=F39087ED65
LsaAddAccountRights hooked, jump to 00191689
LsaAddPrivilegesToAccount hooked, jump to 0019165C
LsaCreateAccount hooked, jump to 0019049D
LsaOpenAccount hooked, jump to 001904C5
LsaOpenSecret hooked, jump to 0019161B
LsaQuerySecret hooked, jump to 001904DC
difference at relocated offset 77DF02D6 in LsaRetrievePrivateData
LsaSetSecret hooked, jump to 001915EB
difference at relocated offset 77DF04A1 in LsaStorePrivateData
LsaStorePrivateData hooked, jump to 001915AD
difference at relocated offset 77DF64A0 in OpenEventLogA
OpenEventLogW hooked: f=8BFF558BEC, m=0F878A9E35
OpenProcessToken hooked, jump to 0019053F
OpenSCManagerA hooked, jump to 00191591
OpenSCManagerW hooked, jump to 00191551
OpenServiceA hooked, jump to 00190578
OpenServiceW hooked, jump to 0019153B
OpenThreadToken hooked: f=8BFF558BEC, m=680C693ECB
RegCreateKeyA hooked: f=8BFF558BEC, m=268BE490F2
RegCreateKeyExA hooked: f=8BFF558BEC, m=3E2E36EAFE
RegCreateKeyExW hooked: f=8BFF558BEC, m=2686E42E36
RegCreateKeyW hooked: f=8BFF558BEC, m=9086C02EF2
RegDeleteKeyA hooked: f=8BFF558BEC, m=6A4568E70C
RegDeleteKeyW hooked: f=8BFF558BEC, m=36650FACC9
RegDeleteValueA hooked: f=8BFF558BEC, m=86C0642E67
RegDeleteValueW hooked: f=8BFF558BEC, m=26F29C9067
difference at relocated offset 77DFC41B in RegOpenKeyA
RegOpenKeyA hooked: f=8BFF558BEC, m=660FBFD264
RegOpenKeyExA hooked: f=8BFF558BEC, m=2E36F367C0
RegOpenKeyExW hooked: f=8BFF558BEC, m=36FF2C2590
RegOpenKeyW hooked: f=8BFF558BEC, m=F29C659090
RegSetKeySecurity hooked: f=8BFF558BEC, m=F3F2F3649C
RegSetValueA hooked: f=8BFF558BEC, m=6894B14693
RegSetValueExA hooked, jump to 001905B1
RegSetValueExW hooked, jump to 00191527
RegSetValueW hooked: f=8BFF558BEC, m=8BC00F8C00
RevertToSelf hooked: f=8BFF558BEC, m=3E8D920000
SetFileSecurityA hooked: f=8BFF558BEC, m=909C0EF265
SetFileSecurityW hooked: f=8BFF558BEC, m=0F01442488
SetNamedSecurityInfoA hooked, jump to 00191512
SetNamedSecurityInfoExA hooked, jump to 001905E8
SetNamedSecurityInfoExW hooked, jump to 001914DA
SetNamedSecurityInfoW hooked: f=8BFF558BEC, m=F694E4A3FA
SetSecurityInfo hooked: f=8BFF558BEC, m=6686E486C0
SetSecurityInfoExA hooked, jump to 001905FE
difference at relocated offset 77E23AB1 in SetSecurityInfoExW
StartServiceA hooked, jump to 00190634
StartServiceW hooked, jump to 0019066E
SystemFunction029 hooked: f=8BFF558BEC, m=90FF2C256D
SystemFunction034 hooked: f=8BFF558BEC, m=9065676AAD
SystemFunction035 hooked: f=8BFF558BEC, m=670FA4ED00
SystemFunction040 hooked: f=8BFF558BEC, m=EAF18DDF77
SystemFunction041 hooked: f=8BFF558BEC, m=362E0F8612
UninstallApplication hooked, jump to 00191495

ole32.dll
CoCreateInstance hooked: f=8BFF558BEC, m=2E9086C0F2
CoCreateInstanceEx hooked: f=8BFF558BEC, m=F28ADB909C
CoGetClassObject hooked: f=8BFF558BEC, m=C1D7009026
CoGetInstanceFromFile hooked: f=8BFF558BEC, m=3666C1D300
difference at relocated offset 77596327 in CoInstall
CoInstall hooked: f=8BFF558BEC, m=36EA2F6359
CoLoadLibrary hooked, jump to 0019085F
CoRevertToSelf hooked, jump to 00191075

Tuesday, March 4, 2008

2008... what's in store?

The security game is a game of cat and mouse. Jedis vs Sith, with Sith usually having the upper hand. What is going to be the big news this year? Overflows will still rear their heads.. this is a given, but what is going to be the direction for this year? Web application security seems to be a big issue brought into the light this year. Sites like MySpace, and Facebook, both of which are constantly undergoing scruitiny, continue to errupt with vulnerabilities. There is always a trade off when attempting to design software which keeps ease of use in mind. You don't want to make something too hard, hence the users won't use it, but you don't want to leave it sitting wide open either. This will definitely be interesting to see how the web arena plays out. Any other thoughts on vulnerability directions this year?

2008... what

Wednesday, September 5, 2007

Security only at layer 7 and above?

I recently had a friend who works for an unamed evil empire disclose to me that he and his colleagues are under the assumption that security is no longer an issue in any layer below 7. I'm going to keep this vaque, but I'm interested to hear the various thoughts from others on this matter. I don't think the day of the network attack will ever subside completely, but are the days of Layer 3 attack detection long gone?

Thursday, July 12, 2007

Vulnerability Auction Services

Lately, it seems, Vulnerability auctions are capturing a lot of news. As a researcher, I'm not quite sure how I feel about them. There are a lot of items to consider. In the past I've been involved with ZDI, iDefense and others with regards to vulnerabilities being sold. Vendor based solutions generally handle the responsible disclosure aspect of the issue, including dealing with the vulnerable vendor. In an auction based scenario, the seller may not have the opportunity to understand who may be purchaing his or her vulnerability. For some researchers knowing the endpoint of the vulnerability may not be an issue. For others ethics may play a part. It's really an interesting area.. what are the thoughts of the crew out there?

Sunday, June 17, 2007

I would like to point out...

That security through obscurity works well when....... the mother %$#^^^$%## logic board in your powerbook dies!!!


/grumble.. grumble...

Thursday, June 14, 2007

Preparing for Vegas!

The majority of the Bastard Labs Crew is confirmed and will be in Las Vegas this year for Blackhat and Defcon. So if your going to be in town and want to talk exploitation or anything else random drop us a line.


See ya there!


ri0t

Thursday, May 17, 2007

You are the weakest Link... goodbye!

It's pretty apparent that no matter how well you patch a system, or how well you think you've patched a system, passwords are the weakest link for the most part. Also it's interesting how there always seems to be that ONE host that is left sitting on in the darkest corners of the epic corporate empire, which is still vulnerable to that 1999 exploit lovin.

What I find truly interesting is the number of "security" professionals I run across who have some of the lamest passwords I've ever seen. While I understand how much of a pain the arse it can be to remember complex passwords, to simply use the name of your company followed by a number is irresponsible.

there is no real point to this point other than the griping you're reading, it's just something humorous I seem to run across time and time again as I am called in to assess the security posture of different organizations.

*NOTE* I know it's incredibly easy to use rainbowcrack and/or other tools of the trade, but this is made so much easier when accessing the box to pwdump or cachedumpe is made 10x easier by a weak passwords or some 1999 exploit lovin

Monday, April 16, 2007

Can I take your syscall for you?

It seems that for a bit of time now, HIPS products are taking off and being installed in organizations. HIPS is still a relatively young technology with the way technology goes. There are some mature products out on the market, and the features and abilities are ever changing. Lately we here at the BL have been working on HIPS evasion techniques, lots of interesting things to think of, and lots of interesting techniques to try out. Since most HIPS are utilizing hooking techniques, it's fun to see exactly where they hook and what they leave out. Hidden or little utilizes APIS, and/or calls can be fun vectors to look at.

We'll be posting more here when we finalize our research. Perhaps a neat evasion tool, hrmm, I'll have to check with the ninja monkies on that one..

[commonly hooked dll]

ntdll.dll
kernel32.dll
core.dll
ADVAPI32.dll
RPCRT4.dll
NETAPI32.dll
msvcrt.dll
PSAPI.dll
SHLWAPI.dll
GDI32.dll
USER32.dll
MSVCR71.dll
WININET.dll
CRYPT32.dll
MSASN1.dll
OLEAUT32.dll
ol32.dll
msi.dll
urlmon.dll
SHELL32.dll
------ and the list goes on!

Friday, April 6, 2007

Smashing SEH

Ok so recently i have been working on a couple of Buffer Overflows where EIP is gained through smashing SEH so here is a quick mini primer on smashing SEH for fun and profit

So here is the short definition when a win32 program runs it sets on the stack and address of the SEH the program will jmp to this address if there is ever an exception that causes the program to die Thus the reason it is called the Standard Exception Handler.

So on occasion you will have a program that you can overflow the buffer thus overwriting data on the stack but and exception fires during the copy or something else in the data stream causes an exception causing the program to fire the SEH before you get code execution (thats overly simplified but you get the point) So what is a researcher to do? how bout overwrite the address that SEH is pointing to Smile

So if we overwrite the buffer we will eventualy get to 2 address on the stack the first is the “Pointer to the Next SEH” and then the next address after that is the current SEH so coceptualy our buffer looks somewhat like this

so if we send a buffer and fill the top buffer space with A’s then set the Pointer to the Next SEH to BBBB set the SEH to CCCC and the second buffer space to DDDD our buffer will look something like this (again this is just an example)

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCCDDDDDDDDDDDDDD

now remember this is just an example in the real world the buffers hopefully will be much bigger Smile

so when the exception fires what you will see is eip set to CCCC and then 2 addresses down from EBP (stack base pointer) you will see a address that contains this

BBBBCCCCDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

now thats kinda interesting thats our buffer but how do we get to it?

Bring on the pop pop ret Smile. If we can set the SEH to an opcode that contains a Pop Pop Ret when it fires it should pop 2 addresses off the stack and return into our buffer. ok so now we can get into the buffer but how do we get to shellcode from here? after all the buffer doesnt just contain our shellcode of DDDDDD it also contains BBBB and CCCC so what are we to do? Well up until this point we havnt used the Pointer To the Next SEH address for anything (the BBBB space) so what we do is we set BBBB to \xEB\x06\xFF\xFF what is \xEB\x06? in assembly it is Jmp Short 6 bytes so when we pop pop ret into this space the execution flow will hit this jump over our CCCC return address directly into our DDDDDDDD shellcode Smile YaY!!!!

so now we have code execution by Busting the SEH on win32 programs

Some things to think about….

The buffer space after the return address may be to small for a full payload which means we may have to use a staged payload that jumps back into our main buffer

In windows XP sp2 microsoft introduced SafeSEH which limits where the SEH can point to. this can be overcome by pointing back into the binary itself for a pop pop ret provided the binary hasnt also been compiled with /SafeSEH

Just some things to think about and mabey get the brain juices flowing

Thursday, April 5, 2007

Welcome to the Bastard Labs Security Research Blog

Fear the Bastards got a blog :P more to come