Posted on

Avoid getting tracked in a datamining society

Welcome to the information age! Memory is cheap, millions of records are copied in the snap of a finger and everybody wants your information. This is called data-mining and everybody is doing it essentially to better advertise to you. These databases of your facts & habits are often sold and even hacked. It is time to ponder how little control you have over your own information. And when you do so, think not only about the information you give but above all about the information that can be inferred from it.

Compiled bellow is a list of tips for avoiding getting tracked in modern society. They range from simple good practice to paranoia. Obviously you could go live as a hermit in the woods and be untraceable. Feel free to comment on anything I missed and I’ll add to the post.

Day to day life

  • Broadcast the least information possible. Does your state require license plates in the front & rear? 19 states don’t, google them. Police cameras automatically scan all the license plates they see, why double your chances? Your license plates are also often recorded when you drive through tolls.
  • Pay everything in cash, credit/debit card transactions can easily place you in space and time. Moreover, encoded in the magnetic stripe is your name, stores know everything you buy and when you buy it. This is pant creaming data for the marketing geniuses trying to figure out ways to make you consume more.
  • Avoid customer rewards programs. An even better way to tie information back a a customer that might use multiple methods of payment. Still want the sweet deals? Don’t use your real info when signing up, or just don’t sign up, the cashiers often have default cards to scan.
  • Avoid mail-in rebates. They are nothing more than a way for you to sell your information.

I.T. life

This is a dense section, no surprise this is where most data mining occurs.

  • Don’t let email load remote content

This is commonly used as a way to know if you’ve opened the email, at what time you opened it, where you opened it from (IP geolocation) and what your email client was. The technical explanation is that some email have HTML formatting with images included. These images can be embedded in the email itself or referenced to a remote server. In the later case, the remote server will for example enable PHP parsing for JPEG files, execute code to track you and then feed the image to the email client which never had a clue it was loading a “special” image. This is all transparent to the user and the email client.

  • No smartphone GPS tracking

Let’s take an example: you enable Google Latitude on your cell phone to share your location with friends and get to know fun facts about how much you travel. The information you give Google are geographic coordinates, the informations inferred from it are where you live, where you work and whether or not you pull your 40 hours a week there.

  • Let’s go further: no smartphones at all!

Apple’s Iphones and Google’s Android phones gather location information WHETHER YOU WANT IT OR NOT. That’s right, you can turn off GPS all you want your phone still recurringly reports back to Apple & Google telling them not only where they are but also which other wireless devices they see around.

More info here from the most excellent Samy Kamkar.

The tech giants are involved in a major data gathering process where they use you to create a comprehensive map of the wireless spectrum. This is both an awesome project using crowdsourcing to accomplish a daunting task & a scary invasion of privacy. Because it doesn’t ask you, and because you take it home and so it reports your wireless router and so now everytime you use a regular computer connected to said router, they know exactly where you are. It is scary because even if you could turn it off, others around you are passively reporting your location.

  • Even further? no cell phones! your location can be triangulated from cell towers.
  • Forget social networks, even if you use fake information. Sooner or later, your contacts, something you said, someone that said something about, will be traced back to your real self.
  • Remove EXIF data from the pictures you distribute online, especially if they were taken with smartphones.
  • SSL encryption, SSL everywhere. In fact any time you configure a connection (IMAP, FTP, HTTP) make sure that it uses an encrypted mechanism. The number of network taps are growing and you don’t want to make the job easier on them.
  • Review pictures you distribute online for license plate numbers, bills laying on tables and other identifiers.
  • A strong firewall not just for incoming traffic. Nowadays devices are very noisy, from Bonjour to checking for updates the packets coming out of your network interfaces without your knowledge are plentiful and growing. And every time to send a packet out, your presence is known. A firewall with rules on outgoing traffic is a good idea to keep unwanted traffic to a minimum.
  • Don’t give your email address to anyone that asks for it, use services like mytrashmail.com or even better yet, get a new email account every time. This way if they sell your information you will know right away since you only have 1 email account per company. You can then check they EULA and see if maybe they boast of not selling your information, Make them accountable! On a side note Gmail offer the capability of adding a plus (“+”) following by a string of your choosing to your regular email address. For example if your email address is address@gmail.com, Gmail will also accept mail to address+sillysite@gmail.com. This way you can segregate mail by company with the convenience of having it all go to the same account. The caveat to that is that “+” is often considered as an invalid character in an email address even though it is a valid character.
  • Adblock is one of the best plugin for your web browser (Firefox or Chrome). It removes ads thus significantly enhancing your browsing experience. By negating traffic to advertisement servers, you are denying their chance to data mine the crap out of you. Browser fingerprinting is one of many techniques used with an argument often made that the combinations of browser related software are so plentiful that your browser can be uniquely identified. Permanent cookies are also used to keep an eye on your web whereabouts.

And even if you follow all these steps, you are not 100% untraceable online.

The path of maximum sheep

Finally, for when you have to give information, try and be a generic & blend as possible.

  • Your name is needed to sign up for something? John Smith.
  • Need a new car? White Honda Civic, no bumper stickers, no vanity plates.
  • Gotta find a new name for a PC? Linksys.
  • Need a username for that shitty forum? User2656, don’t use the one you use everywhere else or one thing leading to another, it can most likely be tied to your real identity.
Posted on

Adding an Endace card to Symantec’s DLP

I decided to publish this hack as I could not find an iota of information about getting an Endace card working With Symantec’s DLP (previously Vontu) on RedHat.

After you’ve installed the module for your Endace card, you recycle your sensor and are confronted with the following error message:

Endace DAG driver is not available
Packet Capture was unable to activate Endace device support. Please see PacketCapture.log for more information.

