Dr. Antonio Nucci

By Supranamaya Ranjan

A recent article by Kelly Jackson Higgins, Senior Editor at Dark Reading, brings forth an interesting theory about the continued proliferation of botnets. She propounds the view that may be the owners of machines infected with Bots don’t care or don’t know enough to do anything about it. If they knew enough, then may be they would have gotten rid of the malaise.

While until now most botnets have been used for launching spam campaigns, we are starting to see them being used for geo-political attacks against an organization or a country. The recent DDoS attacks (Estonia ‘07, Radio Freedom Europe or RFE/RL ‘08) may just be a precursor of things to come. We can only hope that users become more aware about the botnet phenomena in time before we see an all-out cyber war.

Patching your machine with the latest update from your Anti-Virus company may only go so far in preventing your machine from being hijacked by a Botnet. We have seen time and again how during zero-day worm attacks (Code Red), signatures couldn’t be extracted in time. That gap can fortunately be filled by Service Providers, who can see the traffic entering their customers’ network and can hence alert them via a Managed Security Services (MSS) offering. Potentially, a Service Provider could keep track of presence of botnets within their customer periphery and then pro-actively alert them to get rid of the same.

The NarusInsight Secure Suite provides this capability to Service Providers at multiple levels. First, a Service Provider can detect and bounce off all attacks that are entering its paying customers’ network periphery. Second, the provider can dynamically deploy new layer-7 parsers (or, signatures) to detect botnet Command-and-Control traffic (or, traffic exchanged between a bot and its commanding server). Thus, as soon as a human analyst reverse-engineers the language for communication between bots and their command-and-control server, it can be quickly pushed out via this dynamic parser to the NarusInsight platform, whereby future traffic that matches this pattern would automatically be classified as botnet traffic.

By Supranamaya Ranjan

This must be the summer of geo-politically motivated Distributed Denial of Service (DDoS) attacks. We are close to the one year anniversary of the first cyber-war against the Baltic republic of Estonia. Last week CNN was DDoS’ed by supporters of a pro-China group called, Revenge of the Flame. And in the course of all this, a bystander sports site, Sports Network Management, which only had the misfortune of sharing the word ‘cnn’ in its website while not being directly affiliated to CNN at all, also got DDoS’ed. To top it all, in apparent retaliation, one of the sites behind the patriotic drive sweeping China, Red Heart China Signature (www.5sai.com), got its site DDoS’ed by a group of ip-addresses located in Europe.

Close at the heels of all these intense attacks and counter-attacks, we hear of yet another. Various news sources are reporting that Radio Freedom Europe’s Belarus site was DDoS’ed this weekend starting from April 26. The radio station was going to cover mass protests in Minsk, Belarus dedicated to the anniversary of the Chernobyl disaster. The radio station had plans to direct people to their website to check out pictures, videos of the coverage, etc. However, much to their dismay their site was totally inaccessible for 2 days and 2 nights under a massive DDoS storm. According to the RFE/RL Belarus Service Director:

“There was not much we could do because at this moment we also lost e-mail communication and Skype communication with Belarus. As we found out later, the attack was so massive that the firewall that protects Radio Free Europe went down. And a number of other [RFE/RL] sites went down as well.”

These attacks set a scary precedent. That political agendas can very easily find their way in the form of online hacks and attacks. Even more scarier is the fact that the exact perpetrator of a DDoS attack can be very difficult to pin-point, especially if the attack was launched by a Botnet.

Let alone find the identity of the attacker, it can sometimes be incredibly difficult to even find the location of the attacker. In these geo-political attacks, a lot of times, claims are made that the attack was launched from a certain country or region. A case in point are reports that suggested that the DDoS attack on Red Heart China Signature was launched in Europe. However, there could be a completely different picture, where those 4 European ip-addresses were only used as frontmen for the attack, while for all practical purposes, the actual attacker could be somewhere in Antarctica, controlling those 4 machines.

