Ah, so... according to your research, if you already have the admin pw and physical access, infiltrating the Mac network would be easier than infiltrating the dream Windows system you envision without having the admin pw or physical access. Truly outstanding and brilliant work.
I have no idea what you are talking about.
The point was that Apple has done a good job preventing initial exploitation and trying to contain exploitation to a low-rights process. If the attacker is able to defeat those protections, which is plausible on both platforms at the skill level we are discussing, then the next step is using network exploits to become other users, possibly administrators. It is this step that is much easier on managed OS X networks.
1) On Windows 2008R2/7 it is possible to prevent downgrade to NTLM using GPO. This is a significant improvement and one we would like to see Apple replicate. 2) Even if you downgrade, it requires an extensive offline attack to recover a strong password from an NTLM handshake. NTLMv2 also has the benefit of being impervious to pre-computed dictionary attacks and contains better protections against relay attacks. DHX2 can be decoded in real-time on a laptop.
NTLM attacks are the bread-n-butter of APT attackers so it's important to limit their usefulness via appropriate GPO.
I think you mean to say that it is impossible to secure a Mac network using Active-Directory services.
No, we mean using the Apple services that are equivalent to the Windows services in most enterprises. Specifically OpenDirectory, AFP, mDNS, Server Admin and Remote Desktop.
Show me this secure Windows network and I'll show you a unicorn that shits glitter.
Windows 2008R2 x64 with all Windows 7 x64 member workstations. 2008R2 functional level. GPO: KerbOnly, NoLMHash, Require RPC Privacy and Integrity, Require SMB signing (Server and Client), Require LDAP signing (Server and Client), Require AD-enabled IPSec with IPAuth on Windows subnet, use smartcards for Kerb Pre-Auth.
As perfect and magical as your fantastical horned equus that defecates metal flakes? No, but much harder and noisier to penetrate than the best you can do with 10.7 Client and Server.
So how is this different from any other OS? sudoer is sudoer.
The escalation prompt impersonation is in no way unique to OS X. We never said it was, although it's a bit easier on OS X than on Windows.
There seems to be some misunderstanding on Slashdot of the purpose of this research. Our goal was to apply our experience with advanced attacks against corporate Windows networks against equivalent Apple technologies so that the defenders could stay one step ahead. We have a lot of clients that are now 40, 50, even 80% Macs on desktops, and it's important that we understand what these networks look like to somebody who has been given a year and a staff to penetrate and completely own the enterprise. Not everything we mention in the slides should be a criticism of OS X, in fact the majority of steps in this attack tree are pretty much identical on either platform. Understanding the details of each of those steps is important when designing countermeasures to prevent or detect each part of the attack tree.
How is this any different than any other hash storage mechanism -/etc/shadow,/windows/Windows/System32/config
These password stores are not accessible to a non-root/admin user. The section of the talk you are referencing is about local privilege escalation. We were trying to come up with ways we could escape after exploiting something like the low-rights Quicktime rendering process, and offline brute-forcing the Keychain is one option. BTW, those passwords stores aren't really equivalent to the Keychain, a better example would be Windows DPAPI, which provides a key that also mixes in a pre-machine secret to prevent this type of attack.
Slide 28 -- I'm not particularly clear on why you would want ASLR or DEP to be configurable -- that just opens another avenue of attack. It should be always on every process all the time to be meaningfully effective.
It's unlikely that any consumer OS will ship with these protections on all of the time. By default, both OS X and Windows 7 apply ASLR and NX protections to binaries that "opt-in". The difference is that on Windows you can force these protections on binaries from legacy compilers and linkers. This will often result in the process crashing, but in an enterprise environment you might prefer to crash old programs than to allow somebody to run Firefox 2, for example. This would be a simple fix for OS X and I wouldn't be shocked if they slipped it into a future patch quietly as a sysctl.
Slide 38 -- you keep calling the attack on the Keychain credential store a "brute force," but it isn't -- it's a simple social engineering attack to get a password. Unfortunately the Keychain keeps (encrypted) passwords in the clear rather than hashes only, but this is so users don't forget their passwords.
There are a couple of issues getting mixed together here. One way that you might escalate your privilege from a sandboxed, low-rights process would be a social engineering attack using an escalation prompt, as we showed. The keychain offers another option, because the encryption key used to protect it is solely derived from the user's password. The keychain file is available from the sandbox, so an attacker could pull the keychain file and send it off-site for a brute-force attack. The algorithm is definitely non-trivial to brute-force (1000 rounds of seeded MD5) but is not out of bounds for state-sponsored attackers, especially if the user is using a weak password. So the keychain isn't only useful to us as a repository of network passwords, but as a decryption oracle that can be cracked off-site (like in a basement in Beijing, cough...).
Our recommendation to Apple was to provide the user keying material that is partially derived from the user as well as from a machine-specific key stored somewhere only available to root. This would at least prevent low-rights and sandboxed processes from using the keychain as an oracle, although it would likely impact compatibility with downlevel versions of migration assistant.
Slide 53 -- "Modify existing binaries and services, which breaks signing but is generally not noticed" -- maybe in your shop, pal, not mine.
How do you regularly check for system binaries being modified? Do you use Tripwire? There seems to be no equivalent technology built into OS X, so we pointed out that one way to persist malware would be to modify parts of the system that are already running. This is, in no way, an OS X specific issue, although the lack of kernel extension signing makes it a bit more problematic than on Windows. (That being said, state hackers have already demonstrated a propensity for stealing Authenticode certificates from hardware makers, so driver signing isn't super helpful on Windows).
Slide 76 -- "Run your computers as little islands on a hostile network" -- FTFY
I disagree with this correction and your summary of our work. Our conclusion is that Apple has evened the score with Windows on anti-exploit technologies and has made it much easier for their ISVs to use the OS's sandboxing capabilities. We also concluded that it is possible to build a secure, managed Windows network that uses integrated authentication mechanisms to provide access to network services, although most organizations will not be ready to take the back-compat hit it takes to do so correctly. We concluded that it is currently impossible to build a secure network using OS X and OS X Server, and that any use of Apple-proprietary protocols makes credential stealing and network escalation attacks easier than it should be.
The Tl;DR is that Apple machines are more secure alone, and Windows machines are more secure when connected and managed.
There are a couple of different issues here. Escalating locally (even from inside the sandbox) can be done via impersonating an escalation prompt or by an offline brute-force of the keychain. Our criticism of the keychain is that it provides a decryption oracle that can be moved off of the machine and cracked at the leisure of the attackers. Even though it's relatively strong (1000 round MD5) state-sponsored attackers will definitely recover poor passwords.
There are also often local privilege escalation bugs that are regularly patched, but we didn't discuss these since we were most interested in the architectural issues that are difficult to correct.
On the network there is no cracking necessary. Via a downgrade a user's network password can be recovered with trivial computation resources.
The details of the networks attacks aren't clear in our slides without the associated commentary. One day that will be available online, but only after BlackHat makes it's killing off of DVD sales.
I still stand by my assertion that a well configured Mac network should never have allowed a normal user to install the exploit software in the first place though.
This would be our hope, and it is important to build in technical and procedural controls to reduce the chance that attackers get a foothold on your network. However, our experience dealing with state-sponsored attackers has demonstrated that it's impractical to make local execution your first and last line of defense. These folks are backed up by human intelligence and experienced humint operatives, and their social engineering attacks are quite effective, especially against remote, non-native-English employees. When our clients ask for advice on preventing APT, we do give them tips on preventing the initial infection, but a lot of our recommendations are around preventing and detecting control channels, exfiltration and network privilege escalation.
Slide 41 of the presentation shows the hierarchy of available authentication protocols and the best known attack against each. DHX has technically been deprecated, but it was replaced by DHX2 which has the exact same problem. The MITM tool we demonstrated works just fine on 10.7.
You can turn off plaintext auth, but you cannot disable unsigned DH.
Even if you could restrict to kerberos, there is no channel binding protecting the contents of these protocols, so auth relay attacks are pretty easy to pull off.
The mDNS MITM attack can be carried out across Layer-3 routing in some circumstances. In situations where this does not work, an attack against clients on the same broadcast domain is just as effective.
I would love for these issues to be fixed in 10.7.1, but that is extremely unlikely as truly hardening OS X against network privilege escalation would require significant architectural and cryptographic changes that would break backwards compatibility. These are equivalent issues to those faced by NT4 networks, although I have faith that if Apple was interested in correcting these issues they could do so much more quickly than Microsoft took to go from NT4->2008R2.
The slides are available here. Please let me know if you have any substantive feedback.
Yes, Apple services generally support Kerberos as an authentication scheme. The problem is that it's almost always possible to downgrade from Kerberos to unsigned Diffie-Hellman and retrieve the plaintext password trivially. This requires an active MITM attack on the network. Traditional ways attackers have done this include ARP spoofing, DHCP spoofing and DNS poisoning attacks. Our talk also discussed a Mac-specific MITM which uses Bonjour to temporarily take over the identity of OS X servers and relay or downgrade authentication.
Even if OS X allowed itself to be limited to Kerberos auth (and it doesn't) most Apple protocols do not perform channel binding, meaning there is no cryptographic integrity protection tied to the initial handshake. This allows an attacker to relay the Kerberos handshake and then modify the resultant communication, which can be disastrous if the communication is security critical, such as LDAP or an AFP mounted home directory.
A competently administered Mac network, with proper encryption, privileged separation, threat training , etc should be no more vulnerable than any other
That is incorrect. Our research has shown that it is currently impossible to secure a network using OS X services. The only secure Mac network is one that runs the machines as separate "islands" without directory services, file sharing, or remote server administration. There are a lot of insecure Windows networks, due to the use of downlevel versions as well as configuration mistakes, but in theory you can build a new Windows 2008R2/7 Active Directory network that is hardened against network privilege escalation using GPO (KerbOnly, NoLMHash, RPC privacy/integrity, AD integrated IPSec, smartcard auth, etc...)
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.
While the origin of the issue is the virtualization layer, it is more specifically a cloud problem because most IaaS/VPS providers use standard images with a public random seed file, so everybody's machine initializes up to the same state (RTC + random seed + handful of interrupts).
Actually,/dev/random and/dev/urandom have their own, separate secondary pools that are fed off of a main pool when entropy is "depleted" in the second level pools. This is an area of research for us as well, since Linux's entropy estimation algorithm fails in situations where the timing deltas of entropy gathering events (IRQs and disk IOs) are actually predictable, so it's possible that the second level pools are not being refreshed at appropriate times.
If you write to/dev/urandom, it goes into the primary pool by tradition. This is what the rc scripts do on bootup with the random seed file on disk.
BTW, it's absolutely the wrong solution to get entropy from another source on the network (for many reasons, but one is that you can't do a secure HTTPS handshake without, you guessed it, unguessable random numbers). The whole point here is that we are looking for a way for 500 Linux instances on EC2 to have different entropy pools before the kernel completes boot. The only possible solution is for the hypervisor (Xen for Amazon) to provide a simulated HW RNG that pulls entropy from a real HW RNG or from an entropy daemon in the hypervisor.
The best way to learn about Linux RNG basics is Gutterman et. al. Analysis of the Linux Random Number Generator. Several of the issues they describe have been addressed, such as their PFS concerns, but their description of the entropy pools is still accurate.
Howdy... I'm actually one of the contributors to the book. We have been working with Adobe and CERT for a while on this issue, and we felt that as much time as is reasonable had elapsed since the initial reporting. The disclosure of security vulnerabilities is always a complicated ethical issue, and you have to weigh the public's right to know with the possibility that a speedy fix may reduce the overall damage from disclosure. Even with several months of work, "patching" the vulnerabilities is complicated, since the issues exist in the SWF files themselves and not in Flash player, so the only solution is for website owners to re-generate their Flash applets with the updated generators, which should be out shortly.
A more formal vulnerability report is being co-ordinated with CERT and should be out soon with the details of the issues.
"Exploits" that require you to run in the same user context as the attacked process are fun to impress people on Slashdot and not the point of shatter attacks, which are worthwhile in situations where a message handler is accepting messages from other user contexts. This was mostly a function of high-rights services popping GUIs onto the interactive user's desktop. That is much less likely these days, since most devlopers now know to have a separate process for GUI interaction that communicates back to the service through a better method than COM.
If you want to "exploit" your own explorer.exe, I would recommend using OpenProcess(). That'll be a lot faster.
The Windows messsaging model sucks, but its something that has been seriously attacked by Microsoft and will hopefully become less of an issue as other Win32 developers figure this out.
Microsoft has put a signifigant amount of work into creating USER/GDI messaging passing barriers between the new Vista integrity levels. This feature is called UIPI and mostly works in the betas.
BTW, almost no Microsoft written applications are still vulnerable to shatter attacks on XP. This is mostly an issue that still hits ISVs because they don't understand the problem.
Nobody here understands that since the DOJ consent decree, almost no big design decision at Microsoft happens without lawyers involved.
The most damaging legal argument against Microsoft (and one that was widely hailed by Slashdotters) was that it destroys competitors by bundling products for free in the OS. This is obviously a true charge, as experienced by Netscape, and much of the legal oversight at Microsoft is meant to keep walls up between different business units, to prevent illegal bundling of products.
If Microsoft shipped AV in the OS (which I personally would love) for free or greatly below market prices, McAfee and Symantec would be all over them with civil anti-trust complaints in a second. In addition, the judge overseeing the consent decree might (or state AGs) might reconsider some of the deals made in the past.
It is unbelievably hypocritical for people in this forum to both:
a) Celebrate Microsoft losing anti-trust battles, and reveling in the fact that there are now large legal hurdles to improving their products.
b) Complain that Microsoft doesn't destroy the desktop security software segment with free AV, on top of already free Spyware checking and firewall.
Yes, you can, but that is only because Microsoft tolerates the chipping community.
There's nothing stopping them from updating the software upon Live connection in a way that detects chips while offline. I'm sure that will be the policy for the 360.
XBox games don't use a full 3D abstraction layer, like many DirectX or OpenGL games do. They are directly targeted (and optimized) for the Nvidia GPU, and the firmware and GPU compiler technology for the first XBox's graphics system probably belongs to Nvidia.
After such a big embarassing loss to ATI on the X360, it is highly unlikely that Nvidia would agree to license their technology for inclusion in a software emulator on the new platform.
Interestingly enough, MSFT has made some acquisitions over the last couple of years that point to building such emulation (VirtualPC, JIT scode conversion technologies), but it might be for naught if there is a legal barrier on the graphics chip.
I know, sucks.
Re:Windows on the Power Architecture???
on
The Xbox 360 Unveiled
·
· Score: 4, Interesting
Windows NT originally had a kernel that ran on PPC, so this really isn't a huge jump for them.
PPC can switch big/little endian, and since the low-level bootstrapping and HAL code already existed, it probably wasn't a huge deal to build XNA (this is their new XBox/Win gaming dev platform) compilers for x86, PPC, x64, and maybe even.Net CLR.
Although it is generally true that a C corp or a corporate-taxed LLC would allow you to pay some of your money as dividends, if you are the sole owner of a corporation, the IRS deems it an "insignificant entity". That means you might get the benefits of limited liability, group health insurance, and other corporate perks, but that the money it earns will be treated as self-employment income.
1099 work is not corp-corp, and most companies will not pay a corporation with one shareholder/employee, since that makes them somewhat liable for your tax evasion (they don't report checks to corporations to the IRS). Microsoft got busted with paying non-declared corp-corp consulting fees a couple of years back, and now there is a huge set of hoops one has to jump through to consult for them.
Talk to a CPA or tax attorney when you set up your payment structure, or just take 1099 work and be done with it. Remember, 1099's are declared to the IRS like W-2s, so you need to pay those taxes.
My account always says that the difference between tax evasion and tax avoidance is 3-9 months in Camp Fed.
My Steam just started re-downloading HL2
on
Half Life 2 Goes Gold
·
· Score: 2, Interesting
Yesterday, it had told me I had "100%" of the preload (Silver Pack), and now that dropped to 80% and its downloading again.
Perhaps this is a seed of the final changes. I wonder if Steam can do incremental patching of the other preloaded content. Seems likely now.
Eeye and @stake contacted the Apple security team after finding these bugs, and coordinated the timing of the announcements to follow the availability of the patch.
The controversial part of this practice is when the software vendor stalls the fix (which always happens). At what point does @stake go public with a vuln? Three months? A year? There are guidelines that all of these organizations have agreed to, but they aren't legally enforcable, and so there is a lot of gray area in how long a company can wait to release a fix, and how they must classify it afterwards.
Slashdot Mirror
Ah, so... according to your research, if you already have the admin pw and physical access, infiltrating the Mac network would be easier than infiltrating the dream Windows system you envision without having the admin pw or physical access. Truly outstanding and brilliant work.
I have no idea what you are talking about.
The point was that Apple has done a good job preventing initial exploitation and trying to contain exploitation to a low-rights process. If the attacker is able to defeat those protections, which is plausible on both platforms at the skill level we are discussing, then the next step is using network exploits to become other users, possibly administrators. It is this step that is much easier on managed OS X networks.
That is incorrect.
1) On Windows 2008R2/7 it is possible to prevent downgrade to NTLM using GPO. This is a significant improvement and one we would like to see Apple replicate.
2) Even if you downgrade, it requires an extensive offline attack to recover a strong password from an NTLM handshake. NTLMv2 also has the benefit of being impervious to pre-computed dictionary attacks and contains better protections against relay attacks. DHX2 can be decoded in real-time on a laptop.
NTLM attacks are the bread-n-butter of APT attackers so it's important to limit their usefulness via appropriate GPO.
I think you mean to say that it is impossible to secure a Mac network using Active-Directory services.
No, we mean using the Apple services that are equivalent to the Windows services in most enterprises. Specifically OpenDirectory, AFP, mDNS, Server Admin and Remote Desktop.
Show me this secure Windows network and I'll show you a unicorn that shits glitter.
Windows 2008R2 x64 with all Windows 7 x64 member workstations. 2008R2 functional level. GPO: KerbOnly, NoLMHash, Require RPC Privacy and Integrity, Require SMB signing (Server and Client), Require LDAP signing (Server and Client), Require AD-enabled IPSec with IPAuth on Windows subnet, use smartcards for Kerb Pre-Auth.
As perfect and magical as your fantastical horned equus that defecates metal flakes? No, but much harder and noisier to penetrate than the best you can do with 10.7 Client and Server.
So how is this different from any other OS? sudoer is sudoer.
The escalation prompt impersonation is in no way unique to OS X. We never said it was, although it's a bit easier on OS X than on Windows.
There seems to be some misunderstanding on Slashdot of the purpose of this research. Our goal was to apply our experience with advanced attacks against corporate Windows networks against equivalent Apple technologies so that the defenders could stay one step ahead. We have a lot of clients that are now 40, 50, even 80% Macs on desktops, and it's important that we understand what these networks look like to somebody who has been given a year and a staff to penetrate and completely own the enterprise. Not everything we mention in the slides should be a criticism of OS X, in fact the majority of steps in this attack tree are pretty much identical on either platform. Understanding the details of each of those steps is important when designing countermeasures to prevent or detect each part of the attack tree.
How is this any different than any other hash storage mechanism - /etc/shadow, /windows/Windows/System32/config
These password stores are not accessible to a non-root/admin user. The section of the talk you are referencing is about local privilege escalation. We were trying to come up with ways we could escape after exploiting something like the low-rights Quicktime rendering process, and offline brute-forcing the Keychain is one option. BTW, those passwords stores aren't really equivalent to the Keychain, a better example would be Windows DPAPI, which provides a key that also mixes in a pre-machine secret to prevent this type of attack.
Slide 28 -- I'm not particularly clear on why you would want ASLR or DEP to be configurable -- that just opens another avenue of attack. It should be always on every process all the time to be meaningfully effective.
It's unlikely that any consumer OS will ship with these protections on all of the time. By default, both OS X and Windows 7 apply ASLR and NX protections to binaries that "opt-in". The difference is that on Windows you can force these protections on binaries from legacy compilers and linkers. This will often result in the process crashing, but in an enterprise environment you might prefer to crash old programs than to allow somebody to run Firefox 2, for example. This would be a simple fix for OS X and I wouldn't be shocked if they slipped it into a future patch quietly as a sysctl.
Slide 38 -- you keep calling the attack on the Keychain credential store a "brute force," but it isn't -- it's a simple social engineering attack to get a password. Unfortunately the Keychain keeps (encrypted) passwords in the clear rather than hashes only, but this is so users don't forget their passwords.
There are a couple of issues getting mixed together here. One way that you might escalate your privilege from a sandboxed, low-rights process would be a social engineering attack using an escalation prompt, as we showed. The keychain offers another option, because the encryption key used to protect it is solely derived from the user's password. The keychain file is available from the sandbox, so an attacker could pull the keychain file and send it off-site for a brute-force attack. The algorithm is definitely non-trivial to brute-force (1000 rounds of seeded MD5) but is not out of bounds for state-sponsored attackers, especially if the user is using a weak password. So the keychain isn't only useful to us as a repository of network passwords, but as a decryption oracle that can be cracked off-site (like in a basement in Beijing, cough...).
Our recommendation to Apple was to provide the user keying material that is partially derived from the user as well as from a machine-specific key stored somewhere only available to root. This would at least prevent low-rights and sandboxed processes from using the keychain as an oracle, although it would likely impact compatibility with downlevel versions of migration assistant.
Slide 53 -- "Modify existing binaries and services, which breaks signing but is generally not noticed" -- maybe in your shop, pal, not mine.
How do you regularly check for system binaries being modified? Do you use Tripwire? There seems to be no equivalent technology built into OS X, so we pointed out that one way to persist malware would be to modify parts of the system that are already running. This is, in no way, an OS X specific issue, although the lack of kernel extension signing makes it a bit more problematic than on Windows. (That being said, state hackers have already demonstrated a propensity for stealing Authenticode certificates from hardware makers, so driver signing isn't super helpful on Windows).
Slide 76 -- "Run your computers as little islands on a hostile network" -- FTFY
I disagree with this correction and your summary of our work. Our conclusion is that Apple has evened the score with Windows on anti-exploit technologies and has made it much easier for their ISVs to use the OS's sandboxing capabilities. We also concluded that it is possible to build a secure, managed Windows network that uses integrated authentication mechanisms to provide access to network services, although most organizations will not be ready to take the back-compat hit it takes to do so correctly. We concluded that it is currently impossible to build a secure network using OS X and OS X Server, and that any use of Apple-proprietary protocols makes credential stealing and network escalation attacks easier than it should be.
The Tl;DR is that Apple machines are more secure alone, and Windows machines are more secure when connected and managed.
There are a couple of different issues here. Escalating locally (even from inside the sandbox) can be done via impersonating an escalation prompt or by an offline brute-force of the keychain. Our criticism of the keychain is that it provides a decryption oracle that can be moved off of the machine and cracked at the leisure of the attackers. Even though it's relatively strong (1000 round MD5) state-sponsored attackers will definitely recover poor passwords.
There are also often local privilege escalation bugs that are regularly patched, but we didn't discuss these since we were most interested in the architectural issues that are difficult to correct.
On the network there is no cracking necessary. Via a downgrade a user's network password can be recovered with trivial computation resources.
The details of the networks attacks aren't clear in our slides without the associated commentary. One day that will be available online, but only after BlackHat makes it's killing off of DVD sales.
I still stand by my assertion that a well configured Mac network should never have allowed a normal user to install the exploit software in the first place though.
This would be our hope, and it is important to build in technical and procedural controls to reduce the chance that attackers get a foothold on your network. However, our experience dealing with state-sponsored attackers has demonstrated that it's impractical to make local execution your first and last line of defense. These folks are backed up by human intelligence and experienced humint operatives, and their social engineering attacks are quite effective, especially against remote, non-native-English employees. When our clients ask for advice on preventing APT, we do give them tips on preventing the initial infection, but a lot of our recommendations are around preventing and detecting control channels, exfiltration and network privilege escalation.
Slide 41 of the presentation shows the hierarchy of available authentication protocols and the best known attack against each. DHX has technically been deprecated, but it was replaced by DHX2 which has the exact same problem. The MITM tool we demonstrated works just fine on 10.7.
You can turn off plaintext auth, but you cannot disable unsigned DH.
Even if you could restrict to kerberos, there is no channel binding protecting the contents of these protocols, so auth relay attacks are pretty easy to pull off.
The mDNS MITM attack can be carried out across Layer-3 routing in some circumstances. In situations where this does not work, an attack against clients on the same broadcast domain is just as effective.
I would love for these issues to be fixed in 10.7.1, but that is extremely unlikely as truly hardening OS X against network privilege escalation would require significant architectural and cryptographic changes that would break backwards compatibility. These are equivalent issues to those faced by NT4 networks, although I have faith that if Apple was interested in correcting these issues they could do so much more quickly than Microsoft took to go from NT4->2008R2.
The slides are available here. Please let me know if you have any substantive feedback.
Admins can't fix this. There is no way to restrict OS X clients (and it's the clients we care about in auth downgrade attacks) from using DH.
I am the researcher quoted in the article.
This would be easier if the story linked to the real presentation.
Yes, Apple services generally support Kerberos as an authentication scheme. The problem is that it's almost always possible to downgrade from Kerberos to unsigned Diffie-Hellman and retrieve the plaintext password trivially. This requires an active MITM attack on the network. Traditional ways attackers have done this include ARP spoofing, DHCP spoofing and DNS poisoning attacks. Our talk also discussed a Mac-specific MITM which uses Bonjour to temporarily take over the identity of OS X servers and relay or downgrade authentication.
Even if OS X allowed itself to be limited to Kerberos auth (and it doesn't) most Apple protocols do not perform channel binding, meaning there is no cryptographic integrity protection tied to the initial handshake. This allows an attacker to relay the Kerberos handshake and then modify the resultant communication, which can be disastrous if the communication is security critical, such as LDAP or an AFP mounted home directory.
A competently administered Mac network, with proper encryption, privileged separation, threat training , etc should be no more vulnerable than any other
That is incorrect. Our research has shown that it is currently impossible to secure a network using OS X services. The only secure Mac network is one that runs the machines as separate "islands" without directory services, file sharing, or remote server administration. There are a lot of insecure Windows networks, due to the use of downlevel versions as well as configuration mistakes, but in theory you can build a new Windows 2008R2/7 Active Directory network that is hardened against network privilege escalation using GPO (KerbOnly, NoLMHash, RPC privacy/integrity, AD integrated IPSec, smartcard auth, etc...)
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.
While the origin of the issue is the virtualization layer, it is more specifically a cloud problem because most IaaS/VPS providers use standard images with a public random seed file, so everybody's machine initializes up to the same state (RTC + random seed + handful of interrupts).
Actually, /dev/random and /dev/urandom have their own, separate secondary pools that are fed off of a main pool when entropy is "depleted" in the second level pools. This is an area of research for us as well, since Linux's entropy estimation algorithm fails in situations where the timing deltas of entropy gathering events (IRQs and disk IOs) are actually predictable, so it's possible that the second level pools are not being refreshed at appropriate times.
/dev/urandom, it goes into the primary pool by tradition. This is what the rc scripts do on bootup with the random seed file on disk.
If you write to
BTW, it's absolutely the wrong solution to get entropy from another source on the network (for many reasons, but one is that you can't do a secure HTTPS handshake without, you guessed it, unguessable random numbers). The whole point here is that we are looking for a way for 500 Linux instances on EC2 to have different entropy pools before the kernel completes boot. The only possible solution is for the hypervisor (Xen for Amazon) to provide a simulated HW RNG that pulls entropy from a real HW RNG or from an entropy daemon in the hypervisor.
The best way to learn about Linux RNG basics is Gutterman et. al. Analysis of the Linux Random Number Generator. Several of the issues they describe have been addressed, such as their PFS concerns, but their description of the entropy pools is still accurate.
Howdy... I'm actually one of the contributors to the book. We have been working with Adobe and CERT for a while on this issue, and we felt that as much time as is reasonable had elapsed since the initial reporting. The disclosure of security vulnerabilities is always a complicated ethical issue, and you have to weigh the public's right to know with the possibility that a speedy fix may reduce the overall damage from disclosure. Even with several months of work, "patching" the vulnerabilities is complicated, since the issues exist in the SWF files themselves and not in Flash player, so the only solution is for website owners to re-generate their Flash applets with the updated generators, which should be out shortly.
A more formal vulnerability report is being co-ordinated with CERT and should be out soon with the details of the issues.
"Exploits" that require you to run in the same user context as the attacked process are fun to impress people on Slashdot and not the point of shatter attacks, which are worthwhile in situations where a message handler is accepting messages from other user contexts. This was mostly a function of high-rights services popping GUIs onto the interactive user's desktop. That is much less likely these days, since most devlopers now know to have a separate process for GUI interaction that communicates back to the service through a better method than COM.
If you want to "exploit" your own explorer.exe, I would recommend using OpenProcess(). That'll be a lot faster.
The Windows messsaging model sucks, but its something that has been seriously attacked by Microsoft and will hopefully become less of an issue as other Win32 developers figure this out.
Microsoft has put a signifigant amount of work into creating USER/GDI messaging passing barriers between the new Vista integrity levels. This feature is called UIPI and mostly works in the betas.
BTW, almost no Microsoft written applications are still vulnerable to shatter attacks on XP. This is mostly an issue that still hits ISVs because they don't understand the problem.
Nobody here understands that since the DOJ consent decree, almost no big design decision at Microsoft happens without lawyers involved.
The most damaging legal argument against Microsoft (and one that was widely hailed by Slashdotters) was that it destroys competitors by bundling products for free in the OS. This is obviously a true charge, as experienced by Netscape, and much of the legal oversight at Microsoft is meant to keep walls up between different business units, to prevent illegal bundling of products.
If Microsoft shipped AV in the OS (which I personally would love) for free or greatly below market prices, McAfee and Symantec would be all over them with civil anti-trust complaints in a second. In addition, the judge overseeing the consent decree might (or state AGs) might reconsider some of the deals made in the past.
It is unbelievably hypocritical for people in this forum to both:
a) Celebrate Microsoft losing anti-trust battles, and reveling in the fact that there are now large legal hurdles to improving their products.
b) Complain that Microsoft doesn't destroy the desktop security software segment with free AV, on top of already free Spyware checking and firewall.
Yes, you can, but that is only because Microsoft tolerates the chipping community.
There's nothing stopping them from updating the software upon Live connection in a way that detects chips while offline. I'm sure that will be the policy for the 360.
XBox games don't use a full 3D abstraction layer, like many DirectX or OpenGL games do. They are directly targeted (and optimized) for the Nvidia GPU, and the firmware and GPU compiler technology for the first XBox's graphics system probably belongs to Nvidia.
After such a big embarassing loss to ATI on the X360, it is highly unlikely that Nvidia would agree to license their technology for inclusion in a software emulator on the new platform.
Interestingly enough, MSFT has made some acquisitions over the last couple of years that point to building such emulation (VirtualPC, JIT scode conversion technologies), but it might be for naught if there is a legal barrier on the graphics chip.
I know, sucks.
Windows NT originally had a kernel that ran on PPC, so this really isn't a huge jump for them.
.Net CLR.
PPC can switch big/little endian, and since the low-level bootstrapping and HAL code already existed, it probably wasn't a huge deal to build XNA (this is their new XBox/Win gaming dev platform) compilers for x86, PPC, x64, and maybe even
Although it is generally true that a C corp or a corporate-taxed LLC would allow you to pay some of your money as dividends, if you are the sole owner of a corporation, the IRS deems it an "insignificant entity". That means you might get the benefits of limited liability, group health insurance, and other corporate perks, but that the money it earns will be treated as self-employment income.
1099 work is not corp-corp, and most companies will not pay a corporation with one shareholder/employee, since that makes them somewhat liable for your tax evasion (they don't report checks to corporations to the IRS). Microsoft got busted with paying non-declared corp-corp consulting fees a couple of years back, and now there is a huge set of hoops one has to jump through to consult for them.
Talk to a CPA or tax attorney when you set up your payment structure, or just take 1099 work and be done with it. Remember, 1099's are declared to the IRS like W-2s, so you need to pay those taxes.
My account always says that the difference between tax evasion and tax avoidance is 3-9 months in Camp Fed.
Yesterday, it had told me I had "100%" of the preload (Silver Pack), and now that dropped to 80% and its downloading again.
Perhaps this is a seed of the final changes. I wonder if Steam can do incremental patching of the other preloaded content. Seems likely now.
Eeye and @stake contacted the Apple security team after finding these bugs, and coordinated the timing of the announcements to follow the availability of the patch.
The controversial part of this practice is when the software vendor stalls the fix (which always happens). At what point does @stake go public with a vuln? Three months? A year? There are guidelines that all of these organizations have agreed to, but they aren't legally enforcable, and so there is a lot of gray area in how long a company can wait to release a fix, and how they must classify it afterwards.
>Microsofts policy is the holes dont exist, Apples is they exist and when we find them we fix them.
u rity
Compare:
microsoft.com/security
apple.com/sec
Which one is a security response site, with links to bulletins, patches, and descriptions of current incidents?
Which one is a page full of sales BS?
Hint: It's not what you expect.