Logs… Privacy Issues?

Warning-LogsLogs… We will never get rid of them! It’s a pain to manage them from a technical point of view but collecting events and using them can also introduce more issues in companies… from a legal point of view! Tonight, an ISACA Belgium Chapter meeting was organised within the context of the Open Privacy Forum. If log management remains a hot topic, the legal issues could become a real nightmare compared to the technical ones. The speaker was a lawyer, Johan Vandendriessche. He gave a very good overview of the (Belgian) law regarding our privacy with logs.

[Note: I'm not a lawyer and laws are complex. I'll just give some facts grabbed during the meeting. Please use them "as is"]

First of all, the problematic of privacy must be addressed way before the deployment of a technical solution. Why? The way logs will be stored and processed may require some specific technical features. The first question to ask yourself is “Which log do I need?“. We can use logs for statistics or security purposes. Take as example an Apache event:

x.x.x.x:52772 - - [20/Feb/2014:23:00:05 +0100] "GET / HTTP/1.1" 200 18905 "-"
"NewsBlur Page Fetcher - 3 subscribers - http://www.newszeit.com/site/59364/devrandom
(Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/534.48.3 (KHTML, like Gecko)
Version/5.1 Safari/534.48.3)"

The Referer, User-Agent and HTTP code and object size are very useful for statistic purposes. And, from a security perspective, we have the source IP address, the source port. Depending on the future usage that we will make of this event, we can drop some information or anonimize it. We are facing here a dilemna: If the law says that we are authorized to log only useful events, more and more companies tend to store a huge amount of events for forensics reasons or behavioral monitoring. The golden rule is always the same: If you keep logs, it must be for a (good) technical reason like ensuring that the network has good performances. They cannot be used to track people.

Then comes the second question: “Does this log contain PII?” (“Personal Identifiable Information“). PII is a very large topic! Even if the identification of a person is not immediate, some information are considered as private. A good example is a car plate. IP addresses were also considered as PII in recent cases! Here a some facts to keep in mind about logs:

  • The scope of logging must be cleary defined. What is the nature of the data? A “data controller” (the person responsible of the data stored) must be able to justify the choices.
  • Logs cannot be used to track employees but people must be aware that their tracks are covered (how and where)
  • Access to the logs must be restricted to authorized people only. Access to logs must generate… a new log!
  • Some logs are mandatory for legal or business reasons
  • Proper controls must be implemented to protect your logs. In this case, the principle of “due care” applies. Companies must implement appropriate controls to protect their logs.
  • Can we re-use old logs (archived) for processing? Yes if the purpose of the search is compatible to the original one.

Many questions were asked during the presentation, which proves that it’s a hot topic. But it also demonstrated that lot of grey zones remain. A last tip: Before processing logs with private data, ask for some help from the legal department of your company!

February 2014 OWASP Belgium Chapter Meeting Wrap-Up

JimTonight was organized the first OWASP Belgium Chapter of the year. Two speakers were invited, George Danezis and Jim Manico. Same place, same faces and classic introduction by Seba with news about the OWASP foundation and the local chapter. Did you know that the chapter had ten years old last year! Congratulations! Here is my quick wrap-up…

Read More →

Tracking Processes/Malwares Using OSSEC

TerminatorFor a while, malwares are in front of the security stage and the situation is unlikely to change in the coming months. When I give presentations about malwares, I always like to report two interesting statistics in my slides. They come from the 2012 Verizon DBIR: In 66% of investigated incidents, detection was a matter of months or even more and 69% of data breaches are discoverd by third parties. The problem of malwares can be addressed at two levels: infection & detection. To protect against infection, more and more solutions are provided by security vendors and some are quite performant but they don’t fully protect you. To contain the malware, the detection process is also critical. If you can’t prevent some malwares to be installed, at least let’s try to detect them as soon as possible. To track malicious activity, there is no magic: you have to search for what’s abnormal, to look for stuff occurring below the radar. Malwares try to remain stealthy but they have to perform some actions like altering the operating system and contacting their C&C. To detect such activity, OSSEC is a wonderful tool. I already blogged about a way to detect malicious DNS traffic with OSSEC and the help of online domains blacklists like malwaredomains.com.

Read More →

Pwning and Pivoting!

PivotingWhen talking about security to small companies – the “SME market” as the business says – their reaction is often: “Me? Why should I care? I’m so small and my business is not relevant for cyber-criminals…“. This is a big fail! As a proof, I like to ask them for a top-10 or top-20 of their customers. There are chances that a big name will pop-up. Let’s take a practical example: A contractor is in charge of some systems maintenance on your network Usually a VPN has been established with this company and you restrict access to your servers to this VPN only. But do you really know who’s sitting behing the keyboard at the other side of the encrypted tunnel? For years, I’m in contact with customers using such services and most of them do not care of this problem. A VPN must be considered as a door into your network and properly controled in this way! (VPN are configured with an “Any to Any : Allow” rule at the central firewall)