So the point being that to perform detailed and accurate forensics of these sorts, Managed Security Services as provided by the ISPs is better off than an edge-security solution installed at the web site itself. Web server logs of the victim site can only provide an idea of the frontmen of the attack. While, ISPs can not only detect that a DDoS attack is underway and hence alert the web site, they can also correlate and identify who else did the attackers talk to - and potentially determine the botnet controller or the real perpetrator of the attack.

By Supranamaya Ranjan

Over the last 24 hours, several security researchers have analyzed the tools that were distributed to launch the DDoS attacks against CNN. The interested reader can get an analysis of the 3 tools at Dancho Danchev’s blog.

The attack tool that caught my attention is the one in which the ‘hacktivists’ via mailing lists and forums urged users to do one of the two following things. The more tech savvy users or the generals were urged to install an executable after which they would be able to serve a web page on their web site (e.g., hackerhf.com/cnn.html, etc.). This web page would then load www.cnn.com continuously (almost once per second) in a frame. The lesser tech savvy ones or the soldiers were asked to simply point their browser towards the web pages set up by the generals. As long as they kept their browsers up and running, requests would be sent towards CNN’s homepage continuously, thereby throttling either the bandwidth around CNN or Akamai, its Content Distribution Network or bringing CNN’s web server infrastructure to its knees.

Interestingly, just this geo-political activism was able to generate enough traffic at CNN so that legitimate users’ requests were delayed from 1 seconds on a usual day to 4 seconds times on Sunday morning for 3 hours (source: Netcraft) . Note however that requests were never dropped and everyone was able to browse CNN albeit slowly.
A packet trace analysis of what happens when a soldier logs on to one of the generals’ sites reveals the following sequence of HTTP requests that are generated:

Sequence of http requests

Most interestingly, note that the next group of HTTP requests to CNN start after 1 minute (time gap between request IDs 124 and 4910). In other words, this tool allows a Firefox client with default settings to generate attacks at a highly modest rate of once per minute. Interestingly, the frame embedding CNN definitely appeared to be refreshing itself much faster than that, at 20 times per minute. Every browser has a parameter where the browser sends requests to check for new content on an existing site at a particular rate. For instance, for Firefox:

“browser.cache.check_doc_frequency [Integer] (3) - This setting determines how often Firefox checks for newer versions of the page you are viewing. This setting is similar to Internet Explorer’s ‘Check for newer versions of stored pages’ setting. If set to 0 Firefox only checks once per browser session; if set to 1 Firefox checks every time a page is viewed; if set to 2 Firefox never checks (i.e. it always uses the version stored locally in your browser cached); and if set to 3 (the default) Firefox checks at automatically determined intervals. If you browse mostly pages which update their content extremely often (i.e. a few times a day) you may wish to set this to 1 though it will slow down browsing speed. The default of 3 is best for fastest browsing on most connections. You can experiment to see if 0 suits your needs, but don’t use a value of 2.”

One does wonder whether the hacktivists instructed their users to change the default Firefox setting from 3 to 1, where requests would be generated to CNN as fast as the frame refreshes. And assuming that 100% of the users had done this browser setting change, then would CNN’s response time have increased exponentially? May be then it would have crumbled to the attack!

It also makes one wonder which problem is easier: detecting attacks launched by human armies or that launched by botnets?

By Supranamaya Ranjan

Throughout this weekend, CNN’s website was under threat of a DDoS attack purportedly being planned by a group called Revenge of the Flame (source: DarkVisitor blog). Fortunately, there were no large scale attacks and CNN.com was very much up and running. The weekend plot involved dramatic twists and turns that Hitchcock would have been proud of. First, the hacker group postponed the attack since the news had leaked far and wide. Later for reasons unbeknownest to us, the group called off the attack completely and even disbanded.

