Still using Windows 2000? you are at risk

As Microsoft gradually stops supporting Windows 2000, vendors of other products around them also stop supporting it. This is no big deal for those that moved to Windows XP, 2003 or Vista – but it could be a big deal to all those that simply don’t have the computer power to do the switch and want to stick to their working OS.

Microsoft has promised to release security related patches for Windows 2000 for a bit more, but this will eventually stop – what is more concerning is the fact that Adobe and Apple have done this quietly and are placing their users at risk.

It has been quite a while now that Adobe [Acrobat Reader] has not released an update for its software with the claim – you guessed it – unsupported OS, and even more than a while that Apple [QuickTime] has not released an update for Windows 2000.

With the emergence of new vulnerabilities for Acrobat Read and QuickTime people are not only left behind on the vulnerability prevention race track, they are not made aware of it – both programs don’t care enough to give their users adequate wanning they are at risk.

List of issues affecting QuickTime with no apparent fix for Windows 2000:

* QuickTime 7.2 issues, QuickTime 7.3 issues, QuickTime 7.4 issues, QuickTime 7.5 issues – all these probably affect QuickTime 7.1 too


What is your blackberry doing without telling you?

I recently added a contact to my BlackBerry PIN network. The contact was informed of this via an email, and then went on to reply (accept) to this email based invitation.

The response sent from his blackberry was not visible in his “sent” folder, nor was it visible in my “inbox” as apparently BlackBerry has the ability to secretly delete emails as soon as they are processed – thus making it do things a bit “under the radar”.

It’s not yet clear to me how difficult it is to do this manually – adding of a contact to your BlackBerry PIN list – but here are some clues on the email mechanism. Apparently, you need to include in the subject and in the beginning of the message body (subject works in most cases – html appears to behave differently) the following string:

< $RemoveOnDelivery,SuppressSaveInSentItems>

You can combine the above in the subject line with confirm, which will cause BlackBerry to send back a delivery confirmation, combined with the deletion and suppression of saving the item:

< $confirm, RemoveOnDelivery,SuppressSaveInSentItems>


Secure coding practices – would you expect the RFC to follow them?

We recently did some work finding inherited vulnerabilities in SNMP supporting devices – mainly embedded/hardware.

SNMP like many other protocols is defined in several RFCs, starting with the basic RFC that describes the protocol structure and goes up to RFC 3414 which describes how authentication and encryption (referred to as privacy by the SNMP spec) are done.

The RFC describes a few algorithms, such as the one for key localization, in great detail – i.e. providing a C source code:

void password_to_key_md5(
u_char *password, /* IN */
u_int passwordlen, /* IN */
u_char *engineID, /* IN - pointer to snmpEngineID */
u_int engineLength,/* IN - length of snmpEngineID */
u_char *key) /* OUT - pointer to caller 16-octet buffer */
u_char *cp, password_buf[64];
u_long password_index = 0;
u_long count = 0, i;

MD5Init (&MD); /* initialize MD5 */

