Inside Cyber Warfare Part 15

In the face of such lengthy and complex negotiations, a tiny DoS attack that lasted for only a few days hardly seems like an instrument of Kremlin policy in this particular case.

In addition to these two possible explanations, a third may be a dispute between competing ISPs operating within the country. This possibility was recently presented to the author by a colleague who visited Kyrgyzstan and spoke personally with the parties involved.

A final lesson on the Kyrgyz DoS attack of 2009 is the value of alternative a.n.a.lysis, particularly on all questions of attribution.

[37] http://www.cisco.com/en/US/docs/internetworking/technology/handbook/bgp.html.

Team Cymru and Its Darknet Report.

"Who is looking at your SCADA infrastructure?" a briefing paper that Team Cymru published in early 2009, looks at scans that they spotted in a region of cybers.p.a.ce where such scans should not have been occurring (i.e., no active services or servers reside there) and therefore any activity or traffic is deemed malicious to some degree. They referred to this region as a "darknet." As explained in the briefing paper, "Traffic entering a Darknet normally comes from scans generated by automated tools and malware, looking for vulnerable ports with nefarious intent." These ports belong to Supervisory Control and Data Acquisition (SCADA) systems.

SCADA systems are typically used by utility companies, nuclear power plants, water treatment systems, communications systems, and various industrial processes. Although these systems do have safeguards, they remain vulnerable to a variety of cyber attacks for a number of different reasons. A complicating factor in safeguarding them is the antiquity of the software employed, in some cases dating as far back as the 1970s. More modern SCADA software has updated security, but it relies on the public Internet. Generally speaking, attackers will scan for vulnerabilities and tailor their attacks based on what they find.

Team Cymru researchers recorded the IP addresses of the machines generating these port scans and identified a geographical location for each using traceroute (see Figure 9-4): USA.

The two main hotspots for scanning appear to emanate from IPs located in Houston, Texas, and Miami, Florida.

Western Europe There are hotspots in London, United Kingdom, Seville, Spain, and locations in Scandinavia and Southern France.

Eastern Europe Hotspots in this region include St. Petersburg and Moscow, as well as a location in the Ukraine and Bucharest, Romania.

Far East By far the most concentrated grouping of hot spots, the Far East contains concentrations of SCADA-scanning IPs in Thailand, Hong Kong, Taiwan, Korea, j.a.pan, and several locations in China.

The authors of this report believe that the scans are being generated by infected computers, hence the geolocation of scanning IPs should not be construed as evidence of espionage activities by a foreign government or nonstate actor from that region. The preceding information refers to scans of the following SCADA-a.s.sociated ports: udp/20000, tcp/502, udp/2222, and tcp/44818.

Figure 9-4. Geographic origins of darknet scans for 2008.

Using WHOIS.

Any time an individual or company seeks to register a URL, they are legally required to provide accurate identifying data (name, address, contact information). This is an ICANN requirement and is enforced by many of the legitimate providers of domain registration services. Unfortunately, not all providers perform their watchdog duties as well as they should, including ICANN itself (although their rate of fraudulent registrations has decreased recently).

In the case of StopGeorgia.ru, the domain was registered to an alias that appeared on numerous spam sites (see Chapter 7). This works well with domain registration services that do not perform verification checks on all new applications. Unfortunately, there are a number of companies that regard lax registration as a fair trade-off for an increase in sales revenue. This is a critical part of the puzzle for criminal enterprises operating on the Internet.

In other cases, domains are registered with stolen data. In one case that was reported to me, the stolen data was from a US serviceman deployed in Iraq. When he returned to the United States at the end of his tour, he was contacted by his service's investigative division in reference to his "terrorist" website. The investigation was dropped once it was determined that his ident.i.ty had been stolen and used to register the domain name; however, that determination didn't happen in a timely manner and caused quite a bit of consternation on the part of the serviceman and his family.

