##security (freenode) official blog

Privacy and Secrecy on Untrusted Networks

2012-01-18T19:10:00.000-08:00

A common question that comes up in the channel quite often is to how to keep your internet traffic "private". Of course, "private" can mean many different things, and the answer to this question can vary quite a bit depending on what you're trying to keep private from.

People tend to fall into 3 categories.

Want to hide your traffic from the local network
Want to hide your source from a remote website
HIDE ALL THE THINGS!

Before we get into specific solutions for these problems, lets talk about potential solutions at a high level.

SSL

I'm sure at this point you're familiar with SSL. SSL provides transport layer

security between your browser and a remote server. There are potential attacks against SSL, but for the most part it does a good job of preventing someone from eavesdropping on your traffic. Of course, that depends on the remote service supporting SSL. If the remote system you're accessing does not support SSL, there's nothing really you can do to add it.

It will not prevent any eavesdropper or the website operator from knowing your IP or what webserver you are visiting.

Tor

Tor provides anonymity by encrypting your network traffic through a series of intermediate nodes before sending the traffic out through an "Exit node". The traffic from the exit node then looks like it would have without Tor in the first place.

Tor does an excellent job of hiding your source IP address from remote websites. There are attacks to bypass this level of anonymity, but in most cases it works out well. It also does a good job of hiding the content and destination of your traffic from attackers on your local network (are you on unprotected wifi at a coffee shop?)

A big warning though. Unencrypted traffic (http, imap, pop3 or smtp without SSL), can be sniffed by the owner of the exit node, much like if someone was on the same open wireless network as you are and you used these sorts of protocols. So who are the people who own these exit nodes? Quite often they are security researchers, government agencies, or other people with vested interest in sniffing your traffic. So you may be trading a small risk for a much larger one.

VPN

VPNs and VPN like systems (SSH forwarding, SSH SOCKS proxy support, etc) allow you to essentially forward your traffic to a remote location where it is then sent unencrypted.

Much like a Tor exit node, the owner of the VPN server may sniff any unencrypted traffic. The difference is who owns the VPN server. Chances are the system is owned by you, the company you work for, or a service you're paying money to. A bit more trustworthy than an exit node operator, although SSL encryption is still recommended.

So going back to the 3 problems.

Want to hide your traffic from the local network

SSL is a good basic option. For traffic that doesn't support encryption, or for things that are a bit more sensitive, add a VPN service of some sort. Running a VPN type service on your home system may be a good option if you're comfortable setting one up.

Want to hide your source from a remote website

Assuming you really need to hide your identity, Tor is your best option here. A VPN would transfer your source IP from your current IP to the VPN endpoint... but who owns that endpoint? Is it a system you own? One you're paying for a service from (vulnerable to a subpoena)? Your employer?

Just make sure you take the necessary steps to protect any login credentials, or

sensitive content.

HIDE ALL THE THINGS!

Perhaps you should talk to a therapist?

New DoS in Bind - What it means

2011-11-17T18:08:00.000-08:00

Yesterday ISC announced a new vulnerability in bind that appears to be getting exploited in the wild. So far it appears to be a denial of service (DoS) only, causing a crash in recursive nameservers. There is no impact to authoritative only nameservers (authoritative that are also recursive could be impacted). I'm not quite certain if the crash is caused by badly formatted requests or responses, and if the record type matters.

So what does this mean to your environment?

Well, first, you'll want to patch your recursive nameservers (the nameservers dedicated to allowing your users to turn names into IP addresses). Your exposure should be limited since your recursive nameservers should be limited to just your users. You are limiting your recursive nameservers to your user IPs, right? If not, go do that as well. There are a number of problems that can be caused by having your nameservers open to the general public.

Now, you likely have authoritative nameservers as well for allowing your customers to look up IPs for your servers (www.yourcompany.com). These boxes should be save as long as your authoritative nameservers don't have recursion enabled. If they do, disable it. Keeping those services separate is definitely a good idea. In this case, someone could take your company off the internet by exploiting the vulnerability.

