I’m just back from Montpellier where was organised the 2014’s edition of the RMLL (“Rencontres Modiales des Logiciels Libresâ€) or LSM in English (“Libre Software Meetingâ€). This is a huge event similar to the FOSDEM in Brussels where people who love free software exchange views, researches and make some networking. The event location changes every year and this edition was organised in the south of France… not a bad place! The event is huge and is organized across a whole week, attracting a few hundreds of people. Within the main event, other small events are organised and talks are divided in multiple topics like:
- Society
- Enterprises
- Culture
- Development
- Sysadmin
- Health
- Education
- Internet
- Do-It-Yourself
I started the Monday with an exception: My first choice was not in the security track but looked very interesting to me: Christophe Hamerling performed some drone hacking. The presentation title was “Hackin the (AR-)Drone†and focussed on the well-known Parrot device. In fact, the drone was a good opportunity for Christophe to learn how to use the Node.js platform. After a small introduction, he explained that the protocol used by the drone to communicate with the remote controller was reverse-engineered and a framework was created based on Node.js to take control of it. The rest of the presentation was based on demos how to take control of the drone and get interesting data from his sensors:
- To take off and land
- To take a picture or record a movie with the builtin camera
- To interact with Twitter (and send commands to a Twitter bot)
- payload
- ct
- meta
- log
- not
To continue with Netfilter, Arduro Borrero presented his project called “nft-syncâ€. The idea is to have a good tool to properly (and safely) distributed Netfilter configuration across multiple firewalls (ex: a cluster of x nodes) or to manage multiple policies for multiple firewalls. The tool has already a public API for remote management. Its main features are:
- A basic configuration file
- Two running modes: command line or daemon
- Different operations already implemented: Fetch, Pull, Sync
- Data are exchanged in JSON/XML
nft-sync is still a proof-of-concept supported by Google as a GSoC project. More information is available here.
Eric Leblond made two presentations. The first one was an overview of the integration of Netfilter with an IPS. To follow on the same subject, Eric demonstrated how easy it is to configure Netfilter to talk with an IDS like Suricata.
The old way (with Iptables) was to use NFQUEUE and configure “nfq†in Suricata (forget Snort which does not implement this feature). On the other side, Netfilter can do this easily by defining a new chain dedicated to filtering. It’s easy as creating two chains with different priorities. After a short coffee break, Eric came back with his second presentation about a very important topic when you create and manage firewall policies: logging! Iptables had already some feature to log via Syslog but it’s not very sexy and remains difficult to parse. The next generation of solution to log Iptables events was via ulog & ulogd. The daemon has many ways to output events. The most common being into a SQL database and to a PCAP file. With ulogd2, new features were introduced like an improved DB support. ulogd2 can also log volumes of data (interesting if you need to perform some accounting) and can log NAT transformations. Eric also demonstrated how to sent Netfilter events into Kibana to produce nice dashboards.
Next talk was presented by Victor Julien, the lead developer of the Suricata project. Again, Netfilter was addressed and Victor reviewed how to integrate Netfilter with Suricata. This IDS has so many features that it’s impossible to list them. The complete list in available here.
Balazs Scheidler presented an open source software called Zorp. It’s an proxy firewall which is able to filter up to the application layer. Keep in mind that today:  “HTTP is new TCPâ€. We have to deploy tools to inspect the HTTP traffic and not only on port 80! An interesting feature, New Zorp features can be added using Python. Balazs gave as example an module to inspect the Facebook chat sessions.
And, to close the first day, Victor Julien came back to present his Iptables based firewall manager called “Vuurmuurâ€. For the story, “Vuur†means “Fire†in Dutch and “Muur†means “Wallâ€. This project was started a long time ago when Victor decided to learn programming. The second goal was to provide to his colleagues who did not have a strong Iptables background, a nice tool (nurses based) to manage the firewalls by themselves. The tools is not upgraded often (the last release is from 2009) but Victor has still some ideas to add features. This closes the first day.
The second day started with Stéphane Bortzmeyer (from the AFNIC) who spoke about DNSSEC. He started with a small review of the DNS. It provides:
- Stability (ex: when servers move between ISP’s but remain accessible)
- Memorability (sexy domain names for marketing 😉
- Security : really? No very true but DNSSEC improves it!
- It’s a generic DB and does not only return IP addresses
- It’s a critical system on the Internet
DNS suffers of many threats. Two first cannot be mitigated by DNSSEC:
- Unauthorised change in a zone file (GIGO) – Very difficult to mitigate – use classic controls
- DDoS
But the following are addressed by DNSSEC:
- Traffic corruption
- Cache poisoning
- Unauthotized updates
- Spoofing master (zone transfer corruption)
First (but old) improvement, TSIG (“Transaction SIGnatureâ€) protects you against malicious zone transfers. It’s already commonly used. TSIG a shared secret, so it’s difficult to deploy massively. It cannot protect the “last mile†(distributing the shared secret to all clients is unmanageable). The DNSSEC basics are:
- Each zone has a key (with a public and private part)
- Resource records are signed
- Authoritative name servers serve the signed data
- Validating resolvers check the signature with the public part
Tip: DNSviz.net is useful to see the chain of trust. Example:Â http://dnsviz.net/d/dns.be/dnssec/. Of course, free software support DNSSEC:
- OpenDNSSEC is a tool to manage keys
- NSD, Knot, PowerDNS & BIND are name servers which serve signed zones. Note that powerDNS & Bind can do serving + automatic signatures
- ZoneCheck to check zones
Based on Stéphane’s experience with DNSSEC, the main problem is not the “technical†deployment of DNSSEC. It can be achieved in a few minutes – there are tutorials everywhere on the Internet – but the procedures that must be implemented around DNSSEC. Example: Don’t forget your signature expiration. It is mandatory to have a good planning:
- First of all, do you need it (do you have sensitive data to protect?)
- Take care of stupid firewalls which limits DNSSEC (512 bytes packets)
- Use NTP (time sync is a key)
- Monitor! (check NTP, signature expiration, key protection!)
The next talk was about the Haka language by Mehdi Talbi. Haka is an open source security oriented language. The context where Haka can be interesting: Today we need to develop network parsers to analyse new attacks and interact with network flows (log them, generate alerts or modify them on the fly).The idea behind Haka is also to allow people to write such filters without writing C code. Haka has the following security rules:
- Check packet fields and data content
- Match malicious patterns across multiple packets
Haka works with LUA scripts. Here is an example of rule which replace images by lolcats in an HTTP stream:
local image_ext = { '.png', '.jpg', '.gif' }
haka.rule{
hooks = { 'http-request' },
eval = function (self, http)
local request = http.request
local path = request:split_uri()['path'] or ''
for _,ext in pairs(image_ext) do
if string.match(path, ext .. '$') then
-- Ready to lolcat the web? :)
-- Redirect request to server hosting a lolcat image
request.uri = "http://myserver/lolcat.jpg"
break
end
end
end
}
Another nice demo was injecting Javascript in HTML code. Nice demo: injectponies.lua http://panzi.github.io/Browser-Ponies/. This is a very interesting tool to play with if you already have a server capturing your network traffic (or on a proxy).
After a short coffee break, Eric Leblond came back on stage with a third topic: How to use IDS/IPS to effectively perform attack detection. Interesting features, file extraction, TLS handshake analysis (to prevent bad stories like Diginotar). Lot of logging: HTTP request, TLS certificate log, DNS logging and Lua scripting allow to write rules in a easier way. Suricata rules can become very complex. Suricata 2.0 has new features:
- EVE logging (JSON output for events)
- Improved VLAN handling
- NSM runmode (detectionless)
- Improved CUDA performance
The new feature that was reviewed by Eric is how to improve logging and reporting. By combining the new EVE logging feature with ELK (Elasticsearch, Logstash and Kibana), it is possible to build very sexy dashboards (as Eric said: “Defensive security can also be sexy!â€). Eric demonstrated how easy it is to get interesting stats. His example was based OS detection. In the RFC’s, the start value of a TCP window is not specified. It means that each operating systems is free to use any value. By example, Windows 7 SP1 uses a TCP window of 8192 bytes. This information can be used to authenticate the different OS which are sending traffic to your network. Using Kibana, it’s easy to play the TCP windows and he detected some unusual accesses like Chines in his demo. This highlighted connection from China to the port 22 but always from the same port (6000). The scanner used was based on raw sockets and connections were not initiated by the OS itself. The next step was to write a honeypot in SSH to log all probes. Eric called this the “French hospitalityâ€. Excellent example to demonstrate how to get most of your IDS and logs!
Christian Perez and Solange Gentil reviewed their practical experience with Snort in a real environment at the CEA Cadarache. I found this presentation very interesting because it described a real implementation of a free solution with real (read: business) constraints. Usually, talks presented during security conferences are based on proof-of-concepts, studies. In this case, it was based on real facts.
The goal of the Snort deployment was multiple:
- Detection
- Analysis
- Incident management
Once the architecture in place, they faced some recurrent threats:
- Compromized hosts
- Security policy violations
- Inside threats
To improve the detection of suspicious traffic, Solange explained that Snort is feed with the following rule sets:
- EmergingThreats
- SourceFire VRT
- And homemade rules
- Encryption makes many rules obsolete
- They are many ways to bypass IDS
- Automation and transfer are still a great challenge (help desk & mitigation)
A very nice practical return of experience!
After a sunny lunch break outside, Ninon Eyrolles talked about the obfuscation of code or “know your enemy!â€. Usually obfuscation is used to “hide†some code. This aspect is at the opposite of the message broadcasted by the RMLL – the code must be free and open. But she demonstrated that understanding how obfuscation is used and how to detect it can be very helpful.
In fact, obfuscation is found at many levels: In malwares, in DRM implementation (protection of sensitive data) and is also doing cool stuff on encryption. To break something, you need to understand how it is made. Ninon gave more focus will be on two obfuscation techniques:
- Control flow obfuscation
- Data flow obfuscation
Ninon reviewed different techniques likes loop unrolling, inlining of functions, junk code insertion. And, for each technique, she explained the weaknesses and some detection techniques. This is not a key topic for me but the presentation was very clear and didactic!
The next slot was assigned to… myself. I made a presentation about malware analysis based on a free toolbox. It was not only the analyse of malicious code but also how to automate the scanning process and how to extract juicy information to correlate them with your other security solutions (IDS, firewalls, SIEM, etc). My slides are available here.
Lunar followed me with a presentation about Tor. But the presentation quickly switched to a Q&A session regarding Tor. The topic was very interesting and the room assigned to the security track crowded with many people sitting on the ground. A good proof that Tor remains a very hot topic. Some numbers about Tor:
- 6000 relays worldwide
- 3000-4000 people worldwide
- Don’t run a node personally (run it under an association)
- Don’t run a node at your home, run it in a datacenter / on a VPS
- Don’t use a browser other than TorBrowser. Regular browser have weaknesses which will disclosed sensitive information about you.
The last talk of the day was the one of Daniel Faucon who spoke about the instant messaging clients and their lack of privacy. Often, instant messaging users say “Why encrypt? Why privacy? I’ve nothing to hide!â€. This is of course a complete fail! As said Daniel, for most of us, our primary threat is not the NSA but our ex-boy|girlfiriend, our employer, parents or neighbours! Another example, in some countries, the disclosure of a sexual orientation can be vey dangerous. Why is chat an interesting target? Because it is a main communication media between people and that generates a lot of qualitative information about you. And “qualitative†information means at a certain point “quantitative†information…
Daniel reviewed the history of cryptography to come to the conclusion that current tools are excellent from a security point of view but they suxx for average users. Think about PGP: it’s not easy to understand how it works for non-IT people. Daniel explained the basics of OTR (“Off-the Record Messagingâ€) and how it can improve our privacy. OTR advantages are:
- It is fast and easy to use
- Encryption is thrown away forever (or asap)
- Light authentication of messages during the conversation
- Signatures mean nothing after the conversation is closed
- Instant messaging clients: Pidgin, Jitsi
- IRC clients: irsii-otr, weechat-otr , chatsecure (IOS or Android)
But the main restriction of OTR is that it protect 1-2-1 conversations only. Multiparty-OTR is one of the solution. Crypto.cat software currently use the Multiparty Protocol for group conversations. If solutions exist, they’re not intensively used. Why? Like PGP, it remains complex. Skype & Facebook are so easy and one click away from you. Daniel’s conclusions are:
- Usability must be considered as a important feature to help all users!
- Never use a closed-source chat client
Unfortunately, I was not able to attend the third day. I flew back to Belgium this morning. You can watch the live stream and on-demand videos (soon) on video.rmll.info. Except a small glitch with the room reservations, the event was well organized, kudos to the security track team: @cbrocas, @doegox and @moutane.
Hello Xavier,
Apparently, the slides are not yet on the RMLL site but, for the security track, they are here : http://moutane.net/RMLL2014/
Hello Stéphane,
Hmm… Sorry for this mistake (or misunderstanding). Are the slides online? It was on your conclusions slide. I’ll rectify asap.
Very good summary, very useful.
But I do not think I said “First of all, do you need it (do you have sensitive data to protect?)” Everyone desserves a secure name resolution, therefore DNSSEC.