Despite calls by the group for halting the attack, there were relatively smaller scale attacks that did happen over the weekend. May be the calls to stop didn’t propagate to the participants as far and wide. Multiple sites of CNN (www.cnn.com, www4.cnn.com, edition.cnn.com) were the target of these attacks. NarusInsight Secure Suite (NSS) reported 2 different kinds of attacks going towards CNN - ICMP flood attacks and TCP SYN flood attacks. Interestingly the attacks had very similar signatures, e.g. an instance of a SYN flood involved the attacker distributing his packets across multiple source ports while sending exactly the same number of packets per source port). This can be expected given that the hacker group had made it easy for the novice who could download a script to launch the attack.

The highest bandwidth attack seen by NSS was an 80 Mbps SYN flood attack, while the others were much less than that. Regardless, the attacks were never big enough to bring down CNN and much to our joy we could continue reading about the Pennsylvania primary, the olympic torch being relayed around the world and all the other stuff that gets us up in the morning.

By Supranamaya Ranjan

Since early yesterday morning (18th April), we have been following ‘The Dark Visitor‘ which has leads about a large-scale DDoS attack being planned on CNN.com. The attack was planned for 5 am PST, but seems to have been called off, rather postponed since too many people found out about it. Nevertheless, I took a look at the traffic heading towards CNN and NarusInsight Secure Suite (NSS) didn’t report any attacks for today morning.

NSS did report 2 separate TCP SYN flood attacks yesterday morning though, one was targeted towards cnn.com and the other towards edition.cnn.com. These attacks lasted very briefly (2 minutes) and had the uniformity typically only seen in attack traffic, e.g. each of the attackers generated the same amount of traffic. We will keep a close eye on this in case the attack does happen. Since CNN is very much up and running, I am off to get my daily dose of news now!

By Supranamaya Ranjan

The impact that prefix hijacking, inadvertent or otherwise, can have on the Internet was brought to the fore recently when YouTube was inaccessible for almost 2 hours from most of the world. We were tracking the global BGP routing tables at that time and NarusInsight Secure Suite (NSS) generated alerts as soon as the incident happened. First, at Feb 24, 18:43:00 UTC, the prefix 208.65.153.0/24 was detected to appear in the routing tables for the first time and hence was immediately classified as ‘Subnet Hijacking’. Note that YouTube only announces the super-prefix 208.65.153.0/22 and hence the appearance of the more specific prefix 208.65.153.0/24 from an AS different from YouTube led it to be classified as a Subnet hijacking. Next, after about hour and a half, YouTube engineers announced the /24 prefix for the first time in order to regain their lost traffic. Since the /24 was being announced by two ASes at the same time, this announcement was classified as ‘Duplicate Hijacking’.

An interesting angle that is often overlooked regarding prefix hijacking is that there are other incidents that look similar to a hijacking that happen all the time. Multi-homing is one such case which looks similar to a prefix hijacking. For instance, when an ISP signs up a new upstream service provider and is hence multi-homed to the Internet via multiple upstream providers. Now when the link to the current provider goes down, the ISP would fall back upon the new provider, who would then announce the prefix on its behalf. Overall, from the perspective of an observer outside this ISP, it would appear that this prefix is announced (and hence owned by) two different ASes.

Indeed, in the 2 hours that the YouTube hijacking was happening, there were ~743 total BGP prefix hijacking alerts that were reported by NSS, a majority of which were really cases of multi-homing or of an ISP having obtained a new prefix block. How could an ISP, that is monitoring the health of the BGP routes that it is receiving, distinguish the YouTube hijacking from all these other alerts? NSS ranks prefix hijacking alerts by their impact to traffic and hence in this case, the YouTube alerts were ranked at the top.

The quick and drastic effect of this false prefix announcement was evident in the sudden drop in traffic headed to YouTube. As shown in the graph below, the traffic heading to YouTube drops to 0 bytes/sec around midnight Feb 25, 2008 and stays at that level for the next hour and a half, until when YouTube announced its /24 to obtain its rightfully-owned traffic. The fact that this drop was not due to diurnal variations that occur in traffic (when traffic drops down during the night time), is evident from the fact that during the same time duration, traffic heading to Google was still the same (~ 1 MB/sec).