/* Use while loop until we've done 1 Megabyte */
while (count < 1048576) {
cp = password_buf;
for (i = 0; i < 64; i++) {
/* Take the next octet of the password, wrapping */
/* to the beginning of the password as necessary.*/
*cp++ = password[password_index++ % passwordlen];
MD5Update (&MD, password_buf, 64);
count += 64;
MD5Final (key, &MD); /* tell MD5 we're done */

/* Now localize the key with the engineID and pass */
/* through MD5 to produce final key */
/* May want to ensure that engineLength <= 32, */
/* otherwise need to use a buffer larger than 64 */
memcpy(password_buf, key, 16);
memcpy(password_buf+16, engineID, engineLength);
memcpy(password_buf+16+engineLength, key, 16);

MD5Update(&MD, password_buf, 32+engineLength);
MD5Final(key, &MD);

People reading this RFC would jump with joy and just copy paste the above code into their own code and continue on their work of getting SNMP to work on their hardware.

Little will they know that the RFC team has made notice that:

May want to ensure that engineLength < = 32, otherwise need to use a buffer larger than 64

“Ohh pff, who needs to ensure anything on my robust hardware – what is the worst that can happen, a server crash :D

Actually, the worst that can happen is a neat buffer overflow, as no one guarantees that the engineID is limited to 32 bytes, in reality the length is not limited by the transport layer (the ASN.1) but rather only by the RFC specification, which again not everyone checks or conforms to it by 100%.

I would expect the RFC editors/creators to place sample code that is secure. Something like so would have sufficed to prevent the code from being easily exploited:
memcpy(password_buf, key, 16);
memcpy(password_buf+16, engineID, engineLength < 32 ? engineLength : 32);
memcpy(password_buf+16+(engineLength < 32 ? engineLength : 32), key, 16);

Especially since Google searching the above example proved that quite a few people were too lazy to not only fix the security issue but too lazy to remove the embarrassing comment.


Q: Outlook attachments

Another one for you this week, we especially liked XenoMuta’s answer to our previous one.
Lets go:

Dear SecuriTeam,

i am not sure if you are able to help us to find a solution for a special problem but i’ve tried everything and spent a lot of time in the internet without any achievement.

we want to export the content of multiple exchange servers from our branch offices into personal folders (.pst files) and import these informations into our exchange mail system. the main problem why we are not yet able to do this is that we want to scan the content for viruses, worms (if possible with multiple virus scanners) and for unwanted content like videos, music, executables and so on and this in a way that a real content scan would be done instead of just checking against the file extension. also all attached archives (zip, rar etc.) should be opened (if possible) and scanned for its content. if an attachment is found which cannot be scanned because of password protection or encryption or whatever reason this attachment or the complete mail should be deleted or moved to a quarantine area.

Thank your very much for your support

Best regards
J. B.


Q: THC PPTP Bruter

Once again – another security question from our readers to the security experts who read this blog:

I ran across your site looking for information regarding the security of PPTP. I then found the PPTP bruter program from THC. I am a small business owner. I am a VAR (value added reseller) of POS (point of sale) equipment. My POS equipment is usually windows PC’s running POS software. I install a SOHO router that is also a PPTP endpoint so I can VPN in and remotely administrator my clients systems.

I’m trying to find out how easy it would be for someone to hack my PPTP endpoint. Can you help me figure out how to test my router?


K. L.


A new WMF attack looming?

It appears that a new WMF attack is coming, as you recall about a year back an WMF vulnerability was used on several high profile sites to infect visitors, this now appears to start happening again.

The first sign of this is the appearance of exploits for the vulnerability, starting off with version specific and evolving into a generic one.

The second sign is web sites being infect with hidden iframe that redirect to a javascript code that is at the moment dormant, or refers to non-existing domains.

The last stage is those javascripts getting modified, or the non-existing domains poping up into existing, you got yourself an infection.

It is time to start your vulnerability assessment engines, make sure all your windows based machines are tested, verify that your website passes a web site audit, and lastly get updated as this news item evolves.


Google calendar as a spam platform

Apparently Google’s calendar has been elected to become a new spam platform.

I started receiving these a few days ago, at first I thought it to be a fluke but not it has become a flood.

Someone in Google should probably start looking at this and getting it fixed, as this isn’t a “fake” Google calendar invitation but rather a legit Google generated one.

In essence the invitation contains the subject of what can be considered good by most :) good news:

When I read “Cheque” I am happy :)

But that is just me, maybe someone else will become sad, maybe the guy who is giving the cheque :)

And then this is followed by:

My Dear friend

How are you today together with your family,i thank God almighty for his infinity mercy upon my life for latter making this business to work out sucessfull.
I’m happy to inform you about my success in getting the fund transferred under the cooperation of the new partner from LUXMBURG . Presently i’m in LUXMBURG for investment projects with my own share of the total sum. meanwhile,i didn’t forget your past efforts and attempts to assist me in transferring those funds despite that it failed us some how.

Out of my sincere heart i have deceided to show gratuted to you and i have signed a Cheque on your behalf for your compasation,now contact my secretary in Cotonou, Republic of Benin,his name is Mr. Santex Romack  and his email address ; in and ask him to send you the total amount of $1.5,M Cheque which i kept for your compensation for all the past efforts and attempts to assist me in this matter.and instruct him where to send the amount to you.I appreciated your efforts to assist that time despite that you later disappointed me.

so feel free and get in touch to my secretary Mr Santex Romack Please do let me know immediately you receive it so that we can share the joy together after all the sufferness at that time. in the moment, i am very busy here because of the investment projects which i and the new partner are having at hand, finally, remember that I had forwarded instruction to my secretary on your behalf to receive that money, so feel free to get in touch with Mr.Santex Romack  and he will send the Cheque to you without any delay.

Sincerely Yours
Mr,John Max

And finally of course the meeting details in both iCal and vCal, which asks me to meet with them or just reply so that they can tell me exactly where we should meet :)

The headers of the email show that it was sent by Google’s internal SMTP server and was auto-generated by Google’s calendar service


iPhone Key Leak

The key which is used to sign iPhone application has apparently leaked, posting the key itself appears to be illegal, therefore we won’t do it, but others have, so just Google search it.


Google as an RBL

For those not familiar with RBL, the term means Real-time Blackhole List, it is mainly used for SPAM fighting. I have recently started playing around with Google as an RBL engine, the idea is that if the search term I use hits too many hits it is likely to be SPAM :)

The danger of course is that the term could be simply popular – but the trick here is that I’m using something very special as the search term – the IP address of the poster.

