SecuriTeam Digest

When Ax1024 isn’t enough

Recently, h07 published a vulnerability in Easy File Sharing FTP Server. Apparently a simple buffer overflow in the PASS command. This vulnerability is a nice example where fuzzing won’t cut it.

But the catch in the vulnerability is a comma. Only passwords starting with a comma (0x2c) can be overflowed. Why is this so important?

A fuzzer will usually take a legal FTP session, and will try to overflow interesting sections. The password field is a prime candidate, but the problem is, if you test for a simple overflow you’ll just send many ‘A’ characters or something similar. This is because fuzzers tend to look for the coin under the street-light.

Fuzzers today are sophisticated enough to look for many different types of programmer errors, but will usually look for the poster-child of each. For example, to find a format string, just send many %x. This is not done due to programmer lazyness, this is due to the sheer amount of possibilities to check. FTP is a relatively simple protocol, but with vendor extensions it has dozens of commands. Checking every command for vulnerabilities could take a long time, and with network considirations we’re talking weeks and months of continous bombardment on the target server.


Joanna Rutkowska’s blue pill and Vista RC2

joanna just published a blog entry on this issue, and how her poc doesn’t work on the new vista release.

why, etc.

“it quickly turned out that our exploit doesn’t work anymore! the
reason: vista rc2 now blocks write-access to raw disk sectors for user
mode applications, even if they are executed with elevated administrative



(hat tip to elad efrat)

Tiny PE – Rel0ad3d (304 bytes!)

Another long night, :sigh:

Creativeness is the name of the game,
in the end if you shave another byte or two, it’s not a big deal, (as much fun as it is, don’t get me wrong) you have to come up with better ideas. Sometimes, you are sure that what you got something good, but then you have to push your limits, and come up with something better.

I wish to thank Peter Ferrie, Nicolas Brulez and Jamz Yaneza for encouraging me and providing some information, about that downloader virus which is known to be around 330 bytes…

I haven’t got any sample of it, nor I know the real size, but to be sure my Tiny PE is smaller, my latest version stands at 304 bytes. If you read carefully my first blog post about this Tiny PE, I said that I was playing with Optional Header Size. So this time I cut a big part of it, and managed to crunch my code even more and put the Import Module Descriptor inside the header itself :) Though, now I think I broke compatibility with other versions of Windows…

Who is going to get it to below 300 bytes? hehe.

You can find the latest Tiny PE here: tiny3.exe.

If you like Assembly, or you just happen to remember hex code by heart,
even something easy like: EB 02 13 37 33 C0 40 C3 (LOL – sad but true), then you should subscribe to our new code crunchers mailing list at http://whitestar.linuxbox.org/mailman/listinfo/code-crunchers !

Have a beautiful weekend,
Gil Dabah

Code crunching, crazy asm tricks? – code crunchers mailing list

The Code-Crunchers mailing list has just been established.

Got an asm trick? Got a cool code crunching thingie going? Want to help crunch things further with others?

Just saw the most amazing exploit?

This is the place.

Open to anyone, not directly security related. To subscribe:

Reference, Tiny PE: http://blogs.securiteam.com/index.php/archives/675

Tiny PE – The Frenzy Ends! (or not, now at 304 bytes!)

For an update on how I got it smaller, check:

Hi everyone,

As I promised to get the tiny.exe less than 400 bytes, I sat last night and did it. Now with a new record size of 384 bytes and still supposed to run on all Windows versions. :)

You can find my original blog post with further technical details on this challenge here:

Here’s a snippet of the conversation between me and a good friend.
This is one of the ways to develop new tricks for code crunching:

Arkon: The problem with that URLDownloadToFileA is that it creates another thread,
Arkon: and that thread never terminates for some unknown reason to me.
Arkon: So I HAD to call ExitProcess and finish it, otherwise my process will hang. :(
Arkon: But now what I’m going to do is raising a silent exception 😡
Matthew: Just blow away the SEH chain and trigger an INT3.
Arkon: It will eliminate the string “ExitProcess” and the GetProcAddress code for it as well.
Matthew: BAM! :) Instant process death…
Arkon: This is too long.
POP FS:[0]
Arkon: Nah
Matthew: XOR ESP, ESP might also do the trick :-)
Arkon: LOL!!!
Arkon: Wait I’m stupid, push 0 is 2 bytes long.
Arkon: 2 bytes ExitProcess OMFG
Matthew: You’re a maniac

Thanks to my idea and to Matthew Murphy, I got the new .EXE size to merely 384 bytes.
It seems to be 99% usage of all spared room in the file…
If you even dare looking at this .EXE, you are crazier than me,
well – I wrote it, but you will have to understand it. :)
This is only one trick, there are way more undocumented tricks to explore and to learn from!

Check it out here:

Gil Dabah

Code Crunching – Tiny PE (challenge) [update #2: now with 304 bytes!]

[ Update: tiny PE is now at 384 bytes. The follow-up post and one of the techniques used to achieve this can be found here.
Update #2: tiny PE is now at 304 bytes:
http://blogs.securiteam.com/index.php/archives/690 ]

Or shall I dare saying the Tiniest?

It all began a few days ago, a few friends challenged me to write a smaller PE executable than theirs.

Ground rules

It might sound fairly easy at first, but it’s not, and there is merely one simple goal:
Grab a file from the Internet and execute it.

With the following rules:
1) Only Imports section is allowed for kernel32.dll to get LoadLibraryA and GetProcAddress.
2) All strings must not be viewable (except rule 1), so we xor… :)

After working dozens of hours I came up with something extremely crazy, 411 bytes.

Most of the debuggers will hate this file and it has anti-disassemblers effect. I couldn’t check it on many systems, just my WinXP and it works nicely.

Here’s the hex:

Hex of Tiny PE

Heap Spraying: Exploiting Internet Explorer VML 0-day XP SP2

Credits: Niega

At the first time, I decide the release the article at Oct 10. But there is someone already publish the exploit, so there is no means to still keep it private.

Last article, I had described that my method can’t be used to exploit XP SP2. But things change because Niega give me some information that he could produce some error that different from the old one.

This exception may be expected and handled.
eax=0013be58 ebx=001cc564 ecx=0013be4c edx=00000041 esi=000020d4 edi=00140000
eip=6f9eed1e esp=0013be34 ebp=0013c05c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program\Delade filer\Microsoft Shared\VGX\vgx.dll –
6f9eed1e 668917 mov word ptr [edi],dx ds:0023:00140000=6341

IE crashes, but not with the security cookie checking failure. This is the interesting one, may be I can made the code execution from this (the reason why I’m give up to find the way to made the exploit work on XP SP2 because there is others can do it). Niega said that he produce the error by overwrite the stack massively. I reproduce the error by create the attack vector like this: