Public Google Calendar (be nice 
)
List of security cons worldwide and CFP deadlines. In case you want to submit something 
Please collaborate!
You can access it and/or add it to your Google Calendar here
“The world is at war. You just don’t know it already.”
tl;dr
http://www.daemon-enterprises.com/wargame
I have put together a little wargame to start 2012 with some nice hacking stuff.
It consists of five challenges covering the following categories:
How To Play
The different challenges are logically united through a common plot. I thought it would be nice to write some kind of “short novel” along the way (warning, I’m not a writer, it sucks big time )
You have to solve a challenge at the end of each “chapter” in order to access the next one. Usually the solution of these challenges are some part of an URL leading to the next chapter.
However, as it’s normal (and really frustrating) to get stuck on a challenge I will unlock a chapter every week or so. This way you have the option of playing sequentially or just pick up your favorite challenge topic.
Some of the challenges are designed so that you can take a shortcut if you recognize what’s behind them. A good example of this would be Chapter 0×02 [Spoiler Alert!]
However you can as well take the long road and show what you got!
The “hint” panels
On the right side of the page you can find a couple of “dropdown” panels with some help. The one at the top, conveniently named “[ How To ]” contains the instructions to get the URL for the next chapter.
At the bottom, the panel “hints” contains well… some hints. It contains links to the materials needed to solve the challenge as well. Note that sometimes important pieces of information are scattered through the chapter’s text. Be sure to read it, I know it sucks but it’s short
The characters
Some of the characters are anonymous but I took the liberty to add a couple of chapters starring real world pr0n stars, like Aaron Portnoy or Corelanc0d3r. Kudos to them and please don’t sue me!
No seriously guys, don’t sue me 
Blah, Blah, cut to the chase
You can start playing here:
http://www.daemon-enterprises.com/wargame
The unlocked chapters will be announced in twitter, under @m0n0sapiens
Good luck and go save the world!
After one week online, the brave Daemon Taskforce, fighting fiercely against the (evil?) almighty Daemon came from the following countries. (see graph below)
Unfortunately, the graphics are labeled in German, but anyway… it summarizes like this:
Also, watch out Daemon, they are getting closer! ^^
If you are into Python (I do!) this should be your new homepage: facts.learnpython.org
But it’s a fact, you can’t ignore Ruby. Gems like nokogiri, savon, buby… Metasploit… maybe you heard about it .
Long story short, the sooner you learn it, the better.
For a nice introduction, with cool graphics, I would recommend this one: tryruby.org
(it only takes about 1/2 hour to go through!)
So, what are you exactly waiting for?
One more year, I will be at the BackTrack Day in Fulda, Germany giving a talk.
This time it goes about how to find vulnerabilities in software and use them to write an exploit. Since this is just an introduction, the title “Mama, where do the exploits come from?” seems quite appropriate
Moreover, I got the last slot, quite late in the evening, when everybody is rather tired and sleepy so I had to increase the talk’s fun factor. You can get the look and feel in the following preview:
If the feedback is good I will consider translating it to english and posting it here. We’ll see
Just a PoC of an idea I had some days ago. Software like KeePass, to name one, have gone to great lengths in order to protect the sensible data on disk or even memory.
But everything has a weak link…
The idea is a small “post-exploitation” program which allows you to stalk debug the KeePass.exe module, attaching to it and waiting for an user action (copy an username/password to the clipboard.)
I found that between calls to the Win32 Clipboard API, the cleartext of the credentials is placed in a predictable place on the stack. A small “debugger” program attached to it can therefore pause execution at the corresponding function call and read the password from the stack
This isn’t in any way a robust solution, rather something I coded “quick and dirty” in Python, using PyDbg (what else?) but it should be easy to code a small Win32 program with exactly the same functionality.
Don’t forget that after all PyDbg is kind of a wrapper around the Win32 debugging API…
And using the douchey expression “without further ado”, here is a demo video.
KeePass Live Debugging from Carlos Garcia Prado on Vimeo.
The code can be downloaded here
319 828 534 116
Some days ago, as a part of the Metasploit Bounty Program I decided to give a shot to one of the big ones, the IBM Tivoli LDAP vulnerability.
After poking around in the direction indicated in the advisory, I think it may not be exploitable after all.
Stack-based buffer overflow in the server process in ibmslapd.exe in IBM Tivoli Directory Server (TDS)[...] and 6.3 before 6.3.0.3 (aka 6.3.0.0-TIV-ITDS-IF0003) allows remote attackers to execute arbitrary code via a crafted LDAP request.
The specific flaw exists in how ibmslapd.exe handles LDAP CRAM-MD5 packets. ibmslapd.exe listens by default on port TCP 389. When the process receives an LDAP CRAM-MD5 packet, it uses libibmldap.dll to handle the allocation of a buffer for the packet data. A specially crafted packet can cause the ber_get_int function to allocate a buffer that is too small to fit the packet data, causing a subsequent stack-based buffer overflow. This can be leveraged by a remote attacker to execute arbitrary code under the context of the SYSTEM user.
The application makes use of Smartheap for SMP (SHSMP.dll) from the company MicroQuill (see links below)
It’s a *CUSTOM HEAP MANAGER* and got our attention when it was called by libibmldap!ber_bvecfree+0×28 and caused the crash.
03c8fcfc 0a90ae5c SHSMP!MemFreePtr+0×10
03c8fd08 005b86d8 SHSMP!shi_AfxFreeMemoryDebug+0x1c
03c8fd1c 004098c8 libibmldap!ber_bvecfree+0×28[...]
So let’s take a look at the *infamous* ber_get_int() cross references…
This memmove() looked very promising so I spent some time checking all paths from ber_get_int to this memmove() and checking if I could control the Size parameter in order to produce an overflow. Unfortunately it resulted in a dead end.
Since there is already a patch for this (probably) vulnerable version I decided to do some binary diffing to narrow the scope, the same way it’s done with Microsoft patches.
Turbodiff yielded the following results:
1. ber_skip_tag() ??? red block below ADDITIONAL (?) cmp ecx, eax – jb loc_1002807B *after* ntohl() call
2. sub_1000E0E0() *after* the call to sub_1001BA90() there’s a cmp esi, 0xFFFFFFFF – jnz short loc_1000E3B0
3. sub_10019DA0() just deleted some debugging…
4. sub_1001C460() just some reordering of blocks…
5. sub_1001cae0() reordering and debugging elimination…
6. sub_10025a30() reverse condition, block reordering…
The patched libibmldap.dll contains an additional check in the function ber_skip_tag(), where the result of the call to ntohl (argument user controlled) is inspected. You can tell this is defined as an unsigned integer by the instruction used in the comparison (jb).
In this screenshot the additional block is marked in green:
The function returns the value stored in edi and copy the return value of ntohl (user controlled) at [ebp+0]
What happens with this value is too complicated to analyze statically, so let’s debug from here on
Once inside ber_skip_tag():
Set breakpoints at
- nthol called with arg. 0x3A010000 -> obviously returns 0x0000013A
- at the time, edi equals 0x00AB0190 (esi and edi are interchanged, this is normal). That means that the missing check is calculating something based on a data structure: [esi + 8] – [esi +4], looks a lot like “end – start”
[edi + 4] = 0x00A5C630
[edi + 8] = 0x00A5C761
[edi + 8] – [edi + 4] = 0×0131 (goes into ecx)
cmp ecx, eax
jb short pop_and_return
translates to:
if ecx < eax failure();
since eax = 0×0131, there’s no problem this time
But… can I manipulate these bytes? What do they mean?
Maybe they are addresses in memory (from an allocation?)
EDI points to our user controlled data (mangled?).
Maybe some kind of (prev. chunk)(next chunk) structure?
Although promising, it looked like I wasn’t going nowhere. So I decided to follow the wise saying “use the source, Luke“ and started the X-rays decompiler inside IDA.
It’s always easier to follow how the arguments propagate between function calls in the code than in the raw assembly
Following our logic the security problem must occur *after* the missing check, so we can focus on the code after that point in ber_skip_tag().
After inspecting the code produced by X-Rays and how the (unchecked) value gets propagated backwards through the function call chain it was clear that it wasn’t used in any dangerous function.
Time to forget the advisory and study what happen with the packet data from ber_scanf_w() downwards.
From the ber_scanf() Linux Man Page:
The ber_scanf() routine is used to decode a BER element in much the same way that scanf() works. It reads from ber, a pointer to a BerElement such as returned byber_get_next(), interprets the bytes according to the format string fmt, and stores the results in its additional arguments. The format string contains conversion specifications which are used to direct the interpretation of the BER element. The format string can contain the following characters:
[...]
V Sequence of octet strings with lengths. A struct berval *** should be supplied, which upon return points to a dynamically allocated null-terminated array of struct berval *’s containing the octet strings and their lengths. NULL is returned if the sequence is empty. The caller should free the returned structures using ber_bvecfree().
From the MSDN Library:
Use a berval structure for attributes that contain raw binary data, such as certificates, graphics, or sound files.
… Or maybe some MD5 hash
It looks like the problem isn’t restricted to the CRAM-MD5 authentication, but is generic when working with non-ascii data.
I set a breakpoint at ber_scanf() and checked the arguments…
The first argument of this function is a pointer to the BerElement (shown in the dump).
The second is the format string. In this case {V} indicating some non-ascii data (see above)
The third argument in this case is a struct berval*** (see above). You can dereference it twice to get to the struct berval* (containing pairs len/value)
Notice how the lengths are specified by the user!
typedef struct berval {
ULONG bv_len;
PCHAR bv_val;
} LDAP_BERVAL, *PLDAP_BERVAL, BERVAL, *PBERVAL;
These structures can be seen in the following screenshot:
The first pBerVal has a length of 0×08 bytes and is located at 0x00A904E0. It’s just the “CRAM-MD5″ string on the original packet.
Following pairs len/value contain some of the pattern we sent (user controlled)
[17:47]:/pentest/exploits/framework3/tools/pattern_offset.rb a1Aa 2000
4
Nice, but are these values being used somewhere afterwards? Memory allocation? String copy?
In order to find out quickly I put a memory breakpoint on this page and breakpoints at malloc(), calloc(), realloc(), memset(), memcpy(), memmove() and strcpy() as well, just to be sure.
Notice how the heap manipulation functions (malloc, calloc, etc.) are hijacked into the SmartHeap library.
We hit directly the ber_bvecfree() without accessing this page and…
… Crash
Also, apparently the PoC shows just a crash caused by overwriting some registers, which results in an access violation. It looks like none of these registers can be used to achieve code execution.
It could still be that choosing carefully our buffer we could avoid the crash at ber_bvecfree() and somehow reach a dangerous portion of the code, but this is a looong shot…
http://xforce.iss.net/xforce/xfdb/66711 (IBM)
http://www.exploit-db.com/exploits/17188/ (PoC available )
http://www.zerodayinitiative.com/advisories/ZDI-11-136/ (ZDI) <— Detailed explanation!
http://www.microquill.com/smartheapsmp/index.html
Actually, the word “patching” instead of “trojanizing” would fit as well, but “trojanize”, which apparently is not even an english word, looks cooler
Today I was reading an article, written by the always awesome Didier Stevens, about the new version of EMET. In that article Didier explains how to use EMET in order to allow legacy applications enjoy some of the modern security techniques (DEP, ASLR, SEHOP, etc.)
Although EMET is a very nice tool, I started wondering if a more “intrusive” method would be successful. A method like the binary code inclusion and flow hijacking used in some simple trojan horses.
Just to play a bit I decided to add DEP capabilites to PuTTY, the almighty SSH client
Activating DEP for a given binary is a simple thing. This just have to call a Kernel32.dll function name SetProcessDEPPolicy with the right arguments.
In our case, just a Dword argument set to 0×00000001 will do the trick:
PROCESS_DEP_ENABLE (0×00000001)
Enables DEP permanently on the current process. After DEP has been enabled for the process by setting PROCESS_DEP_ENABLE, it cannot be disabled for the life of the process.
Now I just need to know the address of the function in order to CALL it in x86 ASM. Since the symbols in Kernel32 don’t change among SP and are not ASLR’ed, it’s rather safe to use a hardcoded address.
In order to get this address I just open any binary in Immunity Debugger and search for it by name in the Executable window:
Names in KERNEL32, item 1146
Address=7C8622A4
Section=.text
Type=Export
Name=SetProcessDEPPolicy
Nice, everything I need now is a good place inside the original binary where to put my new code. No surprise, there’s a huge code cave at the end of the image:
This will be more than enough place since my “shellcode” is really small:
push 0×01
call 7C8622A4
This is the assembler equivalent of the following function call:
SetProcessDEPPolicy(1);
I want to reach this code so early as possible, so I’m going to hijack the entry point of the application and redirect the execution flow to my code cave.
Original Entry Point
0044777F > 6A 60 PUSH 60
00447781 68 B8744600 PUSH putty_de.004674B8
00447786 . E8 E91E0000 CALL putty_de.00449674[...]
PATCHED Entry Point
0044777F > E9 5C7D0000 JMP putty_de.0044F4E0
00447784 90 NOP
00447785 90 NOP
00447786 . E8 E91E0000 CALL putty_de.00449674
I need to save the two ASM instructions I overwrite in order to execute them after the “shellcode”.
The following screenshot shows precisely this code, commented. On it you can observe the usual foreign code inclusion armor (PUSHAD/PUSHFD/POPFD/POPAD) which takes care of saving/restoring the state of CPU registers and flags.
The discussed function call is implemented and the original code is placed at the end, finishing with a jump to resume the normal execution flow.
It’s important to note that usually there would be a routine to align back the stack after the “shellcode” (before the POPFD instruction) but in this case the payload is so simple that the only modification is a single push and the function itself takes care of rewinding the stack.
In the screenshot you can see as well that right after the function call, the register EAX contains the value 1. This is the return value of the function, indicating that it was successful.
Saving the changes as “putty_dep.exe” and opening both the original and the trojanized patched PuTTY, we can proof that the modification produced the intended result (check the DEP column in Process Explorer)
Isn’t that nice?
UPDATE: Didier Stevens has gone three steps further as usual and wrote some shellcode implementing this functionality. Go Didier! Check it out here.
319 828 534 116
Yes, I know this is kind of a dramatic title but this will probably damage my sanity (or what remains of it…)
I’ve been studying some egghunting methods as a part of a you-know-what-kick-ass-course and at a certain point, due to some bad characters filtering we had to encode the payload. To be on the safe side, the egghunter was encoded with x86/alpha_mixed.
We have our own test machine on the course lab, which runs Windows Vista… but I had to do it in my own lab running Windows 7, of course. <– the typical smart-ass
After getting enough access violations to stop a train I decided to check out what the f**k was happening under the hood. I haven’t found a solution yet but I have isolated the root of the problem. If anybody gets any further please let me know on the comments!
The thing goes like this: the decoding stub, as any other self-{referencing, decoding, modifying} (that is, motherfucka code), needs some kind of GetEIP in order to find its own position in memory. There are a couple of ways to achieve this, so let’s check what the source code of the encoder has to say:
- from the source code of x86/alpha_mixed (SVN 11713) -
# We need to create a GetEIP stub for the exploit if (not reg) if(datastore['AllowWin32SEH'] and datastore['AllowWin32SEH'].to_s =~ /^(t|y|1)/i) buf = 'VTX630VXH49HHHPhYAAQhZYYYYAAQQDDDd36FFFFTXVj0PPTUPPa301089' reg = 'ECX' off = 0 else res = Rex::Arch::X86.geteip_fpu(state.badchars) <-- probably SEH wasn't allowed if (not res) <-- and a FSTENV GetPC is used raise RuntimeError, "Unable to generate geteip code" end
On Vista+ SEH GetPC are incredible difficult to write due to additional SEH checks.
It looks like the only option left for Vista/Win7 is to use the GetEIP_FPU (FSTENV) method.
This FSTENV GetEIP is awesome for two reasons: it’s really small (only 7 bytes) and it doesn’t introduce any null chars into the payload. On the other side, it uses some obscure x87 (yes, the original arithmetic co-processor) assembler, which makes it not exactly straightforward
$+0 FLDZ ; loads 0x00 onto the stack $+2 FSTENV SS:[ESP - 0x0C] ; save the environment at ESP - 0x0C ; since the environment is an structure and the address of FLDZ ; is stored at offsec 0x0C on it, now this address is at ESP $+6 POP ECX ; ECX contains now the address $+0
However, the code of the x86/alpha_mixed decoder stub is different. I guess this is an enhanced version of it.
Here an screenshot of the problematic code (click to enlarge)
As you can see there are two fundamental differences:
The screenshot was taken after the execution of FSTENV (see EIP reg). At this time the address of $+0 should be on top of the stack, ready to be popped to ECX (forget the previous pop/push ebp, they don’t change the stack, is some kind of code interleaving)
But the value at ESP is far from being within the main executable memory space. Actually is 0x8xxxxxxx, that is, *inside the windows kernel*.
This value is popped into ECX and slightly modified by the following instructions until it reaches the *quite properly* commented as “offending instruction” where the access violation occurs as we try to write into kernel space.
As mentioned at the beginning, this code is working without problems in Windows Vista Ultimate but it’s causing this fault on Windows 7. If you know what happens here, please let me know in the comments, I’ll much appreciate it!
UPDATE: corelanc0d3r pointed out in twitter that this could be an issue on AMD processors. It makes sense, since FSTENV GetPC depends on obscure x87 assembler instructions. It could be a slightly different implementation on AMD. Thanks Peter!
As a part of a well-known-kick-ass-course I’m taking right now I had to backdoor an executable of my choice with a certain payload.
The executable I chose was the Putty SSH client, mainly because it’s widespread and the fact that is contained in just one .exe
The choice about the payload was pretty clear… one metasploit generated reverse tcp shell to go, please!
After sucessfully backdooring <– is this even a verb? our beloved SSH client I thought: “man, every antivirus in the world is going to catch this little puppet…”, so I submitted it to virustotal.
Here are the results:
| Antivirus | Version | Last update | Result |
|---|---|---|---|
| AhnLab-V3 | 2011.01.18.00 | 2011.01.17 | - |
| AntiVir | 7.11.1.241 | 2011.01.25 | - |
| Antiy-AVL | 2.0.3.7 | 2011.01.25 | - |
| Avast | 4.8.1351.0 | 2011.01.25 | Win32:Hijack-GL |
| Avast5 | 5.0.677.0 | 2011.01.25 | Win32:Hijack-GL |
| AVG | 10.0.0.1190 | 2011.01.25 | - |
| BitDefender | 7.2 | 2011.01.25 | Backdoor.Shell.AC |
| CAT-QuickHeal | 11.00 | 2011.01.25 | - |
| ClamAV | 0.96.4.0 | 2011.01.25 | - |
| Commtouch | 5.2.11.5 | 2011.01.25 | W32/Rozena.B.gen!Eldorado |
| Comodo | 7495 | 2011.01.25 | - |
| DrWeb | 5.0.2.03300 | 2011.01.25 | - |
| Emsisoft | 5.1.0.1 | 2011.01.25 | - |
| eTrust-Vet | 36.1.8117 | 2011.01.24 | - |
| F-Prot | 4.6.2.117 | 2011.01.24 | W32/Rozena.B.gen!Eldorado |
| F-Secure | 9.0.16160.0 | 2011.01.25 | Backdoor.Shell.AC |
| Fortinet | 4.2.254.0 | 2011.01.24 | - |
| GData | 21 | 2011.01.25 | Backdoor.Shell.AC |
| Ikarus | T3.1.1.97.0 | 2011.01.25 | - |
| Jiangmin | 13.0.900 | 2011.01.24 | - |
| K7AntiVirus | 9.78.3635 | 2011.01.24 | Riskware |
| Kaspersky | 7.0.0.125 | 2011.01.25 | - |
| McAfee | 5.400.0.1158 | 2011.01.25 | - |
| McAfee-GW-Edition | 2010.1C | 2011.01.25 | - |
| Microsoft | 1.6502 | 2011.01.25 | Trojan:Win32/Swrort.A |
| NOD32 | 5816 | 2011.01.25 | - |
| Norman | 6.06.12 | None.. | W32/Swrort.A |
| nProtect | 2011-01-18.01 | 2011.01.18 | - |
| Panda | 10.0.2.7 | 2011.01.24 | - |
| PCTools | 7.0.3.5 | 2011.01.25 | - |
| Prevx | 3.0 | 2011.01.25 | - |
| Rising | 23.42.00.06 | 2011.01.24 | - |
| Sophos | 4.61.0 | 2011.01.25 | - |
| SUPERAntiSpyware | 4.40.0.1006 | 2011.01.25 | - |
| Symantec | 20101.3.0.103 | 2011.01.25 | - |
| TheHacker | 6.7.0.1.119 | 2011.01.24 | - |
| TrendMicro | 9.120.0.1004 | 2011.01.25 | Mal_Xed-21 |
| TrendMicro-HouseCall | 9.120.0.1004 | 2011.01.25 | Mal_Xed-21 |
| VBA32 | 3.12.14.3 | 2011.01.24 | - |
| VIPRE | 8189 | 2011.01.25 | - |
| ViRobot | 2011.1.25.4274 | 2011.01.25 | - |
| VirusBuster | 13.6.162.0 | 2011.01.24 | - |
| Additional information |
|---|
| MD5: 8ea25860c59a0577f9b3fb28efbdc9ed |
| SHA1: 94a3cafc73aae27dde47cd29f0d22be89659bc89 |
| SHA256: e25cb3295de57065437dd9aa701dceaf9485a00bffc2598a5a78bc6d4ccec6d4 |
| File size: 458752 bytes |
| Scan date: 2011-01-25 11:58:58 (UTC) |
Only 28.6% of the main AV vendors marked this file as a threat.
Hmmm… WFTBBQAV!
It happens a lot, it’s the Achiles’ heel of most pentesters and wannabes.
So you are a 1337 h4xx0r and you have just fired metasploit against a vulnerable Windows box, eh? It worked! Cooooool… you type whoami and it turns out you have System privileges… The cmd.exe prompt stays in front of you, blinking…
And now WHAT?! Well, you aren’t always gonna have the meterpreter by your side.
This pretends to be a short list of useful Windows command line snippets (yes, windows has a command line too!)
Think about it just as a quick reference, I will update it with kick-ass wmic commands later…
Some good old net commands
net user carlos hacking123 /add
adds an user to the system
net localgroup
groups on this machine? do you find anything interesting?
net localgroup “Remote Desktop Users” carlos/add
I can RDP now
net accounts
minimum pass length, lockouts, this stuff
net config [server | workstation]
juicy info
net view
anybody there?
net share
list Windows shares
net use
mount Windows shares!
net statistics [server | workstation]
tactical info
net help