The IP address shouldn’t be popular; except for a few rare cases, IP addresses listed on Google are directly related to SPAM – either they are listed under wiki-like sites as being banned, or they appear as mass-comment posters. Simply put, if your IP is listed in Google you must be up to no good.

How good is this method? Nothing is bullet proof, but if you have a suspicion of something being SPAM, put the IP in Google and see there are hits; Almost all the comment SPAM I filtered out this month had more than 100 hits in Google, all non-SPAM had either 0 or below the 10 hits mark.

BTW: A good advantage of Google is that it is quick – a few seconds to get a respond – a disadvantage is that you cannot just “hammer” them with searches or they will block you – maybe someone can pickup this idea and make an RBL from IP addresses using Google as a back-engine.


From description to exploit

Every once in awhile I get an opportunity to work on a “known” vulnerability, but with very little or even no available technical details. These known vulnerabilities tend to be “known” just to their finder and to the vendor that fixed the vulnerability. We know they exist because an advisory is published, but not much more than that.
From the point where the vulnerability got fixed, no one (researcher or vendor) has any interest in disclosing the vulnerability details – as it is no longer interesting – leaving security researchers with insufficient information to confirm whether this vulnerability affects anyone else beside the specific vendor – and specific vendor version.

This is the point I reached today, where our team wanted to update a test of our vulnerability scanner to check for the exploitability of a certain vulnerability on a new platform. The version indicated it was vulnerable to the problem but there was no way to confirm it as the vulnerability’s technical description was inadequate, and checking only the version is a sure way for multitude of false positives.
With the little information available:
The get_server_hello function in the SSLv2 client code in OpenSSL 0.9.7 before 0.9.7l, 0.9.8 before 0.9.8d, and earlier versions allows remote servers to cause a denial of service (client crash) via unknown vectors that trigger a null pointer dereference.

I was determined to discover what was the “unknown vector” and see whether the product I tested was in fact vulnerable or not.

First step was to understand what the SSLv2 exactly is, and how I can get it – well simple enough here, “openssl s_client” is just what I needed – it was a sample SSL client that utilizes the get_server_hello() function.

Then I needed to create an SSLv2 session, this proved to be a bit more difficult as SSLv2 is now considered insecure and most SSL installations disable it – further Firefox no longer allows connecting to those sites that support it… but apparently Apache 2 haven’t given up on it, and you can turn SSLv2 support quite easily through the SSLProtocol definition.

Once that was available, I launched beSTORM’s auto-learn mechanism and made it capture the SSLv2 traffic – a complete session can be quite extensive but I only needed the first packets as they were the one get_server_hello() function looks into – once this was ready I used the pcap export capabilities to load the captured data into Wireshark – and use Wireshark’s existing dissection to mark which fields where what – who was the length of what, what was a flag, etc.

Then I told beSTORM to start listening on incoming traffic and play around with the values, I mainly concentrated on the following ServerHello parameters:

  • Packet Length (total length)
  • Session ID Hit (valid value is either set to 0×01 or set to 0×00)
  • Certificate Type (it is an enumeration of three possible values)
  • Certificate Length
  • Certificate Value
  • Cipher Spec Length
  • Cipher Spec Value
  • Connection ID Length
  • Connection ID Value

After a few thousands of combinations – taking about 50 minutes – with beSTORM modifying the Session ID Hit (set to 0×00), Certificate Type set to NULL (0×00), Certificate Length equal to 0, Certificate Value set to none, Cipher Spec Length equal to 0, Cipher Spec Value set to none and the default captured values of Connection ID – the openssl client crashed:

Program received signal SIGSEGV, Segmentation fault.
0x0808638d in get_server_hello (s=0x81aed90) at s2_clnt.c:542
542 if (s->session->peer != s->session->sess_cert->peer_key->x509)

Now all I needed was to instruct beSTORM to build a module from it – job done.

From a very vague description to an exploit in about an hour :-)

An exploit can be found at:  OpenSSL SSLv2 Client Crash (NULL Reference)


Orkut virus/worm on the loose

An Orkut based virus/worm appears to be on the loose, it propagates by posting notes on people’s scrapbook. So chances are that if you got a new scrapbook item on your long-unused Orkut it is because the worm has infected one of your friends there.

The virus/worm utilizes javascript code to propagate. The source of it can be found here: hxxp://
Update: Google apparently is actively deleting items from the scrapbook of people that were infected and that have infected others.

Update 2: More details can be found here:


Fuzzing is not just buffer overflows

We recently introduced a few improvements to our beSTORM fuzzing framework to make it test for things other than the common buffer overflow, format strings, integer overflow, off-by-one, etc. These includes less common vulnerabilities like command execution and code injection. These type of vulnerabilities are more complicated to test as they require close integration with the product being tested – namely monitor what it tries to open (similar to what filemon does) and what it tries to execute (in the case of Perl, PHP, etc).

