Monthly Archives: August 2009

HOWTO: Crack Yahoo’s Intranet

Ben Reed gave me a run-down of how he managed to win Yahoo’s internal Crack Day by getting into the corporate network and making commits to their code repositories, all using off-the-shelf tools and without writing a line of code. These flaws have been fixed by now.

The first step is to associate with the wireless network. The network is secured using WEP, which is straightforward to crack using WEPCrack. This can be done from anywhere near the campus premises, and it took Ben at most 30 minutes.

Yahoo uses Cisco VPN and Aruba VPN. Cisco VPN turns out to be IPsec with extensions, and Yahoo’s is configured to use pre-shared keys (as opposed to certificates/PKI). It’s also configured to use aggressive mode for a faster three-packet initial key exchange, as opposed to main mode, which uses six packets but is more secure. From the excellent NIST Guide to IPsec VPNs:

…unlike main mode, aggressive mode can be used with pre-shared secret key authentication for hosts without fixed IP addresses. However, with the increased speed of aggressive mode comes decreased security. Since the Diffie-Hellman key exchange begins in the first packet, the two parties do not have an opportunity to negotiate the Diffie-Hellman parameters. Also, the identity information is not always hidden in aggressive mode, so an observer could determine which parties were performing the negotiation. (Aggressive mode can conceal identity information in some cases when public keys have already been exchanged.) Aggressive mode negotiations are also susceptible to pre-shared key cracking, which can allow user impersonation and man-in-the-middle attacks. Another potential issue is that while all IPsec devices must support main mode, aggressive mode support is optional. Unless there are performance issues, it is generally recommended to use main mode for the phase one exchange.

The flaws were pointed out back in 1999:

Aggressive mode does not usually provide identity protection, as this option is not required to be implemented. The identities can be exchanged in the clear, before a common shared-secret has been established. This is considered a feature for mobile users. Yet it is mobile users who are most likely to be affected by eavesdropping on wireless links. Such revealed identities are long-term liabilities. Compromised identities continue to be useful to an adversary until all participants have revoked the associated permissions. Identity attacks are extremely easy and may be mounted from anywhere on the Internet. Moreover, the revealed identities might be encrypted in other exchanges. This provides a ripe opportunity for cryptanalysis of those exchanges. This fundamental design flaw is inherent in the specification, and remediation will require removal of the aggressive mode feature.

Windows laptops are required to use the Aruba VPN client, of which we know nothing. Only Macs use the Cisco VPN client, so we need to find some Macs; this can be done with passive OS fingerprinting tools like p0f by Michal Zalewski.

Now we can use ARP spoofing to fool the Macs into thinking we’re the gateway and sending all their packets through us. Ben used ARPoison. Make sure you’ve activated IP forwarding on your system so that you actually route packets.

Once we’re the man in the middle, we can use FakeIKEd to nab the credentials:

FakeIKEd, or fiked for short, is a fake IKE daemon supporting just enough of the standards and Cisco extensions to attack commonly found insecure Cisco PSK+XAUTH VPN setups in what could be described as a semi MitM attack. Fiked can impersonate a VPN gateway’s IKE responder in order to capture XAUTH login credentials; it doesn’t currently do the client part of full MitM.

One problem is that you need to tell fiked the shared key. You can get this by grabbing a copy of Yahoo’s VPN client from Yahoo Frontyard, which is Yahoo’s external-facing site for employees. However, the site requires a valid login and is served over HTTPS. The trick is that it installs an authenticator cookie, which is also sent along with non-HTTPS requests to other yahoo.com sites.

Note that the VPN system has since been reconfigured, and now uses certificates/PKI to avoid MITM attacks. Furthermore, the VPN authentication has been augmented with RSA SecurID, which provides a rolling token for two-factor authentication. This complicates the attack, though SecurID is still vulnerable to MITM attacks executed within the appropriate timeframe.

Once you’re in the corporate network, you can mount user home directories which are exported over NFS. Permissions are not enforced over NFS (which is designed to be used by a trusted set of hosts, but apparently the NFS servers here don’t use any such list of hosts), so you can assume any user ID and touch anyone’s files—including their SSH authorized_keys file. Simply drop your public key in ~filo/.ssh/authorized_keys, and you can now log in as David Filo and (among other things) commit code.

Yahoo has since disabled the ability for sshd to use users’ authorized_keys files and instead has a separate mechanism for adding public keys.

Summary

  • preliminary: get the VPN shared key
    • find a Yahoo employee at a cafe and sniff his cookies to yahoo.com sites
    • this traffic includes the cookies to Yahoo Frontyard, Yahoo’s external-facing site for employees
    • log in to Yahoo Frontyard as this employee and grab the VPN shared key
  • crack the wireless network WEP on the Yahoo campus
  • find a Mac using OS fingerprinting; Macs use the weak Cisco VPN
  • become the gateway router for the Mac by spoofing ARPs, thus causing all their IP packets to go through you
  • (using the VPN shared keys stolen earlier) interpose as the fake VPN server, thus stealing the user’s credentials and gaining access to the corporate network
  • mount an NFS-exported user directory, and inject your key into someone’s .ssh/authorized_keys