Tuesday, April 21, 2009

Tor Website blocked at My Hotel

picture-2

My hotel uses OpenDNS to block access to the Tor website. Google Translate is also blocked. They are categorized as "Proxy/anonymizer". This is one of the most annoying things about filtering. I just wanted to quickly translate some text from Russia to English and then read the Tor blog and ....

picture-1

Yes, in order to block the Tor Blog, which uses HTTPS, they are MITM'ing SSL. (If you accept the bad certificate, the Tor Blog is blocked.) It doesn't look like they are MITM'ing *all* SSL but just connections to selected IP addresses.

It's funny, because I often recommend OpenDNS to people in order to avoid filtering, but OpenDNS also has a filtering service.

Monday, April 13, 2009

When Hype is the Threat

Articles like this are very irritating. They are short of detail and long on hype. And when that hype focuses on the wrong threat, it becomes the threat itself.

This WSJ article is a typical case. These stories are not new and the pop up from time to time usually focused on Russian or Chinese hackers -- and in this case some unholy alliance of both (I'm surprised that Al Qaeda wasn't thrown in to this "Haxis of Evil" :)) Some have suggested that the article was planted for political purposes but, regardless, the hype seems to focus on the wrong threat.

Since there are no details in the article the author attempts to use an example to hype the threat: the infamous Australian sewage example. However, this just proves the overall uselessness of the entire article.

First, the "sewage hacker" case was an inside job. The attacker was "employed by the company that had installed the system" that he later "hacked". Second, he had specialized knowledge of the system (related to his "insider" status):

After a brief police pursuit from the Sunshine Coast towards Brisbane, Boden was run off the road. In his car was the specialized proprietary SCADA equipment he had used to attack the system, and a laptop; however, it was a piece of $18 cable that ultimately led to his downfall.

Grounds for charges were slim, but the handmade cable showed he had the technical capability to hack the Scada system.

The laptop found in his car contained enough messages to prove he sent commands to disrupt various pump stations and that, combined with proprietary radio equipment and specialized cable, was enough to find him guilty of what has been dubbed the first case of critical infrastructure hacking in Australia.


Third, the attack did not occur over the Internet.

"We worked out he had to be within a 25-mile radius, but one night we had not seen any evidence of hacking until he came on about 6.30 a.m. We had private investigators put cars along all the bridges and overpasses from the Sunshine Coast to Brisbane, because we knew the description of his car and knew he would be driving past. The investigators waited until they saw him on the highway and contacted police to intercept the car.

"When police went to intercept him, he did a runner; the police then ran him off the road and found a car full of proprietary gear. No one had seen him hack our systems, but from his laptop we were able to find the last recorded event and messages sent which exactly matched our SCADA radio monitoring systems."


So, following the logic in the WSJ article the Chinese and/or Russian hackers would have to drive (can you do that over the Internet?) to within 25 miles of their targets -- after having previously been employed by them -- in order to conduct their attacks.

Now, the point here is not to diminish the threat of attack against critical infrastructure but to point out that the hype-based approach ends up bringing focus on the wrong kinds of threats. By focusing on external Internet-based threats (that may or not really exist) the focus on the insider threat is lost.

In many cases the insider threat is of more importance than an external, Internet-based threat (especially when such systems are *not* connected to the Internet). A recent case concerning an oil platform is yet another example:

A Los Angeles federal grand jury indicted a disgruntled tech employee Tuesday on allegations of temporarily disabling a computer system detecting pipeline leaks for three oil derricks off the Southern California coast.


In an old Gartner exercise, a team was given $200 million, access to state-level intelligence, and five years to plan attacks. Even though this study is old, I like it because the scenario gives the attackers significant resources as opposed to many that simply rely on "hackers" from X or Y countries. They also divided the team into various groups focusing on different parts of critical infrastructure.