Now a number of people like to run recursive nameservers bound to localhost or restricted to just the local system via firewall rules. Are these boxes safe? Well, it depends. Now is where the questions about request versus response, and request type really matter. With these restrictions, sending a malicious request would be difficulty (assuming it is a bad formatting of the request itself). Getting the box to receive a malicious response could very well be possible, depending on what the box is doing.

Run an SSH daemon? SSH daemons are often configured to look up DNS records for the IPs that connect to them. A malicious PTR (reverse DNS) record could get you. The PTR record is then looked up in an A record query in order to make sure they match. A malicious A record could get you.

Proxy server? Pretty easy to trigger a proxy to look up an IP.

Web Browser? A malicious webserver can get you to look up all sorts of things.

SMTP servers do a lot of reverse and forward lookups.

Malicious responses could crash DNS and cause service outages in a lot of these cases. Now, maybe the DNS server doesn't matter so much on these boxes. That's something you'll need to decide on your own based upon your own requirements.

SSL/TLS Basics

2011-11-16T18:18:00.000-08:00

SSL and TLS are a big part of security on the internet, and is often not very well understood by users or by sysadmins alike.

History of the Protocol

SSL got its start back in 1994 with version 2.0 (Initially labelled 0.2), authored by engineers at Netscape. Due to vulnerabilities in the protocol, it was replaced by SSLv3 in 1996. Future development of the protocol was handed off to the IETF, including a rename to TLS in 1999.

Since SSL version 2 was replaced by version 3 so long ago, backwards compatibility from older clients is NOT necessary or desired.

Quick Intro to Cryptography

Before we get started on SSL itself, it is useful to have a very high level understanding of the difference between various types of cryptography.

There are two major types of cryptography, symmetric and asymmetric.

Asymmetric cryptography, or public key cryptography, is a system which uses a pair of keys for encryption purposes. The user generates a private key and a public one. Messages encrypted with the public key can be read by the private key, and messages encrypted with the private key can be read by the public key (for message signing purpose). Examples of asymmetric crypto include RSA and DSA.

Symmetric cryptography uses a single key which both the sender and receiver need to have a copy of prior to communication occurring. Examples of symmetric cryptography include des, 3des (triple des) or AES.

Symmetric crypto is much faster than asymmetric crypto, and is much more secure while using small key sizes. DSA uses a key size of 1024 bits while RSA is commonly used at 1024, 2048 or 4096 bits. AES on the other hand is most commonly used at 128 or 256 bits.

How SSL uses Crypto

SSL uses a combination of both symmetric and asymmetric crypto in order to secure access to websites (or other services).

Webservers are configured with a key pair made up of a private key (typically RSA), and a public x509 certificate which has the matching public key embedded in it.

The x509 certificate includes a number of fields including valid dates, a Common Name (CN) which identifies the site the certificate belongs to, and various other identifying fields. The cert is signed by another RSA cert which belongs to a Certificate Authority (CA) which is trusted either directly or indirectly by the browser.

As a browser hits a website, an SSL handshake occurs. At a high level, this handshake includes the client sending a list of suggested symmetric ciphers and compression methods. The server sends its public cert and a random number and selects a cipher to use for the session. Assuming the public cert verifies properly or the user chooses to accept it, the client then chooses a PreMasterSecret and encrypts it to the server's public key. The client and server then use the PreMasterSecret and the random number to create the symmetric key to be used in the agreed upon cipher.

Once the browser and cert have agreed upon the symmetric key and cipher, the rest of the session is encrypted using symmetric crypto, which is faster and more secure. This is why you generate a 1024 or 2048 it key for your webserver, yet hear recommendations to use 128 or 256 bit key strength.

X509 Cert Validation

X509 certs are validated using PKI, which is more than I really want to get into right now. Lets just say it brings a whole giant mess of additional complexity and weakness into the picture.

More Info

For more info, the Wikipedia article on TLS is very well written.

Starting over with IPv6

2011-03-07T17:31:00.000-08:00

Well, I finally decided to take the plunge, and start to learn IPv6. I figure I might as well be the guy that waited until the last minute instead of being one of the millions that waited until AFTER the last minute. As it turned out, it wasn't as bad as I thought it was going to be.