A look at /var/log/Vontu/debug/PacketCapture.log yields:

ERROR PacketDriverFactory - Driver Dag is unavailable: libdag.so.3: cannot open shared object file: No such file or directory [PacketDriverFactory.cpp(423)]

do an

updatedb
locate libdag.so

You will notice you just compiled a version more recent than libdag.so.3. As it turns out, Symantec DLP v11.0 does NOT know how to use the generic libdag.so nor the latest libdag.so.4.0.2 you just compiled. I’ve tried many tricks mostly with symlinks and I just couldn’t get it to use libdag.so.4.

Hold on to your pants as I explain the unholy hack that made it work:

edit /opt/Vontu/Protect/lib/native/libPacketDriverDag.so.11.0.0 , this is a binary file so using a hex editor is a good idea although vi works fine. Also, do respect placement very carefully, you will be changing 1 character and 1 character only.

search for libdag.so.3 and replace its 3 by a 4.

Recycle your server again and it should be happy about life 🙂

Posted on

2-factor authentication & writing PAM modules for Ubuntu

Download

2ndfactor.c

The problem

Passwords are often seen as a weak link in the security of today’s I.T. infrastructures. And justifiably so:

  • re-usability, which we’re all guilty of, guarantees that credentials compromised on a system can be leveraged on many others. And given the world we live in, password re-use is inevitable, we just have too many accounts in too many places.
  • plain text protocols are still used to transmit credentials, and the result is that they are exposed to network sniffing. This is worsened by the increase in wireless usage which broadcasts information. Telnet, FTP, HTTP come to mind but they aren’t the only ones.
  • lack of encryption on storage is a flaw that too often makes it way into architecture design. How many databases have we heard about getting hacked & dumped? How many have we not heard about?
  • password simplicity & patterns are also factors weakening us against bruteforce attacks.

So far, the main counter measure we’ve see out there is complexity enforcement. Sometimes IP restriction, or triggering warnings on geographic inconsistencies (Gmail, Facebook). But these barely help alleviate problem.

A solution

One hot solution that is making its way into critical systems (banks, sensitive servers) is Multi-factor authentication, and by “multi” we’ll stick to 2-factor authentication (2FA) because, well 3 factor authentication might be getting a little cumbersome :). The goal is to have more than one mean of establishing identity. And as much as possible, the means have to be distinct in order to reduce the chances of having both mechanisms compromised.

Let’s see how to implement 2FA on an Ubuntu server for SSH. Ubuntu uses PAM (Pluggable Authentication Modules) for SSH authentication among other things. PAM’s name speaks for itself, it’s comprised of many modules that can be added or removed as necessary. And it is pretty easy to write your own module and add it to SSH authentication. After PAM is done with the regular password authentication it already does for SSH, we’ll get it to send an email/SMS with a randomly generated code valid only for this authentication. The user will need access to email/cell phone on top of valid credentials to get in.

Implementation

Let’s do an ls on /lib/security, this is where the pam modules reside in Ubuntu.

Let’s go ahead and create our custom module. First, be very careful, we’re messing with authentication and you risk locking yourself out. A good idea is to keep a couple of sessions open just in case. Go ahead and download the source for our new module.

Take a look at the code, you’ll see that PAM expect things to be laid out in a certain way. That’s fine, all we care about is where to write our custom code. In our case it starts at line 35. As you can see, the module takes 2 parameters, a URL and the size of the code to generate. The URL will be called and passed a code & username. It is this web service that will be in charge of dispatching the code to the user. This step could be done in the module itself but here we have in mind a centrally managed service in charge of dispatching codes to multiple users.

Deploying the code is done as follows:

gcc -fPIC -lcurl -c 2ndfactor.c
ld -lcurl -x --shared -o /lib/security/2ndfactor.so 2ndfactor.o

If you got errors, you probably need to first:

apt-get update
apt-get install build-essential libpam0g-dev libcurl4-openssl-dev

Do an ls on /lib/security again and you should see our new module, yay!

Now let’s edit /etc/pam.d/sshd, this is the file that describes which PAM modules take care of ssh authentication, account & session handling. But we only care about authentication here. The top of the file looks like:

# PAM configuration for the Secure Shell service

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth       required     pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
auth       required     pam_env.so envfile=/etc/default/locale

# Standard Un*x authentication.
@include common-auth

The common-auth is probably what takes care of the regular password prompt so we’ll add our module call after this line as such:

auth       required     2ndfactor.so base_url=http://my.server.com/send_code.php code_size=5

The line is pretty self descriptive: this is an authentication module that is required (not optional), here’s its name and the parameters to give it.

send_code.php can be as simple as:

<?php mail( "{$_GET['username']}@mail_server.com", "{$_GET['code']}" ) ; ?>

Or a complex as you can make it for a managed, multi-user, multi-server environment.

Lastly, edit /etc/ssd/sshd_config and change ChallengeResponseAuthentication to yes. Do a quick

/etc/init.d/ssh restart

for the change to take effect.

That’s it! try and ssh in, the code will be dispatched and you will be prompted for it after the usual password. This was tested on Ubuntu 10.04 32b / Ubuntu 10.04.2 64b / Ubuntu 11.04 64b / Ubuntu 12.04 64b.

A few disadvantages of this 2FA implementation worth mentioning
  • more steps required to get in
  • doesn’t support non TTY based applications
  • relying on external services (web service, message delivery), thus adding points of failure. Implementing a fail-safe is to be considered.
  • SSH handles key authentication on its own, meaning a successful key auth does not go through PAM and thus does not get a chance to do the 2nd factor. You might want to disable key authentication in sshd’s config.