Sussy McBride Shouts: I got hacked

Thanks to Sensepost for reporting this story last month. They describe an advisory published by Charles Miller and Dino Dai Zovi whereby arbitrary characters in Second Life are digitally mindjacked and robbed. By walking on "land" owned by an attacker, and having Second Life configured to automatically display video, a victim's avatar and computer can be exploited via the November 2007 Quicktime vulnerability. In the YouTube video you can see "Sussy McBride" be freeze, shout "I got hacked," and give her money to the attacker.

I am fascinated by this story because it is the natural progression from a 2006 post Security, A Human Problem describing a Second Life denial of service attack. In that post I said:

First, it demonstrates that client-side attacks remain a human problem and less of a technical problem. Second, I expect at some point these virtual worlds will need security consultants, just like the physical world. I wonder if someone could write a countermeasure at the individual player level for these sorts of attacks?

I wonder if anyone in Second Life will start creating disposable bodyguard avatars to walk in front of highly-valued avatars, thereby acting as "digital mine detectors?"

Read More

Incident Severity Ratings

Much of digital security focuses on pre-compromise activities. Not as much attention is paid to what happens once your defenses fail. My friend Bamm brought this problem to my attention when he discussed the problem of rating the severity of an incident. He was having trouble explaining to his management the impact of an intrusion, so he asked if I had given any thought to the issue.

What follows is my attempt to apply a framework to the problem. If anyone wants to point me to existing work, please feel free. This is not an attempt to put a flag in the ground. We're trying to figure out how to talk about post-compromise activities in a world where scoring vulnerabilities receives far more attention.

This is a list of factors which influence the severity of an incident. It is written mainly from the intrusion standpoint. In other words, an unauthorized party is somehow interacting with your asset. I have ordered the options under each category such that the top items in each sub-list is considered worst, and the bottom is best. Since this is a work in progress I put question marks in many of the sub-lists.

1. Level of Control




• Domain or network-wide SYSTEM/Administrator/root


• Local SYSTEM/Administrator/root