I got started after I saw a question on Reddit looking for good reading material. One of the top links was a rather good primer on ipv6. From there I decided to get access to an ipv6 tunnel, and work on obtaining a free IPv6 certification from Hurricane Electric.

I looked at two different tunnel brokers. First I looked at Hurricane Electric's offering. Unfortunately they tunnel over Protocol 41 which can be a bit difficult to deal with behind a NAT since home routers may or may not provide you with the ability to forward non-TCP/non-UDP traffic.

After that didn't work out, I looked at Sixxs.net which ended up working out a lot better for me.

The process for dealing with Sixxs.net is a bit slow. They are rather careful about who they give out IPv6 connectivity to and what you're able to do, so you can get bogged down a bit in the approval process. It took me a day for my account to get approved, then another day for my tunnel and finally a third day to obtain my own subnet.

Once all was said and done, I had my FreeBSD box acting as the local end of my tunnel using AICCU. Sixxs was routing my own personal /48 network to the FreeBSD box which was then using radvd to announce the route on my local network. My Mac, Android and Linux devices were all able to autodetect their new IPv6 IP address without using DHCP and used it in addition to their existing RFC1918 space IPv4 addresses in order to retrieve content.

I even got around to finally learning to use Pf in order to filter the new inbound IPv6 range. If you try this yourself, just remember that your IPv6 range is tunneled directly to a system on your local network, and your existing firewall rules will likely do nothing to protect these IPs. Be prepared to enact IPv6 filtering rules ASAP.

Its definitely worth the time and effort to learn this stuff. You get to join a relatively small set of people who have hands on knowledge with IPv6 networking so you'll be getting a leg up on the competition. Besides, its all so new you'll get an opportunity to find all of those devices that don't handle IPv6 quite right. What else could you want as a security guy?

Invisible IP Addresses

2010-11-19T07:50:00.000-08:00

I stumbled across something interesting the other day. I was working on a webserver which was configured to listen to traffic on a specific IP address defined within the Apache configuration. Oddly, this IP address did not show up in ifconfig, but the box WAS serving traffic for it. Even an ifconfig -a failed to show the IP. My only theory was that since the interface was brought down AFTER Apache started listening to that IP, it was somehow still wedged up.

So I confirmed the network init scripts, and rebooted the box. After the reboot, the device once again began listening to this "unconfigured" IP. As it turns out, this was due to how the interface was being configured.

/sbin/ip addr add 10.1.8.2/8 dev eth0:1

# ping 10.1.8.2 -c 1

PING 10.1.8.2 (10.1.8.2) 56(84) bytes of data.

64 bytes from 10.1.8.2: icmp_req=1 ttl=64 time=0.036 ms

--- 10.1.8.2 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.036/0.036/0.036/0.000 ms

# ifconfig eth0:1

eth0:1 Link encap:Ethernet HWaddr 00:25:64:c2:2f:6d

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

Interrupt:21 Memory:febe0000-fec00000

# ip addr list

2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000

link/ether 00:25:64:c2:2f:6d brd ff:ff:ff:ff:ff:ff

inet 192.168.1.57/24 brd 192.168.1.255 scope global eth0

inet 10.1.8.2/8 scope global secondary eth0

inet6 fe80::225:64ff:fec2:2f6d/64 scope link

valid_lft forever preferred_lft forever

Apparently that if you add an additional IP address to an interface using ip addr, it does not show up in ifconfig unless you add a label to it.

/sbin/ip addr add 10.1.8.3/8 dev eth0:2 label eth0:2

# ifconfig eth0:2

eth0:2 Link encap:Ethernet HWaddr 00:25:64:c2:2f:6d

inet addr:10.1.8.3 Bcast:0.0.0.0 Mask:255.0.0.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

Interrupt:21 Memory:febe0000-fec00000

Seems like an interesting way to hide an IP address on a system. Most people I know use ifconfig rather than "ip addr list" to get a list of IP addresses on a box.

SSL Chaining - The RFC

2010-08-19T10:21:00.000-07:00

Quick follow-up on gdfuego's post.

From RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Section 7.4.2):

   certificate_list
   This is a sequence (chain) of certificates.  The sender's
   certificate MUST come first in the list.  Each following
   certificate MUST directly certify the one preceding it.  Because
   certificate validation requires that root keys be distributed
   independently, the self-signed certificate that specifies the root
   certificate authority MAY be omitted from the chain, under the
   assumption that the remote end must already possess it in order to
   validate it in any case.

There's no reason why a web server can't infer the order of the chain from Issuer and Subject relationships. However, there's no guarantee that any given server will do this for you unless they state this as a feature.

The key thing is that it is part of the protocol that the certs be provided already in order.

Yes Virginia, SSL Chain Ordering Does Matter

2010-08-19T08:30:00.000-07:00

If you've ever deployed an SSL certificate from a major SSL vendor, you've probably seen mention of chain/intermediate SSL certificates. These certs are available for download when you retrieve your newly signed cert. But the big question is, are you doing the right thing with them?

A bit of background

All web browsers out there ship with a set of root certificates. These are certificate owned by certificate authorities for the purpose of signing SSL certs. Any form of public key cryptography requires some form of security public key distribution, and the way SSL handles this is through these bundled root certs.

Root certs are dangerous though. If someone was to compromise your root cert, you'd need to "revoke" it, which in this case essentially means getting it removed from every browser on the Internet. You'd also have to get them a replacement, which is a similarly daunting task. Due to this, the authorities out there typically use their root certs to create a subordinate root. This is a certificate authority which is granted the right to sign other certificates by the root cert within your browser. Replacing a subordinate is a LOT easier as they can sign additional subordinates as desires, and they can provide an online revocation method in case of compromise.

So root certs typically sign subordinates, and subordinates sign your cert. Note that there are some exceptions to this. For example, Thawte signs all their certs with their root. You can also pay extra to other CAs for a root signed cert if you have a reason to need one. Last time I looked at a price for something like that, it was around $3000 from a middle of the road CA. God knows what someone like Verisign would charge.

What this means

So you bought a signed cert, and you're loading it on your webserver. Browsers try to validate this cert, but it is not signed by one of their trusted roots. In order to validate your cert, they need to have a copy of the public cert for the subordinate root. This certificate is typically called either a chain cert or an intermediate. And now we're back to where I started.

In order for the browser to get a copy of this chain, your webserver should be configured to send the intermediate after your certificate. Then the browser can follow the chain back to the root that it originally trusted. If you leave this out, browsers will tend to fail to validate your cert. Note that these failures may be intermittent and I believe some browsers will actually cache chain certs. So if someone previously visited a website who's cert is signed by the said chain, they may not get an error.

In Apache, you specify the file with the certificate chain using the SSLCertificateChainFile variable in mod_ssl.

Multiple Intermediates

And here's where things go to hell. You can have a certificate signed by an subordinate signed by a subordinate signed by a root. Or a longer chain than that. You handle this case by including ALL of the chain certs within the file specified by SSLCertificateChainFile.

The place where people screw up is with the ordering of this file. The certificates should be specified in order by who signed what. So if you public cert is signed by sub2 which was signed by sub1 which was signed by root, your chain file should have sub2 and then sub1. If you screw up the ordering, some browsers will report a problem while others do not. In fact, I find that while FireFox and IE don't care about ordering, the browser on Android phones do, which can be rather confusing to server admins.

Detecting Problems

There's an easy way to make sure that you got the ordering right:

openssl s_client -showcerts -connect server:443

Openssl will print the certs in the order that they were recieved. You can ignore the certs and just look at the descriptions above them. Each cert should have an "s" line and an "i" line. This signifies the "Subject" and the "Issuer" of the cert.

The first subject should be your website. The first issuer is the CA that signed your cert.

The next subject should match the issuer line of the previous cert. The next subject should match the issuer line of the previous cert. All the way to the end.

If they're out of order, fix em.

Blippy exposes credit card info

2010-04-23T13:02:00.000-07:00

Apparently Blippy accidentally leaked credit card information.

