Category: News

Worst Jobs in Science 2007 – Microsoft Security Grunt

huh?Popular Science had an interesting article about The Worst Jobs in Science 2007, their annual bottom-10 list, in which they salute the men and women who do what no salary can adequately reward. Number 6 on the list was Microsoft Security Grunt. From the article:

The people manning secure@microsoft .com receive approximately 100,000 dings a year, each one a message that something in the Microsoft empire may have gone terribly wrong. Teams of Microsoft Security Response Center employees toil 365 days a year to fix the kinks in Windows, Internet Explorer, Office and all the behemoth’s other products. It’s tedious work. Each product can have multiple versions in multiple languages, and each needs its own repairs (by one estimate, Explorer alone has 300 different configurations). Plus, to most hackers, crippling Microsoft is the geek equivalent of taking down the Death Star, so the assault is relentless.

I do not envy the techs who suffer day after day in this role but I can’t help but think that I’d rather be doing this job than the one in the Number 10 spot: Whale-Feces Researcher:

“Brown stain ahoy!” is not the cry most mariners long to hear, but for Rosalind Rolland, a senior researcher at the New England Aquarium in Boston, it’s a siren song. Rolland, along with a few lucky research assistants, combs Nova Scotia’s Bay of Fundy looking for endangered North Atlantic right whales. Actually, she’s not really looking for the whales—just their poo. “It surprised even me how much you can learn about a whale through its feces,” says Rolland, who recently published the most complete study of right whales ever conducted.

NIST Draft SP 800-54, Border Gateway Protocol Security

NIST has just released draft SP 800-54 entitled Border Gateway Protocol Security (PDF). Few people comprehend the seriousness of an attack on a protocol such as BGP. The introduction section of the paper provides some insight:

Most of the risk to BGP comes from accidental failures, but there is also a significant risk that attackers could disable parts or all of network, disrupting communications, commerce, and possibly putting lives and property in danger. This document discusses the structure and function of BGP, potential attacks, available countermeasures, and the costs and benefits related to countermeasures. The emphasis in this publication is on measures that may be applied either immediately or in a short time. A variety of proposals have been introduced in standards bodies for more comprehensive approaches to BGP security, but issues are not yet settled as to which, if any, of these proposals will be adopted by the producers and consumers of routing equipment. The aim of this document is to give decision makers a selection of measures that can be deployed rapidly, yet provide significant improvements to routing security.

A good explanation of BGP can be found on Wikipedia:

The Border Gateway Protocol (BGP) is the core routing protocol of the Internet. It works by maintaining a table of IP networks or ‘prefixes’ which designate network reachability among autonomous systems (AS). It is described as a path vector protocol. BGP does not use traditional IGP metrics, but makes routing decisions based on path, network policies and/or rulesets. From January 2006, the current version of BGP, version 4, is codified in RFC 4271.

The paper provides detailed explanations, with diagrams, of several potential attacks against the BGP protocol:

  • Peer Spoofing and TCP Resets
  • The goal of the spoofing attack may be to insert false information into a BGP peer’s routing tables. Peer IP addresses can often be found using the ICMP traceroute function, so BGP implementations should include countermeasures against this attack.

  • TCP Resets Using ICMP
  • TCP resets cause loss of BGP peering sessions, forcing a need to rebuild routing tables and possibly causing route flapping.

  • Session Hijacking
  • Like the TCP reset attack, session hijacking involves intrusion into an ongoing BGP session, i.e., the attacker successfully masquerades as one of the peers in a BGP session, and requires the same information needed to accomplish the reset attack. The difference is that a session hijacking attack may be designed to achieve more than simply bringing down a session between BGP peers.

  • Route Flapping
  • Route flapping refers to repetitive changes to the BGP routing table, often several times a minute. A “route flap” occurs when a route is withdrawn and then re-advertised. High-rate route flapping can cause a serious problem for routers, because every flap causes route changes or withdrawals that propagate through the network of ASes.

  • Route Deaggregation
  • Route deaggregation occurs when more specific (i.e., longer prefix) routes are advertised by BGP peers. For example, if prefixes 129.0.0.0/8 and 129.0.0.0/16 are both advertised, BGP algorithms will select the second (for any addresses within 129.0.0.0/16) because it is more specific. In some cases this is normal and appropriate operation as a result of configuration changes, but it can occur as a result of error or malicious activity.

  • Malicious Route Injection
  • BGP exists to spread routing information across the Internet. Routers tell each other what prefixes they can reach and provide data on how efficiently they can reach addresses within these prefixes. In a benign, cooperative environment this works well, but a malicious party could begin sending out updates with incorrect routing information.

  • Unallocated Route Injection
  • A particular variety of malicious route injection involves the transmission of routes to unallocated prefixes. These prefixes specify sets of IP addresses that have not been assigned yet, i.e., no one should be using these addresses, so no traffic should be routed to them. Therefore, any route information for these prefixes is clearly faulty or malicious, and should be dropped.

  • Denial of Service via Resource Exhaustion
  • Like all computers, routers have a finite amount of storage and processing cycles available. One of the most common attacks of this type is known as a “SYN flood”, in which a large number of TCP/IP communication sessions are started using the SYN (synchronization) packet, without follow-up by the appropriate next packet type. This causes the receiving host to reserve storage space for the session. With enough SYN packets, space is eventually exhausted on the host. Since BGP is implemented on TCP/IP, BGP processing can be affected by this attack.

  • Link Cutting Attack
  • An inherent vulnerability in routing protocols is their potential for manipulation by cutting links in the network. By removing links, either through denial of service or physical attacks, an attacker can divert traffic to allow for eavesdropping, blackholing, or traffic analysis. Because routing protocols are designed to find paths around broken links, these attacks are particularly hard to defend against.

I encourage everyone to give this paper a thorough read, especially if you’re responsible for the boarder routers in your organization and leverage the BGP protocol.

Introducing The Open Event Log Project

OELThe Open Event Log (OEL) Project was conceived by Andrew Hay in May 2006 as a repository for system/server/application event logs to aide in incident response and forensic analysis. Many tools are now available to assist the analyst in interpreting event logs but a better understanding of the logs, as well as samples, were lacking. Most vendors post their event log specifications but it helps to have a central location that displays samples of these logs.

The ultimate goal of this site is to educate users on proper event log collection and analysis techniques which goes hand in hand with our motto: “No log left behind!”

Please note that there is no corporate backing of this site in order to remain as independent as possible.

Each device/application will display the following information to help the community:

  • Log Sample
  • Log Description
  • How To Enable Logging
  • Regular Expression Matching

An example of this format can be seen with the Juniper NetScreen entry here: http://www.openeventlog.com/index.php/Juniper_NetScreen

I’d appreciate any feedback you might have and invite you to contribute as much as possible.

Scroll to top