Today marks the 1 year anniversary of tssci security. I first started
this blog last year with a goal to put my thoughts on security and
technology in general out into the open. Since I started, I've learned a
lot from other bloggers and people who read and comment on my blog. The
blog has helped me develop relationships, make friends and establish
contacts in the security industry. It makes for a great conversation
starter with people, especially with those who recognize my name and my
blog's title. It helped land me an internship with a Fortune
10
company and probably has been the best career move I've made so far
being only 20 years old (21 just a couple days away!).
I plan on continuing to share with you all my experience and knowledge
as I get older and learn more. To conclude today's post, I'd like to
express my sincerest thanks to everyone whose read, subscribed,
commented, emailed, IM'd, met and chatted with me over the last year.
Special thanks to the Catalyst Community and to LonerVamp and
dre -- you guys are awesome.
-Marcin
Posted by Marcin on Thursday, August 23, 2007 in
Other.
Add this to your .bashrc to make tab completion with bash more useful
when handling multiple files with similar names:
bind '"\t":menu-complete'
Ctrl-D can be used to exit Bash. This can be very convenient and then
again, almost too convenient. Specify it must be pressed twice before
exiting by adding to .bashrc:
export IGNOREEOF=1
Posted by Casey on Thursday, August 23, 2007 in
Linux.
Last year, a colleague pointed me to an article by Roland L. Trope in
September/October 2006 IEEE Security &
Privacy,
Immaterial Transfers with Material
Consequences.
From the abstract:
The need for such regulations is clear, but many firms underestimate
the challenges of complying with the defense trade controls embodied
in the US International Traffic in Arms Regulations (ITAR).
Companies hoping to enter into defense contracts must therefore
redefine their basic approach to technical data because the ITARs
require that they control the destinations of their communications.
For example, the ITARs prohibit unlicensed communications of
sensitive data to foreign destinations (another country or a foreign
national).
Trope recounts a fictitious company's plans and their problems with ITAR
and IT. Based on real events, in March 2006 The Boeing Company and L-3
Communications agreed to pay civil penalties of $15 million and $7
million USD respectively for not complying with ITAR. The consequences
and fines for illegal exports are real. If the Directorate of Defense
Trade Controls determines a violation(s) were unintentional, it can
impose a civil penalty up to $500,000 per violation. If it determines
violations to be intentional, it can impose up to $1 million for each
violation. This can spell numerous violations and result in huge fines
if for example, over the course of one day hundreds of emails are
exchanged between engineers who are both US Citizens and foreign
nationals.
The company planned to encrypt all sensitive traffic and use code names
for email attachments containing sensitive data. They believed using
code names to disguise data would minimize the risk, but in reality,
engineers would select select names from a theme for one project, and
names from another theme for another. It wouldn't take long for someone
to group the emails into their respective project. Many companies adopt
a policy and reliance on encryption for protecting their most sensitive
data. If a laptop goes missing, it is deemed not a risk because it was
encrypted with X algorithm. Not in the eyes of the ITAR, which must
distinguish between procedures that retain control over data and
procedures that relinquish control. By making it available to a foreign
national to obtain a copy, you are committing an export. Encryption is
not enough to comply with ITAR because it is not a durable safeguard.
I think we can all agree on this, that given enough computing power and
time, a determined attacker will crack the encryption.
The article also brings up the issue of disclosure and transfer of data.
Data can be disclosed orally or visually through any number of means
such as email, instant message, presentations, etc. If one makes it
possible for a foreign national to obtain a copy of sensitive data
during transmission, an export has occurred. The company in the story
stored sensitive data in an unlocked closet at one of their locations.
Foreign nationals visiting from other countries would be allowed to
store their briefcases in that closet, and consequently give them access
to ITAR-controlled data.
Protecting sensitive data, whether it be ITAR-controlled, classified, or
restricted internal communication is important for every company. Much
of the policies and solutions we implement ignore the problems that
arise when people need to decide on the fly which files contain
sensitive information. It's a huge undertaking to classify existing
data, but you gotta start somewhere -- create a (scalable) data
classification policy and start with all new data.
Posted by Marcin on Wednesday, August 22, 2007 in
Defense and
Security.
Thanks to everyone involved at making this a successful
event. It was my first time out to BeanSec, but unfortunately will
likely be my last this year (I am going back to school in September). I
made the two hour drive all the way out from Hartford, CT, and it was a
blast. There were about thirty people in attendance at The Enormous Room
in Cambridge, Mass from 6:30pm up until 9:30~10pm.
It was fun hanging out with Chris
Hoff (who btw, was an
excellent host), Oliver Day, Mike, Tim from Arbor Networks, Christian
and his fellow Cisco colleagues, and
Joshua` <http://pbnj.sourceforge.net/>`_.
I'm sorry if I forgot to mention anyone. I know there are a couple of
you, but I forgot/didn't catch your names. Just post here in the
comments and leave a link to your personal site or blog. My next CitySec
gathering that I'll be attending is SunSec in Phoenix.
Posted by Marcin on Wednesday, August 15, 2007 in
People.
Web 2.0 has (re)introduced a wide variety of attack vectors that can be
used against Internet users to steal sensitive information, control the
web browser, and more. The security industry has seen a shift from
concentrating on the servers that house data to protecting the data
itself. Many web applications and social-networking sites today exhibit
flaws that expose them to all sorts of attacks, with much focus on XSS,
CSRF, exploiting the same-origin policy and malicious code execution.
With insight from a couple of web security experts and some further
research, I've compiled a list of must-have Firefox extensions that help
ensure safer and more secure browsing with Firefox. Many of us have
agreed that the security "functionality" these extensions provide should
be built right into Firefox (*cough*Mozilla Security Team*cough*).
Below, I outline the risk and how each extension goes about mitigating
it.
Adblock Plus
- Risk: Spammers and advertisers are increasingly using more
malicious ways of getting advertisements to you. We saw in the past
hacked ads on
MySpace
and other
sites
serving malicious code to infect users.
- Use Adblock Plus to block advertisements. You can right-click an
advertisement (or image) and add it to your blacklist. There are also
subscription filters you can subscribe to that will remove almost all
advertisements automatically. The subscription filters are maintained
by individuals like you and I, who hates ads just as much.
CS Lite
- Risk: Some sites set cookies for tracking browser behavior of
their users across multiple sites. These are cookies usually set by
third-party advertising companies that have banner ads on the site
you visited. This can be a privacy risk for Internet users who accept
cookies globally and are not more selective in which sites they allow
to set cookies.
- With CS Lite, you can easily control cookie permissions on a domain
basis. You can allow, block, or termporarily allow a site to set
cookies. Initially, set CS Lite to deny cookies globally, and then
enable them on a per site basis. Using this method, you can eliminate
all those pesky tracking cookies served by third-party advertisers.
FoxyProxy
- Risk: When you visit a website, your IP address is recorded in an
access log (unless the site specifically does not keep access logs).
Sites such as Google tie your search records to your IP address. That
means every search for information, be it medical remedies, hobbies,
porn, etc, provides some piece of information about you. This poses
an ever greater privacy threat than tracking cookies.
- Use FoxyProxy to manage proxy settings within Firefox. FoxyProxy can
also be used with Tor, which tunnels your browsing sessions through
multiple servers around the world. It is much harder to trace your
browsing habits back to your original IP when you proxy through
multiple systems as you do on the Tor network.*For more information
on proxies, see the Wikipedia
entry.
LocalRodeo
- Risk: Anti-DNS pinning (explained
here)
is an attack vector that has seen been mentioned a lot recently in
the press. Essentially what happens, is malicious JavaScript can tell
a browser to connect back to a site with a different IP address than
originally set. This is especially dangerous when launched against
sites with areas that are non-public (corporate intranets).
- Protect yourself from malicious JavaScript using LocalRodeo. You
might be thinking, "but doesn't NoScript protect me?" See the section
on NoScript below for more information.*A more general anti-CSRF
solution is being worked on
here.
RefControl
- Risk: When you click on a link or open a tab to a new site, that
site can see what page referred you to them in their logs and
analytics software. This can be a privacy risk since this site now
knows where you were coming from. Some sites instruct users to post
non-clickable links or disable HTML in posts to prevent their site
from showing up in other sites' referrer logs. This could even be a
liability for some sites, especially those that host links to
questionable material.
- Use an extension like RefControl to disable Firefox from sending
information on the referring site. You can enable referrers on a per
site basis, if you need too. I have enabled for just such an
occasion, on digg.com, since clicking on a link to duggmirror.com
relies on the referrer to redirect you to the appropriate site
mirror.
NoScript
- Risk: Web sites using various scripting languages to increase
functionality of their websites. Unfortunately, these scripting
languages open us up to a wide range of attacks such as XSS, XSRF and
CSRF. Since the script is executed locally versus server-side,
malicious scripts can be used to compromise the web browser.
- Use NoScript to block scripts globally. NoScript can be configured to
allow scripts to run on a per domain basis. NoScript can also help
prevent XSS attacks because it can identify when a non-trusted site
tries to inject JavaScript into a trusted site and filters it. But
what about LocalRodeo? Well, NoScript isn't perfect. It can't be. If
you allow scripts to run on a domain basis, you risk running
malicious code. If a site you "trust" is compromised (e.g. cnn.com),
any code on that site is run. If an attacker has inserted malicious
JavaScript into the site, you're pwned. With LocalRodeo, you are more
protected against malicious attacks, such as anti-DNS pinning.
*See Andre Gironda's Reflections on Trusting the Same-Origin
Policy *See
Same-Origin Policy Part 1: Why we're stuck with things like XSS and
XSRF/CSRF
SafeCache
- Risk: Your browser caches various files when it visits a website
to make subsequent visits load quicker. What we've seen though, are
ways of tracking users via
caches and cache timing
attacks.
- SafeCache segments browser cache by the originating document,
preventing Site A from using a timing technique to determine if
you've visisted Site B.*
SafeHistory
- Risk: CSS can set the color of a link based on whether you have
clicked or visited the site previously. This can be used against you
in a CSS History
Hack
as demonstrated by Jeremiah Grossman.
- Like SafeCache, SafeHistory segments the marking of visited links on
the basis of the originating document.* You might notice that
NoScript protects you in the POC for both SafeCache and SafeHistory.
That's true, but go ahead and disable NoScript for the site and
you're not protected anymore. We need to be careful which sites we
trust, because though the author may be ethical doesn't mean an
attacker who compromises their site will be.
Further Reading: *Protecting Browser State from Web Privacy
Attacks
Edit: Changed No-Referrer extension to RefControl
Posted by Marcin on Wednesday, August 15, 2007 in
Privacy and
Security.
