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.