Focus On: MySQL remote code execution

Christmas is coming and Santa brought us a new interesting vulnerability about another database system: today it's the turn of one of the most spread and used RDBMS, MySQL.

MySQL 5 is in fact prone to a remote command execution vulnerability.

This vulnerability has been tested on Linux, with MySQL versions 5.0.45 and 5.0.51, the latest one.

This is a pre-authentication vulnerability so you won't even need a valid username and password but a GRANT from your IP on the database, to let the connection start.

Like all the database softwares, you won't find so many MySQL's exposed on the internet, while it can be very common in a Local Area Network.

Also, MySQL is often used in web application development, so most (all?) of the web hosting providers sell access to the MySQL server together with the web space.

By exploiting this vulnerability you will be able to access the content of all the databases present on the DBMS without needing a local privilege escalation since the files on the filesystem containing the database data are owned by the same user running MySQL.

If you buy this vulnerability you will receive a fully working PoC and all the technical details.

Of course, for further information don't hesitate to contact us via e-mail, and if you want to make a bid on the vulnerability, do it here.

Focus on: SAP MaxDB remote code execution

A very interesting vulnerability appeared a while ago on our marketplace and it's now time to give it the visibility it deserves.

Today we are in fact going to focus on a remote command execution vulnerability in SAP MaxDB (you can bid on it here).

