Who Needs a Botnet if you Have Google?

Abstract

Botnets have become a growing threat to networked operations in recent years. They disrupt services and communications of vital systems. This paper, gives an overview of the basic anatomy of a Botnet and its modus operandi. In this paper, we present a Proof of Concept of how Google gadgets may be exploited to achieve these basic components of a Botnet. We do not provide a full fledged Botnet implementation but merely to mimic its functionality through Google Gadget API. Our goal was to have Google act as proxy agent to mask our attack sources, establish Command and Control structure between Bots and Botherders, launch attacks and gather info while at the same time maintaining some degree of stealth as to not be detected by users. [PUBLICATION ABSTRACT]

Headnote

Abstract: Botnets have become a growing threat to networked operations in recent years. They disrupt services and communications of vital systems. This paper, gives an overview of the basic anatomy of a Botnet and its modus operandi. In this paper, we present a Proof of Concept of how Google gadgets may be exploited to achieve these basic components of a Botnet. We do not provide a full fledged Botnet implementation but merely to mimic its functionality through Google Gadget API. Our goal was to have Google act as proxy agent to mask our attack sources, establish Command and Control structure between Bots and Botherders, launch attacks and gather info while at the same time maintaining some degree of stealth as to not be detected by users.

Keywords: Botnet; Google Gadget; Command and Control; DDoS

1. Introduction

A Botnet is a collection of compromised computers or agents that are infected by malware. These agents use sophisticated command and control techniques to execute complex and distributed network attacks. Agents are usually unaware that they have been compromised and are partaking in these attacks. They are often controlled by an external agent known as Botherders or master agents (Banks 2007, Vamosi 2008).

According to Steward (in Vamosi, 2008), the techniques used by large Botnets such as Storm are available online, but a Botnet is more than the sum of its parts. What makes a Botnet successful is combining all these components into a coherent structure.

Stracener states in (Stracener, 2008), that future malware will run on the internet instead of standalone computers. His premise is that, as the modern computer infrastructure moves closer to a networked cluster or cloud so too will the threats to these infrastructures. He warns of his concerns about malicious gadget and key vulnerabilities related to gadgets. A study conducted by WorkLight Inc. (in MacManus, 2008), found that 48% of internet bank users, ages 18-34, would use secure thirdparty Web 2.0 gadgets for their personal banking, if their banks did not provide them with such functionality. This would imply the users would be able to make a informed decision about what it means to identify a Web 2.0 gadget as being secure.

Stracener's concerns are mimicked by The Cloud Security Alliance in their paper (Hubbard et al., 2010). They identify seven key threats to Cloud computing security:

* Abuse and nefarious use of cloud computing

* Insecure interfaces and APIs

* Malicious insiders

* Shared technology issues

* Data loss or leakage

* Count or service hijacking

* Unknown risk profile

In this paper we demonstrate a rudimentary Botnet construct by exploiting Google services to host our Botnet. We investigate the core components of a Botnet and then attempt to mimic the components using Google Gadget API. It is not the goal of this paper to illustrate the weaknesses in a specific API but rather to illustrate the danger of user generated content on the World Wide Web. Our aim is to proof that online services can be organized into a botnet like structure.

Google Gadgets API is design for rapid development of small web based utility applications such as: calendars, currency converters and news feed readers (Peterson, 2009). By including Open Social API to a Google gadget, one can enhance shared gadget interaction and extend one's gadget to the Social Media domain.

Flaws in Google Gadgets have been demonstrated by Barth et al. (2009). They noted that JavaScript can lead to exploitation. These vulnerabilities include session sharing vulnerabilities which enable Cross-Site Scripting (XSS) and malicious redirects to Man-in-the-middle attacks. Google has been reluctant to fix some of these vulnerabilities since 2004. (Robert 2008)

In Section 2, we investigate the composition of a basic Botnet. In Section 3, we describe our attempt at mimicking these components. In Section 4, we discuss our Botnet model. In Section 5, we propose possible future application of this work. In Section 6, we discuss our conclusion and possible means of stopping these types of Botnets.

2. Anatomy of a botnet

Botnets tend to share communalities in their structure and design. In this Section, we describe the common components of a Botnet as well as their role within the Botnet.

2.1 Command and control component