Armed with these new tests we took one of the candidate we knew had no vulnerabilities of “common” ones as it is written in Perl, as such it was never audited for vulnerabilities, launched our fuzzing module for HL7 (Health Level 7) and awaited for the results, after several hundred of tests it detected something very particular:


\x0bMSH|^~\\&|||||20071203173658|||20071203173658.98 \x0d`/usr/bin/whoami`|||XXX|\x0d\x1c\x0d

Instead of the “normal” – non fuzzed traffic:

\x0bMSH|^~\\&|||||20071203173658|||20071203173658.98 \x0dMSH|||XXX|\x0d\x1c\x0d

Caused the program located under /usr/bin/whoami to get launched, of course this isn’t a ready made exploit or it is a vulnerability none the less, you can probably guess what the next step is :)

Update: The author of the program has promptly fixed the vulnerability and has released a new version, accessible by using the toolkit’s CVS version.
P.S: even though the software hasn’t been updated since March 2005, several vendors provide it as part of their HL7 implementations.

A CVE has been given to this vulnerability: CVE-2007-6264


Fuzzing the FIX Protocol

We have been asked by one of our customers to provide a beSTORM fuzzing module for the FIX protocol, for those who don’t know what FIX is – in laymen terms it what allows the world of finance to work as it is part of the Financial Information eXchange, the protocol is fairly simple and very insecure – not just because it is textual.

I will update you guys as soon as I can provide more details.


And the winner is …

Researchers from the Netherlands have predicted that the next president will be Paris HiltonOprah WinfreyAl Gore… well actually they don’t know, but what they do know is that they can created PDFs, or any other file format that allows storing random bits inside of it without affecting it, that all share the same MD5 value 3D515DEAD7AA16560ABA3E9DF05CBC80.

More details on the research can be found at their Predicting the winner of the 2008 US Presidential Elections using a Sony PlayStation 3 paper.



We have been working lately on improving beSTORM’s fuzzing support for SCADA. SCADA stands for Supervisory Control And Data Acquisition or in other words, the ability to monitor and control hardware/equipment.

SCADA isn’t one single protocol, rather it provides a concept which several protocols implement. One of them is DNP3 (Distributed Network Protocol). Originally SCADA protocols were used in closed environments with dedicated wires running through the organization which provided end-to-end communication. Today this type of physical implementation is uncommon and networking infrastructures are used – mainly Ethernet.

DNP3 is one of these, as it can be “carried” on a regular Ethernet infrastructure. It can also be routed through your network if you use DNP3 implementation over TCP/IP, in which case your deployment is much easier – connect the equipment to the network give it an IP address and you can control from anywhere that is reachable to that IP address.

As DNP3 and SCADA in general are mainly used in industrial equipment, it is not easy to come by hardware beSTORM will test. We therefore decided to start some place easier – the sniffer. There are several DNP3 Sniffers out there, the most common and popular is Wireshark (formerly known as Ethereal).

Testing was pretty straightforward. Put a listening netcat on DNP3′s designated port (20000) and fire our beSTORM DNP3 fuzzer at it. Pretty soon we noticed that beSTORM was able to not only fuzz the DNP3 protocol, but also cause several instances of Wireshark to freeze, one of them due to an endless loop Wireshark entered into (fixed in version 0.99.6) and another one caused it to exhaust large amounts of CPU and Memory as Wireshark tries to display more elements then would normally be in a single DNP3 packet (version 0.99.6 is vulnerable).

The endless loop, fixed in version 0.99.6, is caused by the following code:

for (temp16 = 0; temp16 < num_items; temp16++)

The code is vulnerable as the temp16 is set to be 16 bit value while num_items is set to be a 32bit value, which means that I can cause the temp16 to loop forever by supplying a 32bit value to the num_items parameter.

Update: Wireshark has released a new version which is immune to this attack version 0.99.7.


Project Hayneedle

I came across this blog entry, which tries to help German citizens – and others people that are under similar circumstances – confuse the authorities that might be monitoring traffic originating from a single IP address in other to deter him (the citizen) from doing illegal things ( government stated illegal – in the German case security research).

The project named Hayneedle tries to baffle agencies monitoring Internet traffic by generating a multitude of apparently random traffic in order help you to better hide what you are actually looking for – in laymen term, generate enough “noise” so that the “signal” is hidden.

In my opinion, the idea is pretty nice, but I would think that in this case a TOR like solution would be better, as the government seeks here to monitor your IP address’s access to sites, TOR’s goal is to eliminate that ability. In any case I wish the Hayneedle project best of luck, and hope it will make the government understand how fullish they are – no big hops on this part :)