Fig. 1: Drop in traffic heading to YouTube

This incident is sure to open the flood-gates of discussion on security in BGP. In the past, authentication of BGP sessions has been proposed as a means to prevent un-authenticated routers from leaking BGP routes on to the Internet. But even if YouTube did have authenticated BGP sessions with all its one-hop peers, clearly it still wasn’t able to prevent someone many AS hops away from causing grave damage. While the BGP community searches for the right mechanism to stop such leaked routes from propagating, currently ISPs can benefit from solutions such as NSS which provide for timely detection of a hijacked prefix and also quantify the impact the hijacking would have on traffic.

By Supranamaya Ranjan

While prefix hijacking has been known by the carrier networks for several years now, its impact on delivering attacks in the Internet hasn’t been grasped fully yet. In the last post, I described how hijacking an already existing prefix can lead to stealing traffic away from the original prefix owner, leading to a “Denial-of-Reachability” attack. In this post, I will describe the wide array of malicious attacks that can be injected by an attacker by hijacking a previously un-announced prefix.

We have witnessed Email Spam campaigns being carried under the guise of hijacking of several /16 and /20 prefix blocks via traffic monitored at one of the largest carrier ISP networks in North America. Given the multi-million dollar industry that is Spamming, it is no surprise that spammers have pushed the frontiers even further. However, this is an incredibly clever method for delivering spam, and the reasons for this are rooted in the increasingly lucrative spam business model as well as evolution of anti-spam campaigns. Further, the anti-spam campaigns have also taken a new turn, where a comprehensive list of ip-addresses detected to originate spam are blacklisted and provided as a DNS query in what is commonly being referred to as DNS-based BlockLists (DNSBLs). Mail servers can automatically look up source ip-address of an email via these DNSBLs to determine whether to forward the email or filter it.

Now, in order to work around the DNSBLs, spammers have resorted to hijacking large prefix blocks that are un-announced by any one else in the Internet. Owning a large prefix block, say /8, provides spammers access to a huge number (16 Million) unique ip-addresses. Now, a sophisticated spammer can spread the workload cleverly so that he remains under the radar of the DNSBLs. If the spammer has access to say, 10 mail servers for originating emails, then he could rotate the ip-addresses allocated to these mail servers in such a way that none of the ip-addresses ever become prominent. Since the hijacked prefix is now routeable back to its originating AS and router, hence, this method for spam delivery works really well- spammers are even able to get back notification of whether their email was successfully received by the destination mail server. Moreover, once the daily email target has been accomplished, the spammer may even withdraw the prefix, thereby covering his tracks completely from trace-back programs such as ICMP pings, Nmap or traceroute.

This portends an even scarier future, where an attacker may launch not only spam under the disguise of prefix hijacking, but a bewildering variety of other attacks. Another attack that we at Narus, foresee being driven by prefix hijacking just as easily are Search Engine Click Frauds, where an advertiser clicks through a competitor’s ads to wipe out his advertising budget. Any automated technique for click fraud detection must maintain counts of how many clicks originate from which ip-addresses. Now, hijacking a prefix gives the attacker a huge set of ip-addresses from which he can originate his clicks, to the point that he can remain “below-the-radar” for clicks per ip-address. Since, Click Fraud is widely acknowledged by Search Engine companies to be their bete noire; could prefix hijacking enabled Click Fraud be their ultimate nemesis?

Indeed, it is no mean task to detect prefix hijacking enabled Spam or Click Fraud, since appliances that only have a partial uncorrelated view of the network are doomed for failure. Fortunately, via its patent pending anomaly correlation technology, NarusInsight Secure Suite can correlate seemingly separate attack incidents such as those launched via prefix hijacking, into one cohesive meta-alert, providing the complete picture from root cause to end result.

By Supranamaya Ranjan

Prefix hijacking is the Internet equivalent of identity theft. An attacker steals your IP address and originates or collects traffic pretending to be you.

An amusing, albeit catastrophic, incident of this sort happened in December 2004, when TTNet, an ISP in Turkey, accidentally announced 100,000 prefixes (the Internet currently consists of roughly 250,000 prefixes) as belonging to itself. Some ISPs in the area took the announcement at face value and believed that sites such as BBC, Google, etc., were routed via Turkey. The result was that for almost a day, the unsuspecting ISPs were not able to reach most of the Internet – arguably due to no fault of their own – while TTNet got inundated with unexpected traffic. (Another example, indeed, of how the inter-connected nature of Internet routing is so susceptible to tenets of the chaos theory – that a butterfly flapping its wings in the Tropics may well trigger a series of events that culminate in a snow avalanche in the Arctics).

Prefix hijacking attacks in the Internet is increasing both in frequency and complexity. In combination with current day attacks, prefix hijacking can prove lethal to many networks and businesses. As I will discuss in this blog, these attacks are being launched with relative ease today.

To understand prefix hijacking, one must understand how traffic destined to an IP address is routed in the Internet via the Border Gateway Protocol (BGP), the primary inter-domain routing protocol of the Internet.

Blocks of IP addresses or prefixes are allocated by authorities such as IANA to Internet Routing Registries (IRRs) such as ARIN in North America, RIPE in Europe, APNIC in Asia Pacific, LACNIC in Latin America and AFRINIC in Africa. When it obtains a prefix, an ISP may choose to announce the prefix itself, and in doing so, own responsibility for exchanging routes with the neighboring BGP routers so it can gain connectivity to the rest of the Internet. In such cases, the ISP also obtains an Autonomous System (AS) number, and announces its prefixes as itself. However, inter-domain routing is a fairly intensive task, and ISPs usually abdicate responsibility for routing to their upstream providers, typically carrier networks. Thus, the rest of the Internet sees these prefixes as belonging to the carrier AS.

Now, this is where it becomes more complicated but much more interesting. In return, carriers typically rely on the customer ISP to ensure that the prefixes it is asking the carrier to announce on its behalf, are really the ones it owns. In other words, carriers turn a blind eye to whatever prefixes a customer ISP is handing over for announcement. This provides fertile grounds for breeding prefix hijacking. All a hijacker has to do is break into a BGP router of a customer ISP and inject malicious prefixes it wants announced to the Internet. Gaining access to a BGP router can be relatively easy. In several cases, ISPs have been known to leave the default management console password unchanged on BGP routers! Alternatively, an attacker doesn’t even need to break into a router. He could simply register as an ISP, purchase upstream access from a carrier and voilà, inject prefixes at will.

And what could be the motives behind a prefix hijacking attack? Incidents such as TTNet portend a scary future where an attacker may inject prefix announcements duplicating those of popular web sites such as Google, Amazon, Ebay,Yahoo or financial institutions, to redirect and hijack traffic destined to these sites. The simplest motive could be to hold these companies hostage, asking them to pay substantial ransoms or else their customers will not be able to reach them. In addition, hijacked sensitive information could be compromised and abused. In a distributed attack where false prefixes are injected from many different points in the Internet, the attacker may be able to convince many more routers and ISPs that its announcements are the real ones. And since loss of traffic means loss of revenue and potential customer churn, this could be the next generation of Internet blackmail and terrorism.

Fortunately, solutions such as NarusInsight Secure Suite (NSS) provide real-time detection and mitigation of prefix and route hijacking. NSS enables carriers and service providers to detect such anomalies as soon as they occur. The enterprises that actually own the hijacked prefixes are alerted so they could deal with the threat before damage is done.

By Supranamaya Ranjan