A large part of a Botnet's success can be attributed to its ability to execute large, synchronized, distributed attacks. This would require sophisticated command and control (C2) structures to coordinate these attacks (Banks 2007, Ollmann, 2009).

Communication channels usually relay herder instructions, such as commands to execute on remote PC. Bots use channels to send back retrieved data such as key logger information or command response information. These communications need to be covert in order to hide the Botnet activities.

Over the years several covert channels have been used to communicate commands between Bot and Botherder such as Twitter, Internet Relay Chat (IRC) and Instant Messages. Several advance C2 techniques such as steganography or social media sites to hide Botnet communication in plain sight.

Next we look at the types of attacks that could be executed by Botnots (Ollmann, 2009)

2.2 Attack vector

Botnets are usually goal orientated. For the most part their goal is either profit or service disruption. There are several means of achieving these goals using botnets. In this Section, we discuss some attacks commonly used by Botnets.

2.2.1 Distributed denial of service attack

Due to Botnet size and the distributed nature of Botnets, Distributed Denial of Service attacks (DDoS) are a popular form of attack (Felix et al., 2005). In this attack the Botherders issue a command to all its subordinate Bots to connect to a targeted system at the same time. The targeted system can usually not handle the sudden influx of requests and which cause system services to be temporarily disrupted. Botherder rent out these services to competitors to disrupt competitor services (Kiefer, 2004).

2.2.2 Spam relay

The first generation of Botnets where reliant on email to spread and infect various hosts. Botnets would open a SOCKS v4/v5 proxy on compromised machines, allowing it to send spam at the request of the Botherder. Botnets also harvested email addresses from infected hosts to add to its spam lists. (Engate, 2009)

2.2.3 Data harvesting

Botnets report back valuable system information to Botherders. This information can include key stroke logs, system vulnerabilities, service availability on host machine, open port data and network traffic. Botherders collect and collate this data to retrieve data such as user names and passwords which could be used for mass identity theft. Botnets scan for system weakness that could possibly be exploited at a later stage if Botnet functionality is compromised in future. By sniffing network traffic Botnets could become aware of rival Botnets infecting host PCs and disrupt these rival Botnet functionality.

2.2.4 Ad serve abuse

Botnets can be utilized for monetary gain. Botnets can be used to exploit the Pay Per Click or Impression Based internet advertising models. By forcing infected machines onto ad serve sites or using iFrames to fool users into clicking on advertisements, Botherdes can generate revenue from marketing companies.

Botherders infect host PC with browser add-ons, Browser Helper Objects (BHO), or browser extensions which changes user browser interaction to relay them to ad serve sites or simply generate brows requests to ad serve sites automatically. These Add-ons can serve a dual purpose, as it can collect user data from browser and relay it to Botherder.

2.3 Viral capability

One of the great strengths of a Botnet is its sheer size. This also makes Botnets so tough to take down. Hence it is essential for a Botnet to spread fast and to vastly distributed systems.

The first generation of Botnets where primarily reliant on email and malicious page redirects to spread. Modern Botnets such as Asprox, Koobface, Zhelatin and Kreios C2 spread via social media (Denis, 2008) (Eston, 2010). The Botnet posts users content on social networks sites which infect any user that follows the malicious links. Some Botnets have been known to hide within popular trusted applications. Trojans drop malicious code in trusted address spaces and exploits weaknesses in hosts PC to compromise it and make it part of Botnet network.

2.4 Stealth component

Botnets are only useful as long as they are not detected. Hence stealth is a fundamental requirement for all Botnets.

It is the opinion of the researchers that stealth is required in each of the components previously identified in this section. If communications are noisy, infected host might become aware of malicious activity and firewalls or intrusion detection systems might block communications. If attack is disruptive, anti-virus companies will detect and block the attack. Mechanisms used to spread Botnets must seem organic and natural for it to be affective. It is the combination of these requirements that make Botnets so difficult to construct and maintain.

In the next section we our attempt at constructing these components using Google Gadgets API.

3. Attempt at constricting a botnet

In this Section, we will discuss our attempt to create a proof of concept Botnet; At first we look at cloud computing as a whole and then more specifically using Google Gadgets API we investigate the possibility of using Cloud computing to mimic the attack components of a Botnet, as presented in Section 2. It is important to note that, this paper is not just specifically targeted towards exposing Google API weaknesses but to illustrate the dangers of user generated content and cloud computing on the World Wide Web.