The vulnerability has been triggered on Linux machines running SAP MaxDB version 7.6.00.37 (that's the lastest version) and 7.4.3.32, and on Windows machines running SAP MaxDB 7.6.00.37. Other versions may also be affected.

This vulnerability is also pretty easy to exploit: just send a specially crafted request, containining an arbitrary command, to the listening port of the vulnerable MaxDB service and that command will be executed with the credentials of the user running the process (usually 'sdb' on Linux).

Yes, you can figure that a database service is rarely open on the Internet, but in a LAN it's not-so-rare to find so this vulnerability is pefect in a variety of corporate pentesting scenarios.

As you know, SAP AG products run on the majority of intranets of the biggest companies all around the globe and all the products developed by SAP AG are focused on Enterprise Resource Planning (ERP).

Of course, every SAP applications that requires a Database service will use MaxDB RDBMS.

The situation can be really alarming if you sum all of the factors described above: easiness of exploitation + remote access + spread of the product + confidentiality of the data contained into the database. The result can be scary.

Once you can execute commands on a machine running MaxDB, with the credentials of the MaxDB user, it's very easy to dump the content of the whole database.

Together with the vuln you will also buy a fully working and reliable PoC.

Hopefully this post will be able to help both the companies running this vulnerable SAP product by rising their awarness and the security companies looking for better tools.

WabiSabiLabi Walkthrough

Hello folks, since we received a lot of questions about the whole marketplace procedure we'd like to point out some of our policies.

First thing, the researcher needs to sign up to our website: from this point on he can start submitting his work to the lab.

Please note that before selling anything, he'll be asked to fax or email his ID card details and a landline phone number, that we'll use to verify his identity.

We usually need full details about a vulnerability, so we might start a direct correspondence with the researcher, if necessary. Every communication is encrypted with PGP/GPG (here's our public key).

Once we get all the required details we can start testing the vulnerability.
Even if we are doing our best to speed up this part of the process it still requires some days: you can help us by sending as much information as you have about the vulnerability, i.e. debugger output, commented proof of concepts and step-by-step methods to trigger the vulnerability, in case it's a complicated vulnerability to exploit.

Despite our dedicated entry in our F.A.Q. page we are often asked which vulnerabilities we will accept or reject:

- all vulnerabilities related to network services, network clients, standalone clients, web applications and network devices are accepted and tested.

- we DO NOT accept vulnerabilities in specific websites, like for example eBay, Gmail, Hotmail, online casinos etc.

Once the vulnerability has been tested and accepted, we decide a starting price and a selling strategy together with the researcher, who will then receive our NDA. This must be returned signed, via fax or mail.

At this point we are ready to publish the vulnerability.

When the vulnerability is sold we will pay the researcher via paypal to his verified account or via wire transfer to his bank account.

If you want to be a bidder all you have to do is subscribe to our portal and provide the papers required to check and verify your identity. Please note that we only accept payments coming from a verified bank account in your name.

That's all.

Our purpose is raising awareness and reducing risk and contributing to the research of new vulnerabilities by both helping and protecting researchers and giving them appropriate compensation for their amazing work.

Quicktime zeroday vulnerability still zeroday

This morning we opened our favourite RSS reader and we found out a post about one of the vulnerabilities in our marketplace, the Quicktime client-side vulnerability.

As reported by Errata Security Blog, during the last few days some exploit codes for a Quicktime vulnerability have been posted.

What they say about one of the POC is:

"An interesting note is the most robust of the exploits makes a derogatory mention of WabiSabiLabi Labs, the exploit auction site. WabiSabiLabi has a QuickTime exploit for sale now that lists QuickTime 7.2 and Windows XP as the targets. You have to wonder if this is another case of a researcher using vague details to find the same vulnerability."

We just want to specify that the vulnerability shown on those POCs IS NOT the one present in our marketplace.

So, if you are interested in receiving some more details about the vulnerability we proposed don't hesitate to contact us and if you are interested in buying it, make a bid!

Focus on: ClamAV remote code execution

From today on we will periodically talk about one of the most interesting vulnerabilities present in our marketplace.

Of course, we won’t disclose any technical details on how to reproduce or exploit the vulnerability, we will just give a brief description of it and, most of all, we will describe the impact that it may have on an enterprise and/or home environment.

Today we will discuss about a new ClamAV vulnerability.
As most of you know, ClamAV is an “open source (GPL) anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail gateways”. It provides also a set of utilities, like for example a daemon and a command line scanner.

It has been recently submitted to our labs a vulnerability that allows a malicious user to execute arbitrary code on the machine running one of the utilities of the ClamAV suite by simply sending a specially crafted email to the vulnerable mailserver. You can bid on it HERE .
The latest verified vulnerable version is 0.91.1 but other versions could be affected as well (UPDATE: after further tests we can confirm that also 0.91.2 is vulnerable).

As you can obviously imagine, the impact of this vulnerability is ravaging.

ClamAV is used on almost every enterprise mail system based on Linux/Unix. When exploited, this vulnerability allows an attacker to execute arbitrary code on the target machine in the context of the user running the affected application and to have a “base” on the local network / DMZ, thus having the possibility to escalate privileges (if needed) and compromise other servers nearby the attacked one.

Of course, as it’s an antivirus engine designed for mailservers, the attacker can locally escalate his privileges and get access to all the mail traffic to and from the company just by sniffing the traffic on the compromised machine.

In a home scenario, even if ClamAV is not widely used in such environment, the impact can also be high. If a home computer is compromised, the attacker can access documents and files stored on that computer and use these informations to gain higher privileges.

The included PoC works very reliably.

This vulnerability has a starting price of 500 euros: bid on that and, as a security company, you will gain a very high competitive advantage.

Back from the Microsoft Blue Hat conference

The conference is over. Indeed it was an interesting experience which left us a bunch of good feelings.
How is this possible? Even the press was amazed, when got informed about our participation to the 8th Blue Hat conference, which was held in Seattle, in the Microsoft campus between September 27th and 28th, 2007.

Honestly, we were a bit amazed ourselves. But then, thinking carefully, we understood this was probably the right occasion to discuss our initiative directly with the people from which we could expect the most solid critics or maybe, the most solid handshakes. It was a challenge we had to take.

Guess what? We indeed received both solid critics and solid handshakes.

We were very much impressed by a lot of things, last but not least the incredible natural environment in which the Microsoft Camp has been built. Thirty thousands people working in a breathtaking environment, no wonder Bill decided to keep Microsoft headquarters in Seattle, rather than moving them to a more IT-fancy location like Frisco, for example.

Roberto Preatoni, our strategists holding the speech at the Blue HatGiacomo Paoni, our CTO in the speaker's lounge

Once at the conference, we have been requested to hold three different speech sessions. Two for the executives and one for the Microsoft employees, developers, long-time friends (what a big crowd of young, open minded people!).

We had the occasion to explain in detail our initiative, and to answer to challenging questions, especially those questions coming from some of the Microsoft executives. One of them suggested us to be more transparent by publishing our own vulnerability acceptance policy. Suggestion taken Sir, we'll do it.

During the conference days, beside the speeches we had the possibility to hang out and to exchange point of views with the Microsoft folks. Some of them wanted to discuss variations of vulnerability market models, some other wanted to exchange their views on legal issues. Many of them came just for an handshake.

The conference was very useful for us also because it gave us the possibility to exchange views and contacts with the speakers, a bunch of young, brilliant minds from which we got good advices. Among those minds, the Tipping Point guys (and girl, hi Terry!) with whom we had a lot of insightful comments in a cooperative environment. Cheers.


One thing is sure: if we brought 30,000 WabiSabiLabi corporate t-shirts to the conference, we would have had 30,000 thousands Microsoft employees wearing it next day at work. Quite an achievement, isn't it?

Don't worry folks, to all of you who requested us a WabiSabiLabi t-shirt, a loooong list, you will get it. Just give us the time to go back to the land of the chocolate and cheese and we will print them.


At the end, we were prepared to face the worst, but we actually faced nothing but the best.
And it came naturally. To push the things for the best, we didn't even have to get the Miracle Prosperity Handkerchief that one of the very many Reverends wanted to give us through our hotel room's television. And it was coming for free...

Now hiring!

Yes, we are already hiring, Sirs! If you are an expert in code analysis, reverse engineering, exploit coding, vulnerabilities testing, crypto analysis and if you are interested in working with us, then ring the bell.

We are also interested in finding area managers located in the following continents: USA, Asia-Pacific, East Europe.

Needless to say, your English skills should be fluent (no need to speak Switzerland-ese).

Our offer is: the possibility to join a team of highly motivated and skilled people, a competitive salary and benefits and an enjoyable workplace.

For further details, you might want to check our careers page.

HITB 2007 - CTF Daemon 03 writeup

As requested by many, by the voice of Hyperion, our reverse engineer the explanation about the HITB2007 CTF's daemon 03. Quite a job!

Among the flag daemons featured in the HITBSecConf2007 Kuala Lumpur CTF, daemon03 proved an unique and unusual challenge. While all other daemons had to be coerced into revealing their flag, number 3 eagerly offered its flag to inquirers… in its own, cryptic language, that had to be learned first. It was not enough to attack daemon03: one had to get to know it, greet it, listen to what it had to say. It was only fortunate that me, the team's reverser/coder, had to be the one to deal with the shy one.

Technical

In my experience, I found it useful to perform some high-level analysis before wasting time with the minutiae of decompilation (I have become notorious in some circles for beginning most of my reversing sessions from inside notepad). Thus, first things first, I gave daemon03 the ritual objdump greeting:

Hyperion@Regulus ~/HITB
$ objdump -x daemon03

daemon03:     file format elf32-i386
daemon03
architecture: i386, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x080489e0

Program Header:
    PHDR off    0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
         filesz 0x00000100 memsz 0x00000100 flags r-x
  INTERP off    0x00000134 vaddr 0x08048134 paddr 0x08048134 align 2**0
         filesz 0x00000013 memsz 0x00000013 flags r--
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x00009bf8 memsz 0x00009bf8 flags r-x
    LOAD off    0x00009bf8 vaddr 0x08052bf8 paddr 0x08052bf8 align 2**12
         filesz 0x000001a8 memsz 0x000001b8 flags rw-
 DYNAMIC off    0x00009c0c vaddr 0x08052c0c paddr 0x08052c0c align 2**2
         filesz 0x000000d8 memsz 0x000000d8 flags rw-
    NOTE off    0x00000148 vaddr 0x08048148 paddr 0x08048148 align 2**2
         filesz 0x00000020 memsz 0x00000020 flags r--
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
         filesz 0x00000000 memsz 0x00000000 flags rw-
0x65041580 off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
         filesz 0x00000000 memsz 0x00000000 flags --- aaa0

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
SYMBOL TABLE:
no symbols

It seemed already daemon03 played the shy card: no section table. Since the executable clearly contained strings betraying the presence of a section table, I had to assume this was just a matter of a zeroed-out counter field somewhere. I could have restored the field, but it seemed unnecessarily invasive. I'm a shy guy myself and I could sympathize with daemon03: going so intimate with his internal structures (mutilated structures, at it) so early in the game would have only proven awkward and ultimately counterproductive. My knowledge of ELF is a bit rusty, but from having implemented an ELF loader for the ReactOS kernel I knew loadable program headers were what really mattered to the memory layout of an ELF executable. I could expect difficulties in locating internal tables (external symbols, the GOT, etc.), but the program was simple enough for that not to matter much.

IDA Pro, the ever reliable digital anatomopathologist, in fact, did not get squeamish and correctly loaded daemon03 on her examining table in a matter of seconds, despite some understandable perplexion that left some "organs" unidentified and some "nerve endings" unconnected. As expected, imported functions laid orphaned of cross-references, their stubs left unnamed, and line addresses in the disassembly view were to be prefixed by "LOAD" instead of the familiar ".text". I did not get squeamish, either, recognizing a familiar overall structure I spent hours examining a day prior, the conspicuous many fingers pointing at the tiny pale circle in the sky called main.

LOAD:080489E0 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
LOAD:080489E0
LOAD:080489E0
LOAD:080489E0                 public start
LOAD:080489E0 start           proc near
LOAD:080489E0                 xor     ebp, ebp
LOAD:080489E2                 pop     esi
LOAD:080489E3                 mov     ecx, esp
LOAD:080489E5                 and     esp, 0FFFFFFF0h
LOAD:080489E8                 push    eax
LOAD:080489E9                 push    esp
LOAD:080489EA                 push    edx
LOAD:080489EB                 push    offset sub_804C990
LOAD:080489F0                 push    offset sub_804C930
LOAD:080489F5                 push    ecx
LOAD:080489F6                 push    esi
LOAD:080489F7                 push    offset sub_8048B92
LOAD:080489FC                 call    sub_8048918

My experience with Linux executables was near zero before the competition. It's now at zero-point-something, but at least I've learned to recognize the above piece of code as the initial call to __libc_start_main. So let's mark "start", "sub_804C990" (actually _fini), "sub_804C930" (_init), "sub_8048918" and all routines below their call graph as library functions (Alt+P,L Enter), and rename "sub_8048B92" to "main", and move on to it.

Once inside main, we continue our campaign of marking uninteresting functions as "library routines", and manually naming imported external functions. We clearly begin with the initial call to read, which we annotate accordingly (and, while we're at it, we give readable names to outgoing argument pseudo-variables):

LOAD:08048BB1                 mov     [esp+2A8h+arg8], 512
LOAD:08048BB9                 lea     eax, [ebp+inbuf]
LOAD:08048BBF                 mov     [esp+2A8h+arg4], eax
LOAD:08048BC3                 mov     [esp+2A8h+arg0], STDIN_FILENO
LOAD:08048BCA                 call    _read
LOAD:08048BCF                 mov     [ebp+inbufsize], eax

We know it will be followed by the call to flag_func, the function that authenticates and processes calls from the scorebot:

LOAD:08048BD2                 mov     [esp+2A8h+arg8], offset aEtcFlagsDaemon ; "/etc/flags/daemon03.txt"
LOAD:08048BDA                 mov     eax, [ebp+inbufsize]
LOAD:08048BDD                 mov     [esp+2A8h+arg4], eax
LOAD:08048BE1                 lea     eax, [ebp+inbuf]
LOAD:08048BE7                 mov     [esp+2A8h+arg0], eax
LOAD:08048BEA                 call    sub_8048B24

The flag_func in daemon03 is identical to the function found in the other daemons, which let me mark three more functions (sub_804A9F0, sub_8048EC0, and sub_804A6C0, a jumbled mess of anti-hardening code, CRC32, MD5 and SHA1 I wasted hours delving into by mistake and my inexperience with CTFs) as library routines and identify the import stubs for write, fopen, fprintf, malloc, etc. At this point I finally had enough data to reconstruct all the imports, and make my reversing work easier. IDA Pro reverse-engineered the imports as such:

extern:8052DB0 ; ---------------------------------------------------------------------------
extern:8052DB0
extern:8052DB0 ; Segment type: Externs
extern:8052DB0 ; extern
extern:8052DB0 ; int feof(FILE *)
extern:8052DB0                 extrn feof:near
extern:8052DB4 ; int write(int fildes,const void *buf,size_t nbyte)
extern:8052DB4                 extrn write:near
extern:8052DB8 ; int fileno(FILE *)
extern:8052DB8                 extrn fileno:near
extern:8052DBC ; int fprintf(FILE *,const char *,...)
extern:8052DBC                 extrn fprintf:near
extern:8052DC0 ; int fflush(FILE *)
extern:8052DC0                 extrn fflush:near
extern:8052DC4 ; int system(const char *string)
extern:8052DC4                 extrn system:near
extern:8052DC8                 extrn random:near
extern:8052DCC ; void *malloc(size_t size)
extern:8052DCC                 extrn malloc:near
extern:8052DD0 ; size_t fread(void *,size_t size,size_t n,FILE *)
extern:8052DD0                 extrn fread:near
extern:8052DD4 ; time_t time(time_t *timer)
extern:8052DD4                 extrn time:near
extern:8052DD8                 extrn __fxstat:far
extern:8052DDC                 extrn __libc_start_main:near
extern:8052DE0 ; void *memcpy(void *,const void *,size_t)
extern:8052DE0                 extrn memcpy:near
extern:8052DE4 ; int fclose(FILE *)
extern:8052DE4                 extrn fclose:near
extern:8052DE8 ; void exit(int status)
extern:8052DE8                 extrn exit:near
extern:8052DEC ; void free(void *)
extern:8052DEC                 extrn free:near
extern:8052DF0 ; void *memset(void *,int,size_t)
extern:8052DF0                 extrn memset:near
extern:8052DF4 ; FILE *fopen(const char *name,const char *type)
extern:8052DF4                 extrn fopen:near
extern:8052DF8                 extrn srandom:near
extern:8052DFC ; int sprintf(char *,const char *,...)
extern:8052DFC                 extrn sprintf:near
extern:8052E00 ; size_t fwrite(const void *,size_t size,size_t n,FILE *)
extern:8052E00                 extrn fwrite:near
extern:8052E04 ; int read(int fildes,void *buf,size_t nbyte)
extern:8052E04                 extrn read:near

In a normal program, all of these would be cross-referenced to their callers. In the poor, brutalized daemon03, I had to intervene manually with some reconstructive surgery. While identifying and renaming the stubs, I noticed they were in the same order as symbols in the externs section:

LOAD:08048868 ; [00000010 BYTES: COLLAPSED FUNCTION sub_8048868. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048878 ; [00000010 BYTES: COLLAPSED FUNCTION _write. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048888 ; [00000010 BYTES: COLLAPSED FUNCTION sub_8048888. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048898 ; [00000010 BYTES: COLLAPSED FUNCTION _fprintf. PRESS KEYPAD "+" TO EXPAND]
LOAD:080488A8 ; [00000010 BYTES: COLLAPSED FUNCTION sub_80488A8. PRESS KEYPAD "+" TO EXPAND]
LOAD:080488B8 ; [00000010 BYTES: COLLAPSED FUNCTION sub_80488B8. PRESS KEYPAD "+" TO EXPAND]
LOAD:080488C8 ; [00000010 BYTES: COLLAPSED FUNCTION sub_80488C8. PRESS KEYPAD "+" TO EXPAND]
LOAD:080488D8 ; [00000010 BYTES: COLLAPSED FUNCTION _malloc. PRESS KEYPAD "+" TO EXPAND]
LOAD:080488E8 ; [00000010 BYTES: COLLAPSED FUNCTION sub_80488E8. PRESS KEYPAD "+" TO EXPAND]
LOAD:080488F8 ; [00000010 BYTES: COLLAPSED FUNCTION sub_80488F8. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048908 ; [00000010 BYTES: COLLAPSED FUNCTION sub_8048908. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048918 ; [00000010 BYTES: COLLAPSED FUNCTION ___libc_start_main. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048928 ; [00000010 BYTES: COLLAPSED FUNCTION sub_8048928. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048938 ; [00000010 BYTES: COLLAPSED FUNCTION sub_8048938. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048948 ; [00000010 BYTES: COLLAPSED FUNCTION _exit. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048958 ; [00000010 BYTES: COLLAPSED FUNCTION sub_8048958. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048968 ; [00000010 BYTES: COLLAPSED FUNCTION sub_8048968. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048978 ; [00000010 BYTES: COLLAPSED FUNCTION sub_8048978. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048988 ; [00000010 BYTES: COLLAPSED FUNCTION _fopen. PRESS KEYPAD "+" TO EXPAND]
LOAD:08048998 ; [00000010 BYTES: COLLAPSED FUNCTION sub_8048998. PRESS KEYPAD "+" TO EXPAND]
LOAD:080489A8 ; [00000010 BYTES: COLLAPSED FUNCTION sub_80489A8. PRESS KEYPAD "+" TO EXPAND]
LOAD:080489B8 ; [00000010 BYTES: COLLAPSED FUNCTION sub_80489B8. PRESS KEYPAD "+" TO EXPAND]
LOAD:080489C8 ; [00000010 BYTES: COLLAPSED FUNCTION _read. PRESS KEYPAD "+" TO EXPAND]

Even in my ignorance of Linux executables, this looked too perfect to be a coincidence, so I proceeded to rename them and give them the Alt-P,L treatment. At this point, most of the executable's code was marked with the light blue of library routines. I briefly examined the remaining routines, marking a couple more: sub_8048AD4, which looks like an unused hex_dump function (it must be part of a standard library of CTF-specific routines together with flag_func), and sub_8048A32, a helper routine that lets the compiler emulate PC-relative addressing on the uncooperative x86 architecture, for the purposes of position-independent code. This long and extensive scrubbing gave us a sparkling clean call graph (Ctrl-F12):

Still too messy for my tastes, so I gave it some manual clean-up, removing the orphaned externs, the noisy light-blues and other irrelevant elements:

My top-down approach to reverse-engineering was finally paying off, revealing the program in all its straightforwardness: some standard library code, some custom library code shared with the other daemons, and a mere two custom routines, main and sub_804C9E0. It was finally time to get myself intimate with main and its mistery companion.

The flow graph of main appeared straightforward, as well:

I could clearly identify two failure points (the exhaustive approach really paid off, as IDA Pro automatically marked the "_exit" function as non-returning, removing some spurious execution paths from the graph) and a loop followed by a success path. As per standard procedure, I proceeded to collapse the function's prolog and group the failure points together, to make for a leaner graph. The success path and function epilog looked simple enough to be hidden away, too:

LOAD:08048E5B                 mov     eax, stdout
LOAD:08048E60                 mov     [esp+2A8h+argc], eax
LOAD:08048E64                 mov     eax, [ebp+inbufsize]
LOAD:08048E67                 mov     [esp+2A8h+arg8], eax
LOAD:08048E6B                 mov     [esp+2A8h+arg4], 1
LOAD:08048E73                 mov     eax, [ebp+outbuf]
LOAD:08048E76                 mov     [esp+2A8h+arg0], eax
LOAD:08048E79                 call    _fwrite
LOAD:08048E7E                 mov     eax, stdout
LOAD:08048E83                 mov     [esp+2A8h+arg0], eax
LOAD:08048E86                 call    _fflush
LOAD:08048E8B                 mov     eax, [ebp+var_C]
LOAD:08048E8E                 mov     [esp+2A8h+arg0], eax
LOAD:08048E91                 call    _free
LOAD:08048E96                 mov     eax, [ebp+outbuf]
LOAD:08048E99                 mov     [esp+2A8h+arg0], eax
LOAD:08048E9C                 call    _free
LOAD:08048EA1                 mov     [esp+2A8h+arg0], offset aUsrBinDate ; "/usr/bin/date"
LOAD:08048EA8                 call    _system
LOAD:08048EAD                 mov     eax, 0
LOAD:08048EB2                 leave
LOAD:08048EB3                 retn

The normal exit points of a function can be quite telling. This one's told me a buffer was written on standard output, two objects allocated on the heap, one of which being the aforementioned buffer, and that the "date" command was executed at the end so that its output would be concatenated with the daemon's. None of this appeared vital to the understanding of the loop (most certainly the heart of the program, which at this point pretty transparently appeared to be an encryption algorithm with a pseudo-random component to the secret key), so I collapsed the success path with the failure exits to form a single exit point. The beginning of the main function was quite familiar too: a fixed-width read from standard input followed by a call to flag_func, so I collapsed that section too. A cursory look at the loop confirmed my suspicions: a trivial loop of "inbufsize" iterations, and, luckily, the body only appeared to perform basic arithmetics. For the first time since the CTF had begun, I had a really good feeling about it…

Before turning my undivided attention to the loop, very obviously the meat-and-potatoes of daemon03, I started chipping away at its surroundings. First of all, it appeared only the first 4 bytes of client input were deemed of interest:

LOAD:08048BEF                 mov     [esp+2A8h+arg8], 4
LOAD:08048BF7                 lea     eax, [ebp+inbuf]
LOAD:08048BFD                 mov     [esp+2A8h+arg4], eax
LOAD:08048C01                 lea     eax, [ebp+inbuf4bytes]
LOAD:08048C07                 mov     [esp+2A8h+arg0], eax
LOAD:08048C0A                 call    _memcpy

Then, the flag file was opened:

LOAD:08048C0F                 mov     [esp+2A8h+arg4], offset aRb ; "rb"
LOAD:08048C17                 mov     [esp+2A8h+arg0], offset aEtcFlagsDaemon ; "/etc/flags/daemon03.txt"
LOAD:08048C1E                 call    _fopen
LOAD:08048C23                 mov     [ebp+flagfile], eax

Next, the opened file description number of the flag file was retrieved with fileno, and passed to the mysterious sub_804C9E0, along with what appeared to be a structured output buffer:

LOAD:08048C55                 mov     eax, [ebp+flagfile]
LOAD:08048C58                 mov     [esp+2A8h+arg0], eax
LOAD:08048C5B                 call    _fileno
LOAD:08048C60                 mov     edx, eax
LOAD:08048C62                 lea     eax, [ebp+outstruct]
LOAD:08048C65                 mov     [esp+2A8h+arg4], eax
LOAD:08048C69                 mov     [esp+2A8h+arg0], edx
LOAD:08048C6C                 call    sub_804C9E0
LOAD:08048C71                 mov     eax, [ebp+field]
LOAD:08048C74                 mov     [ebp+var_10], eax

Much to my relief, sub_804C9E0 proved to be a thin wrapper around __fxstat, which I assumed to be some kind of versioned fstat system call that could multiplex between multiple modes (such as 32-bit vs 64-bit offsets), so I simply renamed sub_804C9E0 to "_fstat" and returned my attention to main. IDA Pro didn't seem to have a definition of struct stat that matched the Linux version the program was compiled for, but it was nevertheless pretty clear that fstat was being used to retrieve the flag file's size. The program, armed with this knowledge, then allocates two buffers as large as the flag file, one of which will be written to standard output in the success path:

LOAD:08048C77                 mov     eax, [ebp+flagfilesize]
LOAD:08048C7A                 mov     [esp+2A8h+arg0], eax
LOAD:08048C7D                 call    _malloc
LOAD:08048C82                 mov     [ebp+buffer1], eax
LOAD:08048C85                 mov     eax, [ebp+flagfilesize]
LOAD:08048C88                 mov     [esp+2A8h+arg0], eax
LOAD:08048C8B                 call    _malloc
LOAD:08048C90                 mov     [ebp+outbuffer], eax

The flag is then read in memory, into the first dynamic buffer:

LOAD:08048CC0                 mov     eax, [ebp+flagfile]
LOAD:08048CC3                 mov     [esp+2A8h+argc], eax
LOAD:08048CC7                 mov     eax, [ebp+flagfilesize]
LOAD:08048CCA                 mov     [esp+2A8h+arg8], eax
LOAD:08048CCE                 mov     [esp+2A8h+arg4], 1
LOAD:08048CD6                 mov     eax, [ebp+flag]
LOAD:08048CD9                 mov     [esp+2A8h+arg0], eax
LOAD:08048CDC                 call    _fread
LOAD:08048CE1                 mov     [ebp+inbufsize], eax
LOAD:08048CE4                 mov     eax, [ebp+flagfile]
LOAD:08048CE7                 mov     [esp+2A8h+arg0], eax
LOAD:08048CEA                 call    _fclose

I could then group all the preceding basic blocks into a single graph node I called simply "initialization". The algorithm found itself cornered before me, corraled into a mere two-and-a-half basic blocks:

A realization hit me. I paused, smiled, turned right to Emanuele and asked "You know what time is it?" "Is it time for [expletive]?" (we had taken to using curse words as punctuation by that point) "Oh, no", I said, my smile now a chesiresque grin, "It's time to write code".

About two hours later, spent switching back and forth between Visual Studio, IDA Pro, the Windows calculator, pen-and-paper notes, a remote GDB session (on the live team server no less!) and my own overheating brain, I had the algorithm fully decompiled and tested against the binary. Here is it, in form of inline annotations to the disassembly:

LOAD:08048D13                 mov     [esp+2A8h+arg0], 0
LOAD:08048D1A                 call    _time
LOAD:08048D1F                 mov     [esp+2A8h+arg0], eax
LOAD:08048D22                 call    _srandom        ; srandom(time(NULL));
LOAD:08048D27                 call    _random
LOAD:08048D2C                 mov     edx, eax
LOAD:08048D2E                 lea     eax, [ebp+key]
LOAD:08048D34                 xor     [eax], edx      ; key ^= random(); // key comes from input
LOAD:08048D36                 mov     eax, [ebp+key]
LOAD:08048D3C                 mov     [ebp+state], eax
LOAD:08048D42                 mov     ecx, [ebp+state] ; state = key;
LOAD:08048D48                 and     ecx, 0FF00FFFFh ; // in retrospect, I know this to be some clever
LOAD:08048D48                                         ; // compiler-generated code to perform division
LOAD:08048D48                                         ; // by 10 without divisions
LOAD:08048D4E                 mov     eax, 0CCCCCCCDh
LOAD:08048D53                 mul     ecx
LOAD:08048D55                 mov     eax, edx
LOAD:08048D57                 shr     eax, 3
LOAD:08048D5A                 mov     [ebp+index], eax
LOAD:08048D60                 mov     edx, [ebp+index]
LOAD:08048D66                 mov     eax, edx
LOAD:08048D68                 shl     eax, 2
LOAD:08048D6B                 add     eax, edx
LOAD:08048D6D                 add     eax, eax
LOAD:08048D6F                 sub     ecx, eax
LOAD:08048D71                 mov     eax, ecx
LOAD:08048D73                 mov     [ebp+index], eax ; index = state % 10;
LOAD:08048D79                 mov     eax, [ebp+index]
LOAD:08048D7F                 mov     edx, ds:keytable[eax*4]
LOAD:08048D86                 lea     eax, [ebp+state]
LOAD:08048D8C                 xor     [eax], edx      ; state ^= keytable[index];
LOAD:08048D8E                 mov     [ebp+i], 0
LOAD:08048D98
LOAD:08048D98 loc_8048D98:
LOAD:08048D98                 mov     eax, [ebp+i]
LOAD:08048D9E                 cmp     eax, [ebp+inbufsize]
LOAD:08048DA1                 jge     loc_8048E5B     ; for(i = 0; i < inbufsize; ++ i)
LOAD:08048DA1                                         ; {
LOAD:08048DA7                 mov     eax, [ebp+i]
LOAD:08048DAD                 add     eax, [ebp+flag]
LOAD:08048DB0                 movzx   eax, byte ptr [eax]
LOAD:08048DB3                 mov     [ebp+flagbyte], al ; flagbyte = flag[i];
LOAD:08048DB9                 mov     [ebp+const], 65h
LOAD:08048DC0                 movzx   eax, [ebp+const]
LOAD:08048DC7                 add     eax, eax
LOAD:08048DC9                 mov     [ebp+const], al ; const = 0xca; // no idea why this wasn't inlined
LOAD:08048DCF                 mov     edx, [ebp+state]
LOAD:08048DD5                 mov     eax, edx
LOAD:08048DD7                 add     eax, eax
LOAD:08048DD9                 add     eax, edx
LOAD:08048DDB                 mov     [ebp+state], eax ; state *= 3;
LOAD:08048DE1                 mov     eax, [ebp+state] ; // probably some more compiler-generated
LOAD:08048DE1                                         ; // code. No idea as to the intended purpose
LOAD:08048DE7                 mov     ecx, eax
LOAD:08048DE9                 shr     ecx, 18h        ; tmp1 = key2 >> 24;
LOAD:08048DEC                 mov     eax, 0F0F0F0F1h
LOAD:08048DF1                 mul     ecx
LOAD:08048DF3                 shr     edx, 4          ; tmp2 = ((0xf0f0f0f1 * (long long)tmp1) >> 32) >> 4;
LOAD:08048DF6                 mov     eax, edx
LOAD:08048DF8                 shl     eax, 4
LOAD:08048DFB                 add     eax, edx        ; tmp3 = (tmp2 << 4) + tmp2;
LOAD:08048DFD                 sub     ecx, eax        ; tmp1 -= tmp3;
LOAD:08048DFF                 mov     eax, ecx
LOAD:08048E01                 add     eax, 8
LOAD:08048E04                 movzx   ecx, al         ; tmp3 = (tmp1 + 8) & 0xff;
LOAD:08048E07                 mov     eax, [ebp+state]
LOAD:08048E0D                 shr     eax, cl
LOAD:08048E0F                 and     eax, 0FFh
LOAD:08048E14                 xor     eax, [ebp+state]
LOAD:08048E1A                 inc     eax
LOAD:08048E1B                 mov     [ebp+state], eax ; state = (((state >> tmp3) & 0xff) ^ state) + 1;
LOAD:08048E21                 mov     eax, [ebp+state]
LOAD:08048E27                 mov     dl, al
LOAD:08048E29                 add     dl, 2Eh         ; key = ((state & 0xff) + 0x2e) & 0xff;
LOAD:08048E2C                 lea     eax, [ebp+flagbyte]
LOAD:08048E32                 xor     [eax], dl       ; flagbyte ^= key;
LOAD:08048E34                 mov     eax, [ebp+i]
LOAD:08048E3A                 mov     edx, [ebp+outbuffer]
LOAD:08048E3D                 add     edx, eax
LOAD:08048E3F                 movzx   eax, [ebp+const]
LOAD:08048E46                 add     al, [ebp+flagbyte]
LOAD:08048E4C                 mov     [edx], al       ; outbuffer[i] = flagbyte + const;
LOAD:08048E4E                 lea     eax, [ebp+i]
LOAD:08048E54                 inc     dword ptr [eax]
LOAD:08048E56                 jmp     loc_8048D98     ; }

Basically, the algorithm has a 4-byte initialization vector, filled with a value derived from the 4-byte key in the program input, the current timestamp after a round of srandom/random and an internal table of 10 magic numbers (that seem to have been borrowed at random from the S-boxes of the Korean SEED algorithm, RFC4269). This vector is used to produce a key the same length as the input. The key and input are combined with XOR into a temporary output. Finally, the value of every byte in the temporary output is rotated by 202 positions (0xCA in hexadecimal) to produce the final, encrypted output. Apart from the rotation step, the algorithm is symmetric: given an identical initialization vector and the encrypted output as input, it will produce the plain input. The tricky part is, of course, to reverse-engineer the initialization vector for any particular iteration.

Not having the time (nor inclination) to mathematically prove how many bits of the state were actually used to derive the key, and so whether a brute-force attack over a possibly limited keyspace was feasible, I had to attack the algorithm in the intended way: parsing the output of the UNIX date command back into a timestamp. I hate parsing. With a hint of shame for a rushed job (and a sigh of relief for a rushed parsing job), I limited myself to parsing the time fields, assuming the remote machine to have the same date and timezone as the local machine. The score server wanted a hexadecimal dump of the flag, so I quickly whipped up a dump routine. Getting impatient, I tested my half-finished decoder against an actual output from daemon03, and with a mounting wave of pride I witnessed a single, perfect line of output that matched the actual flag. My creature was ready for the field.

Tactical

The decoder written and tested (and "ported" from Windows to Linux — a mere recompilation sufficed — to use the right srandom/random), attacking daemon03 looked trivial. In went our half of the secret key (I picked a fixed value, "ABCD", or 0x44434241), out went the flag, ready for automated submission. This was the theory. The field proved less cooperative.

Intermittent failures were to be expected from the outset. More than one second could conceivably pass between the daemon's call to time and /usr/bin/date's, so we expected having to execute the attack multiple times in a row until the output stabilized. What we didn't expect was corrupted output. Flags were meant to be 20 bytes long, but some actually were 21 bytes, others 41 (I had to change the decoder to take a variable-length input. Most inconvenient. I'm not a huge vim fan). Some daemons didn't seem to execute /usr/bin/date (I hope all of these were at least supposed to count as failures. Corrupted output means denied service). In a few cases, completely bogus outputs resulted. To make it worse, we just happened to deploy our attack in the middle of a "flap" of bad flags, scorebot glitches and network issues.

By that time, though, I had turned my attention to daemons number 5 and 7 (trivially exploitable and they contained the shellcode themselves! sure wished I had looked at them earlier), the joys and worries of daemon number 3 already behind me.

Strategical

The overall impact of the daemon03 effort on the ongoing war was, frankly, disappointing. Very few valid flags could be milked from it, and the breakthrough was not worth much. Flags weren't refreshed as often as we expected (or ever, really), and only half-heartedly did we launch multiple waves of attack.

All in all, for a challenge that required hours of work, reversing, coding, debugging, and not just a canned input and/or some trial-and-error, we were pretty underwhelmed. Nothing to do but keep our ol' reliable strategy going until the end, slowly and steadily racking up points and solidifying our second place. We had to accept that the daemon03 challenge would be its own reward, and move on.

WSLabi @ HITB Malaysia 2007

As previously announced with a dedicated post, WabiSabiLabi has been invited to the Hack In The Box security conference, in Malaysia, to participate with a dual mission: try to compete with the Asian experts at the Capture the Flag hacking game and to hold a speech to the conference attendees about our marketplace initiative.

We welcomed such opportunity as it gave us the occasion to meet the people and show our faces (in response to those who speculated about our non-existence) as well as to address to the public, with a speech aimed to explain every single aspect of our venture from the business and legal point of view.

The response has been fantastic. In two days we have talked (beside the public speech) to more than 100 people who were eager to ask us details about the WSL project. We also released 6 newspapers interviews as well as a BBC radio interview. Believe it or not, in those 2 conference days we received nothing but compliments for our initiative, from hackers, security companies attending the conference, from journalists and from militaries.

One of the questions often addressed to us was related to the trust that should be put in place in order to have WSL being perceived positively from both the security researchers and security companies. People were asking us: "how will you build the trust?" and our answer was: "It will take time, we know it. Being here showing our faces in the most important conference in the Far East it's a first important step."

So there we were, people could see us, people could touch us, people could ask us.

During the 50 minutes speech, our Director of Strategy Roberto Preatoni tried to address most of the criticism we received at our launching date. We think we succeeded in explaining to the attendees (and through the press interviews to the general public) what is the scope of WSL and how the whole security market segment will benefit from it.

Roberto Preatoni, WSL Director of Strategy during his speech at HITB

During the conference, we participated also at the Capture The Flag competition, where 10 teams (8 from Asia, us from Switzerland and the US Army team) struggled with offensive and defensive techniques, reverse engineering, crypto analysis, exploit coding etc.

At the end of the competition, we managed to score second, behind the excellent team SaoVang from Vietnam (really tough and skillful guys, believe us). During the competition we also wasted a lot of time reversing some crypto daemons, but eventually at the end we succeeded. More details about this in a separate post.

The SaoVang team with the WSL team at the end of the competition

A particular mention to the US Army team (Army Strong). They didn't succeed in scoring any hacking task, but they succeeded to get the best defensive points. Considering that their critical mission in every day's life is to defend the US Army network (they don't have any legal right to attack), we think that they met their mission objective which was to come to the CTF to score the best in defense. Mission accomplished, congratulation US Army Team!

The WSL team with the US Army team. Cheers guys!

The WSL team at work

The WSL team receiving the 2,000 USD prize

The score table at the end of the CTF competition

Overall it has been a truly exciting experience, the HITB conference is just a "must-be-there" event, with a very high level of speakers and attendees. We certanly will try to show up also the next year, that time aiming to the first price ;)

WSL @ Hack In The Box, over.

WSL in tour

WabiSabiLabi has been invited to speak at the Kuala Lumpur Hack In The Box 2007.

Hack in the Box is a world-class conference where we will be able to showcase our strategic director Roberto Preatoni as he relates the experience of the project so far and the future challenges that await it.

Mr. Preatoni will address the controversies and criticism that have surrounded it ever since the launch, as well as discuss the lessons we have learned.

We are also very excited to have been invited to a vendor's private conference, and we are preparing a dedicated speech for it. More details available soon.

Slides of the speeches will be available for download after the two events.

Hope to see you in Malaysia!

PS: HITB is a great conference, we welcome you to visit it!

Two months after...

Hello World, after the launch of our project (two months ago) we have been pretty busy attending conferences all around the planet (more to come on this, later) , meeting very interesting people, closing partnership and tuning our approach to this thrilling market.

At this point, we think we owe you a report about the current status:

twelve vulnerabilities up for bidding. Four of which pretty high-profile, with three distinct exploitable buffer overflows in the SAP front-end (more to these than meets the eye... let's just say the highest bidder is in for a big surprise), and a remote code execution flaw in ClamAV; all of which coming with reliable (albeit harmless, of course) Proof of Concept code.

Despite the naysayers, the sabotage attempts, the hostility, the marketplace is very much healthy. Healthier than ever. Almost a thousand registered users, five successful sales, twelve opened auctions online at this time, several good reviews and explicit approvals and more to come yet. Not to mention the innumerable invalid (or otherwise worthless) submissions weeded out by our team, in a never-ending dedication on quality over quantity.

We want to thanks all the people supporting our project and especially, obviously, all the researchers who are supporting the program, believing in it.

Hypocrisy in the Exploit Market

In the recent frenzy of comments on WSLabi that appeared after our first round of press-releases, we came across one post that we consider particularly interesting.
It has been written by Ben Laurie and posted on his blog. This post deserves to be commented a little, as it partially hits some good points but it also shows evidences of lobby-driven press coverage influence (we are referring here to some articles recently appeared on the press).
In bold, our comments.

_________________________________________________________________

"I am amused to read about an auction site for zero-days. Why am I amused? Not because I think that selling zero-days is cool, but because of the massive hypocrisy by other zero-day vendors.

“How do you know bidders aren’t people with nefarious purposes”

wails Terri Forslof of zero-day vendor, TippingPoint. I don’t know, Terri, but I’ve been wondering how you figure that out for some time.

Companies like TippingPoint and VeriSign’s iDefense both pass along details of vulnerabilities they buy to the affected software vendors, and both withhold public disclosure of the flaws until the vendor has shipped a “patch” to plug the security holes.

Aren’t they nice? They only tell paying customers about the flaws before they’re patched. That’s clearly different from WabiSabiLabi, who only tell paying customers about the flaws before they’re patched. Oh, wait…

There is a good point here about the traditional vendor's business model and "responsible disclosure" policy but also a misunderstanding that we need to clarify.

WSlabi is indeed introducing a step-ahead in the way the disclosure is handled. In fact, everybody can get informed about the existence of a vulnerability just by browsing our marketplace. They don't need to buy the related security research in order to be alerted while, with traditional security vendor's business model, only the paying customers gets alerted.

Now, who is more ethical?

This really does amuse me, though

WabiSabiLabi’s founder said the company currently has no plans to notify affected vendors, saying that could ultimately decrease the price buyers are willing to pay for any one vulnerability.

Now, the dodgy geezers at WabiSabiLabi are trying to convince us that they would only sell to well-intentioned people. How can they possibly square that with the idea that buyers will pay more for unfixed vulnerabilities? What possible good motive could such a buyer have?

Of course, I’m having a hard time figuring out why anyone would be buying these vulnerabilities in the first place: perhaps the story is that they will get competitive advantage by being able to claim that they have fewer vulnerabilities? I’m looking forward to the adverts: “XYZ - now with fewer security holes than competitive products! Get it before they outbid us!”.

Any security company, which is doing legitimate penetration tests and rendering security services to customer might be interested in buying from the marketplace.

The reason it's obvious as it gives a huge competitive advantage against the competitors.

Having clarified these points, we really enjoyed Ben's post. We'd like to see more of such challenging and constructive comments...

Squeezing the lemon twice

WabiSabiLabi's philosophy is to provide a way to maximize Security Researchers' reward.

We consider the Security Researcher a valuable company's asset, in this view beside the revenues generated by the marketplace, we are willing to provide the Security Researcher with a system to guarantee a stream of extra revenues over the time, based on our Vulnerability Sharing Club (VSC) program. Each Security Research sold through the marketplace without the "Buy exclusively!" option, will automatically qualify to enter into the WSLabi's VSC program.

To each of those Security Researches will be assigned a value in thousands (rounded to the upper thousand), correspondent to the maximum price it had been purchased from the marketplace.

Example:

To make it simple, let's assume that our VSC program will be listing only two hypothetical security researches, submitted by two different researchers to the marketplace. The first is sold at a maximum price of 4000 euros, while the second is sold at a maximum price of 16,000 euros.

The assigned points will be:

- 4 points to researcher 1
- 16 points to researcher 2
Total assigned points = 20

At the end of each quarter, 10% of the generated revenues from our VSC program, will be distributed to both researchers, proportionally to the assigned point. If, for example, the VSC program generated in the fiscal quarter revenues for 200,000 Euros, 20,000 Euros will be assigned to the researchers:

Researcher 1: 20,000 / 20 (total assigned points) * 4 = 4,000 Euros
Researcher 2 : 20,000 / 20 (total assigned points) * 16 = 16,000 Euros

Every three months (fiscal quarter) the points for each Security Research contained in WSLabi's VSC package will be assigned to the correspondent Security Contributor. At that point, a share on the total revenues generated by the VSC sales will be distributed among the Security Contributors, proportionally to the total points assigned to them.

As long as the Security Research will stay in the VSC package, the Security Contributor will keep cashing royalties from his intellectual property. Each Security Research will be considered accountable as long as it has not become public or patched or outdated and anyway for a maximum period of 1 year.

If the Security Research is related to a vulnerability that has become public, patched or outdated by new software releases, it will be taken away from our VSC program and the relevant points will be deducted from the next quarter to the correspondent Security Contributor.

In a nutshell: WabiSabiLabi contributors will be rewarded:

- from the marketplace, having also the possibility to perform multiple sales from the same security research, therefore cashing more than one time

- from our VSC program, where submitted vulnerabilities will allow to obtain a share of the revenues generated by marketing the VSC services. The share will be proportional to the price obtained through the marketplace and will last as long as the vulnerability becomes patched, disclosed or outdated and for a maximum period of 1 year.

IPhone call for vulnerabilties

Finally, last Friday the IPhone hit the market.
We witnessed thousands of Apple lovers waiting countless hours in line, ready to assault the shops to buy this year's "King of the Gears".

While shop clerks were still cashing the money from the first IPhone sales, the hacker community already started a bunch of projects aimed to bring the IPhone down to its knees.

In S. Francisco, they organized a camp where attendees "will include web designers, developers, testers, and iPhone owners--all working together, on their precious weekend, to improve the web experience for iPhone owners." Yes, we really love the wording here.

Always at the same time, other hackers decided to open apart the *just purchased* IPhone in order to let us peek at its inner circuits
In another part of the globe, other hackers posted some hints about activating the IPhone's latent features without a cellphone contract and activation process.
Meanwhile, some other hackers started to talk about potential IPhone multiple security issues, just hours after the purchase.
At the end of the day, other hackers posted a link from which apparently it is possible to download the firmware of the IPhone, directly from an Apple server.

So much of attention for this newborn baby, we certainly want to do our part.

WABISABILABI is releasing a CALL FOR SECURITY RESEARCH AND ANALYSIS based on the IPhone hardware and software platform

Security researchers from all over the world are invited to report to us the findings and eventually use our marketplace platform to find buyers for their discoveries.

When vendors get nuts

In a post recently appeared on the McAfee's Avert Labs Blog (posted by Vinoo Thomas) we were quite entertained by reading an astonishing statement in which McAfee curses against a crew of virus researchers who "dared" to send a proof of concept of a virus to McAfee's laboratories.

The concept virus is quite interesting as it is reported on the blog "virus Bad Bunny a.k.a StarOffice/BadBunny is a multi-platform macro virus written in StarBasic and which executes on Linux, MacOSX and Windows. It is capable of infecting JavaScript, Ruby and Perl script files and also attempts to perform a denial of service attack on antivirus vendor sites by sending large ICMP packets continuously."

Pretty neat! Now, where would it be the value of such PoC? The value consists in the early-alert the antivirus vendor gets about the possible release of a new attacking vector/methodology on which, needless to say, they will base their business. Knowing in advance new attacking vectors/methodologies is crucial for the security business as the security vendors should always try to be a step-ahead of the cyber criminals. You cannot build a decent security strategy without valuing properly the messages coming from your intelligence network, and in such view warnings (or PoCs) coming from researchers are certanly the best kind of intelligence a security agency could ever dream of.

But no, McAfee dismissed the job of those researchers by reporting Peter Ferrie’s motivating words for such virus authors. “So imagine you’re a virus writer, someone who specialises in one-of-a-kind viruses, and you want to do something that’s really new and different. What should it be? How about quitting?

Take the cue guys. Get a life!"

We have just two questions here:

1 - Assuming all virus writers would quit writing viruses, what would McAfee's shareholders say?
2 - Do McAfee really think that giving the finger to researchers would be the best motivation for them not to sell their research to the criminal market?

Think once. Even better, think twice.

WabiSabiLabi's philosophy

Wabi-sabi (in Japanese katakanaワビサビ) represents a comprehensive Japanese world view or aesthetic centred on the acceptance of transience. The phrase comes from the two words wabi and sabi. The aesthetic is sometimes described as one of beauty that is "imperfect, impermanent, and incomplete". It is a concept derived from the Buddhist assertion of the Three marks of existence — Anicca, or in Japanese, 無常 (mujyou), impermanence.

Wabi-sabi nurtures all that is authentic by acknowledging three simple realities: nothing lasts, nothing is finished, and nothing is perfect."

In this view, Wabi-sabi is the perfect term to represent the implicit imperfection of the IT security, as well as the scope of our project, which is to contribute to its improvement. This goal is achieved by completely re-designing the traditional security research cycle, introducing for the first time ever a market-driven approach to correctly value the security researchers contributions.

Nothing lasts, but everything can always be improved in its life-cycle.