Tag Archives: Sniffer

Junkie the Network Sniffer

Internet JunkieI always try to keep my blog independent of all commercial products. I don’t like “v€ndor$” trying to sell you the “most-powerful-solution-ever-seen-on-earth”. For me, information security must be based on a deep analyze of the problems, then chose the best solution to match the requirements (features, budgets, ease-of-use, etc). This time, I’ll make a small exception and mention a company but only for the following reason: some of their source code is released for free.

SecurActive is a French company which develops network and application monitoring solutions. In a few words, their solutions are powerful network sniffers which analyze the collected data to provide deep flows analysis regarding security and performance. As usual, there are lot of open source solutions installed under the cover. They like free software and decided to release a core component developed by them selve: “Junkie“.

What’s Junkie? This tool could be seen as the merge of Wireshark (t-shark) and tcpdump. Junkie captures the traffic from a designed interface but decodes the detected protocols on the flight. To have a better understanding, check out the following HTTP request:

Capture@0x96ca6bc: head_len=24, payload=74, dev_id=0, tv=1304362144s 810422us
Ethernet@0x96ca71c: head_len=14, payload=60, vlan_id=0, source=00:0c:29:f5:ed:fd, dest=00:23:08:3f:55:a2, proto=2048
IPv4@0x96d3a14: head_len=20, payload=40, version=4, addr=192.168.254.62->192.168.254.1 (hashed the other way), proto=17, ttl=64
UDP@0x96c74d4: head_len=8, payload=32, ports=50364->53
DNS@0x96c766c: head_len=32, payload=0, QUERY, tx_id=19437, err_code=0, request_type=AAAA, dns_class=IN, name=www.google.com
Capture@0x96ca6bc: head_len=24, payload=144, dev_id=0, tv=1304362144s 842322us
Ethernet@0x96ca71c: head_len=14, payload=130, vlan_id=0, source=00:23:08:3f:55:a2, dest=00:0c:29:f5:ed:fd, proto=2048
IPv4@0x96d3a14: head_len=20, payload=110, version=4, addr=192.168.254.1->192.168.254.62, proto=17, ttl=64
UDP@0x96c74d4: head_len=8, payload=102, ports=53->50364
DNS@0x96c766c: head_len=102, payload=0, ANSWER, tx_id=19437, err_code=0, request_type=AAAA, dns_class=IN, name=www.google.com
Capture@0x96ca6bc: head_len=24, payload=74, dev_id=0, tv=1304362144s 842868us
Ethernet@0x96ca71c: head_len=14, payload=60, vlan_id=0, source=00:0c:29:f5:ed:fd, dest=00:23:08:3f:55:a2, proto=2048
IPv4@0x96d3a14: head_len=20, payload=40, version=4, addr=192.168.254.62->192.168.254.1 (hashed the other way), proto=17, ttl=64
UDP@0x96c74d4: head_len=8, payload=32, ports=49208->53
DNS@0x96c766c: head_len=32, payload=0, QUERY, tx_id=42977, err_code=0, request_type=A, dns_class=IN, name=www.google.com
Capture@0x96ca6bc: head_len=24, payload=142, dev_id=0, tv=1304362144s 873071us
Ethernet@0x96ca71c: head_len=14, payload=128, vlan_id=0, source=00:23:08:3f:55:a2, dest=00:0c:29:f5:ed:fd, proto=2048
IPv4@0x96d3a14: head_len=20, payload=108, version=4, addr=192.168.254.1->192.168.254.62, proto=17, ttl=64
UDP@0x96c74d4: head_len=8, payload=100, ports=53->49208
DNS@0x96c766c: head_len=100, payload=0, ANSWER, tx_id=42977, err_code=0, request_type=A, dns_class=IN, name=www.google.com
Capture@0x96ca6bc: head_len=24, payload=178, dev_id=0, tv=1304362144s 915593us
Ethernet@0x96ca71c: head_len=14, payload=164, vlan_id=0, source=00:0c:29:f5:ed:fd, dest=00:23:08:3f:55:a2, proto=2048
IPv4@0x96d3a14: head_len=20, payload=144, version=4, addr=192.168.254.62->74.125.79.147 (hashed the other way), proto=6, ttl=64
TCP@0x96c7704: head_len=32, payload=112, ports=39549->80, flags=Ack, win=183, ack=1273586323, seq=1427884801
HTTP@0x96c789c: head_len=112, payload=0, method=GET, code=unset, content_length=unset, mime_type=unset, host=www.google.com, url=/