Nevertheless, checking WHOIS registrations does provide another link in the evidence chain. Sometimes mistakes are made and actual government websites are used as the identifying data (e.g., GhostNet). This is rare, but it does happen. Part of any OSINT investigation is looking for the small oversights that even the most careful individuals make from time to time.

The Cambridge University investigation of the Chinese espionage operation against the Office of His Holiness the Dalai Lama (OHHDL) underscores the value of checking WHOIS data: During our initial network monitoring exercise, we observed sensitive files being transferred out of the OHHDL using a modified HTTP protocol: the malware picked up files from local disks and sent them to three servers which, according to APNIC, were in China's Sichuan province, using a custom protocol based on HTTP. The malware uses HTTP GET and HTTP POST messages to transfer files out and also appears to verify successful transmission. Sichuan, by the way, is the location of the Chinese intelligence unit specifically tasked with monitoring the OHHDL.

Note.

WHOIS information can be checked with numerous free online Internet toolkits, such as http://www.dnsstuff.com, http://www.robtex.com, http://www.demon.net/external/, and http://www.whois.sc, simply by entering either a domain name (sans the "www") or an IP address.

Caveats to Using WHOIS.

There are numerous caveats to using WHOIS in an investigation.

The information contained on a cyber warfare, extremist, or hacker website will most likely be stolen, fraudulent, or garbled. Even legitimate registrants may elect to use a privacy service to mask their WHOIS information.

Another caveat is that multiple websites may be hosted on the same server and yet have nothing to do with one another.

In spite of these issues, an investigation into WHOIS information still may provide pieces of a larger puzzle. The following are some tips that might prove useful when investigating other attack platforms similar to StopGeorgia.ru that engage in cross-border cyber attacks: If the data is clearly fraudulent (garbled or nonsensical name and address info), it is not a legitimate site.

If the data appears to be legitimate but a web search on the name and email address shows it was used to register numerous blacklisted websites, then again, it is not a legitimate site.

If, as in the case of Innovative IT Solutions Corporation (the hosting company for the StopGeorgia.ru domain), the data is accurate, the next step is to perform a web search on the business address.

If multiple businesses are registered at the same address, it is most likely a mailbox rental facility, and chances are the business is a front for other purposes.

If the business location is adjacent to a government office or, even better, a Ministry of Defense office (as was the case with Steadyhost.ru in Chapter 7), you have secured another piece of the investigative puzzle.

Chapter 10. Weaponizing Malware.

A New Threat Landscape.

There are so many emerging threats to computer networks that a detailed overview of them is beyond the scope of this book. Instead, this chapter addresses various modes of attack that have been used in cyber warfare and espionage, as well as a few new innovations that seem particularly perilous to high-value targets such as SCADA systems or cla.s.sified networks within the defense industry (both government and contractor systems).

StopGeorgia.ru Malware Discussions.

A significant portion of the discussion on the StopGeorgia.ru forum was dedicated to traditional (distributed denial of service) DDoS tactics and tools, but more interesting tactics discussed there focused on abusing application-level vulnerabilities in order to take advantage of CPU-intensive stored SQL procedures.

By abusing CPU-intensive application-level vulnerabilities (such as with SQL injection), Georgian information systems can be rendered inoperative using a small number of attacking machines. Whereas traditional DDoS attacks against robust websites can require thousands of bots simultaneously attacking the victim server, exploitation of SQL injection vulnerabilities require only a handful of attacking machines to achieve the same effect.

The discovery and exploitation of these application-level vulnerabilities shows moderate technical sophistication, but more importantly, it shows planning, organization, targeted reconnaissance, and evolution of attacks.

The introduction of SQL injection attacks in conjunction with DoS attacks is alarming for many reasons: SQL injection attacks could indicate that all data stored in the backend databases could have been pilfered or altered. This information could be used as a foundation for further attacks and intelligence gathering against related web applications.

