Once again, here is my quick review about the BruCON network that we deployed for our beloved attendees! Yes, we are glad to take care of your packets during the conference. Nothing changed since the last edition, we deployed the same network in the same venue with the same controls in place. But this year, the biggest change was our brand new wall of sheep…
Let’s start with some stats! Our Internet bandwidth was the same as last year: a 100Mbits wireless link. This is was enough as we had peaks up to 80 Mbits of traffic. Hélas, our partner which provides the Internet pipe is still not ready to deliver IPv6.
We provide two networks: a “public” for the visitors and a “private” one for the crew, the speakers which is not sniffed. The Wi-Fi network is the most used but more and more people decided to stick to 3G/4G connectivity to avoid connecting to the wild network. We detected 334 unique MAC addresses which requested an IP address during the conference. The split across the different client types is shown below.
About the applications used, HTTP remains in first position, not a surprise. If HTTP remains the top protocol, SSL & OpenVPN came in 2nd and 3rd position. This means that people also tend to use encrypted communications.
DNS is always a goldmine. Â Here is a top-20 of requests that we captured (based on DNS traffic, whatever DNS servers were used!). To clean up the mess, I removed the PTR requests.
Count | Query |
28847 | |
25334 | a.t |
19089 | google.com |
11895 | wpad |
9113 | t.co |
5738 | brucon |
5487 | brucon.org |
4917 | apple.com |
4102 | ey.net |
3956 | pentesteracademy |
3733 | appspot.l.google.com |
3697 | pentesteracademylab.appspot.com |
3434 | printer |
3314 | facebook.com |
3158 | amazon.com |
2773 | images.amazon.com |
2752 | ecx.images-amazon.com |
2730 | twitter.com |
2520 | ssl |
2422 | clients.l.google.com |
Personnally, next year, I’d like to create some honeypots to redirect the traffic to hosts like “wpad” (Web Proxy Autodiscovery Protocol) or “printer” ;-). We provided a DNS server via DHCP but many people have fixed DNS servers configured. Funny, lot of them where RFC1918 IP addresses not used on the BruCON network. Corporate servers?
Count | DNS Server |
131815 | 10.4.0.1 (BruCON official DNS) |
73294 | 224.0.0.251 |
32559 | ff02::fb |
14887 | 224.0.0.252 |
13939 | ff02::1:3 |
6544 | 8.8.8.8 (Google) |
2294 | 172.246.84.42 |
883 | 8.8.4.4 (Google) |
565 | 86.39.202.67 |
500 | 208.67.222.222 (OpenDNS) |
We detected network flows with ~25K unique hosts over the world. Mainly to the Europe and United States.
It’s also interesting to search for errors or “weird” traffic. Here is the top-20 of problems/suspicious traffic detected by Bro:
Count> | Suspicious Behavior |
7891 | dns_unmatched_msg |
3578 | dns_unmatched_reply |
1607 | data_before_established |
1456 | unmatched_HTTP_reply |
1342 | possible_split_routing |
1017 | unescaped_special_URI_char |
1015 | window_recision |
884 | line_terminated_with_single_CR |
811 | above_hole_data_without_any_acks |
734 | TCP_ack_underflow_or_misorder |
453 | unknown_packet_type |
350 | dns_unmatched_msg_quantity |
294 | DNS_Conn_count_too_large |
284 | TCP_seq_underflow_or_misorder |
270 | unknown_protocol_2 |
210 | zero_length_ICMPv6_ND_option |
178 | non_ip_packet_in_egre |
177 | bad_HTTP_request |
173 | connection_originator_SYN_ack |
169 | inflate_failed |
We also provider a Tor SOCKS proxy to the visitors but it was not eavily used… Maybe promote it more next year? But the brand new wall of sheep was a great success. It is a modified version of Dofler and offers the following features:
- Display pictures on-the-fly
- Capture credentials from clear-text protocols
- Scan for vulnerable hosts on the network (via PVS)
- Display a graph of protocols usage
Displaying pictures on the fly is dangerous when hackers will be the primary target. That’s why I implemented a skin-color detection filter to prevent most of the p0rn images to be displayed on the wall-of-sheep. Of course, it became quickly a new game for some attendees who tried to display all kind of (not only p0rn) pictures. Most of the time they succeeded but the filter was working quite well nevertheless. Check the two following impressive numbers:
- 80.838 pictures were captured over the three days
- 18.052 pictures were detected as “p0rn”
About the captured accounts, even if people are more aware and are trying to protect themselves, we collected 242 accounts:
- POP3
- IMAP
- HTTP
- FTP
- IRC
- NNTP
That’s all for my wrap-up!
Yep, available somewhere online, I’ll try to find back the URL…
That’s interresting, thank you for the report. Is the code for the skin detection is public somewhere ?
Images are extracted on the fly from TCP flows… There is not relation between the images & URLS.
On the todolist: when an image is extracted, capture also the source IP address and blacklist it if the image is detected as p0rn.
/x
You might want to harden that filter. By simply visiting a p0rn site (which wasn’t blocked because the word wasn’t in the url), I managed to get quite some of those on the wall. Followed by ofcourse come hentai from a Google img search and the “All your base are belong to us” classic 😉
BTW: It also became a game to get some of your own (fake) credentials in the list 😛