As you can see, each packet is decoded based on the OSI-layer model. At the highest layer, useful information is decoded like the request types, URL, FQDN, etc. At the moment, common protocols (including over IPv6) are handled: CIFS, DNS, FTP, HTTP, BitTorrent, Netbios, RTP, SIP, SSL. As the source code is provided, why not write your own parser? Another cool feature is the plugin architecture. Plugins can be developed to perform more action on the captured traffic. In the default source tree, a simple “dumper” plugin is provided (it displays the captured traffic as seen above). Junkie is an interesting tools which could be greatly enhanced by third-party developers.

The source code is available on github.com/securactive/junkie.

 

 

Wall Of Shame: Pros & Cons

Shame on meA “Wall of Shame” or “Wall of Sheep” is a real-time demonstration application which searches for non secured (read: sent in clear text) login/passwords sent through a network. One of the well-know wall of sheep is the one operated every year during the Defcon conference in Las Vegas.

A few days ago, the second edition of BruCON was organized in Brussels, Belgium. Since the beginning, I was tempted to run a wall of shame but there was too much important tasks to complete during the first edition (it was just a “nice to have” project). This year, I came back with my idea and I did it. But this was a long debate! Some people were excited by the idea while others were more skeptical. Finally, it was decided to display the wall of shame during a few minutes like a sort of proof-of-concept. That’s why I’d like to give my vision about running a wall of shame.

Everybody who’s attending a security conference or bar using an open WiFi network must be aware of the risks encountered to use unencrypted protocols. Common “old” protocols are unencrypted like POP3, IMAP, HTTP, FTP, VNC and much more. Best practices are to use the “S” versions like POP3S, IMAPS or to completely encrypt your traffic into a VPN. From my point of view, a wall of sheep must be seen as an educational or security awareness tool. The goal is certainly not to compile a huge list of credentials and abuse of them later.

The pro of a wall of shame is the “electroshock” received by people who see their obfuscated login information published on a big screen. You prove to them by “A + B” that indeed their information is not protected. Unfortunately, the human behavior acts like this: you can repeat millions of time the same story, we’ll forget it soon. Our brain has two types of memory: short-term and long-term. By default, what we learn/see/listen is stored in the short-term memory. Sometimes, with the help of special actions or events, the information can be moved to the long-term memory. A wall of shame is a great security awareness tool. Keep in mind that awareness also means recurrent reminders. A lot of people had background processes or agents running without realizing it and got hit by using WiFi…. It’s not just about unaware users as even security experts made the screen (no name here ;-) ).

Besides the fact that a wall of shame is funny and well accepted by the audience, they are disadvantages and you have to keep them in mind. Some people won’t be happy to see their name mentioned on the wall. Be prepared to receive complaints from angry people. In some countries, there might also be legal issues (or gray areas). Do NOT try to decrypt encrypted traffic! Never! Finally, your wall of shame may revive the debate about hackers vs. crackers.

So, how to deploy a “safe” wall of sheep? Here follow some important protections to be implemented:
  • First, think about the communication! Your visitors must be warned about the risks of potential collection and disclosure of personal data. This can be performed via printed documents (written black on white) and verbal announces at regular interval.
  • The wall of shame must be available only from restricted terminals and certainly not published on the Internet. Do not let visitors to access it, just display it on a beamer or a big screen.
  • The wall of shame must be running entirely in the server memory (via a tmpfs). No information is stored on disks. Just unplug the power cable and everything must be gone!
  • Of course, the server must be installed in a safe location with restricted access (physical and logical)
  • The server must collect data from a restricted network (example: the free / unencrypted WiFi network provided to the visitors)
How to display the collected information:
  • Do not display the complete IP address. The last byte of the destination address must be hidden (ex: 123.123.123.*);
  • Only the first letter of the password is displayed;
  • The remaining password is replaced by a random number of stars (to prevent people to guess the password length);
  • The last 15 discovered login/password is displayed (to limit the history in time).

Of course, everything must be properly deleted wiped after the event. If you’re interested and would like to run your own wall of shame, have a look here.

Wall of Sheep

Click to enlarge