Attackers who have pilfered the backend databases via SQL injection could have access to legitimate username and pa.s.sword combinations, allowing them to masquerade as legitimate users, providing a sustained source for intelligence gathering. This is especially alarming for .gov.ge systems, where pa.s.sword reuse or other vulnerabilities could lead to the compromise of other sensitive systems or loss of sensitive information.

In some cases, SQL injection attacks can be used to compromise not only information stored in backend databases but the machine hosting the database. This represents a compromise of an organization's internal infrastructure.

Once the underlying system is compromised, it can be used as a stepping stone for further attacks against an organization's internal network. Considering the poor state of internal network security for most organizations, a moderately sophisticated attacker could use a compromised database server to gain access to a considerable amount of internal information. Once again, this is especially alarming for .gov.ge systems or applications that could have access to other sensitive systems.

Finally, detection of a targeted SQL injection attack designed to pilfer data or compromise the underlying system during a rigorous, traditional DDoS attack would be extremely difficult to detect, especially if it included SQL injection attacks designed to cause a DoS condition.

SQL injection, blind SQL injection, and using BENCHMARK

SQL injection is an attack technique that takes advantage of poor secure-application coding practices. If an application does not provide the correct validation for user-supplied input parameters, an attacker could embed SQL commands within the parameters pa.s.sed from the web application to the backend database.

The result is that the attacker can execute arbitrary SQL queries and/or commands on the backend database server, using the web application as the delivery mechanism. SQL injection is a critical application issue and typically results in the loss of all the data stored within the database and a compromise of the system housing the database. Additional information on generic SQL injection attacks can be found at http://www.owasp.org/index.php/SQL_injection.

If a hacker discovers a SQL injection vulnerability on a website, but the SQL injection does not return any readable data, this is known as "blind" SQL injection. The blind SQL injection vulnerability executes an attacker-controlled SQL query on the backend database with no indication as to whether the injected query actually succeeded or failed.

Hackers turned to the BENCHMARK stored procedure (for SQL injection against MySQL databases) to get some indication as to whether their injected SQL query succeeded or failed. By including a Boolean clause (true or false) in the blind SQL injection, the hacker can craft a SQL injection in such a fashion so that if the query is successful (and only if it is successful), the database runs the BENCHMARK query.

The BENCHMARK queries chosen by the hacker are CPU-intensive, typically crypto functions run thousands of times. Since these CPU-intensive BENCHMARK queries take time to complete, the backend becomes "stalled" until the BENCHMARK is completed. If the hacker launches the blind SQL injection with a CPU-intensive BENCHMARK and the application "stalls" for a few seconds before displaying the page, the hacker knows the SQL injection was successful. Conversely, if the attacker launches the blind SQL injection with a CPU-intensive BENCHMARK and the application immediately displays the page, the hacker knows the SQL injection was not successful.

Visit http://www.milw0rm.com/papers/149 for more information about using the BENCHMARK stored procedure for blind SQL injection. It's interesting to note that the hacker who wrote the tutorial is trying to reduce the CPU load involved with BENCHMARK usage in order to avoid detection/server-performance issues.

Now, the specific techniques suggested in the StopGeorgia.ru forum were a new twist on those for typical SQL injection vulnerability exploitation. Some posters to the forum suggested the using the BENCHMARK stored procedure to consume ma.s.sive amounts of CPU cycles on the backend database. BENCHMARK has been a popular technique for blind SQL injection, but using it to intentionally cause a DoS is rare.