According to Garner (Garner, 2008), cloud computing can be defined as style of computing whereby IT-related capabilities are provided as a service using Internet technologies to connect to multiple customers. Botnets have already been found using popular cloud such as Amazon's EC2 as a Command and Control unit (Goodin, 2009). In a report compiled by The Cloud Security Alliance, seven types of security threats where identified (Hubbard et al., 2010). Of these seven, we focused on two main attack factors Abuse and nefarious use of cloud computing as well as Insecure interfaces and APIs.

3.1 Establishing denial of service attack capability

The Google Gadget API provides users the capability to load remote content into gadgets by calling, makeRequest() (Google Gadgets API, 2009). This function is asynchronous and can be called independent from other JavaScript calls. This is a fairly useful capability as this allows users to easily create gadget versions of their websites and extend their market reach. This function instructs one of the servers residing on the Google Gadget Domain to perform an HTTP request on behalf of the gadget user, as illustrated in Figure 3: makeRequest() HTTP request flow. This implies that the request source is obfuscated and that only the Google Gadget Server IP address will appear in the remote server logs. By exploiting this communication structure one can use Google Gadget Servers as Bots for a Botnet. For the purpose of this Proof of Concept we used Goolge's makeRequest() function to send and interpret all command and control messages sent between bots and botherder.

According to Google Webmaster Central (2010), Google uses a Feedfetcher user-agent to retrieve remote content. Google's Feedfetcher user-agent does not follow the Robots Exclusion Protocol. This protocol is not mandatory but is meant to protect certain pages from being viewed by web spiders and crawlers. When asked why Google's Feedfetch agent does not obey robots.txt, the Google representative states that the Feedfetcher request is the result of an explicit action by a human user, and not from automatic crawlers, hence Feedfetcher does not follow robots.txt guidelines. This response would imply it is not possible to generate fetch requests automatically, yet seeing as Google gadgets are coded in JavaScript it is a trivial task to automate the fetch requests.

According to (Google Gadgets API, 2009), Google's makeRequest() function does not validate the existence of a page prior to sending the HTTP request to remote server. This would mean malicious coders can use Google Gadgets to probe websites for config, admin or script files stored in un-listable directories of web pages. This could also be used to create a large amount of traffic towards the web server by generating makeRequest() calls for none-existent pages on the server. This type of probing and traffic generation could also be created by pure JavaScript without the use of Google Gadget's makeRequest() function, but the benefit of using Google Gadget API is that the remote server logs will only contain the IP address of Google Gadget application servers, as illustrated by Figure 4: Remote server log.

Google provides a cache features for all its gadgets to reduce server loads (Google Gadgets API, 2009). This cache server saves a copy of the remote content on a local server for faster retrieval. By default Google gadgets get cached for approximately one hour. Due to the requirement of some gadget developers to have shortened cache timing due to dynamic nature of their gadgets, Google provided developers with the capability to set the cache interval. According to Google Gadgets API (2009), it is possible to set the interval to zero seconds. Google Gadget API does not prevent developers from setting cache interval to zero but warns against setting cache interval to zero as it might overload remote server.

Thus we have discovered two means of disrupting remote server. Either by generating near infinite fictitious web pages from a server, or by fetching the same page recursively and setting the refresh interval to zero seconds.

3.2 Retrieving user data

Clients using the Cloud uses API calls to communicated and execute commands on the Cloud, through its Service-Orientated Architecture (SOA). In general, cloud computing units are heavily compartmentalized to insure no data can be leaked between clients. Unfortunately the components that makeup the Cloud infrastructure, such as CPU, Ram and GPU, where not specifically designed for isolation. (Hubbard et al., 2010) Techniques to exploit this weakness have been demonstrated by Joanna Rutkowska (Rutkowska, 2008) and Kostya Kortchinsky (Kortchinsky, 2009). In our specific case we do not target data on the Cloud specifically we merely use the Cloud as a channel to pass and receive message.

Google gadget API is a collection of JavaScript libraries; as such they require JavaScript to be enabled to utilize its capability. JavaScript can be used to determine user browser history and browser information. Cabri (2007), created a simplistic JavaScript to determine if a page have been visited before. Figure 5: Sites visited script, contains the script he used. By using this script to look up banking sites or social media sites one can determine which banking and social media services the user have visited.

