An avian carrier's blog – Security Atom feed

  1. Who did resurrect will-spam-for-food? (2012-01-22)

    A loooong time ago (was it 15 years ago?), two friends and I created the will-spam-for-food.eu.org DNSBL, also knows as WSFF. WSFF was a honeypot based system whose aim was to prevent massive spams from reaching their victims by catching and blocking the sender IP address early in the process. The system was first written in Ruby, a very young language at this time, then rewritten in Python because using threads in the 64 bits SparcLinux Ruby was very hazardous then and led to frequent crashes.

    A few years later, we had no time to do the routine WSFF maintenance anymore, and decided to shutdown the blacklist. We even unregistered the domain name to make sure that noone would continue to use a stale copy of the blacklist. All went well, until today: I received several emails from site administrators complaining that their site has been added to the WSFF blacklist and asking for a removal. I am still waiting for full reports in order to understand what is currently happening.

    Let me be clear about that: the WSFF blacklist does not exist anymore and has not existed for years. Whoever tells you you have been added to this blacklist either is a liar or runs a badly configured email system. Sending removal requests is useless as we cannot remove you from a non-existent blacklist.

    Note: I will redirect the old contact URL to this post so that system administrators can see this.

    Update 1 (2012-01-22 10:00 UTC): all traces point to MXToolBox, a company that monitor the blacklists for its customers. I have contacted them on Twitter and on their two contact email addresses to let them know they are crying wolf. If you have received such a bogus notification, do not hesitate to send them this page address.

    Update 2 (2012-01-22 17:30 UTC): according to the commenter Kristy C below, MXToolBox stated that they would be removing WSFF from their list.

    Update 3 (2012-01-23 15:00 UTC): an engineer at MxToolBox commented below that WSFF has been disabled in their tool.

  2. Please guess my private gmail address (2010-10-06)

    Let’s assume that:

    • you want to chat with me;
    • you only have my publicly available email address (`sam@rfc1149.net`);
    • you suspect that I also have a gmail account linked to the `sam@rfc1149.net` address;
    • you want to find it so that you can initiate a chat.

    It is easy. Create a new Google Site, and enter the Site settings/Sharing tab. Add my name as a viewer and click Invite these people.

    Then select Skip sending invitation so that I am not notified.

    My sam@rfc1149.net email address was associated with my gmail account: you got it, you can start chatting even if I never intended you to get access to my gmail address. Congratulations!

  3. Reading a DVD with VLC or mplayer is now illegal in France (2006-12-30)

    Starting tomorrow December 31st 2006, reading a DVD protected with CSS (as most DVD are) is illegal in France when it is done with a software allowing to circumvent the protection, such as VLC or mplayer which can both use the libdvdcss library. Today’s Journal Officiel (where laws and executive orders are published) says that you may be fined 750€ (around $985) for doing so. This includes watching any DVD that you have legally purchased.

    Edit 2007-02-21: the fine is 750€, not 135€ as I wrote earlier! Thanks to the two people who pointed at this mistake in the comments.

  4. Tor, plausible deniability, watchdog and seizures (2006-09-11)

    It looks like the German police has recently seized some servers running the TOR anonymity program because the TOR network seems to have been used to anonymously access child pornography. While of course nobody can publicly stand up against such an action, these seizures may sever the privacy of server owners.

    TOR can be configured in several ways:

    • as a client only, it will transmit encrypted requests to an entry point in the TOR network

    • as an exit point: encrypted packets are decrypted and sent to the targetted server and answers are reencrypted and reinjected into the TOR network to be delivered to the original requestor

    • as a middle-man server: encrypted packets are resent to another TOR server; each server in the middle only see encrypted packets, and doesn't know where they will be directed once they have reached the immediate next node in the network

    This technique is called Onion Routing, because the sender builds the packets by encrypting them successively for the latest, next-to-latest, ... relay in the chain. It also provides a response block that will be used to send the answer back and thus establish a stateful TCP connection (a circuit).

    The TOR servers that have been seized by the German police were probably exit points. Even if by default a TOR server keeps no log of the packets it transmits, it may be possible (e.g., if the access provider keeps extensive traces) to go to the previous hop in the chain, meaning that more servers will be seized and searched. Since the length of the chain is freely chosen by the emitting TOR node, examination of a node is the only solution for the police to know whether the suspected computer is the request originator or only acted as a relay.

    The problem is that a machine acting as a TOR server may well host private data, totally unrelated to this investigation. It can also host hidden TOR services. Those services are only accessible from within the TOR network. Their real location is unknown, even to other TOR operators (even if some researchers pretend that they are able to get partial information by warming up the server CPU and measuring the induced clock jitter).

    By searching a seized server, the police may find a hidden service, be it legal or not, thus compromising the anonymity of such a hidden node. What are the best way to avoid that? How can you still hide your hidden TOR services even if the police gets your server and if you are obliged to reveal your encryption keys by law? In general, how can you keep your data private? I can think of a few solutions, that combined together should make it possible to better protect one's privacy:

    • use an encrypted filesystem with plausible deniability, such as FreeBSD GBDE or David McNab's PhoneBook (probably unmaintained): with such a filesystem, you can get many different encrypted volumes whose number and capacity is unknown to the observers; you may reveal some or all of the keys, they have no way to tell

    • use encrypted swap: what good is it to use an encrypted filesystem if some service traces can be found in your previously used swap partition?

    • use a watchdog program that reboots your computer whenever an IP address (your nearest router) stops pinging: it is easy to imagine that forensics experts may want in some cases not to pull the plug out of your machine; as more and more dedicated servers are run out of small power outlets, it is easy to get one without disturbing the power flow by switching them to a battery; of course, a laptop could play the role of the gateway as well, but it is in my opinion more unlikely; anyway, if you router doesn't work, your machine isn't probably really useful, by rebooting it you automatically unmount the encrypted filesystems as well

    Those actions should let you host legal hidden services with less risk that they are discovered by side-effect of an unrelated police operation. At system boot time, your TOR-enabled server would start using a default relay-only configuration. When you log in and mount the filesystems, you can then restart it with the relay and hidden service configuration.

    Note that I do not recommend that you use those techniques to hide illegal activities or that you don't comply with the law enforcement agencies when you have to do so, just as the authors of GBDE or PhoneBook do not condone such activities. I am only trying to show how one can protect TOR hidden services or private data if those services or data are not the goal of the current investigation.

  5. Wiping unused space in a file system (2006-08-23)

    A perverse hacker friend of mine has written a clever yet scaring Windows utility. Each time a USB key is inserted into his computer, the whole content of the key is silently dumped and stored on the machine. It doesn’t copy the existing files; it makes an image of the key.

    After that, when the unsuspecting person has gone away, he can run various utilities such as undeletion tools or recoverjpeg and retrieve files that were previously deleted from the key. Doing so, he was able to get confidential documents, job offers, cracked software, music and pictures that their owner thought they had been deleted.

    My friend is probably not the first one to have had this idea, however he is the first one who told me about it. Since then, I have discovered at least one other implementation of it, called USBdumper.

    Being able to recover deleted files is nothing new. But silently dumping the content of a USB key is clever. I won’t discuss the legal, moral and ethical implications here, I want to focus on ways to protect one’s deleted data from being recovered by a casual attacker, that is one who only temporarily gains access to the device. Also, if you delete a file without using this utility, you have no way to wipe it afterwards, especially if some blocks have been reused in the meantime.

    Wiping utilities have existed for a long time. They write random data over an existing file before deleting it. This way, the previous content of the file cannot be recovered. However, when using journaling file systems, there is no guarantee that the data will really be erased; it could still be at another place on the disk.

    What we need is a tool that wipes all the unused blocks in a file system. This tool would probably have to run in kernel space to avoid race conditions if the computer is accessing the file system at the same time. To avoid writing needlessly and repeatedly on a device which might tear off, such a tool should first read those unallocated block and write them back only if they do not contain a recognizable pattern (such as all zeroes). Remember that we are not interested here in fighting post-mortem analysis using dedicated forensics tools to analyze the disk surface or some flash memory characteristics, we want to protect data from being recovered using a regular computer.

    It would also be useful to have an option at mount time to erase the data being unallocated in a file system. Every time the operating system woud mark a previously used block as free on the disk, it would also erase its content with the same pattern. This would make deleting files slow and accidental mistakes would not be forgiving anymore, but in some environments it would make the system much more secure. To give only one example, on a server, this would prevent an attacker gaining remote root access from accessing the content of previously deleted emails. I would certainly use it.