The forum suggested that attackers use SQL injection vulnerabilities to call a CPU-intensive task (built-in crypto functions) for the backend database to execute hundreds of thousands of times. One post suggested that nested BENCHMARKs be used, each running 100,000 times (that equates to 100,000 100,000, or about 10,000,000,000 times)! These queries would simply consume the CPU for the system hosting the database (often it's the same machine as the web server).

By using BENCHMARK, a single web request can cause a significant load on the database server, and in most cases a single machine can render the database server inoperative. Specific SQL injection points were identified on the forums, as well as observed in collected web server logs. SQL injection was undoubtedly used in attacks against Georgia servers.

Note.

The BENCHMARK stored procedure is specific to MySQL databases, but other popular databases have similar functionality. Other specific techniques mentioned in both forums for bringing down or gaining illicit access to machines included: Regularly checking the status of a host through ping -t -i Using SQL injection through an improperly sanitized query string Brute-force attacks Social engineering to gain pa.s.swords

Twitter as DDoS Command Post against Iran

The mid-June 2009 Iranian elections were so flawed that opposition protests, fueled by harsh Iranian government treatment against protesters, overflowed onto the Internet, creating a wave of instant support for the protesters and fury against the Iranian government after Iranian president Mahmoud Ahmadinejad defeated rival Mir Hussein Moussavi in a contested election.

Official Iranian filtering targeted news media of all types, so Iranian dissidents turned to posting photos and videos on Internet sites such as YouTube and various blogging platforms. Protests, when interrupted by Iranian police, turned violent, and within a few days eight fatalities were reported.

The coordinating medium for this outrage was none other than Twitter, the microblogging service that has defied attempts by journalists, politicians, and comedians to categorize it as a tool of the self-absorbed.

In fact, Twitter has proven its value as a real-time reporting service in crisis environments, for example, Mumbai during the November 2008 terrorist attacks. In the Iranian crisis, the Twitter platform was used by Iranians upset with the election results that showed the current President achieving a landslide victory.

Links to automated DDoS tools were circulated, along with recommended target websites. For example, Jose Nazario wrote on his blog Security to the Core: Here's a peek at one such script [Figure 10-1], using the "page reboot" site as a basis for the tools. Page reboot uses a very simple method, namely use Javascript to reload the URL in the page repeatedly. The browser will happily do so, just like the user was sitting there hitting F5 in their Internet Explorer. This can cause some stress on the attacker's specific machine, reveals their IPs through the HTTP connections, and is trivial to filter, but is growing in popularity.

Figure 10-1. IFRAME elements embed a remote page into a local page In this case someone's put together a single page of HTML with multiple "IFRAME" elements which embed the remote page into the local page. This is a simple magnifier of the local site's effect but has the effect of diminishing results: the attacker's machine slows down for all attacks as it loads them and consumes more bandwidth as it loads all of the pages again and again.

A Norwegian journalist created a "Cyberwar Guide for Beginners" that provides guidance in a number of areas of interest to the global online community who is watching events unfold and wants to do something to help: The purpose of this guide is to help you partic.i.p.ate constructively in the Iranian election protests through twitter: Do NOT publicise proxy IP's over twitter, and especially not using the #iranelection hashtag. Security forces are monitoring this hashtag, and the moment they identify a proxy IP they will block it in Iran. If you are creating new proxies for the Iranian bloggers, DM them to @stopAhmadi or @iran09 and they will distributed them discretely to bloggers in Iran.

Hashtags, the only two legitimate hashtags being used by bloggers in Iran are #iranelection and #gr88, other hashtag ideas run the risk of diluting the conversation.

Keep your bull$hit filter up! Security forces are now setting up twitter accounts to spread disinformation by posing as Iranian protesters. Please don't retweet impetously, try to confirm information with reliable sources before retweeting. The legitimate sources are not hard to find and follow.

Help cover the bloggers: change your twitter settings so that your location is TEHRAN and your time zone is GMT +3.30. Security forces are hunting for bloggers using location and timezone searches. If we all become 'Iranians' it becomes much harder to find them.

Don't blow their cover! If you discover a genuine source, please don't publicise their name or location on a website. These bloggers are in REAL danger. Spread the word discretely through your own networks but don't signpost them to the security forces. People are dying there, for real, please keep that in mind.

Denial of Service attacks. If you don't know what you are doing, stay out of this game. Only target those sites the legitimate Iranian bloggers are designating. Be aware that these attacks can have detrimental effects to the network the protesters are relying on. Keep monitoring their traffic to note when you should turn the taps on or off.