By combining this script with Google gadget makeRequest(), one can determine if the user has auto login enabled for certain social media sites. For example: to test if the user has auto-logon enabled on Facebook one can request http://www.facebook.com/home.php. If the content is the home page it would mean the browser automatically logged the user in or the user has an active Facebook session. If the login page is returned it would mean the user's session has expired or that auto-logon is disabled. Keep in mind that makeRequest() does not display the page, it merely returns its contents to the callback function specified by the makeRequest() call. This means that the user does not need to get any visual cues of gadget activity. The Botnet designer can choose whether to scrape the resulting homepage for more data or to crawl the social network site for more data or to just report the information back to Botherder for future use.

Hashemian (2005), created a PHP script that can be accessed via JavaScript to perform IP resolution and reverse DNS lookups for visitors to sites. This provides more info on the location and domain usage of gadget user. Google's makeRequest() function is also capable of performing a POST request. By combining these JavaScript information gathering techniques and posting capability of Google's makeRequest() one can report back gathered information to Botherder. This is just some of the data that can be gathered using JavaScript and by no means covers all the data that can be harvested by JavaScript but for the purposes of this Proof of Concept they are sufficient.

3.3 Adsense abuse

Advertising companies offering website designers money for serving up adverts on their sites. By requesting pages using makeRequest() one can fool most Impression Based advertising models into counting the page fetch as an impression hence generating revenue for the website designer. Unique IP addresses have a higher weight on Advanced Impression Based advertising sites. Because Google Gadget Application servers make the request, only a select few IP addresses will in effect be displayed in advertising company logs. Hence, Adsense abuse is not really effective with Google Gadget API but it does guarantees a steady and constant number of visits to a site.

3.4 Obfuscating source of attack

Thus far it has already been stated that if the Google Feedfetcher is used to fetch remote data only the Google Gadget Domain Server's IP will be logged in the remote servers access logs. This is already an attempt to obfuscate the source of the attack. Unfortunately for Google gadgets to work and to be published Google needs to be able to access the gadget source code. This means that anyone wishing to add the gadget would also be able to fetch the source code and could possibly deduce that it executes malicious commands. A simple way of overcoming this obstacle is obfuscate the source code. By encoding the JavaScript source code in base64. Wang, (2009) developed a web tool specifically designed to obfuscate JavaScript. Figure 6 illustrates the result of obfuscating the hasLinkBeenVisited() function.

3.5 Spreading of botnet

Thus far we have illustrated two layers of attack. The DDoS attacks and Adsense abuse described in previous subsections are targeted towards remote servers or Impression Based advertising companies, these attacks are in effect performed by the gadget users on behalf of the botherder. The second layer of attack is the data gathering performed on the actual gadget user.

Attacks on remote server, actually require few gadget users. A botherder can automate mass amounts of requests from a single gadget user. FeedFetcher was designed distributed on several machines to improve performance and to cut down on bandwidth Google attempts to make the fetch request on a machine situated near target remote site. This would mean that the IP would constantly change and that the physical location of fetching machines can also be varied.

The second layer of attack is more reliant on the gadget itself to spread among users. For the purpose of this research we merely created several Google accounts and used Google Gadget sharing capabilities to distribute the gadgets. We will now briefly discuss some of the options available for spreading of gadgets.

Google Gadget API provides users with the capability of sharing gadgets among a user's Google contact list or by sending out emails containing an invite to install the gadget. Google also provide the capability of publishing the gadget on their Application servers. Published applications can be ranked and browsed by all iGoogle users. By manipulating the Google ranking system one can increase the probability of your gadget being added by other users.

Google Gadget API is fully integrated with OpenSocial API. OpenSocial API is a web framework for developing social applications which are capable of communicating across multiple social media sites. Peterson (2009), provides some basic steps than can be taken to increase gadget spread.

In the next Section, we will discuss our final Botnet model. We discuss how we mapped all the techniques described in this Section into our final Proof of Concept model.

4. Botnet gadget

