Aurora Attack — Resistance Is Futile, Pretty Much
eldavojohn writes "Do you have branch offices in China? iSec has published a new report (PDF) outlining the severity of the attacks on Google.cn, allegedly by the Chinese government, dubbed 'Aurora' attacks. Up to 100 companies were victims, and some are speculating that resistance to such attacks is futile. The report lays out the shape of the attacks — which were customized per-company based on installed vulnerable software and antivirus protection: '1. The attacker socially engineers a victim, often in an overseas office, to visit a malicious website. 2. This website uses a browser vulnerability to load custom malware on the initial victim's machine. 3. The malware calls out to a control server, likely identified by a dynamic DNS address. 4. The attacker escalates his privilege on the corporate Windows network, using cached or local administrator credentials. 5. The attacker attempts to access an Active Directory server to obtain the password database, which can be cracked onsite or offsite. 6. The attacker uses cracked credentials to obtain VPN access, or creates a fake user in the VPN access server. 7. At this point, the attack varies based upon the victim. The attacker may steal administrator credentials to access production systems, obtain source code from a source repository, access data hosted at the victim, or explore Intranet sites for valuable intellectual property.' The report also has pages of recommendations as well as lessons learned, which any systems administrator — even those inside the US — should read and take note of."
Major attack preventer: Google docs PDF reader.
When you're afraid to download music illegally in your own home, then the terrorists have won!
> The Chinese have existed as a nation for longer than any other civilization on the face of this planet,
> and they take the "long view" in such things.
Thankfully both of these are incorrect to a lesser and greater degree respectively.
There may have been people living in the areas of land now referred to as China, but any links between historical cultures and thought and the modern morass are purely fictional.
And as anyone who has done business in/with China can tell you one of the biggest problems inherent to the nation is a complete inability to plan ahead or consider delayed benefits. None of the Chinese businesses I've worked in, nor the government bureaucracy I've suffered through, have ever included any possibility of passing up 10 bucks in their pocket right now in exchange for a thousand tomorrow.
We're dealing with a cultural mindset that would unhesitatingly slaughter the goose that laid the golden eggs, not in hopes of finding lots of eggs inside (that assumption requires some logical thought and deductive reasoning), but simply to take its feed and head for picking.
There is no concept of repeat business here. Any supplier who believes they can get away with it will supply a shipment of non-functional crap and pocket the single payment rather than even bother trying to set up monthly deliveries of functional goods.
The unstable legal system is partly at fault here. There is just no way in this culture to be sure that your products won't be outlawed/super-taxed next week. Money under the mattress is the only surety.
kartune85 : Incapable of reason, observation or learning. A kind of dim, drab, flightless parrot.
There are several methods of escalating to domain admin once you have Local Administrator access on a member workstation. It is our experience that most large Enterprise AD networks are vulnerable to at least one of these issues:
1. Crack a common local user with a shared password, like "MACHINENAME\ITAdmin". Alternatively, you can use an NTLM hash as a password equivalent with custom tools, like my colleague Jesse Burns demonstrated in 2005.
2. Crack the cached hash of a domain admin from the SECURITY hive. This hash is created by an interactive login to the machine, i.e. via the local keyboard or RDP. These hashes are not stored after remote RPC, SMB, etc...
3. Install a keystroke logger and wait for an interactive login by an Administrator. A good technique is to open an IT ticket as the victim, which often triggers an admin to remotely access the machine via RDP.
4. Wait for an automated process to touch the box with domain admin credentials. Common tools that do this are patch management systems, vulnerability scanners, software licensing compliance tools and event log aggregation systems. When the handshake for the network service begins (say over DCE RPC), the attacker rejects the Kerberos ticket and requests a downgrade to LanMan or NTLMv1. Either one of those protocols will allow an attacker to use a pre-computed time-memory trade-off to quickly recover the password (aka Rainbow Tables).
5. Wait for an automated "touch" and perform a pass-the-hash attack. This is possible on services that do not enforce at least "Packet Integrity" security. The admin and the victim machine legitimately exchange credentials, but the resulting authenticated connection can now be modified by the attacker. Again, see Burns 2005.