Storm bot

It's hard not the get worried about the storm bot these days. In case you've been living under a rock, here are a few headlines about the beast:

• Rub it the wrong way and it will DDoS you (there have been reports of a couple of intrusive packets and queries and you're out. The witnessed bandwidth figures have been pretty worrisome -- something in the vicinity of 5 Gbits/s.)
  
• Convenient packaging, shared, improved upon by several individuals and even localized
  
• Use of fast-flux networks
• Ability to assess of a campaign effectiveness, before it starts (one will actually take a close look at the targeted countries and operating system. Windows 98 -- I wouldn't have guessed so many people are still using it.)
  
• Partitioning of communications using a 40-bit key system
• Emergence of the managed spamming appliance service, how should I call it -- "concept"?
  

I guess we'll just have to see who's going to hire its services -- this past few weeks words from the people tracking Storm Botnet's behavior have been "Precursor to..." or "Something new is upon us". Given that previous DDoS campaigns have been able to severly disrupt normal Internet operation in a small country, it's hard not to feel that a massive gun for hire is being pointed at something -- I can't help picturing it as the infamous WWI's Paris-Gun, don't ask me why.

Update: here's a link to a nice presentation.

On NAC.

NAC is a buzzword these days: in a nutshell: Network Access Protocol tries to govern what you are allowed to do on the network based on who you are. So, there's a policy that is defined according to three parameters:

1. Who you really are (authentication)
2. Your end-point security (are you from a fixed and uptodate security-wise desktop running a secure operating system or are you connecting from a Windows desktop that hasn't been upgraded in the last three month)
3. Network environmental information: are you connecting through a wireless access point or through a VPN. Are you in the main building or a remote office.

Couple points:

1. What's NAC's ROI?
2. NAC is reactionary, it's worrying about last week threats
3. It's complicated, there are tons of solutions (M$, Juniper, Cisco) and its granularity (down to individual FW policies, for instance) can make it difficult to deploy it adequately.
   

Lots of links are available on the topic. Here's one that's a good starting point.

Update: there has been a lot of articles published on NAC recently, as the topic is picking up more steam than ever before. The company StillSecure.com for instance, publishes a bunch of interesting papers on the topic.

Virtualization (or: it's about time)

Virtualization is everywhere these days (duh.) Because of increase in hardware performance, security requirements and the need to run several OS on one system, virtualization is now mainstream enough to be offered on desktop operating systems for the masses to use (Linux, OSX, Windows.) It is so far a x86 game only, although hypervisors for other architectures (like XScale) are in the work.

Hardware vendors are adding a lower level of instructions to help writing hypervisors that will control the VM supporting operating systems running at their current priviledge level. This pushes the security one level down while offering the devastating ability to compromise the software that manages the execution of all operating systems on the platform. This thread could be circumvented by the use of the TPM/PKI to ensure that the hypervisor isn't being tempered with (take a look at this diagram)

Some articles I should have read a long time ago.

There's certainly hope that hardware will address some of the existing performance degradations brought by virtualization. Some applications that could greatly benefit from virtualization can't suffer the I/O performance degradation that existing virtualization technology fails to entirely alleviate.

Firewall failover

I just ran into a nice write up of stateful failover capable firewall running BSD pf.

• CARP (Common Address Redundancy Protocol) is used to switch identity during failover and CARP traffic is used as a measure of the availability node (the master advertises using CARP and if the backup doesn't hear from its master, it'll start advertising itself. Carp is IP protocol #112. CARP has a ARP balance feature that can be used to direct traffic to particular hosts and can be seen as similar to VRRP but presents the further advantages of being more secure and not encumbered by patents.
  

• pfsync implements the IP protocol #240 and performs connection state synchronization so that a stateful failover (i.e. not TCP connections are lost) can be supported. A node joining the firewall cluster will receive a bulk update of the existing connections and then will be updated periodically on a best effort basis.

STP based attacks.

Following a link from the Linux Bridging Ethernet project, I got to read about the security implications of bridging and the use of the STP (Spanning Tree Protocol.) The attacks are all based on abusing:

1. The inherent trust that exists between bridging equipment in terms of Bridge Protocol Data Unit acceptance.
2. The implementation of the topology management that mandates ports to sometimes (partially) block traffic.

Here are some possible attacks:

• Trigger eternal elections of the bridge root. Upon detection of prediodical BPDU packets, the attacker replies with a BPDU claiming that its root status superceeds the one expressed in the packet it just detected. While in bridge root election mode, traffic forwarding on ports is disabled, the eternal elections lanch a DoS attack.
• This type of election based attacks can be made localized, isolating clients on one segment served by a bridge from a server located on a segment served by an other bridge, giving a chance to the attacker to impersonate the server.
• An attacker equiped with links to two independently connected bridges can sever the bridges connection (by initiating and winning elections to be the designated bridge for the two segments) and becomes trusted in forwarding packets between the two bridges, effectively perpetrating a MITM attack.
• STP extensions disabeling the Learning state on user ports (Port Fast, Fast Start, etc...) for reasons of responsiveness will, upon perpetual elections, force the switch reset its switching table making the interfaces in then promiscuous mode subject to APR cache poisoning and the like types of attack.

In the light of these vulnerabilities, assessment of the use of STP as well as the STP enabled equipment deployment should be made and decisions on STP use should be taken.

HTTP request smuggling.

This paper recently posted on /. introduces HTTP request smuggling as a way to exploit discrepencies in the way applications parse HTTP/1.1 requests and act on their content.

Specially crafted combined HTTP requests can lead one application to see a certain request with a certain content. The data then reaches a second application where it is decoded differently:

HTTP_REQUEST .... ; Seen by application A and B
...
HTTP_REQUEST ... ; Seen by application B
...
HTTP_REQUEST ... ; Seen by application A

This discrepancy is exploited to:

• Poison a web cache: the web cache A sees content 1 but the web server B see something different and instead serves content 2 that gets associated with content 1 by web cache A.
  
• Make a firewall such as an unpatched FW-1 R55W not see malicious content in a page and passing it down to IIS where it will be wrongly absorbed (because of a IIS limitation/bug.)
• Smuggle an XSS attack.
  

HTTP request smuggling gravitates around misformed HTTP requests such as:

• Double content-length statements advertising different lengths -- some application pick the first as being the right one, some pick the second one as being the right one, leading to different content interpretation.
• GET requests plus content-length.
• Buffer size limit anomalies, such as the IIS/48k limit
  

What's really to blame in HRS is that all implicated applications are using different HTTP parsers, with different interpretation of edge and borderline cases. The HRS techniques is similar to the HTTP Response Splitting, presente here: HTTP response splitting relies on application bugs that will generate two responses for one request, with the second response content being controlled by the attacker -- the attack works by sending a first crafted request to the application that will generate two responses. A second request is sent to be matched by the second response. Imagine that the two responses are managed by a web cache, cache poisoning is effectively achieved.

Firewalk

I've been reading a bit about firewalk, a traceroute variant with knowledge of what a firewall might
do in order to stop traffic at its door. Here are some notes.

On using traceroute

• Letting traceroute use UDP packet and watch it not being able to report on tells us that some filtering is happening on some hosts. For instance, if we see this in our traceroute output:
  

  13  193.251.243.30  180.328 ms  183.666 ms  172.724 ms
  14  * * *
  15  * * *
  

  We know that at 193.251.243.30 some UDP filtering is happening. If instead we force traceroute to send ICMP packets (-I option,) we might start to see what's behind the filtering host:
  

  
  13  193.251.243.30  164.937 ms  169.354 ms  170.566 ms
  14  193.251.251.54  175.550 ms  177.654 ms  173.038 ms
  15  193.252.117.254  173.594 ms  170.467 ms  180.090 ms

• If the filtering host was blocking ICMP traffic as well, we could try to tickle it with some other UDP traffic it might accept such as DNS. The trick is then to reach the host with the right port number (since traceroute increment the port number for each attempt made) The computation is rather simple, based on the number of hops and the number of attempt. With the-p option, traceroute traffic will reach the filtering host with the right port number. It's also easy to modify traceroute source code not to increment the port number, so that tracing can start at a static port number of your choice.

Firewalk

Firewalk use a combination of all these methods and works once you've (1) discovered a gateway (like 193.251.243.30 in the example above) and (2) discovered a host behind the gateway (like 193.251.251.54 in the example above.) It will send the IP traffic of your choice to ports, using the right TTL in an attempt to find out what's behind the filtering agent, hereby obtaining a map of interesting hosts behind a firewall.

While reading the firewalk paper, I wrote a unpretentious perl script that invokes traceroute and tries to report any host that will do UDP filtering (by comparing the invocation of traceroute with using UDP or ICMP.) Just for kicks, it'll try to add geo location information with the hosts it discovered. Here. Here's an invocation sample:

  $ geotraceroute.pl wanadoo.fr -geolocate -flag_gw
10.2.0.1:  Marina Del Rey, California, United States.(lat=33.98, lon=-118.45)
10.10.72.254:  Marina Del Rey, California, United States.(lat=33.98, lon=-118.45)
209.172.100.193:  San Jose, California, United States.(lat=37.34, lon=-121.89)
209.172.121.229:  San Jose, California, United States.(lat=37.34, lon=-121.89)
209.172.123.1:  San Jose, California, United States.(lat=37.34, lon=-121.89)
140.174.37.61:  Englewood, Colorado, United States.(lat=39.58, lon=-104.90)
129.250.26.38:  Englewood, Colorado, United States.(lat=39.58, lon=-104.90)
193.251.250.41:  Amsterdam, North Holland (province), Netherlands.(lat=52.35, lon=4.90)
193.251.240.2:  Amsterdam, North Holland (province), Netherlands.(lat=52.35, lon=4.90)
193.251.241.133:  Rue, Somme (department), Picardy (region), France.(lat=50.27, lon=1.67)
G 193.251.251.54:  Rue, Somme (department), Picardy (region), France.(lat=50.27, lon=1.67)
193.252.117.254:  Issy-les-moulineaux, Hauts-de-seine (department), Ile-de-france (region), France.(lat=48.82, lon=2.27)
193.252.122.2:  Issy-les-moulineaux, Hauts-de-seine (department), Ile-de-france (region), France.(lat=48.82, lon=2.27)
193.252.122.18:  Issy-les-moulineaux, Hauts-de-seine (department), Ile-de-france (region), France.(lat=48.82, lon=2.27)
193.252.122.103:  Issy-les-moulineaux, Hauts-de-seine (department), Ile-de-france (region), France.(lat=48.82, lon=2.27)

Notice the entry marked with a leading G. It indicates that this host filters UDP but not ICMP. It might just be a gateway. With netpbm it should be possible to map all the entries on a world map. Supported flags are -debug, -resolve, -flag_gw and -help.

Metasploit

I'm looking at the Metasploit source code. It's written in Perl and fairly well organized. It seems to contain libraries that are worth looking at. A couple notes:

• It ships with NetPacket, a perl package that allows for packet crafting -- neat, just combine it with Pex::Racksocket
  
• Their lib/Pex section contains all sorts of routine for low level manipulation of data available as packages. For instance, the x86 one can help you generate x86 machine code. It's used to achieve parametrization of an exploit or a payload.
• But I saw also mention of InlineEgg, which per its documentation seem to be even more powerful.
  

DNS Cache poisoning

Read this good Honeynet article on phising, I followed links of pharming or how to redirect traffic to a known site to a site of your choice, which can be achieved by DNS cache poisoning.

Basically, once you tricked a DNS server to consult an other DNS servers, the information sent back can contain new IP address assignments for some domain names -- anything goes as far as having the victim DNS server consult an other DNS server: email to a non existent user, embedded image links in email, banner ads, etc.

If your DNS software is flawed or not configured properly (NT4 and 2000 have insecure default configuration,) it will accept these as a replacement of what it already knows about the said domain names. M$ is of course the prime target, and also some DNS packages from other well known security companies. Nice.

Crypto Refresh.

I 'm refreshing my knowledge on applied cryptography.

Symetric cryptography:

• Symmetric/public key crypto: parties share a secret, for instance an encryption key. Shared secrets must be communicated securely (with appropriate public/private key crypto, agreed upon generated key after secret signing, via a third party, etc... methods abound.)
• Two set of primitives: symetric encryption algorithms (ensure data secrecy) and message authentication codes (MACs) to ensure data transmission integrity.

Example of an symetric encryption scheme:

• A block cipher mode and encryption method must be selected
• A key is picked, for instance, a password can be used to generate a key (involves salt, iteration numbers.)
• The block cipher mode determines how the the encryption method will be used. For instance, it can be choosen to prevent the same unencrypted input from yielding the same crypted output (better resitance to dictionary attacks.) For instance one could XOR the first chunk with a randomly generated string (an IV: initialization vector, which has to be transmitted) and then have this block encrypted. For the next block use the previously encrypted block for the XOR operation (this is how CBC works -- just encrypting blocks as they come is ECB, a bad block cypher mode.)
• At the heart of the modern computerized encryption schemes are Feistel rounds which use permutation boxes, substitution box (S-boxes) on subkeys and the data to encrypt to achieve Shannon's confusion and diffusion.
  
• Recommendation would be to use CBC/AES.
• Outside of block cipher mode consideration, decryption is achieved by either running the same encryption scheme on the encrypted data, or by running a dedicated decryption function.

Hashes and messages authentification codes (MACs):

• Cryptographic hash function: process input and produce a fixed sized output (hash value or message digest.) Properties: one wayness, noncorrelation (bit flip resistant) weak/strong/partial collision resistance.
  
• Universal hash function: keyed hashes.
• MAC: hash function processing a message with a secret key (+ possible nonce) to give output that can't be obtained without the key.

Public key cryptography, digital signature:

• Involves large prime numbers and factorisation properties.
• Allows for key agreement, digital signature and identity establishement.
• Note that its 1000 times slower than symetric key cryptography when comparison is applicable.
• RSA (does all) Diffie-Hellman and DSA (digital signatures only.)
  
• Public/private key crypto: your public key is available to parties use to encrypt data that only you and your private key can decrypt.
• PKI is used to establish trust between entities. Before using a public key, you must be sure it belongs to who you want to send a message to. Signature: a document is hashed, and the result encoded with your private key. Parties can use your public key to retrieve the hash and compare it to what it's expected to be. If the hash can be decrypted with your public key, you must be the one that signed it with your private key.

Signing and encrypting with public/private keys:

• Concatenate the recipient's public key with the message and sign/encrypt the result
  
• Simply signing and encrypting the signature and the message doesn't work as an intermediary can re-sign with somebody else's public key.

Key and certificates encoding:

• Keys and certificates can be encoded to a binary object (DER: Distinguished Encoding Rules encoding)
• Keys and certificates can be encoded to plaintext (PEM: Privacy Enhanced Mail encoding)

Authentication and Key Exchange:
Further read here. A nice concise presentation on some crypto basics here.

Channel Attacks

This excellent page (along with a really good paper) made me discover the concept of channel attack. Basically, a channel attack consists in discovering something about data being processed by measuring the side effect of processing them, such as latency or even power consumption. Here's an other paper on channel attacks. Fascinating stuff as they seem to be really hard to close (they rely on the nature of the data processing that is being performed.)

The page that triggered the post speaks of channel attacks in the context of hyperthreading able CPUs. Recommendation to limit exposure are numerous:

• HT aware cache sharing prevention
• OS level prevention of execution of applications of different privilege level on the same core.
• Crypto library should be redesigned to prevent channel attacks

Now here's something about an instance of side channel attack, and the process of a side channel attack is presented here.

Cross Site Scripting

A recent Firefox security alert raised the possibility of cross site scripting vulnerabilities for Firefox users. As I didn't know anything about cross site scripting, Google came to the rescue and pointed me to this handy PDF. The idea is to entice the victim to visit a legitimate web site while forcing its browsing agent to execute malicious code while vising the site.

How does malicious code gets embedded in a page served by an uncompromised server? For instance by placing that code into a CGI parameter the targetted site accepts and whose content be will served back to the user. The malicious code, usually Java Script, can then access user sensitive information stored in the navigator and send them back to a web site set by the attacker for data collection -- cookies are a prime target (i.e. document.cookie) since, under certain circumstances and with cookies set properly, one can access a web site while impersonating a legitimate user.

The <script> is the one that comes to mind to be used to trigger JavaScript execution by the victim's web browser while accessing a legitimate site, but other tags like <img> could be used as well (through a src attribute set to javascript:.... Even form's input widget value tags could be used to carry mallicious data through the use of a "> to allow for free HTML escape.

Of course, besides the operator clicking through a possibly unsollicited URL it was provided with, the fault lies in the site that serves parameter values back to the user without doing any sanitization performed on their content (or input validation.) The web application should be written to check incoming parameters for acceptable values and discard or reject anything that could be abused -- the parameter input range should be carefully specified in that regard. Note that all input sources should be subject to filtering: query parameters, body parameters of POST request and HTTP headers.

Output filtering could also be performed on the web server prior to sending the page back to the victim, and content inspection capable firewalls could also be deployed for ingress and outgress filtering.

See also: CSRF or XSRC (Cross-site Request Forgery:) here.

Secure Programming Cookbook.

A coworker lent me a copy of O'Reilly's Secure Programming Cookbook. Just by reading the table of content you get an idea of what you should be thinking about, the rest really are (as being a cookbook) implementation details.

Some notes on file use:

• Don't create a file using fopen as the permissions are 0666 (umask modified.) I never liked the f function anyways.
• Avoid TOCTOU (Time of Check Time of Use) race conditions (before the time you check and the time you use, the attacker as done something to your target and you operate on something that's not what you thought of in the first place.) The best way to avoid these when dealing with files is always to operate on the file descriptor, as the underlying file object doesn't change. If you're using function relying on a string to determine the filename you're 1) wasting cycles and 2) exposing yourself to a TOCTOU based attack.
• Unix/Linux doesn't support mandatory file locks very well. Windows gets it right (a file lock is a lock that, once aquired on a file, prevents other processes from accessing the file in the way described by the lock while the lock is held.)
• To make sure a temporary file can't be used by anyone else: after the file has been opened, delete the file. The process owning the file descriptor will still be able to use the file, while no one else will because the file doesn't exist by name.

On botnets.

The other day I was reading an this link from an entry of .tHE pRODUCT blog. It linked to a recent Honeynet piece on botnets. The article is fascinating and well worth the read. It yields very valuable URL for further exploration on the topic. Here are a few notes.

Here's how a botnet is built:

• Vast section the public internet are scanned
  
• Attacks are launched on 445/TCP (M$ directory service), 139/TCP and 137/UDP (netBios) or 135/TCP (M$ RPC.) Unpatched XP or SP1 patched XP hosts consitute the bulk of the victims
• An IRC client (IRC bot) is installed on the system and it connects to a central server from where they can be managed (uploaded software for instance) or used (DDoS attacks, spamming, keylogging, attacks on IRC networks, Google AdSense and other automated clicking abuses, etc...)
  
• Once compromised, a machine will try to compromise more systems (such as its peers as reachable through examined system configuration)

A compromised machine is called a Bot. A collective of bots is a botnet. Botnets can comprise hundreds of thousands of machines. They are built and used for fun and profit. Note that an unpatched and unprotected Windows box will be compromised within 10 minutes or less on average.

Here's how bots are caught:

An attractive victim (honypot) is placed behind a honeywall, a system running snort_inline so that the IRC traffic can be observed while rendering the bot harmless. The IRC client is also replaced by something that won't be detected as foreign when the bot joints its botnet -- honeypot wrote their one called Drone.

Passive OS fingerprinting.

The classic on OS fingerprinting is here. Active OS fingerprinting relies on sending packets (mostly TCP and ICMP) to open or closed ports and observing the answer, but this is rude.

p0f is a passive OS fingerprinting that allows for all sort of interesting application. It works best when it sits waiting for packets to showup for analysis. For instance, it could be installed on a web server to look at incoming TCP packets to find out what is connecting to it.

Here's how it figures certain things:

• the uptime: the timestamp on SYN requests here (but this depends on the OS: Linux seems to be using ctime, Windows is using some HZ increment.)
  
• The link type: with the gathered MSS/MTU (packet -vs- payload size) values
• NAT: analyzing disparities in fingerprinting received for the same IP (link type, OS identification, etc...)

Just a few hints:

• Look at the TTL value in the received packet and do a traceroute to figure the TTL: 64 is common for Linux/BSD, 128 could be a Windows box
• Look at the Window Size: 0x1600/0x2D00 or so and somewhat constant through the connection is common for Linux.
• Changing through the life of the connection is common for Windows.

Mention of p0f fetched here.

ARP poisoning, port stealing and MITM.

ARP poisoning:

As explained here, one can craft ARP packets with some destination IP and the attacker MAC address to poison an ARP cache: the existing ARP entry matching the destination IP address is updated with your MAC address. Next time a packet flies to the destination IP address, it gets to you -- you can use packet forwarding to still deliver the packet to destination. Note that since ARP cache entries expires, it may be necessary to send the bogus ARP packet periodically. Different type of ARP messages might have to be used to poison ARP caches of different type of hardware/OS peers.

The ARP protocol is stateless. Most OS update their caches with ARP replies without having ever solicited one. Some, like Solaris, are a little tougher but in this case, one can trigger an ARP request by creating a spoofed ICMP request: you ping a destination with IP and the attacker's MAC to force an ARP request, after what you send the fake ARP reply. Circumventing ARP poisoning can be done through active/passive monitoring, static ARP (not flexible) or Secure ARP.

MITM Attack:

Sniffing would get you there in terms of observing traffic, but it doesn't give you the ability to prevent host IP from seeing its traffic before you do. What you achieve effectively is a MITM: Man In The Middle attack where one can sit listening and relaying traffic between two hosts without the hosts being able to tell. As for the actions the MITM can take, they're numerous: injection (commands, insertion of malicious code in JS, etc... -- sequence number modification required of course), key manipulation, filtering, etc...

Port stealing:

This ARP poisoning based MITM attack works better on a local network segment. In order for it to work in a switched environment, you need to steal the switch ports by sending to the switch packets with the relevant MACs of the hosts you want to intercept traffic from so that the switch modifies its CAM table. Once the traffic is captured, you need to reset the CAM entries to be able to resend traffic to its rightfull destination -- this has to be done for every packet, that's a lot of work and traffic might be dropped. Port stealing can be circumvented by using port security on the switch.

More info on that here. here and here.

Of course, all this rogue packet crafting is done using libnet.