• Privileged user (but not SYSTEM/Administrator/root


• User


• None?




2. Level of Interaction




• Shell


• API


• Application commands


• None?




3. Nature of Contact




• Persistent and continuous


• On-demand


• Re-exploitation required


• Misconfiguration required


• None?




4. Reach of Victim




• Entire enterprise


• Specific zones


• Local segment only


• Host only




5. Nature of Victim Data




• Exceptionally grave damage if destroyed/altered/disclosed


• Grave damage if destroyed/altered/disclosed


• Some damage if destroyed/altered/disclosed


• No damage if destroyed/altered/disclosed




6. Degree of Friendly External Control of Victim




• None; host has free Internet access inbound and outbound


• Some external control of access


• Comprehensive external control of access




7. Host Vulnerability (for purposes of future re-exploitation




• Numerous severe vulnerabilities


• Moderate vulnerability


• Little to no vulnerability




8. Friendly Visibility of Victim




• No monitoring of network traffic or host logs


• Only network or host logging (not both)


• Comprehensive network and host visibility




9. Threat Assessment




• Highly skilled and motivated, or structured threat


• Moderately skilled and motivated, or semi-structured threat


• Low skilled and motivated, or unstructured threat




10. Business Impact (from continuity of operations plan)




• High


• Medium


• Low




11. Onsite Support




• None


• First level technical support present


• Skilled operator onsite

Based on this framework, I would be most worried about the following -- stated very bluntly so you see all eleven categories: I worry about an incident where the intruder has SYSTEM control, with a shell, that is persistent, on a host that can reach the entire enterprise, on a host with very valuable data, with unfettered Internet access, on a host with lots of serious holes, and I can't see the host's logs or traffic, and the intruder is a foreign intel service, and the host is a high biz impact system, and no one is on site to help me.

What do you think?

Read More

More Unpredictable Intruders

Search my blog for the term unpredictable and the majority of the results describe discussions of one of my three security principles, namely

Many intruders are unpredictable.

Two posts by pdp perfectly demonstrate this:

• Bugs in the Browser: Firefox’s DATA URL Scheme Vulnerability


• Web Mayhem: Firefox’s JAR: Protocol issues

How many of you who are not security researchers even knew that data: or jar: protocols existed? (It's rhetorical, no need to answer in a comment.) Do you think your silver bullet security product knows about it? How about your users or developers?

No, this is another case where the first time you learn of a feature in a product is in a description of how to attack it. This is why the "ahead of the threat" slogan at the left is a pile of garbage. This is another example of Attacker 3.0 exploiting features devised by Developer 2.5 while Security 1.0 is still thinking about how great it is no big worms have hit since 2005. (The specific cases here are worse than Developer 2.5, since jar: and data: protocols are apparently old!)

How do I propose handling issues like this? As always, NSM is helpful. If you've been keeping track of what happens in your enterprise, you can perform some retrospective network analysis (RNA) to see if you've seen this latest attack vector. (RNA is a term which Network Instruments would like to have coined. I like it, even though the concept of recording traffic in this manner dates back to Todd Heberlein's original Network Security Monitor in 1988. The first mention I can quickly find is in this 1997 paper Netanalyzer: A retrospective network analysis tool.)

RNA and, from this point of enlightenment, ongoing network analysis via NSM and, ideally, other forms of instrumentation (logs, etc.) facilitates impact assessment. Who cares if the sky is falling somewhere else, as reported in whatever online news story -- is your sky falling? If yes, what's the damage? How best can we mitigate and recover? These are the sorts of questions one can answer when some data is available, enabling management by fact and avoiding management by belief.

Read More

DHS Debacle

Thanks to the Threat Level story FBI Investigates DHS Contractor for Failing to Protect Gov't Computer I learned of the Washington Post story Contractor Blamed in DHS Data Breaches:

The FBI is investigating a major information technology firm with a $1.7 billion Department of Homeland Security contract after it allegedly failed to detect cyber break-ins traced to a Chinese-language Web site and then tried to cover up its deficiencies, according to congressional investigators.

At the center of the probe is Unisys Corp., a company that in 2002 won a $1 billion deal to build, secure and manage the information technology networks for the Transportation Security Administration and DHS headquarters. In 2005, the company was awarded a $750 million follow-on contract.

On Friday, House Homeland Security Committee Chairman Bennie Thompson (D-Miss.) called on DHS Inspector General Richard Skinner to launch his own investigation.

As part of the contract, Unisys, based in Blue Bell, Pa., was to install network-intrusion detection devices on the unclassified computer systems for the TSA and DHS headquarters and monitor the networks. But according to evidence gathered by the House Homeland Security Committee, Unisys's failure to properly install and monitor the devices meant that DHS was not aware for at least three months of cyber-intrusions that began in June 2006.

Through October of that year, Thompson said, 150 DHS computers -- including one in the Office of Procurement Operations, which handles contract data -- were compromised by hackers, who sent an unknown quantity of information to a Chinese-language Web site that appeared to host hacking tools.

The contractor also allegedly falsely certified that the network had been protected to cover up its lax oversight, according to the committee.

"For the hundreds of millions of dollars that have been spent on building this system within Homeland, we should demand accountability by the contractor," Thompson said in an interview. "If, in fact, fraud can be proven, those individuals guilty of it should be prosecuted."

Wow. This is huge. I cannot remember any case like it. So what happened?

In the 2006 attacks on the DHS systems, hackers often took over computers late at night or early in the morning, "exfiltrating" or copying and sending out data over hours -- in one case more than five hours, according to evidence collected by the committee.

Five hours. That indicates one means of detecting this sort of activity: time-based analysis of session records.

In July 2006, a Unisys employee detected a possible intrusion but "downplayed it and low-level DHS security managers ignored it," the committee aide said.

It was not until Sept. 27, 2006, that two DHS systems managers noticed that their machines had been accessed with a hacking tool.

Unisys information technology employees began a probe and determined that the break-in affected more computers. They discovered that it reached back as far as June 13 that year and had continued through at least Oct. 1, eventually reaching 150 computers.

Among the security devices Unisys had been hired to install and monitor were seven "intrusion-detection systems," which flag suspicious or unauthorized computer network activity that may indicate a break-in. The devices were purchased in 2004, but by June 2006 only three had been installed -- and in such a way that they could not provide real-time alerts, according to the committee. The rest were gathering dust in DHS storage closets and under desks in their original packaging, the aide said. (emphasis added)

This explains a lot!

Let's finish with this thought:

A Unisys spokeswoman, Lisa Meyer... said that Unisys has provided DHS "with government-certified and accredited security programs and systems, which were in place throughout 2006 and remain so today."

Exactly. C&A has absolutely zero operational security value, as I wrote in FISMA 2006 Scores.

I commend the Congressional committee tracking this problem and I welcome future reporting. I would love to be the expert witness in any trial between the government and Unisys, but that is outside the scope of my current employment!

Read More

Max Ray Butler in Trouble Again

In my first book I wrote the following on p 170:

WHO WROTE PRIVMSG?

The author of Privmsg served one year in prison after pleading guilty in a U.S. District Court to a single count of computer intrusion. In May 1998 he compromised numerous government, military, and academic servers running BIND and installed back doors on those systems. He was caught thanks to skillful use of session data by analysts at the AFCERT and by Vern Paxson from Lawrence Berkeley Labs. See http://www.lbl.gov/Science-Articles/Archive/bro-cyber.html for more information on Paxson’s use of Bro and the “boastful and self-justifying” e-mail the intruder sent to Paxson. For details on the intruder, see Wired’s account at http://www.wired.com/news/culture/0,1284,54838,00.html. Kevin Poulsen’s story at http://www.securityfocus.com/news/203 has more details.

The bottom line is it does not pay to infiltrate government machines -- especially Air Force servers or computers monitored by IDS researchers.

I didn't name Max Ray Butler (aka "Max Vision") as the author of Privmsg, but if you followed the stories you would have figured that out yourself.

I also didn't publicize this August 2002 post by Max to the SecurityFocus Jobs mailing list, subject line bay area security professional, $6.75/hr... Please read below!:

Greetings security employers:

I have an unusual situation that I would like to describe to you, and in doing so I am asking that anyone who can immediately employ me in the San Fransisco Bay Area, please read this email and consider taking advantage of my availablity and temporarily low cost.

I am...
o a seasoned professional with extensive security skills and experience
o a once convicted hacker (DOD, 1998)
o local to the San Fransisco Bay Area, I live in Oakland
o willing to work for mimimum wage (for the next two months)
o eager to work 60 hour weeks; I don't mind nights/weekends/holidays...

My Conviction (why I am desperate)

I am not proud of being convicted of a felony, but it is important that a potential employer know of my status. Apparently if you have FDIC insurance there is a clause stating that you cannot hire a convicted hacker on your projects. It is also because of my status that I am desperate for security-related or even internet-related work.

The truth is, I am living in a federal halfway house transitioning out of prison back into society. I have to find local work to meet their requirements, and they haven't approved any telecommute offers I have had so far. The director of the facility told me that if I don't find a job in the next week or so he will send me back to prison (my sentence actually ends October 12th)...

Sincerely,

Max Vision

That's one of the saddest and most pathetic posts I've ever read.

So where are we now, five years later? Check out Max Vision charged with hacking -- again:

In a five-count indictment unsealed on Tuesday, federal prosecutors allege that Butler ran a scheme to hack into computers at financial institutions and credit-card processing centers, stealing account information and selling the data to others. Butler also ran the online carders' forum, CardersMarket, under the name "Iceman" and "Aphex" as a way to coordinate illegal activities and meet people with similar interests, according to an affidavit penned by the U.S. Secret Service, which spearheaded the investigation...

During the 16-month investigation, the Secret Service maintained two confidential informants, one of which was an administrator on the CardersMarket forum. The informants gave the investigators an eye-opening view of the inner workings of the carders' world, the affidavit stated.

Butler purportedly used at least five different handles -- including "Iceman," "Aphex," and "Digits" -- in an attempt to confuse law enforcement and keep his administrative activities on CardersMarket separate from his outright illegal activities, the affidavit maintains...

A federal grand jury indicted Butler on charges of wire fraud and identity theft. If Butler is found guilty of all five charges, he could face up to 70 years in prison and a fine of $1.5 million, according to the U.S. Attorney's Office in Pittsburgh. Butler is currently being held in San Francisco until he appears in court on Monday.

I know Mr Butler is innocent until proven guilty in US courts, but human evidence gathered by informants is going to be tough to beat.

Show this post to your kids if they think "[malicious] hacking is cool." If you think "[malicious] hacking is cool," remember Mr Butler's fate the next time you break the law.

Read More

Marcus Ranum Highlights from USENIX Class

Because I was teaching at USENIX Security this month I didn't get to attend Marcus Ranum's tutorial They Really Are Out to Get You: How to Think About Computer Security. I did manage to read a copy of Marcus' slides.

Because he is one of my Three Wise Men of digital security, I thought I would share some of my favorite excerpts. Some of the material paraphrases his slides to improve readability here.

• Marcus asked how can one make decisions when likelihood of attack, attack consequences, target value, and countermeasure cost are not well understood. His answer helps explain why so many digital security people quote Sun Tzu:
  
  The art of war is a problem domain in which successful practitioners have to make critical decisions in the face of similar intangibles.
  
  I would add that malicious adversaries are also present in war, but not present in certain other scenarios misapplied to security (like car analogies) where intelligent adversaries aren't present.


• Marcus continues this thought by contrasting "The Warrior vs The Quant":
  
  Statistics and demographics (i.e., insurance industry analysis of automobile driver performance by group) [fails in digital security] because there is no enemy perturbing the actuarial data... and "perturbing your likelihoods" is what an enemy does! It's "innovation in attack or defense. (emphasis added)


• Marcus offers two definitions for security which I may quote in the future:
  
  A system is secure when it behaves as expected; no less and certainly no more.
  
  A system is secure when the amount of trust we place in it matches its trustworthiness.


• Marcus debunks the de-perimeterization movement by explaining that a perimeter isn't just a security tool:
  
  A perimeter is a complexity management tool.
  
  In other words, a perimeter is a place where one makes a stand regarding what is and what is not allowed. I've also called that a channel reduction tool.


• Here's an incredible insight regarding the many "advanced" inspection and filtering devices that are supposed to be adding "security" by "understanding" more about the network and making blocking decisions:
  
  At a certain point the complexity [of the firewall/filter] makes you just as likely to be insecure as the original application.
  
  He says you're replacing "known bugs" (in the app) with "unknown bugs" (in the "prevention" device).


• I love this point:
  
  Insiders and counter-intelligence: What to do about insider threat?
  
  
  
  • Against professionals: lose
  
  
  • Against idiots: IDS (Idiot Detection System) works; detect stupidity in action
  
  
  
  This is so true. I'd extend the "idiot" paradigm further by adding EDS (Eee-diot Detection System). (Cue "Stimpy, you eee-diot!" if you need pronunciation help here.)


• Finally, Marcus slams the idea that one can use an equation to quantify risk. He calls "Risk = Threat X Vulnerability X Asset Value" one wild guess times another wild guess times another wild guess. I agree with this but I would say the concept of separating out those variables helps one understand how Risk changes as one variable changes with the others held constant.
  
  Marcus also offers two approaches to dealing with risk:
  
  
  
  
  1. Think of all possible disasters, rank by likelihood, prepare for Top 10. (9/11 showed this doesn't work.
  
  
  2. Build nimble response teams and command/control structures for fast and effective reaction to threats as they materialize.
  
  
  
  Regarding number one, Marcus obviously thinks that is a waste of time. However, one could argue that if policymakers had paid attention to the intelligence that was available and prepared, the situation could have been different. That's where threat intelligence on capabilities and intentions and attack patterns can be helpful for modeling attacks.
  
  Regarding number two, I am so pleased to read this. It's why I'm building a CIRT at my new job. This comment also resonates with something Gadi Evron said during his talk on the "Estonia Cyberwar":
  
  No one is judged anymore by how they prevent incidents. Everyone gets hacked. Instead, organizations are judged by how they detect, respond, and recover.
  

Read More

Breach Pain

Several stories involving companies victimized by intruders came to light at the same time. It's important to remember not to blame the victim, like the fool editor at Slashdot implied by writing Contractor Folds After Causing Breaches. The company in question, Verus Inc., didn't "cause breaches" -- it suffered them. Some bad guy stealing data caused the breaches. Read Medical IT Contractor Folds After Breaches at Dark Reading for the details.

New details on TJX came to light this week in stories like TJ Maxx Breach Costs Soar by Factor of 10 (Company had to absorb $118M of losses in Q2 alone) and The TJX Effect. The second article says this:

Poorly secured in-store computer kiosks are at least partly to blame for acting as gateways to the company's IT systems, InformationWeek has learned. According to a source familiar with the investigation who requested anonymity, the kiosks, located in many of TJX's retail stores, let people apply for jobs electronically but also allowed direct access to the company's network, as they weren't protected by firewalls. "The people who started the breach opened up the back of those terminals and used USB drives to load software onto those terminals," says the source. In a March filing with the Securities and Exchange Commission,TJX acknowledged finding "suspicious software" on its computer systems.

The USB drives contained a utility program that let the intruder or intruders take control of these computer kiosks and turn them into remote terminals that connected into TJX's networks, according to the source. The firewalls on TJX's main network weren't set to defend against malicious traffic coming from the kiosks, the source says. Typically, the USB drives in the computer kiosks are used to plug in mice or printers. The kiosks "shouldn't have been on the corporate LAN, and the USB ports should have been disabled," the source says.

You can expect me to advocate detection and rapid response, and I'm curious what this will produce: DARPA seeks innovations in network monitoring. Why isn't it "innovations in stopping attacks?" Because that doesn't work.

Read More

No Undetectable Breaches

PaulM left an interesting comment on my post NORAD-Inspired Security Metrics:

...what if the enemy has a stealth plane that we cannot detect via radar, satellite, wind-speed variance, or any other deployed means? And what if your intel doesn't tell us that such a vehicle exists? Then we have potentially millions of airspace breaches every year and our outcome metrics are not helping.

I'm not disagreeing with you that outcome metrics are ideally better data than compliance metrics. However, outcome metrics are difficult to identify and collect data on, and it can be difficult to discern how accurate your metrics actually are.

At least with compliance metrics, we can determine how good we are at doing what it is we say that we do. It has little relevance to operational security, but it's easy and the auditors seem to like it.

For the case of a single breach, or even several breaches, it may be possible for them to happen and be completely undetectable. However, I categorically reject the notion that it is possible to suffer sustained, completely undetectable breaches and remain unaware of the damage. If you are not suffering any damage due to these breaches, then why are you even trying to deter, detect, and respond to them in the first place?

Let me put this in perspective by considering labels attached to classified information as designated by Executive Order 12356:

(a) National security information (hereinafter "classified information") shall be classified at one of the following three levels:

1. "Top Secret" shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause exceptionally grave damage to the national security.


2. "Secret" shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause serious damage to the national security.


3. "Confidential" shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause damage to the national security.

We want to protect the confidentiality of classified information to avoid the losses described above. What happens if we suffered sustained breaches (thefts) of Top Secret data? Are we not going to detect that our national security concerns are being hammered, since we are suffering "exceptionally grave damage"?

This is one way spies are unearthed. If your missions are constantly failing because the enemy seems to know your plans, then your suffering a breach you haven't detected it.

Finally, if you are suffering breaches and your input-based metrics aren't detecting them either, what good are they? Talk about a real waste of money. "It's easy and auditors seem to like it?" Good grief.

Read More

ARP Spoofing in Real Life

I teach various layer 2 attacks in my TCP/IP Weapons School class. Sometimes I wonder if students are thinking "That is so old! Who does that anymore?" In response I mention last year's Freenode incident where Ettercap was used in an ARP spoofing attack.

Thanks to Robert Hensing's pointer to Neil Carpenter's post, I have another documented ARP spoofing attack. Here a malicious IFRAME is injected into traffic by ARP spoofing a gateway. We cover that in my Black Hat class, both of which are now officially full.

Please remember that TCP/IP Weapons School is a traffic analysis class. I believe I cover the most complicated network traces presented in any similar forum. All you need to get the most out of the class is a laptop running a recent version of Wireshark. The class is not about demonstrating tools or having students run tools. Other classes do a better job with that sort of requirement. The purpose of this class is to become a better network security analyst by deeply understanding how certain network-based attacks work. I provide all of the information needed to replicate the attack if so desired, but that is not my goal.

Read More

More on Enterprise Data Centralization

I'd like to respond to a few comments to my post Enterprise Data Centralization. The first paragraph includes the following:

However, I haven't written about a natural complement to thin client computing -- enterprise data centralization. In this world, the thin client is merely a window to a centralized data store (sufficiently implemented according to business continuity processes and methods like redundancy, etc.).

The bolded part is my answer to those who think my "centralization" plan means building the Mother of All Storage Servers/Networks. Please. Do you think I would really advocate that? The bolded part is my shorthand for saying I do NOT mean to build the Mother of All Storage Servers/Networks.

Instead, I envision something similar to the way Google operates. One of you used Google as an example of data decentralization. Sure, the data is decentralized at the level of bits on media, but it's exceptionally centralized where it matters -- the user interface. I can access all of my Google-related content through one portal. If my data needed to be explored for ediscovery purposes, all you need is my Google login. Easy. That's the kind of centralization I'm talking about.

That explanation should also calm those who think I'm building the Mother of All Targets; i.e., nuke the primary and secondary data centers and the whole company is dead. Again, you're thinking at the level of bits and media. I'm thinking in terms of a single interface to all company data.

Now you might be thinking that what I'm advocating isn't all that special. Consider this: do you have a single place to go for all of your company data? If you do, that is awesome. I doubt that it's the case for most of us, however. Unfortunately, we have to move in that direction if we wish to meet legal business requirements.

Christopher Hoff used the term "agile" several times in his good blog post. I think "agile" is going to be thrown out the window when corporate management is staring at $50,000 per day fines for not being able to produce relevant documents during ediscovery. When a company loses a multi-million dollar lawsuits because the judge issued an adverse inference jury instruction, I guarantee data will be centralized from then forward.

The May 2007 ISSA Journal features a great article titled E-discovery: Implications of FRPC Changes on IT Risk Management by Bradley J. Schaufenbuel. It features this excerpt:

Adverse inference jury instruction: If electronic evidence is not produced in a timely manner, a judge may instruct the jury to assume that the missing evidence would have been adverse to the party that failed to produce it. This will greatly diminish this party’s chances of legal success.

Two highly visible examples include Zubulake v. UBS Warburg and Coleman v. Morgan Stanley. The defendant financial institutions in both lawsuits lost their cases due to their failure to adequately produce e-mail evidence, and the resulting assumption that evidence was willfully destroyed or withheld. Laura Zubulake, a former UBS employee, was awarded $29 million in 2005 in her sexual discrimination lawsuit.

And billionaire Ronald Perelman was awarded $1.45 billion in 2005 based on his claim that Morgan Stanley defrauded him in the 1998 sale of his company, camping goods manufacturer Coleman.

Email provides a good example of a place to start centralizing data. Look at the trouble the White House has created in the story House Report Shows White House Officials Sent Thousands of Official Emails Using Outside Accounts.

It's fine to be advocating Google Gears and all these other Web 2.0 applications and systems. There's one force in the universe that can slap all that down, and that's corporate lawyers. If you disagree, whom do you think has a greater influence on the CEO: the CTO or the corporate lawyer? When the lawyer is backed by stories of lost cases, fines, and maybe jail time, what hope does a CTO with plans for "agility" have?

Incidentally, I wouldn't be promoting centralization if I thought it was impossible. Centralization was a word in the first sentence the GE CTO said to me during out first meeting.

Read More

Web-Centric Short-Term Incident Containment

You may have read Large Scale European Web Attack from Websense and other news sources. One or more Italian Web hosting companies have been compromised, and the contents of the Web sites they host have been modified.

Malicious IFRAMEs like the one below are being added to Web sites. These IFRAMEs like to malicious code hosting by a third party under the control of the intruder. When an innocent Web browser visits the compromised Web site, the browser is attacked by the contents of the IFRAME. This is not a new problem. I responded to an intrusion in 2003 that used the same technique. It's the reason why I discussed having the capability to use an extrusion method to modify traffic as it leaves a site. This is an example of Short Term Incident Containment. This technique does not remediate the compromised Web sites or Web servers. It does help clean malicious traffic before it reaches Web browsers. I suggest using Netsed or Snort in inline mode to replace the malicious IFRAME with something benign. It would be helpful to have this sort of capability widely deployed as an application-level incident response tool.

Note: I do not use Gentoo. However, Gentoo's package site nicely provides images for all the tools in their repository. When one is trying to write slides and add images that have some relationship with the material at hand, Gentoo's "package boxes" make nice additions.

As a preventative measure on the Web client side, Greg Castle's Whitetrash would help prevent the third-party content being loaded into the IFRAME.

On a somewhat related note, I am glad to see developments like that from Palo Alto Networks, described by Dark Reading. It's a firewall that makes blocking decisions based on application recognition, not port number. Parts of this functionality are available elsewhere, but eventually all network blocking and inspection products will make decisions using the same method.

Read More

Initial Thoughts on Digital Security Hearing

Several news outlets are reporting on the hearing I mentioned in my post When FISMA Bites. There following excerpts appear in Lawmakers decry continued vulnerability of federal computers:

The network intrusions at State and Commerce follow years of documented failure to comply with the Federal Information Security Management Act (FISMA), which requires agencies to maintain a complete inventory of network devices and systems. Government and industry officials at the hearing acknowledged a disconnect between FISMA's intent and effecting improved network security.

"The current system that provides letter grades seems to have no connection to actual security," said Rep. Zoe Lofgren, D-Calif. (emphasis added)

WOW -- does Zoe Lofgren read my blog?

Some lawmakers are considering whether the Department of Homeland Security should be given primary responsibility for overseeing federal network security, but officials at DHS and elsewhere suggested that wouldn't be the best idea. Noting that DHS has not performed well on the annual FISMA report card and has not implemented all of the recommendations put forth for improved analysis and warning capabilities for attacks, Greg Wilshusen, director of information security issues at the Government Accountability Office, said it would be problematic from an organizational standpoint to put DHS in the position of compelling other agencies to comply.

I agree DHS is not in a position to defend the entire Federal government, but centralized network security is a good idea when skilled defenders are in short supply and high demand. It's clear that some agencies are not capable of defending themselves, while others do a better job. Perhaps a "center of excellence" model might work, where an agency with a very good monitoring team might watch the entire network. Another agency with a very good red team might assess the whole network, and so on.

Further news about the State intrusion appears in Response to May-July 2006 Cyber Intrusion on Department of State Computer Network and State Department got mail -- and hackers.

It's important to note that State was compromised by a zero-day, and a patch from Microsoft took eight weeks to be appear.

The article Intruders infect 33 US government computers with Trojans talks about a compromise an the Department of Commerce:

[T]he cyberintrusion affecting the Commerce Department's Bureau of Industry and Security systems was first noticed last July, when a Bureau of Industry and Security deputy under secretary reported being locked out of his computer. An investigation showed that the system had been compromised and someone had installed malicious code on it that was causing it to make unauthorised attempts to access another computer on the bureau's network...

Investigations also showed that the infected system had attempted to access two external IP address[es] after business hours when the computer was no longer being used...

Over the next 10 days or so, investigators at Bureau of Industry and Security noticed about 10 other computers making similar attempts to connect with suspicious IP addresses. By 18 August, 32 the bureau systems and one non-bureau system had tried to communicate with at least 11 suspicious IP addresses...

To date, an analysis of the forensic data has shown no evidence that information was actually stolen, despite the compromises, Jarrell said. At the same time, it remains unclear just when the first breach occurred or for how long intruders might have had access to the Bureau’s systems.

That's interesting. The initial incident is found through non-technical means ("Hey, my PC no workie!") but extrusion detection would have noticed the outbound connections. If BIS had been collecting session data they would have known when the first attempt to access those external IPs occurred, thereby helping to scope the incident.

Read More

When FISMA Bites

After reading State Department to face hearing on '06 security breach I realized when FISMA might actually matter: combine repeated poor FISMA scores (say three F's and one D+) with publicly reported security breaches, and now Congress is investigating the State Department:

In a letter sent to Secretary of State Condoleeza Rice on April 6, committee Chairman Bennie Thompson asked the department to provide specific information regarding how quickly department security specialists detected the attack, whether the department knows how long the attackers had access to the network and what other systems may have been compromised during the attack. The three-page letter also asks the department to provide evidence that it completely eliminated any malicious software the attackers may have planted, as well as documentation of all of the communications between State and the Department of Homeland Security regarding the incident.

I'm going to keep an eye on the Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology to see what is published on these matters. It's ironic that FISMA scores really have nothing to do with State's problems, and no aspect of FISMA can answer any of the questions cited above.

Read More

Remember that TJX Is a Victim

Eight years ago this week news sources buzzed about the Melissa virus. How times change! Vulnerabilities and exposures are being monetized with astonishing efficiency these days. 1999 seems so quaint, doesn't it?

With the release of TJX's 10-K to the SEC all news sources are discussing the theft of over 45 million credit cards from TJX computers. I skimmed the 10-K but didn't find details on the root cause. I hope this information is revealed in one of the lawsuits facing TJX. Information on what happened is the only good that can come from this disaster.

It's important to remember that TJX is a victim, just as its customers are victims. The real bad guys here are the criminals who compromised TJX resources and stole sensitive information. TJX employees may be found guilty of criminal negligence, but that doesn't remove the fact that an unauthorized party attacked TJX and stole sensitive information. Unfortunately I believe the amount of effort directed at apprehending the offenders will be dwarfed by the resources directed at TJX. That will leave those intruders and others like them to continue preying on other weak holders of valuable information.

Update: At least US credit card holders don't have it as bad as our friends in the UK.

Read More

When Lawsuits Attack

I haven't said anything about the intrusions affecting TJX until now because I haven't felt the need to contribute to this company's woes. Today I read TJX Faces Suit from Shareholder:

The Arkansas Carpenters Pension Fund owns 4,500 shares of TJX stock, and TJX denied its request to access documents outlining the company's IT security measures and its response to the data breach.

The shareholder filed the lawsuit in Delaware's Court of Chancery Monday afternoon under a law permitting shareholders to sue for access to corporate documents in certain cases, The Associated Press reported. The pension fund wants the records to see whether TJX's board has been doing its job in overseeing the company's handling of customer data, the news agency said.

Imagine having your security measures and incident response procedures laid bare for everyone to see. (It's possible there might not be anything to review!) How would your policies and procedures fare?

The following sounds like many incidents I've investigated.

The TJX breach was worse than first thought, TJX officials recently admitted. The company initially believed that attackers had access to its network between May 2006 and January 2007. However, the ongoing investigation has turned up evidence that the thieves also were inside the network several other times, beginning in July 2005.

Originally the company was compromised for nine months, but now the scope could reach almost a year prior. The question is whether this is evidence of compromise by another group or the same group. In either case the company's security posture looks terrible.

The sad part about this sort of incident is that most if not all of the preventative systems TJX might have applied are worthless for response and forensics. I'm guessing TJX is relying on host-centric forensics like analysis of MAC times of files on artifacts on victim servers to scope the incident. I bet TJX is paying hundreds of thousands of dollars in investigative consulting right now, beyond the damage to their brand and other technical and financial recovery costs.

Hopefully these lawsuits will shed some light on TJX's security practices so other companies can learn from their mistakes. This is the sort of incident that my future National Digital Security Board would do well to investigate and report.

Read More

Zone-H Explains Defacement

Web site defacement mirror Zone-H posted a revealing report on the recent defacement of their own site. The intrusion resulted from a combination of human and technical failures.

The moral of the story is that anyone can be compromised, because the attacker has the initiative. The attacker is usually more motivated and has more time, and resources than the defender. In a world where anyone can be compromised, there is no excuse for not monitoring and preparing for incident response. Every digital resource is a future victim.

The "solution" to intrusions is analog: arresting the intruders. It is not technical.

Read More

Security, A Human Problem

I don't play Second Life or any video games these days. If I had the time I would play Civ IV. Neverthless, virtual worlds like SL are becoming increasingly interesting, as demonstrated by today's attack of the killer rings (pictured at left), also known as a "grey goo" attack.

This comment in the accompanying Slashdot post explains that it's possible for a rogue user to exploit vulnerabilities in Second Life and introduce code that peforms a sort of denial of service attack on the game. The attack occurs when game participants decide to interact with the gold rings shown in the thumbnail from this site. It's similar to human penetration testers leaving USB tokens or CD-ROMs at a physical world place of business and waiting for unsuspecting employees to see what's on them.

This story illustrates two points. First, it demonstrates that client-side attacks remain a human problem and less of a technical problem. Second, I expect at some point these virtual worlds will need security consultants, just like the physical world. I wonder if someone could write a countermeasure at the individual player level for these sorts of attacks?

Update: Here's a YouTube video.

Read More

Israeli Incident Response Report

Incident responders from Beyond Security published an interesting report (.pdf) explaining their involvement in a recent defacement of an Israeli Web site. I read the report but was surprised to not see any mention of shutting down access to the Web site upon discovering the intrusion. There was no question of compromise -- the image above shows what happened to the Web site. Consider the following excerpt from the report.

[T]he web site in question was defaced by Team Evil and action had to be taken immediately. There was no time to perform a full forensic investigation. What the attacked organization required was a real-time forensic analysis of the attack in order to contain damage and respond accordingly, with the following operational goals in mind:

1. Stop the continuing damage being inflicted as soon as possible by kicking out the attackers who were damaging the site while analysis was done.

2. Prevent further access from the attackers.

3. Determine what hole the attackers used to get in, and seal it.

While these goals are sequential, they had to be done simultaneously to be successful as the attackers were at the same time performing counter-measures and attacking back.

It was a fight between the attackers who were already in the system, and the incident response personnel on the ground with the help of the local system administrator.

"No time" for a forensic investigation? Try shutting down the Web server's switch port. It sounds like the intruders were active while the IR team worked:

While examining the second web GUI tool we noticed that there was currently a user trying to use the exploit. At this stage we no longer had a system administrator present, nor access to the attacked machine. (emphasis in original)

Again, shut down the switch port. Is this the "uptime argument?" Who needs uptime when the public is visiting a defaced Web server?

No wonder the intruders were active -- the defenders were visiting a potentially hostile Web site:

We soon located the tool on the web page... Looking at their site provided another clue.

If the victims were visiting an intruder's Web site during the incident response, that's an easy way to tip off the attackers that defense is taking place.

Finally, observe how the IR team finally tried to take control of the victim:

Left with no other alternative and the organization's approval, we used the intruders' web GUI tool to retrieve the MySQL password and used it to get into the forum database and escalate the permission of a user under our control to an administrator status (probably like the intruders themselves have done...).

Use an intruder's tool to remove the intruder? Wow.

IR is certainly a fluid experience, but I think some basic rules were violated during this scenario. Still, I'm very happy to see Beyond Security share its story. The report itself contains a ton of technical details and I highly recommend everyone read it. It's been a while since I've read anything like it.

Read More

One Thought on State Department Incidents

I have absolutely no special knowledge of this event. All I know I've learned from stories like this. The following caught my eye:

The department also temporarily disabled a technology known as secure sockets layer, used to transmit encrypted information over the Internet.

Hackers can exploit weaknesses in this technology to break into computers, and they can use the same technology to transmit stolen information covertly off a victim's network.

Many diplomats were unable to access their online bank accounts using government computers because most financial institutions require the security technology to be turned on. Cooper said the department has since fixed that problem.

So DoS (heh, pun intended) disabled outbound HTTPS? It sounds to me like the intruders used a HTTPS covert channel (not so covert, actually) to communicate with their victims. I think we are getting to the point where encrypted outbound HTTP will have to terminate on a proxy server that permits inspection or at least logging of the HTTP action. The proxy will then establish its own connection with the remote HTTPS server.

Yes, (1) this breaks end-to-end HTTPS; (2) users will probably have to accept an unexpected SSL certificate; (3) this will undermine any training they may have received to avoid connecting to the uber hacker at https://www.paypa1.com. However, to have any shot at identifying these connections in a timely manner, inspection of clear text at the network perimeter is a must. (What perimeter? It's the line between what you own/control and what you don't.) Not being able to do this probably hurt the DoS.

Read More

Details on Freenode Incident

If you're looking for details on the Freenode incident, check out Regular Ramblings. This single Slashdot post claims Ettercap was involved. I was online at the time as well.

Read More