But not only IT contractors are a risk. Let’s take a second example: A small local florist has won a contract with a big well-known organization. Once a week, he must deliver fresh flowers in the headquarters building. As a contractor, the florist is trusted and have a physical access to the building or access to an extranet. Once onsite, a malicious guy could connect a Pwn Plug in a corner of a meeting room (it tooks only a few seconds).

Every company manages valuable data and not only money, CC#, SSN#, patents or magic formulas. Sometimes it could be your customer base! And if you don’t implement security controls, you could be used as a “pivot“. Pivoting is a technique of using an instance (the “pivot“) to be able to move around inside an infrastructure. First step, you compromise a first system and, second step, you attack others instances which are normally inaccessible. Example: a corporate laptop is compromized while visiting a rogue website. Once the attacker gains a full control, it could perform all kind of tasks like port-scanning (reconnaissance), new attacks against critical server (the Active Directory is a new target) etc. If the definition of pivot focuses primarily to computers, it can also be applied to companies. How easy is it?

As usual, people disclose information online and Google indexes them. Let’s come back to the florist example: We choose a potential nice target: Cap Gemini, a big player in consultancy services and use this simple Google query:

intext:"cap gemini" fleuriste

We find a link to a florist in France which mentions Cap Gemini as a reference. Companies like to display their greatest customers and achievements. Can we blame them for being proud of their references?


The florist has contacts inside the organization and maybe an access badge to enter the Cap Gemini building, who knows? Do we show this only in Holliwood movies? Of course not. Do you remember, a few weeks ago, the US retailer Target was breached and millions of credit cards were stolen via PoS compomized by a malware. But such PoS are not facing the Internet, they should be connected to an internal network, how do they succeeded? After more researches, investigators found that Target was breached via a contractor responsible of the HVAC systems! They accessed the network using the contractor’s credentials! (Source here).

Conclusion: Do you know who are your contractors? How do they address their own security? Think about this story… “Don’t become a pivot!“, everybody has valuable data and could be the target of someone else!

KISS… Your Logs Too!

KissIf there is a gold principle in IT, that’s the one called “KISS“: “Keep It Simple and Stupid“. It says that systems will work best if they are kept simple rather than complex. Simplicity must be a key goal during the design phase. This sounds logical: Keep in mind that information systems must be maintained, patched, debugged, monitoring. When a problem will occur and that your boss will put some pressure on you to solve it asap, it will be much easier if the architecture is simple (and documented!). But I admit that it’s not always easy to stick to this principle. Here is a good example with logs…

Today, one of my projects was to integrate DNS logs with Splunk. On paper, it was easy:

  • Splunk running ✔
  • Bind running with queries logged ✔
  • Splunk for Bind app installed ✔

Let’s see the bashboard and… nothing! The classic message displayed by Splunk: “Waiting for data“. Hmmm… Let’s take a deep breath and jump into the app code and configuration files. After a few checks, a first problem was identified: the app was designed to process Bind logs in a Syslog format but my Bind queries were logged to a “queries.log” flat file… And the formats are not the same (oh joy!):