If you're not familiar with Blippy, they're a social networking site that allows you to link your credit card to their site, and they automatically publish information about when you buy things and what you're buying.

I mean, what could go wrong?

Man-In-The-Middle Attacks - Part 2

2009-12-31T09:26:00.000-08:00

Ok, so last time we talked about MITM attacks on a local network. Its a pretty trivial attack that is hard that can be difficult to protect against. That being said, your attacker would need to have access to your local network in order to pull it off. This could be an issue on a corporate network, campus network or open wireless network, but you should be pretty safe at home (your wireless is protected, right?).

Once the packets leave your network these attacks are a lot less feasible. Competent broadband providers should provide protections against this form of attack on their networks through strict MAC address and IP address bindings to your local cable/dsl modem. If they don't, then they're probably incompetent in other ways as well. Grab yourself some extra IPs while you're there.

After the connection between your house and their equipment you should getting into the realm of routers... Real routers, not the dinky Linksys box you have at your house. Rackmount jobs put out by Cisco, Juniper and others. These devices are setup with point to point long-haul connections and peering setups with other network providers. Your not going to be able to do mac level spoofing on the network connection of one of these devices.

One quick disclaimer. In the past I have been responsible for various types of managed switches, but I have never been responsible for high end routing gear. I have read about various attacks on them, but I lack the real world experience to provide anything in depth on the topic. If anything below is incorrect somehow, please let me know and I'll correct it.

In our previous example we looked a system's routing table. You saw a route which sent any local traffic to the local LAN and a default route which sent all other traffic to a dedicated router. ISP routers also have routing tables, but they are MUCH more complex and are remotely updated regularly via protocols such as BGP. BGP feeds from trusted sources are combined with statically defined routes in order to create cost based routing tables.

How a MITM attack would work

If you're looking to perform a man in the middle attack at this layer you would essentially need to find a way to manipulate the routing tables on the router. If you managed to pull this off you'd be able to direct traffic to an IP address to a different network which could then answer the requests. For example, if you managed to do this to a Comcast router you could cause some portion of their users to hit your systems when they make a request for 66.249.91.104 (one of the IPs for Google).

Own the router

The "simplest" way to manipulate the router would be to get remote administrative access to it. This could mean brute forcing the telnet/SSH password or SSH key, using exploit code (no where near as easy to find as exploit code for user OS systems) or through physical access means if you happen to have the ability to walk up to one of the devices.

Own a peer

Routers establish BGP sessions with other trusted systems in order to obtain updates to their routing tables. If you can find a way to manipulate that system then you can leverage that trust relationship. BGP sessions can be established with Unix or Windows servers in addition to other routers so you may have better luck hitting the peer than you would the router itself. Even if you can own a system on the same network as the peer you may be able to leverage LAN MITM techniques to hijack the traffic.

Conclusion

Attempting to perform a MITM attack at this level is much harder. It would require a higher level of skill on the part of the attacker and barring a newly discovered vulnerability it would require that the network admin (or someone they are trusting) to make a mistake.

Preventing Man-In-The-Middle (MITM) Attacks

2009-12-21T20:07:00.000-08:00

Occasionally people pop into the channel asking how to prevent man in the middle attacks. In fact, one guy popped in several times today under different screen names and asked the question over and over again.

Well, the short answer is that you can't. Man in the Middle attacks are a general concept which can refer to any number of specific attacks all of which require different techniques to deal with. This question would be a lot like asking someone how to prevent theft. The techniques you use to stop someone from stealing your wallet won't help protect your car, your identity or your data.

For a longer answer we can look at how networking actually works, and then look at the potential places where man in the middle attacks may occur and what you can do about them. This is a rather broad topic, so for now we're just going to talk about the LAN and we'll add the rest in later posts.

Lets start with a home LAN using tcp/ip for communications. You have multiple computers plugged into an ethernet hub given IP addresses within the 192.168.1.0/24 network. Computer1 is 192.168.1.2, Computer2 is 192.168.1.3 and Computer3 is 192.168.1.57.