The telecommunications disruption team team suggested that requirements for a successful attack would include working knowledge of telecommunications systems, PHD level education, specific product knowledge of targets and insider assistance. They suggested that it would have large resource requirements and be fairly expensive. As can be seen in an overview by The Register, bribes and insiders play an important role:

With that said, it's nevertheless clear that a fair amount of mischief can be brought about by a large, well-funded technical dream-team. Telecomms group member Fraley reported that it's possible to cause SS-7 (Common Channel Signaling System #7) and PSTN (Public Switched Telephone Network) capacity to collapse for a brief period. However, it would take a very large investment in both personnel and money (bribes, presumably) to accomplish even that much. Perhaps 200 people would be needed, he reckoned. A satchel bomb thrown down a manhole in Manhattan would be far easier, far cheaper, and still fairly destructive, he remarked.


In fact there was a case just recently in which attackers "killed landlines, cell phones and Internet service for tens of thousands of people" and "froze operations in parts of the three counties at hospitals, stores, banks and police and fire departments that rely on 911 calls, computerized medical records, ATMs and credit and debit cards." How? By cutting the fiber optic cables (which would be hard to do via the Internet in Russia or China).

Insiders are also required to exploit SCADA systems:

As for the power grid, it's national, and controlled by large, complex SCADA (Supervisory Control and Data Acquisition) systems. Still, it's only feasible to target a large metropolitan area, team member John Dubiel noted. Attacking the entire grid would be quite impractical. The best approach would be physical attacks on major transmission corridors, all of which are well-known, followed by the malicious use of owned control systems to to create a pattern of cascading failures throughout the target region. "At this point the system is attacking itself," he observed. Finally, one would attack and damage the SCADA systems themselves to hamper recovery efforts.

It's possible to launch remote attacks against some SCADA systems connected to public infrastructure, but insiders would have to be recruited to attack others, he added.


In many cases the focus on protecting critical infrastructure needs to be placed on the physical infrastructure, the "insider threat" and very often on *basic* Internet security practices. (Such as changing default passwords). When the emphasis shifts away from such threats to focus on hype and hazy allegations that may or may not be politically motivated the hype itself becomes the threat. Rather than deal with emerging security problems the emphasis is placed on building a "cyber-Maginot Line" without an accurate articulation of the nature of the threat.

GhostNet & CasperNet

DarkVisitor picked up on some information in the GhostNet report that we didn't really focus on -- the email addresses and other information in the domain name registration records -- and were able to track down the owner of the email address listed in the registry information associated with the control servers www.lookbytheway.net and www.macfeeresponse.org. An infected computer at the OHHDL connected to these domain names and Greg and Shishir were able to observe sensitive documents being transmitted to www.macfeeresponse.org while collecting data in Dharmsala, India. Greg later found that a computer at the Tibetan NGO Drewla aslo connected to www.lookbytheway.net. Both these domains were registered to “zhou zhao jun” using the email address losttemp33@hotmail.com. (I recall Greg and Jaymz working on this for a time, but I think we lost focus when we found the web-interface to the control servers used by a different piece of malware that had infected a computer at the OHHDL which we dubbed GhostNet.)

In a fascinating post, The folks at DarkVisitor were able to track down the owner of that email address as well some forum posts and blog entries that allowed them to acquire the QQ id of the owner of the email address and initiate contact with him. It was really great to see DarkVisitor explore this further.

I'd been calling this malware family "CGI" after their use of CGI scripts, but I like the DarkVisitor's "CasperNet" better.

In addition to a GET request that appears to be a simple "check in" there were some POST connections:

www.lookbytheway.net - 221.5.250.98
- POST /cgi-bin/Report.cgi HTTP/1.1
- POST /cgi-bin/serverlog.cgi HTTP/1.1

These also appear to be "check ins" -- the connections to serverlog.cgi are 15 bytes and contain basically the same information that appears in the GET requests. The connections to Report.cgi are larger (104 bytes) and contain some binary data in addition to text that is similar to the other connections. All these connections occur with a high degree of frequency.

www.macfeeresponse.org - 218.241.153.61
- POST /cgi-bin/Auto.cgi HTTP/1.1
- POST /cgi-bin/AutoTrans.cgi HTTP/1.1

There are significantly fewer connections to the this server and its function appears to be directly related to the retrieval of documents from infected computers. The POST connections to Auto.cgi contain a file name and the command "@@@@begin" which is followed by a POST to AutoTrans.cgi which actually uploads the targeted document. After several connections the entire document is uploaded and another POST is issued to Auto.cgi with the command "@@@@end".

The packet dumps we analyzed showed two documents being uploaded and according to the person using the infected computer one of these documents was related to the Dalai Lama's negotiating position with China and the other contained a list of numerous email addresses.

One of the things I really like about the DarkVisitor investigation is that it reminds us to be careful on the question of attribution. There are a variety of actors operating in this space with a variety of motives. Individuals and groups may be engaging in systematic exploitation of political targets for a variety of reasons that are completely divorced from state intelligence services (even if they appear to be aligned with such interests).

The fact that the DarkVistor research points to the possibility that the CasperNet is the work of a "cracker" (I prefer this definition of "hacker"), and not the Chinese Government as the context alone might suggest, simply shows the complications of attribution. There are numerous scenarios a variety of which we explore in "Tracking GhostNet" that focus on the "privateer" model but there are others as well. An intelligence agent could be tasked compromising political targets using only the tools and methods available within the community. Conversely, attackers may pillage compromised machines for credit card numbers, lists of email addresses to conduct further social engineering attacks as well as politically sensitive information that can be sold.

This is the "attribution problem". Rather than rely on unconfirmed anecdotes and unnamed sources, political context and speculation and/or the fact that control servers are hosted on IP addresses in ranges assigned to China to produce a "smoking gun" pointing at the Chinese government we included a section focused on "alternative explanations" in order to explore variety of scenarios. As noted above, these alternative explanations, even those that focus on the acts of private individuals and groups, do not necessarily absolve the Chinese government but they provide an honest analysis of the variety of possibilities.

Tuesday, April 7, 2009

Symantec & GhostNet

Symantec has put out a nice video demonstrating how gh0stRAT works. We gave the name "GhostNet" to the network of infected computers we uncovered because of the attackers' use of the gh0stRAT tool but it is important to bear in mind how the whole operation works as gh0stRAT is just one part of it.

One of infection vectors that we can confirm that the attacker uses is sending contextually relevant emails with malware packed attachments (.doc's and .pdf's) to potential targets. (If you are interested check out Maarten Van Horenbeeck's work here here and definitely here -- it really is the best research on this stuff out there).

When the the attachment is opened a trojan is dropped on the system. This trojan "checks in" with a control server. In this case, it was an HTTP connection to a webserver. The infected computer retrieves various files from the control server some of which contain "commands" -- one of the commands the attacker issues instructs the infected computer to download and install gh0stRAT. While gh0stRAT allows the attacker to take "real time" control of a compromised computer -- the attacker is online and the victim is online at the same time. -- the initial infection allows the attacker to maintain control when either party is offline.

Once infected with gh0stRAT the compromised computer connects out to a URL (a file on the control server) in order to retrieve the IP address of the attacker's gh0stRAT client. When the attacker is offline, the IP will often be 127.0.0.1 and will be replaced by another IP when the attacker is online and ready to receive connections from the compromised computers running gh0stRAT.

This Symantec video shows how gh0stRAT works.



Also, check out this post at F-Secure.

GhostNet Update

Starting on March 30 2009 the GhostNet starting coming down. The attacker began removing the files and directories being used and then began to configure the domain names of some the control servers to point to 127.0.0.1. Files hosted on other (probably compromised) "command" servers also started disappearing at the same time. It'll be interesting to see if, when and where the network pops up again.