Security in extremely hostile environments

The Defcon network (and pretty much all internet sources within a few miles of that hotel) are probably among the most dangerous environments you can drop a piece of technology into.   This year proved that point more over with Lulzsec and Anonymous attacking CDMA along with spawning rouge access points[0] and rooting a number of people who should have been “security savvy.”  While common sense is still a large part of your security in these environments (accepting Java updates at Defcon? really?), this does provide an interesting use case for networks that you can’t trust ANYTHING on.  As a veteran con-goer, I’ve adapted a few techniques to help me handle such environments.  These methods could easily be used anytime you travel or are planning to be on particularly hostile networks.  Most of this is focused around the idea of having access only to those dangerous networks, while still being able to go about your regular business as much as possible.

First and foremost when considering security in these highly volatile environments you need to operate under the assumption that anything you bring with you is going to be compromised.  Each year I completely wipe my netbook, install a fresh operating system, and then migrate over any files (often requiring some redaction) that I need to have a “working OS.”  I’ll also copy over any media that I might want to entertain myself in the event that I cannot find a viable source of internet.  I use this machine for any internet connections I need as well as to mount questionable media.  In previous years, I’ve also brought work laptops and simply not connected them to anything, but as my paranoia grows things like the “evil maid attack”[1] make me question even physically having data in that environment.  With a box that has no personal data and no real value (outside of the hardware), you can also have a bit more fun by running a honeypot and some form of packet capture safely, possibly resulting in some really fun new intel.

The next big item on my list is access to my personal email.  While I don’t usually receive highly critical or sensitive mails, I do use that email as the recovery for a variety of other services.  Additionally, the account is a number of years old and contains archives of many mails that I don’t feel like sorting through to find any data leakage (I really hate mailing lists that email you your password monthly…)  To overcome this obstacle, I created a new email address and told my old account to forward all new mails to this account.  This let me receive any new mails that I might need to address quickly through a different user/password combination, protecting my original account.  Since we’re operating under the mindset that anything we use will be compromised, it also limits the value of that compromise by containing only new mails and not being connected to any other accounts.  Finally, if the account is compromised, it’s easy to disable all use of it as the forwarding is controlled by a separate account and password.

The other side of the email coin is having an account to give to people who you don’t necessarily trust (or want to know your primary address.)  Using your mail-forward account can work for this too.  Creating this account with a name not-related to your primary account or handle also allows you to keep people from Google’ing for more information on you, ultimately protecting your privacy and anonymity.

Another thing I don’t like to leave home without is a shell account somewhere, usually on my home server, but in this case that won’t work.  Environments like Defcon are more hostile than the regular internet partly because you become a more obvious target, so connecting back to your server may be seen/sniffed and would then be somewhat included in that increased hostility bubble.  To cover this base, I typically use Bshellz.[2]  They provide easy, disposable shells that offer my usual needs (ssh, irc) as well as some slightly more advanced things like web server and database.  The only downside I’ve found with Bshellz is they block random processes from connecting to the internet, so running ii or nmap from them isn’t really an option.

All those usual things you do to secure your computer (antivirus, firewall, browser plugins, common sense) should be installed and configured on their strictest settings.  Ideally, you won’t be in this environment for extended periods of time (more than the length of the con or trip), so having a few extra clicks to convince NoScript and RequestPolicy[3] to render web pages properly won’t be an on-going time-sink.  Purposely not installing more vulnerable tools, like Flash, can also help reduce your attack surface and going a few days without YouTube really isn’t _that_ bad (tho I did get the shakes on day 3.)

In environments where everything is suspect, the name of the game is data partitioning.  Don’t connect to accounts you don’t want to be compromised, don’t bring data you wouldn’t want leaked, and don’t assume that noone is looking.  Most of the techniques listed in this article focus either on separating sensitive information or preemptively setting up controls to mitigate any form of compromise.  At the end of the day, a determined attacker will almost always win, so being prepared to handle a loss should be part of your strategy.

References:

[0] http://seclists.org/fulldisclosure/2011/Aug/76

[1] https://www.schneier.com/blog/…/2009/10/evil_maid_attac.html

[2] http://www.bshellz.net/?page_id=41

[3] https://www.requestpolicy.com/

About samurai

I like computers... A lot. So I tend to spend a lot of time doing varied things with them. Often you'll find me playing with Python or PHP, fighting with operating systems, ranting about some off-the-wall concept, or preparing for zombies.
This entry was posted in Articles and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>