6th European Conference - Academic Conferences

Ivan Burke and Renier van Heerden
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
Figure 2: Google Gadget makeRequest() function
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.
Figure 3: makeRequest() HTTP request flow
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.
35