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.


Google handing over a blogger’s IP

According to several Israeli newspapers google has exposed the IP address of a blogger that was using the “blogger” service.

You might think he was posting instructions on how to prepare a nuclear bomb or the secret Coca Cola formula. It’s much much worse. He was defaming officials in the “Sha’arei Tikva” municipality, which most Israelis can’t even place on a map, and needless to say have little to no interest on the intrigues and political wars there.

My point is, there is no benefit to anyone for exposing the blogger’s IP except to let these officials take him to court, and while google gave a weak legal fight, the decision was reached by out of court settlement, which means they didn’t even try to go the distance in order to block this request.

I think the main issue is not the blogger’s right for anonymity; it’s more about google’s unclear policy on what they do with the information they have. We know google save search data. We know that they have access to deleted emails on gmail (for who knows how long). We don’t know what they do on google talk, but we can guess. What we already know is scary; the fact that we don’t know the rest is even scarier.
It’s clear to everyone that google has information about us and our private life more than any other Internet entity (we had a securitoon about it a while back). Now it’s clear they are playing loose cannon with that information.

Update: Someone identifying herself as “google employee” writes in the talkback comments to the article that google only handed the IP, but the ISP gave the complete identifying information from that IP, and that the press’s picking on google is unjustified. If that google worker is reading this, feel free to email me your version of the story and it will be posted here anonymously (or just leave a comment below).


Fact of the week: iPhone widgets doesn’t send IMEI

I’m sure there are people not aware of the recent state of Apple iPhone IMEI case.
It was reported by UNEASYsilence blog (pointing to the older forum post of that “Stocks” and “Weather” widgets send the IMEI number to Cupertino.

I.e. like this:

The fact is, however, that the string being sent is not the International Mobile Equipment Identity code.

Reference: day after.en.html

What the widget sends is UUID code (Universally Unique Identifier).

Hey, IMEI has 15 characters (and only numbers) and UUID has 32 characters.


Zoned Out #4 (comic strip)

Zoned Out strip #4!

Beyond Security family wishes you all a happy thanksgiving.
Zoned Out #4
Click on the image for full size.

(Check out our new site: ! :) )


Zoned Out #3 (comic strip)

Zoned Out strip #3!

News link:
Zoned Out #3
Click on the image for full size.


Mozilla still working on JAR: protocol flaw

It was 11 day ago when JAR: protocol vulnerability in Firefox was reported by pdp.

According to Bugzilla entry #369814 upcoming Firefox (tests done with Gecko/2007111504) are immune to this vulnerability.

A Mozilla Security Blog entry posted by Mozilla security chief Window Snyder has been released too.

However, as a workaround NoScript version and later may prevent this vulnerability from being exploited, as US-CERT VU#715737 states.

The fact is that the Bugzilla report mentioned was filed as security sensitive on 8th Feb already. The disclosure of Petkov made it public.


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 :)


JAR: protocol vuln – targeting to Google now

According to the report of pdp several Web sites supporting open redircts are vulnerable to recent JAR: protocol vulnerability.

More information about these XSS vulnerabilities (hey, these are serious now!) is available at GNUCITIZEN entry here:

Severe XSS in Google and Others due to JAR protocol issues

Update 26th Nov: The author of Beford Blog has shared information that his “jarjarbinks.htm” PoC type link still works – when entering it manually to browser’s address bar. Google is still affected to JAR flaw.


Another case of the infected HD

A second event of malware infected HD has been discovered, this the second time it has happened in 4 months. The HD are part of “about 1,800 brand new 300-GB or 500-GB external hard drives made for Maxtor in Thailand” that include an autorun.inf file that will execute as soon as the disk is placed into the computer.

More details on the background can be found here and a bit more details on the origin can be read here.

In the old days this wouldn’t have happened as disks were “factory formatted” – requiring you to do a low-level format to start working with them, or at least partition them before use and they weren’t pre-formatted or even contained data on them.
P.S of course Windows is the only operating system that will get infected – Linux or MacOS won’t care about the presence of the autorun.inf file (or the ghost.pif file that is launched by it).


JAR: protocol vulnerability in Firefox, word processor applications reported

An unpatched vulnerability in handling of JAR: protocol handler URL’s has been reported recently.

Information is available at GNUCITIZEN Blog. Link: Web Mayhem: Firefox’s JAR Protocol Issues.

Information was publicly disclosed by Petko D Petkov (aka pdp).

The issue was originally reported in Bugzilla document #369814 by Jesse Ruderman of Mozilla community. I.e. Mozilla security group is aware of the vulnerability.

The vulnerability is due to same origin and XSS issues when opening .JAR packages. The following file formats are known attack vectors: .zip, .doc, and .odt.

The blog entry states Mozilla Firefox and unspecified widely known Google and Microsoft products as affected. Writer, StarOffice Writer, NeoOffice Writer and AbiWord support opening these file types. Microsoft Office 2007 support is provided by an add-in.

Update: This has been assigned to CVE-2007-5947.


Zoned Out #2 (comic strip)

Zoned Out strip #2!

We hope you all had a happy and protected Halloween.
Zoned Out #2
Click on the image for full size.


These days of several XSS vulns on known sites

