[ISN] Stratfor - Lessons Learned

From: InfoSec News <alerts_at_private>
Date: Wed, 4 Jan 2012 02:31:19 -0600 (CST)

By Gregory W. MacPherson
Computer Security Expert, CISSP, etc.
January 3, 2012

The stratfor.com hack is old news by now, so what lessons, if any, are 
there to be learned from this high profile data spill?

To review, stratfor.com private data including credit cards, user 
accounts, and passwords was dumped on pastebin.com on Christmas Day, 
2011. The data spill exposed not only tens of thousands of users to 
potential identity theft but more importantly exposed the security 
practices of those users, as well as the security practices of 

A review of the data and of the incident suggests several points worthy 
of consideration. The data was compromised using either a cross site 
scripting or SQL injection attack. From this fact one might conclude 
that application security trumps data security, and in this case one 
would be correct. Of course if the administrators of stratfor had 
practiced basic data security techniques such as encrypting data at 
rest, then the sensitive PII of tens of thousands of users might not be 
on display for the world today. While the Web site did incorporate SSL 
for user transactions, the account and credit card information existed 
in a data store in clear text rather than as encrypted hash values. Once 
the exterior security of the site was breached, regardless of the 
method, the entire site was compromised. This is referred to in the 
vernacular as "hard exterior, soft chewy inside" and is an unfortunate 
and prevalant security strategy. Numerous discussions of layered 
security have addressed the point, therefore I will not belabor it here. 
Suffice to say that the administrators of stratfor.com now may be viewed 
as idiots for not following well documented and oft published best 
practices for computer security.

A heuristic study of the user account credentials reveals another 
salient fact: stratfor users are idiots as well when it comes to 
security. The password distribution curve for stratfor includes multiple 
uses of passwords of one character, two characters, three characters, ad 
nauseum. Additionally dozens of "joe" accounts - accounts where the 
password echoed the username - are in evidence. Stratfor.com made no 
effort to enforce a strong password policy - a few lines of JavaScript 
would have sufficed - and as a consequence we find embarrassing examples 
such as username stratfor, password stratfor. One real benefit of this 
data breach is that it illustrates a real world example of the poor 
choices that users make when it comes to computer security. Strong 
security must be enforced, not optional, and allowing users to decide 
whether the security measures inconvenience them leads to situations 
such as the current topic of discussion.

A third point for consideration is the situation where multiple users 
with credentials ending in TLDs such as dot-edu, dot-gov, and dot-mil 
utilized passwords on stratfor.com that echo their credentials on their 
more sensitive home sites. One would like to think that people who boast 
of academic, government, or military credentials would be more cognizant 
of their responsibility to protect the privileged information entrusted 
to them, but apparently they too, despite their august credentials, are 
idiots when it comes to authentication credentials and the management 
thereof. Suffice to say that dot-mil sites routinely employ two-factor 
authentication to prevent compromises of this exact sort. Some 
government sites also employ two-factor authentication methods, and 
possibly a few academic sites do as well. For those sites which rely 
solely on the arcane userid and password combination, I suspect that 
this holiday season was less than merry as their security staff worked 
late to try and head off the inevitable compromises that would result 
after dozens of credentials were published.


Did a friend send you this article? Make it your
New Year's Resolution to subscribe to InfoSec News!
Received on Wed Jan 04 2012 - 00:31:19 PST

This archive was generated by hypermail 2.2.0 : Wed Jan 04 2012 - 00:28:14 PST