Feb 5 21:42:22 shiva named[27229]: client \
  query: safebrowsing.google.com IN A + (

05-Feb-2014 21:42:22.868 queries: info: client \
  query: safebrowsing.google.com IN A + (

The file “queries.log” being read by an OSSEC server for HIDS purposes, it was not possible to replace the file by a unique Syslog feed. I reconfigured Bind to generate two differents entries for each queries: one sent to the flat file and one sent via Syslog.

logging {
  channel local_syslog {
    syslog local0;
    severity info;
  channel queries_log {
    file "/var/log/named/queries.log" versions 10 size 10m;
    severity info;
    print-category yes;
    print-severity yes;
    print-time yes;
  channel stat_file {
    file "/var/log/named/stats.log" versions 3 size 1k;
  category queries { queries_log; local_syslog; };

Bind & Rsyslog reconfigured, I had two destinations for my queries (and two times the size stored on disk!). But it was not yet working. Jumping again to the configuration files (more precisely the “transform.conf“), I found a second problem related to the regex used to parse queries. As seen in the Syslog event above, a date, a time and the view details were not available but expected in the regex:

FORMAT=process::$1 named_query_date::$2 named_query_time::$3 src_ip::$4 named_view::$5 named_message_type::$6 named_lookup::$7 named_query_type::$8 named_query_code::$9

I fixed the regex to match my Syslog and it worked but I still had the same events sent twice! Getting rid of the flat file was not possible (used by OSSEC) so I rewrite again my transform.conf file and adapted the Bind app to parse the same file as OSSEC.

Conclusions: Managing logs is not an easy tasks and may require time, even more if your infrastructure changes often. There are multiple ways to collect events. The most common ways are flat files or Syslog (UNIX) or EventViewer (Windows) and, sometimes, databases. Keep your logging configuration clean and simple. The goal is:

  • Avoid redundant storage
  • Avoid lost events (worse case!)
  • Have a clear view of the events flows to debug any issue (for sure, you will have some!)

Also be sure to cover all event types by testing your tools with exhaustive sets of data. Document how events are processed (from the source to the log management solution). My Splunk environment has 17 data sources configured from multiple types (files, UDP, TCP & scripts), not easy to remember how those data are processed!

OS X: How to Avoid the VPN “Grey Zone”?

The Grey ZoneToday, the second edition of “Security Friday” was held in Brussels. As mentioned on the website, the goal is “a gathering of people in the IT security field. Getting together for a drink on the last Friday of the month in a bar near you we talk amongst peers about IT security, non-tech hobbies, favorite beers, and much more“. I like such initiatives because sharing is the key of information security. Maintaining your social network is mandatory! And yes, IT people are social, not always hidden in dark rooms just illuminated by screens! ;-) So, I went to the chosen pub to have some interesting chats and drinks with some Belgian infosec folks (know faces of course). If you’re interested, keep in mind: the last Friday every month!

Amongst the multiple topics that were discussed, one of them was the risk associated with VPNs. This is what I call the “VPN Grey Zone“. Let me explain the problem: My beloved Macbook follows me almost everywhere and, when connected to untrusted network – read: almost everywhere – I’m using a VPN to phone home. But when you wake up your Macbook, you already have plenty of applications running and they are just waiting for some network connectivity. Once you open the Macbook, traffic is generated before your VPN session is established. And during this short period of time, very sensitive information could be sent to the untrusted network. This is what I call the “VPN grey zone“. You don’t know exactly what’s sent in the wild!

To prevent this problem, I’m using intensively a nice feature provided by Little Snitch. If you have an Apple computer, this is a must have tool! Little Snitch is a firewall dedicated to outgoing traffic. Every time an application tries to open a network connection, a pop-up is displayed asking you to allow or deny this connection:

Little Snitch Warning

Since the version 3.1, Little Snitch introduced a very nice feature called “Automatic Profile Switching“. Its goal is to automatically assign network to certain profiles. Networks are, by example, unknown Wi-Fi networks, your home or corporate LANs, etc. But wait, OS X has also a notion of “network profiles”. You can assign a specific configuration (DHCP, fixed IP, DNS, …) to networks. Nice but the Little Snitch profiles allow you to specifiy which traffic will be autorized or not. Example: at home, you will allow your Dropbox client to connect but, when connected to your corporate network, it will be silently blocked to not alert the firewall guys!

In the Little Snitch terminology, what is a network and a profile? A profile is a set of rules which define which process may (or not) connect to an IP and/or this port. A network is identified by:

  • The type (Ethernet, Wireless)
  • The router IP address
  • The router MAC address
  • Geolocalisation (optional)

To come back to our “VPN grey zone“, let’s fix the issue by creating two profiles:

  • Trusted
  • Untrusted

The profile “Untrusted” will contain no rules and will be assigned by default when joining unknown networks as seen in the screenshot below:

Profile Switching

The profile “Trusted” will contain your rules to allow applications to use network resources and will be assigned to your VPN connection. No more traffic sent in the wild a few second before the VPN session is established (or re-established if dropped). Later, create new profiles for locations that you visit on a regularly basis!

Little Snitch is not a free software but it’s worth the price, definitively! If you’re using similar tools & configurations with other operating systems, please share!

DNS Hijacking With Just One Mail

HijackedThis is not new but it still happens in 2014… Hijacking a website with just a small e-mail. Here are the facts. For a while, I’m hosting a friend’s website. His website is quite old and it already moved from servers to servers depending on my deployed infrastructure. A few weeks ago, I notified my friend that a new change should occur asap: The website will be moved (again) to another IP address. Since the last server change, the domain name also moved and is now hosted by an ISP. My friend trusted me and suggested to contact directly the ISP. In this case, the ISP was the registrar and hosting the zone on its DNS servers at the same time! I followed the procedure and contacted the registrar as mentionned on dns.be:

DNS Technical Contacts

I took a deep breath and sent an e-mail to <dnsmaster@belgacom.be> explaining the situation:

From: <me>
To: <dnsmaster@belgacom.be>
Cc: <my-friend>
Subject: Change request xxx.be

Dear DnsMaster,
A friend of mine is hosting his website on my server (xxx.be). I would like to move the
website to a new server. This change implies a new IP address for this host:

 IN A x.x.x.x
 IN AAAA x:x:x:x:x:x

Could you please implement those changes? If extra controls are required, you can reach
me on +32 xxx xx xx xx.

Best Regards,

I was ready to fight and prove them that my request was legitimate but it happened otherwise. I received a nice auto-reply with some classic commercial content (read: “You are very important to us!“) and a ticket number. Step one completed! I expected to have, at least, another e-mail asking me for more details or a phone call (I gave my mobile number especially for this purpose) but… nothing! This is the timeline of events:

  • 10:50 : Original mail sent (see above)
  • 10:55 : Auto-reply with my ticket number
  • 11:35 : Changes done, ticket closed
  • 11:45 : Testing from a public DNS server (to avoid caching issues) – new IP alive!

In less than one hour, the domain name zone was updated! Scrary! In this case, it was good news for me because I was able to complete the website migration much quicker than expected. But from a security point of view, we are facing some issues:

  • I’m not listed as contact or owner in the domain name administrative information
  • I’m never in contact with the <dnsmaster>, they don’t know me
  • The email sent was a piece of cake to write by a (novice) social-engineering guy
  • No contact was taken with me to confirm the change (and even, as an attacker, I would reply: “Sure, do it!“)

Why spend time to pwn servers, play MitM attacks or poison DNS caches if only one e-mail is good enough to hijack a website?

Building IP Reputation Lists from Snort Rules

ReputationWe are already in 2014 for a few days and this is my first blog post for this year! So, let me wish you a wonderful 2014 for you and you family! Let’s start with a quick post about building IP addresses reputation list. This topic was discussed on a mailing list today: Where to find good sources for IP reputation services?

Indeed, IP addresses remain a very common IoC (“Indicator of Compromize“). They can help to identify C&C servers, spammers, compromized websites, etc. Most vendors propose such service with their product. They are of course paid services.

To build a simple IP reputation list, a quick win is to use a set of Snort rules like the one provided by emergingthreats.net. If they provide an IP reputation system called IQrisk, they also provide a feed of Snort rules that can be deployed in your ID(P)S instances. The content is excellent and the feed is proposed in two versions: one paying and one free. The second one is only a subset of the full version but it already contains a lot of interesting stuff. It contains a lot of interesting rules to build our reputation system. Example:

alert ip [,,,,,, \,,,] any -> $HOME_NET any (msg:"ET \
CINS Active Threat Intelligence Poor Reputation IP group 1"; reference:url, \
www.cinsscore.com; reference:url,www.networkcloaking.com/cins; threshold: type limit,\
track by_src, seconds 3600, count 1; classtype:misc-attack; sid:2403300; rev:664;)

Once you subscribed to the open feed, it’s easy to extract the IP addresses from the *.rules files to build your reputation list and use it with other products like a SIEM. This can be easily performed with a few lines of Python:

# cd /data/suricata/etc/suricate/rules
# /usr/local/bin/build_reputation_list.py >/tmp/ip.tmp
# head -5 /tmp/ip.tmp

Once done, import the file into your favourite tool. The script is available in my toolbox on GitHub.

Review: Mobile Security: How to Secure, Privatize and Recover Your Devices

Book CoverI received a copy of a new book published by Packt publishing about mobile security. As mobile devices are more and more targeted by attackers, it was a good idea to publish a book on this hot topic. Written by a group of people working for IBM, the book covers a broad range of topics that can be grouped in two main sections:

  • A review of problems and threats affecting mobile devices
  • Tips and procedure to protect your mobile devices

Across the book, the two main mobile OS are covered (iOS and Android).
Read More →

OWASP Belgium Chapter Meeting Wrap-Up: Using Browsers Otherwise!

OWASP MeetingWe are already very close to the EOY and we are all expecting the Christmas break in a few days. Tonight, the last OWASP Belgium chapter meeting for 2013 was organised with the help of another local chapter which was created in 2013: the ISC2 one. Thanks to the F5 Belgium team who sponsored the pizzas! Two very interesting presentations tonight about browser or more precisely, how to use them otherwise. Of course, the classic intro by Seba with the local chapter and global OWASP news.

Read More →