My colleague, Kevin McTiernan, and I recently spoke at the ISS World Conference in Washington, DC. A key concern we highlighted in our presentations is how standards for Lawful Interception are in denial about denial-of-service attacks. Participants were not fully aware of how DoS, DDoS, scans and Internet worms could interfere with successful interception, and why it is increasingly important for carriers and ISPs to think about securing their LI infrastructure.

A malicious entity can prevent law enforcement agencies and ISPs from successfully intercepting targeted events and traffic data by simply launching a denial-of-service attack on the ISP’s infrastructure. The techniques available to attackers are extensive and bewildering. One could congest the ISP’s network with a SYN flood attack, UDP flood, ICMP Smurf attack or other sophisticated DoS variants. One could also bring down the web portal being used for “LI Reporting?” by sending a flood of HTTP requests towards the web server. These attacks could begin with port scans directed towards the ISP’s network in order to locate the IP address of the reporting web server or the other vulnerable service ports that are open. Exacerbating this is the fact that the tools and resources needed for launching these attacks are easily available on the Internet.

Why exactly would this be important for carrier networks and ISPs? Well, a lot of the DoS, DDoS, scan and worm attacks we’ve seen so far in the Internet have been launched by thrill-seeking script kiddies, or by cyber extortionists looking for some quick bucks, or by spammers looking for unpatched vulnerable machines so that they could add them to their bot armies. However, once ISPs become compliant to CALEA and ETSI in 2007, the scenario will very likely change and cyber mafias will get yet another customer – the thugs and terrorists, who upon learning of impending intercept warrants against them, can be expected to approach the cyber mafias to prevent successful interception! The results will be disastrous, with cyber attacks launched as fast as warrants are issued. Unfortunately, it will be the ISPs and carriers who will bear the brunt of a cyber thug or mafia nexus. Imagine being an ISP that suddenly starts getting a huge number of phone calls from disgruntled customers who couldn’t check their emails, couldn’t access their banking accounts, and couldn’t order life-saving drugs online – all because you are being DDoS’ed for opening up a cyber warrant against a few thugs.

The picture may appear gloomy, but unified security and LI solutions like NarusInsight are fortunately now available. LEAs and ISPs can proactively address the challenge by deploying LI solutions with built-in security capabilities, or by complementing existing LI infrastructures with proven network security solutions.

By Kevin McTiernan

An employee of a large US corporation was fired for excessive use of the Internet during work hours. After his employment was terminated in 2003, the employee filed a lawsuit charging his employer with wrongful termination. He claims that his employer offered programs to assist fellow employees “with much more severe psychological problems?” including drugs and alcohol and thusly, he should have been offered counseling instead of being fired. His employer claims that he was in Internet chatrooms where sexually explicit topics were discussed and visited a website containing sexual content, all of this while using one of their computers. The employee claims the chatrooms were “self medication?” to help cope with post traumatic stress due to his experiences in Vietnam.

This brings up interesting comments about today’s Internet-driven culture. Employers are finding their employees requiring physical therapy for the “thumb tendonitis?” which results from the constant use of smartphones (such as Blackberrys, Treos and Sidekicks). Treatment centers are finding their clientele increasing and needing help with addictions including online gambling, cybersex and online shopping.

It is interesting – could the Internet, by making it possible to communicate with anyone around the clock, by providing an unending supply of information, and by enabling technologies (such as VoIP or videoconferencing), cause dependencies similar to that of nicotine, alcohol and drugs? When you look at the statistics released with a Stanford University study (see “A Stanford University study finds…?” below), there may be a new addiction for the healthcare industry to keep an eye out for.

In this Internet-driven culture, what will the responsibility of an employer be? Would employers be required to monitor all Internet traffic and analyze to look for dependencies? Will employers continue to offer Internet access? How long before we see a pamphlet on our HR admin’s desk on Internet addiction? Will schools need to provide guidance to students similar to teen pregnancy or alcohol abuse?

Stanford University’s Office of Communication and Public affairs has information on their study, here.