Each system has a routing table defined (accessible in Linux by running netstat -rn. For example:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0

This routing table says that for a destination of 192.168.1.0 with a netmask of 255.255.255.0 (192.168.1.0-192.168.1.255) use a gateway of 0.0.0.0. This means that the traffic is local and you send it to the local network.

For traffic destined to 0.0.0.0 with a netmask of 0.0.0.0 (All other traffic), you send the traffic to 192.168.1.1. This address is known as a default gateway.

Communication within the LAN

Lets say that Computer1 has a webserver running on it that Computer2 would like to access. Computer2 will therefor send a SYN packet to 192.168.1.2 on port 80. In order to send this packet Computer2 will first look at its local routing tables in order to determine what is the proper method to send traffic to 192.168.1.2. It will find that both computers are on the same LAN, and will send out an ARP Request for the address.

23:21:04.906254 arp who-has 192.168.1.2 tell 192.168.1.3

192.168.1.1 then sees this ARP request since they're connected via that HUB and will respond with its own MAC address.

23:21:10.952260 arp reply 192.168.1.2 is-at 00:11:22:33:44:55

192.168.1.2 then stores this IP to MAC address mapping in its local ARP cache for a short time, and is able to use this lookup table to send out Ethernet frames to the appropriate network card.

Responses from 192.168.1.2 to 192.168.1.3 then go through the same ARP lookup process in the opposite direction.

Communication outside the LAN

Communication to systems outside of the local LAN work slightly different. Traffic outside of the network is sent to your default gateway (192.168.1.1) which then had additional routing rules defined for what to do with that traffic. Sending the traffic to 192.168.1.1 does follow the same ARP based traffic model that machine to machine communication follows.

The Problems

There are a few problems that could occur at this point.

Passive Sniffing

Since the network was setup with a HUB, all network traffic is broadcast out to all ports. This means that any system could easily listen to all network traffic by turning its network card into promiscuous mode and using a packet sniffer like wireshark, tcpdump or any other libpcap based software.

The security of certain protocols depend on packets being sent out with a secret of sorts that no one else should know. Being able to sniff these secrets means that an attacker can send back a spoofed response which is then believed to be legitimate.

Two main examples of this come to mind:

DNS: DNS requests use a combination of a source port and query IDs to validate the response sent back from a DNS server. If you can listen in on the traffic you can send spoofed responses back to either the client or a recursive server depending on who's traffic you're listening to.

TCP: TCP itself uses a sequence number in its three step handshake in order to initially setup a connection.

Passive sniffing is one of the easier problems to solve. Rather than a HUB, use a Switch. Switches only send broadcast traffic and traffic destined to the appropriate MAC address to a specific port, making passive sniffing much more difficult. Note that there are still attacks that allow for this type of sniffing either through ARP cache poisoning and CAM table overflows (sending so many MAC addresses that the switch essentially flips into HUB mode). Switches also provide better performance as an added bonus.

If you're looking at wireless networks rather than wired you can expect behavior along the lines of a hub if you're running without encryption or if you're using WEP. Using WPA/WPA2 behaves more like a switch due to the use of per-user keys, although there may be key recovery attacks if you're running in pre-shared key mode.

Rogue DHCP servers

There are two main methods for systems to be given their IP address in the first place. Servers are typically given a static IP address which is manually configured on the system. User systems on the other hand obtain an IP address and other settings like DNS servers, gateways, etc via the Dynamic Host Configuration Protocol or DHCP.

DHCP works by a new client sending out a DHCP request via UDP broadcast to the local network. A locally configured DHCP server will see the request and will respond with a DHCP response packet including the necessary networking configuration details.

Since DHCP packets are broadcast and DHCP isn't authenticated in any way, a rogue DHCP server could be installed on a network which will attempt to answer the DHCP request as well. Whichever server's packet is received first will be used by the client system.

The malicious server could provide the client system with a new default gateway, allowing for each man in the middle attacks. A malicious DNS server in the response can also be sent providing for DNS based attacks (to be covered later).

ARP poisoning

Since ARP traffic is sent via broadcast messages, all machines attached to the hub will see it. If 192.168.1.57 sees the ARP request, it can try to respond with its own MAC address before the actual machine can. Alternatively it can attempt to send out an unsolicited response using a technique known as a gratuitous arp. In the case of traffic to 192.168.1.1 (the default gateway) you can essentially hijack ALL traffic destined to the outside of the network through this technique.

Fixing ARP poisoning attacks is rather difficult. Using static arp tables on systems can help quite a bit, but can be a maintenance nightmare. Port security can help by limiting the number of MAC addresses allowed on a given port. This more helps against attacks where you try to steal someone else's MAC address rather than trying to steal their IP. Otherwise using a tool like ARPWatch will allow you to detect these sorts of attacks.

Wireless Security

2009-11-14T15:03:00.000-08:00

We often get people coming into the ##security chatroom asking questions securing a wireless network and what the various technologies involved actually mean and which ones are worth pursuing.

Here are the main technologies involved:

MAC Filtering
SSID hiding
WEP
WPA
WPA2

MAC Filtering

Most wireless access points (WAP) offer the MAC filtering option. This option allows you to provide the access point with a list of Machine Access Control (MAC) addresses which are the only devices that are allowed to talk on the network.

All network cards including wireless cards are shipped from the vendor with a pre-assigned MAC address. A MAC address is a 48 bit number typically represented as 12 hex numbers broken into sets of 2. For example, 11:22:33:44:aa:bb. The first 6 hex digits represent the vendor, and the vendor is responsible for making sure that the final 6 hex digits are unique enough that the chances of a network seeing two devices with the same MAC address is very very slim.

So this MAC filtering feature is designed to allow you to specify only the network devices you want to be allowed on your network. Sounds perfect right? Unfortunately no. There are two big problems with MAC filtering:

Network Sniffing

Wireless networks broadcast over radio waves which any device within a certain area can receive. If MAC filtering worked perfectly it would only prevent other computers from talking on your network. It would do nothing to prevent someone from listening to your network. Anyone within the area would be able to listen to any unencrypted traffic on your network, snarfing passwords, reading your chats, etc.

MAC Impersonation

The bigger problem with MAC filtering is that the MAC address defined on a network device at the factory is more of a suggestion than anything else. Nothing on the device prevents the MAC address from being changed. Linux makes it incrediably easy to change your MAC address, and other operating systems likely have methods for changing it as well.

So if you have someone malicious in your neighborhood, all they need to do is passively listen to your network, determine which MAC addresses are allowed to talk, change their MAC address to match that device and then talk away.

At best MAC address filtering will keep out casual internet leeches. At worst it'll make your network difficult to manage and give you a false sense of security and keep you from implementing something that will actually secure your network.

SSID Hiding

A Service Set Identifier or SSID is the name that you provide your network. Some people leave it on their vendor default (like linksys) while others try to come up with clever names from their network in order to prevent collisions. Setting a unique name for your network is a good idea for a number of reasons. You don't need to worry about accidental naming collisions putting you on the wrong network, and its less likely that you computer will automatically join a potentially hostile network. There's also an additional reason that we'll get to when we talk about WPA/WPA2.

When wireless access points talk about SSID hiding what they're talking about is the SSID beacon feature of the 802.11 protocol. In order to join a wireless network, you need to know the network name. Wireless access points can optionally send out these beacon packets which include the name of the network. These beacons are what populate the list of available networks that your OS displays to you.

The idea of SSID hiding is that if you don't send out the SSID in the beacons then users will need to already know the name of your network in order to join it. This effectively turns your SSID into a password or perhaps just a secret handshake.

This falls down however because the beacon packets aren't the only time the SSID is sent in the clear. They are also sent in probe responses that occur automatically when a legitimate user joins the network.

SSID hiding ends up falling into the same category as MAC filtering. At best it keeps casual leeches of your network, and at worst it makes managing your network difficult.

WEP

Now we get into actual encryption for protecting the network. Unfortunately its weak crypto. It uses an older cipher called RC4, and it uses it poorly. Due to replay attacks, WEP keys can be recovered in 10 minutes or so.

Crunge (a regular in ##security) explained the issue recently on his blog.

WPA

WPA was a big improvement over WEP. It still used the RC4 algorithm in order to maintain compatibility with existing hardware, but it used it much better. WPA uses 48 bit initialization vectors (IVs) rather than the 24 bits used by WEP. It also used a form of automatic key rotation known as Temporal Key Integrity Protocol or TKIP as well as a message integrity code (MIC) in order to prevent the replay attacks.

WPA also allowed for multiple forms of authentication. You could have a single password shared among users called a Pre-Shared Key (PSK). This mode is known as WPA-Personal. You could also tie into a RADIUS server in order to implement other forms of authentication, including x509 certificate based auth (SSL client certs). This mode is known as WPA-Enterprise.

WPA Enterprise is much stronger than WPA Personal and is STRONGLY recommended over a pre-shared key for a corporate environment. For a home environment, pre-shared keys are fine as long as your password is strong and your SSID is unique (I told you I'd bring the SSID back up).

Whenever you have a password involved your network will be vulnerable to brute force attacks. These are essentially attempts to either run through a dictionary of words to see if any of them are your password, or possibly just randomly try every password of X letters (6, 7, 8?). If your password is cat then the strength of the actual crypto will not help you.

Trying each and every password takes a while. Unfortunately WPA Personal is vulnerable to offline cracking attempts. If an attacker captures the right packet (yes, a single packet) on your network, they can try again and again to guess your password without you ever seeing anything. To make matters worse, there are Rainbow tables out there which allow someone to take that packet and look up what password was previously used to generate a packet like that one. Here's where the SSID matters. The password is combined with the SSID in order to generate this packet. That means that people need to generate separate rainbow tables for each SSID name. If your SSID is linksys then getting a rainbow table is easy. If your SSID is lsdfjklh23ljk123, then it most likely doesn't exist and they will need to use a time consuming technique to break in.

Recently weaknesses have been found in the TKIP protocol which makes cracking the network even easier. Due to this, moving to WPA2 is highly recommended.

WPA2

WPA2 functions much like WPA except it replaces the RC4 based TKIP with the AES based CCMP. CCMP is much stronger than TKIP, and is not vulnerable to the recent weaknesses found in it. Older hardware may not support CCMP properly, but this becomes less of an issue as people replace aging hardware.

It comes in the same personal and enterprise editions, and the same brute force attacks apply to weak passwords.

Most wireless access points can be configured to support both WPA and WPA2 at once in order to support both classes of devices. One thing to note there is that this configuration will slightly weaken security for your WPA2 devices. Networks contain both unicast (this packet is for you) and broadcast (this packet is for everyone) traffic. With WPA/WPA2 networks the user is provided a unqiue encryption key for their unicast traffic and a shared group key (GTK) for the broadcast traffic. In order to avoid doubling the amount of broadcast traffic both TKIP and CCMP users are provided a TKIP GTK if WPA is enabled on the access point.

Conclusion

Use WPA2 if you can, WPA if you have to. WEP is better than nothing.

Pre-shared keys are fine if you're a home user. Use Enterprise if you're in a corporate environment and need to protect anything of value. Or if you're an ambitious home user.

Mac filtering or SSID hiding provide little value and can be a management nightmare for any network with a good number of users.

The evils of Pastebin

2009-10-14T19:56:00.000-07:00

First post! (Thanks electr0n)

So in case you've been in a cave recently, there was recently some big news regarding a large number of stolen Hotmail passwords being found on Pastebin. This revealed to people that there was a large scale rather successful hack of some sort against a number of webmail services. If you haven't yet, be sure to change your webmail password just in case.

This made me wonder what else could be found on pastebin though, so I did some searching. What I found would probably surprise a lot of people.

The first thing I stumbled across was Credit Card numbers, SSNs and other personally identifiable information (PII). It looks like someone has been using pastebin.ca as a dumping ground for carding information. Same with pastebin.com, and probably a number of other pastebin sites out there.

Username and password combinations for Myspace and other sites can be found as well.

SSL Private keys are always fun. Especially combined with the public cert.

Heck, just look around at Johnny Long's Google Hacking Database, and apply what you find to a pastebin site. You're bound to find something interesting.