The role and seriousness of cross-site scripting (XSS) vulnerabilities has been a subject of recent FD discussion.

The fact is that since Saturday 3rd Nov there are the following widely known targets: (two issues)
Additionally, several Yahoo domains have unpatched XSS issues. has its own XSS vulnerabilities as well.

According to the archives most of these are still unpatched. Some examples:

Symantec: XSS in search function at Enterprise section

Apple Developer Connection: XSS in search function
FBI: XSS in redirect-type URL (try manually)

Bank of America: XSS on Sign In page (https) has fixed both of its issues.


That Mac Trojan…

Unless you’ve been potholing for the past week or so, you’ll have heard of the Mac Trojan originally reported by Intego, makers of VirusBarrier, at, and later taken up by a number of other sources and resources. Most vendors are referring to as OSX.RSPlug.A or OSX/Puper, and some have referred to its links to the W32/Puper or W32/Zlob families of Windows malware.

Here are some sound links you might find useful. (includes a snort signature).

The significance of this particular threat is not that it’s malware that affects Mac users: there’s lots of that, though most of it predates OS X and won’t work properly in an OS X environment. (NB: there are also macro viruses that might spread through Mac systems even though they don’t have a payload that works in that environment.) Nor is it the first OS X-specific threat: attempted OS X rootkits, Trojans, even the occasional “real” virus, are not common, but have been seen. It’s not a script kiddie “hey, look at me, I wrote a Mac Trojan” effort. It’s not a sophisticated “Proof of Concept” threat that gives the author bragging rights, but isn’t likely to be seen in the real world. Nor is it spreading, AutoStart worm-like, through the entire Mac world. But it is different. It indicates that criminal elements are thinking about the possibilities of infecting or exploiting Macs as well as Windows machines. It’s a basic but viable program from a “professional” source. It uses a similar programmatic and social engineering approach to malware used to exploit Windows machines for frankly criminal purposes. If the bad guys take home the feeling that it has ROI potential, it’s unlikely to be the only example we’ll ever see.

There are positives, here, though. In general, most of the Mac community has reported this soberly and responsibly, rather than going for the kneejerk “Macs don’t have a malware problem” reaction, and that bodes well. If the more security-knowledgeable Mac people are taking the issue seriously, less sophisticated users are less likely to be misled. However, there are still people insisting that this isn’t a major problem, because it’s “only a Trojan, not a virus” and it requires the victim to give it permission to install (and because the anti-malware companies are stressing the low risk factor with this particular malware, rather than its potential as an indicator of future trends. However, those who are over-anxious to dismiss it as unimportant are missing some points.
(1) In the world of Windows, where most malware lives at present, volumes of malware that doesn’t (self-)replicate have exceeded volumes of replicative malware (worms and viruses, primarily) for a while.
(2) Not so long ago, viruses and worms that spread far and fast were the measure of success in malware distribution. Nowadays, with the professionalization of malware writing, the success of malware is better measured by its ability to steal data from any given system than it is by the number of systems infected by a single variant or subvariant.
(3) There’s a persistent myth in the Mac community that Windows malware is primarily “self-launching”: that is, it doesn’t need the victim to execute or install it, because it uses software vulnerabilities, drive-by downloads, buffer overflows and such to force itself onto a system without any action or attention from the computer user. Malware that does do this sort of thing exists, and has for many years (going back to some of the early network worms of the 1980s). But most malware -does- require user interaction.

Roger Grimes (a very sound researcher and writer) recently estimated ( that “86 percent of all announced vulnerabilities were client-side attacks requiring end-user interaction”. He doesn’t claim that his figure is definitive, and he didn’t cover all platforms or all vulnerabilities, but I suspect he’s in the right ballpark.

If we’re right, it suggests that malware which works by “social engineering” — tricking the victim into running malicious software, in this case — is more “successful” than malware that relies on exploiting software vulnerabilities. There are still those who claim that Mac users are smarter than Windows users, and won’t be fooled by social engineering. I’ve seen no evidence of that: in fact, I’d guess that, at the moment, Mac users with no particular security knowledge are particularly vulnerable in that they believe that their systems are so secure out of the box that they don’t need to know or to do anything about security.

Whatever happens next, and whether or not this is the tipping point where Mac users start, to suffer like Windows users, I’m convinced that this is not the time for partisan bickering from either side of the Mac/Windows divide. This is a time to watch and learn, and seek out fact rather than prejudice.


Cryptome: NSA has access to Windows Mobile smartphones

First time in history has released information about the characteristics of NSA’s network surveillance.

According to the newest IP address listing

IP ranges published by Cryptome are used by NSA, by NSA’s private sector contractors, and by NSA-friendly non-US national government agencies to access both stand-alone systems and networks running Microsoft products.

The post continues:

This includes wireless wiretapping of “smart phones” running Microsoft Mobile. Microsoft remote administrative privileges allow “backdooring” into Microsoft operating systems via IP/TCP ports 1024 through 1030.

The site has published NSA-affiliated IP addresses since July ’07. It’s not known if this mysterious source ‘A’ has connections to National Security Agency.


The NULL Terminated Strip #5 (comic strip)

Null Term. strip #5
Null Term. #5
Click on the image for full size.