Figure 7: Botnet Gadget illustrates the basic structure of our Botnet gadget. The Botherder acts as a Gadget developer and uses Google's services to update the Gadget and by extension update the Botnet. By doing this the Botherder can have a single point of access to all Bots at the same time. Updates might include new JavaScript attacks or even new targets for DDoS attack. The Botnet hides in plain sight as a normal gadget. It could either use a command from the Botherder or a temporal event to trigger a remote attack and while the Botnet is waiting to commence the next attack the Gadgets can gather information on Gadgets users and possibly identify other means of communications or vulnerabilities on Gadget user's PC.

In the remainder of this Section we discuss the attacks we added to our PoC Botnet Gadget and we discuss some of the information obtained by our Botnet Gadget.

We used the JavaScript function provided by Cabri (2007) to extract user history information such which Social network site the gadget user has visited and which bank he or she uses. Cabri's (2007) script can only determine if a site has been visited hence it is an exaustive search, hence we scanned though a targeted list of URLs for information we were interested in. We used JSON IP Adress recovery script provided by (Bullock, 2010), to determin gadget user IP Time zone and general geographical location using the retrieved IP.

To determine if the gadget user has auto login for social network sites we create hidden iFrames to try and access logged in content of social media sites. We queried the iFrame content to determine whether the iFrame was redirected to Login page or whether it could access the content. This data along with IP and history data was posted back to our own remote server using Google's makeRequest() function.

For a denial of service attack we used one of our own servers and requested fictitious pages from it using makeRequest() function. We placed fetch request in a n endless loop that generated randomized page requests to our server. This approach was not successful as it lead to gadget user PC to run out of memory. Upon investigation we realized this was caused by Google's AdSense triggering upon each remote request. We realized that by slowing the request time one could effectively use this technique for AdSense abuse but as this was not our goal with this PoC we deactivated AdSense tracking.

We ran the DDoS attack ten times on our own server. We used a single Google Gadget machine. Table 1: DDoS results shows that on average 638 requests were executed per second. According to server logs, eight unique Google domain servers were used to make the remote requests. Based on this data and data pertaining to a specific target server one can determine the number of Gadget users required to effectively take down a remote server. Unfortunately there is no fixed number of Gadget users that is required to disrupt a service. The number required is dependent on server architecture, request routing and data transferred per request. This PoC just determined the rough number of request that are possible using Google gadgets.

5. Future work

This paper, merely wishes to illustrate the ease of generating a potential Botnet using services provided by Google Gadgets. In actuality the only true exploit was the fact that Google allows users to use Google servers to fetch remote content. The fact that Google gadgets require JavaScript in order to run, just facilitate the process of automating the attack.

The whole spectrum of attacks on JavaScript can be used with Google's services. The ability to execute code from Google's computers can lead to other misdirection attacks. Google is not the only commercial player in the internet cloud space. Similar attacks may be possible from Microsoft, Yahoo or Amazon services. We aim to investigate this in future research.

In this paper we did not investigate the possibility of AdSense revenue generation. By registering a impression based advertising mechanism, such as Adgator, one can generate revenue simply by delaying repetitive fetch requests a Botherder. More complex techniques are proposed by Hansen (2008) to add Clickthrough or Pay-Per-Click advertising schemes.

The Botnet Gadget suffers from several critical weaknesses. Because the Botnet Gadget relies on Google Feedfetch agent to make remote requests it can easily be stopped by blocking all requests from this agent. But this will influence other legitimate FeedFetch agent request from Google reader. Another potential weakness is that Google gadget source code needs to accessible by Google Gadget Servers hence if a malicious gadget is detected Google could easily remove the Gadget and the Botherder would lose all its Bots.

6. Conclusion

In this paper we reiterated the views of Stracener (2008) and Hubbard et al. (2010) that as the computer user base moves towards cloud computing so to will the security threats. We used Hubbard's seven key threat indicators to try and identify possible routes of attack for our research.

First, we defined the four key components of a Botnet. We then provided examples of how these components can be mimicked by Cloud services and specifically by Google's gadget API and how they match the Cloud security threats identified by Hubbard. The API was capable of reproducing each of the components functionality, to a limited degree with very little alteration of freely available web resources.

We combined these components to form a simple but working botnet. Although limited in scope, a simple DDoS attack was achieved by using Google servers as the attacking computers. The current botnets concentrate on using personal and corporate computers, but as they are moving into the cloud computing, the botnets will follow.

We identified several weak points in our current design and identified some possible areas for future development of Cloud botnet research. This is still a rather new field and as such this paper hopes to serve as a possible point of reference for future work.

References

References

Banks, S. & Strytz, M., 2007. Bot armies: an introduction. [Online] SPIE Available at: http://spie.org/x15000.xml?ArticleID=x15000 [Accessed 10 October 2010].

Bullock, D., 2010. IP Address Geolocation JSON API. [Online] Available at: http://ipinfodb.com/ip_location_api_json.php [Accessed 8 October 2010].

Cabri, R., 2007. Spyjax - Your browser history is not private! [Online] Available at: http://www.techtalkz.com/news/Security/Spyjax-Your-browser-history-is-not-private.html [Accessed 7 October 2010].

Denis, B., 2008. Anatomy of the Asprox Botnet. [Online] VeriSign Available at: http://xylibox.free.fr/AnatomyOfTheASPROXBotnet.pdf [Accessed 30 September 2010].

Engate, 2009. Defending your network from Botnet threat. [Online] Engate Available at: http://ns1.happynet.com/images/datasheets/Engate_whitepaper.pdf [Accessed 9 October 2010].

Eston, T., 2010. DigiNinja. [Online] Available at: http://www.digininja.org/ [Accessed 5 October 2010].

Felix, F.C., Thorsten, H. & Wicherski, G., 2005. Botnet Tracking: Exploring a Root-Cause Methodology to Prevent Distributed Denial-of-Service Attacks. Computer Security - ESORICS 2005, 3679, pp.319-15.

Garner, 2008. Gartner Says Cloud Computing Will Be As Influential As E-business. Garner Inc. Stamfort: Garner Inc.

Google Gadgets API, 2009. Working with Remote Content. [Online] Google Available at: http://code.google.com/apis/gadgets/docs/remote-content.html [Accessed 7 October 2010].

Google Webmaster Central, 2010. Feedfetcher. [Online] Google Available at: " http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=178852 [Accessed 3 October 2010].

Hansen, R. & Stracener, T., 2008. Xploiting Google Gadgets: Gmalware and beyond. [Online] Available at: http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-stracener-hansen.pdf [Accessed 3 October 2010].

Hashemian, R.V., 2005. JavaScript Visitor IP Address and Host Name. [Online] Available at: I:\JavaScript Visitor IP Address and Host Name.mht [Accessed 3 October 2010].

Hubbard, D. et al., 2010. Top Threats to Cloud Computing V1.0. Cloud Security Alliance.

Kiefer, K.P., 2004. Background on Operation Web Snare. [Online] Available at: http://www.justice.gov/criminal/fraud/documents/reports/2004/websnare.pdf [Accessed 3 December 2010].

Kortchinsky, K., 2009. Black Hat. [Online] Immunity, Inc. Available at: http://www.blackhat.com/presentations/bhusa- 09/KORTCHINSKY/BHUSA09-Kortchinsky-Cloudburst-SLIDES.pdf [Accessed 16 November 2010].

MacManus, R., 2008. Read Write Web. [Online] Available at: http://www.readwriteweb.com/archives/survey_48_of_bank_customers_wa.php [Accessed 6 October 2010].

Ollmann, G., 2009. A Botnet by Any Other Name. [Online] Available at: http://www.securityfocus.com/columnists/501 [Accessed 11 October 2010].

Peterson, V., 2009. Social Design Best Practices. [Online] Available at: http://wiki.opensocial.org/index.php?title=Social_Design_Best_Practices [Accessed 3 October 2010].

Rutkowska, J., 2008. Black Hat. [Online] Coseinc Available at: http://www.blackhat.com/presentations/bh-usa- 06/BH-US-06-Rutkowska.pdf [Accessed 16 November 2010].

Stracene, T., 2008. Securing Widgets and Gadgets in the Web 2.0 World. [Online] Available at: http://blog.cenzic.com/public/blog/208285 [Accessed 6 October 2010].

Vamosi, R., 2008. CNET News. [Online] Available at: http://news.cnet.com/8301-10789_3-10040669-57.html [Accessed 2 October 2010].

Wang, A., 2009. Javascript Obfuscator . [Online] Available at: http://www.javascriptobfuscator.com/Default.aspx [Accessed 12 October 2010].