Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security Apple IT

Ex-NSA Researcher Claims That DLL-Style Attacks Work Just Fine On OS X 93

An anonymous reader writes Ex-NSA and NASA researcher Patrick Wardle claims to have developed a reliable technique of Shared Library replacement which renders Apple's OSX operating system just as vulnerable to exploitation as Windows has been (via its 'DLL' shared libraries) for years. Speaking at CanSecWest, Wardle explained that Apple's refusal to encrypt software downloads via its App Store allows an attacker on the same network to inject a malicious 'dylib' (shared library) without altering the hash of the legitimate-but-vulnerable software, thereby leaving the Developer ID signature intact. Wardle ran a crafted Python script on a typical Mac and discovered 150 dylib-dependent applications, including Apple's own Xcode developer environment — revealed last week by Edward Snowden to be a priority target for the NSA due to its ability to propagate compromised software.
This discussion has been archived. No new comments can be posted.

Ex-NSA Researcher Claims That DLL-Style Attacks Work Just Fine On OS X

Comments Filter:
  • don't the shared libs need to be signed.
    Of course the problem is that when you make signing mandatory you make everyone pay for a cert.

    • I assume something like Windows Resource Protection [wikipedia.org] would also help? For core system libraries, at least.
    • by Jeremi ( 14640 ) on Tuesday March 17, 2015 @10:24AM (#49275809) Homepage

      don't the shared libs need to be signed.

      I was under the impression that as of MacOS/X 10.9.x, all distributed shared libraries in your .app directory needed to be signed as well, or Gatekeeper would treat the app as if it was unsigned. (See the "Code Signing Changes in OS X Mavericks" subsection at this link [apple.com])

      Is the vulnerability described in the article applicable only to older versions of MacOS/X, or has the researcher found a way around that test?

      • by Princeofcups ( 150855 ) <john@princeofcups.com> on Tuesday March 17, 2015 @10:37AM (#49275943) Homepage

        Is the vulnerability described in the article applicable only to older versions of MacOS/X, or has the researcher found a way around that test?

        Quoting the article: "It’s not a point-and-click exploit – the attacker will need to get on the same network as the target Mac, either through a breach or by sharing the same public Wi-Fi access point, and then inject a vulnerable but legitimate application and make some purely cosmetic changes to the appearance of the .dmg (virtual installer disk) file when mounted."

        Sounds pretty theoretical at this point. I don't see the "reliable technique of Shared Library replacement" that the summary declares.

        • by bsDaemon ( 87307 )

          There's a difference between "reliable technique for script kiddies and Anonymous" and a "reliable technique used by foreign intelligence services who, if they want something bad enough are going to get it one way or another". For them, the "cyber attack" aspect is only one method and if it becomes untenable they'll revert to HUMINT means. Human infiltration or malicious insiders can be used to gain the access necessary to propagate the dylib injection attack and gain a more long-lasting digital foothold.

          • by Anonymous Coward

            If the U.S. government had reliable HUMINT programs they might actually be able to catch terrorists, rather than relying on mass surveillance and a crap load of rockets.

        • They leave things a little technical and obfuscated to slow down the script kiddies. You don't want to ship an exploit, just distribute the information.

    • by phantomfive ( 622387 ) on Tuesday March 17, 2015 @10:54AM (#49276085) Journal
      It's complicated. On iOS, the libs all need to be signed and encrypted (the executable portions are encrypted, the metadata is not; so you'd need more than just correct hashing). On OSX, they need to be signed if you enable that in your settings (I haven't checked if the executables from iTunes are encrypted). The researcher is not being very clear. Note for example that the article says, "Wardle is also expected to release following his talk source code for a scanner that discovers apps that are vulnerable to his attack." Note that he didn't say he would release his proof of concept. Any of us can write a Python script that searches for .dylibs.

      So, there are several avenues for attack. One, you could replace a .dylib with one of your own. Secondly, you could append your own code to a .dylib. It's an old technique explained here [reverse.put.as]. You can actually re-sign this and iOS will accept it and run it. Is this what the researcher is doing? He didn't explain.

      He claims to have gotten around the need for signing. How did he do that? In his demo, will he merely disable the setting that requires signing? It's hard to know if he doesn't release his proof of concept.

      I've looked through the mach-o .dylib loader code before, and it didn't feel tight at all. There is plenty of potential for an exploit, so I could believe he found one, but once again it's tough to believe this guy if he doesn't release his proof of concept.

      The fact that the guy is talking more like a PR representative than a researcher makes him suspicious.
      • by Anonymous Coward
        As the Forbes article states, downloads from the Mac App Store are not vulnerable. Normal HTTP browser-based downloads (e.g. dmgs/zips) are vulnerable even if the user has GateKeeper set to only allow stuff from the Mac App Store (highest setting) - so its really just a GateKeeper bypass. I'll be releasing python code, a UI app (for scanning), slides and an in-depth technical white paper that describes everything in great detail :) Didn't want to give away all the details before the conf talk!
    • Incidentally, in the mach-o file format, there is no way to 'load every dll in the directory' or 'load every dylib in the directory.' You have to explicitly list every dylib you want to load, including the full path (or starting your path with @appdirectory). So some of the things this guy says seem a little off. Like this one:

      He noted the attack should also work on downloaded .zip files that contain applications.

      That sounds like he's talking about unsigned applications. Which of course, if you replace a DLL with a different DLL, the different one will get executed. That's not really a vulnera

  • ...an attacker on the same network...

    In most scenarios, unless you have an NSA mole in your home/business, Isn't that basically the same as requiring direct access to the machine? Or are we just talking about "on the same planet" type of access?

    • Given that they can have access to all the cellular networks....

    • by WD ( 96061 )

      Have you ever connected to a network that wasn't yours?

      • Have you ever connected to a network that wasn't yours?

        Yes, but there is a limit to my mis-trust.

      • Have you ever connected to a network that wasn't yours?

        Yes and whenever I do connect (to an untrusted network that isn't mine) from my laptop or from my Android-based Samsung Galaxy S5, I use the latest stable OpenVPN client to connect to a VPN server on my Rasberry Pi at home.

        • by zlives ( 2009072 )

          yayy you and 3 other guys that are protected maybe!!
          chances are your other family members are probably not so secure and they may introduce devices to your network that are compromised.
          the correct answer is give up :)

          not give up security but just the internet... i hope this pigeon reaches /.

          • by zlives ( 2009072 )

            yayy looks like the redundant pigeon made it, lost one to MITM... poor Louis you will be missed.

      • by Imagix ( 695350 )
        _And_ download new software? No.
    • ...an attacker on the same network...

      In most scenarios, unless you have an NSA mole in your home/business, Isn't that basically the same as requiring direct access to the machine? Or are we just talking about "on the same planet" type of access?

      No, it means someone has replaced your access point, impersonated it or you are connecting to a network that isn't yours.

      And no an encrypted WiFI doesn't help, the AP still has access to the unencrypted data.

      • by DarkOx ( 621550 )

        ...an attacker on the same network...

        I hate the language because its wildly in accurate. It should read an attacker on a network between yours and the servers, inclusive.

        Anyone who can MITM the traffic in anyway can use most vulnerabilities that are written up that way. I don't care if its thru some source routing, arp poisoning, packet capture off router or switch interface you traffic will traverse, maybe manipulating related traffic like DNS replies so you address them and they proxy; whatever. There are literally tons of ways.

        I think t

    • Or just one system on your network compromised by other means.
    • by ledow ( 319597 )

      This is the bit that makes me wonder about the "Update Cache" functionality on Apple devices where you can have a server on your local network that ALL devices behind that IP get their updates redirected to as soon as it's turned on.

      Basically, Apple Macs and iPads will do "WSUS-like" updates automatically from any local Mac server that appears to come from the same IP as the Mac/iPad in question. Without asking. Without the clients knowing. And with its own local cache of updates.

      • This is the bit that makes me wonder about the "Update Cache" functionality on Apple devices where you can have a server on your local network that ALL devices behind that IP get their updates redirected to as soon as it's turned on.

        Basically, Apple Macs and iPads will do "WSUS-like" updates automatically from any local Mac server that appears to come from the same IP as the Mac/iPad in question. Without asking. Without the clients knowing. And with its own local cache of updates.

        Then I guess most of us are safe; because there are virtually no "Apple Mac Servers" in use, anyway.

        And are you talking about "Net Boot" stuff? Because that is even more rare.

        And what do you mean by "comes from the same IP?" By definition, that is essentially impossible.

        • by ledow ( 319597 )

          Er... never heard of NAT? Or IP spoofing?

          And, no, it's not related to the Net Boot things.

          Update Cache basically is a way to deploy a Mac server on your network and stop all the iPads/iMacs on site trying to update from Apple directly.

          The server advertises itself to Apple, who then redirect ANY machine that seems to have the same IP to update from the specified update server. For OS X updates, iOS updates, even apps. Basically, one "Apple Server" (or something that advertises itself as such) on your loca

          • Sure, there's probably encryption and hashing and verifying and all that supposedly going on,

            So, IOW, you have no idea as to what the security measures are that Apple has put into place, and you are simply speculating that it would be insecure is ridiculous.

            • It would seem that way. I haven't looked at the protocols, but I do have the OS X Server app ($19.99) running on a Mini on my home network with the caching functionality turned on. It appears to be nothing but a CDN that caches various Apple downloads (software, media..) locally and acts similarly to a transparent proxy. I wouldn't be horribly surprised if it was running Squid, but - like I said - I haven't looked at it. So if we're now at the point that content caching is anathema, then we'd better all ju
              • if we're now at the point that content caching is anathema, then we'd better all just unplug from our ISPs and start sneaker netting everything. Or something.

                Exactly.

      • Except that if you are using the Software Update Service that is part of OS X Server, you either have to MITM DNS and re-point swscan.apple.com to your box, or you have to enroll all the Macs you want to redirect to the Profile Manager service on the same server (or another MDM profile you've created with something) that tells it to get it's software updates from that location. Or, if you want to go old school, you'd need to edit the /Library/Preferences/com.apple.SoftwareUpdate.plist file and add a Catalo

      • by mlts ( 1038732 )

        Isn't Update Cache similar to WSUS? This makes sense since LAN bandwidth is almost always a lot more plentiful than having every box pull their updates via the Internet.

        AFIAK, Apple's updates are signed, so if someone does tamper with the update cache server, it will be detected.

  • HTTPS? (Score:3, Insightful)

    by Anonymous Coward on Tuesday March 17, 2015 @09:34AM (#49275291)

    I tend to agree with Apple on this one; there shouldn't be any need for HTTPS as the contents of the packages aren't meant to be secret. If this researcher was successful in his attempts to replace the shared libraries in a dmg package the problem is that the installer isn't checking for the signature on the dmg, or individual signatures of files within.

    tldr; so long as proper signatures are in place and handling is observed traffic interception is not a problem as it will be caught and the hijacked package discarded.

    Note that proper signatures are more secure than HTTPS, as the trusted Root CA list is necessary for HTTPS to work, and who really thinks that Verisign or the like would turn down a request from the US Government?

    • by Anonymous Coward
      the contents of the package may not need to be secret, but people may not want the NSA to know which packages they're installing.
      • by Anonymous Coward

        Good point, but afaik https "get" request isn't going to be encrypted, only the result of the request.

    • by ledow ( 319597 )

      How do you obtain the expected signatures to match against the package if not by HTTPS or similar?

      As you point out, if Verisign is happy to oblige, then the signatures can be altered in-transit as easily as the packages here, and there'd be no warning.

      It only takes one Apple-signed developer package in the hands of someone with this kind of access to fake the origin and authenticity of the package signature AND package if the connection itself isn't secure.

      • by tlhIngan ( 30335 )

        How do you obtain the expected signatures to match against the package if not by HTTPS or similar?

        As you point out, if Verisign is happy to oblige, then the signatures can be altered in-transit as easily as the packages here, and there'd be no warning.

        It only takes one Apple-signed developer package in the hands of someone with this kind of access to fake the origin and authenticity of the package signature AND package if the connection itself isn't secure.

        The packages are signed by Apple using a key provid

    • For non-app store downloads, Gatekeeper is supposed to be this check (e.g. the user can say only allow signed apps or only apps from the app store). So yes, any HTTP download can be modified - the vulnerability here, is that Gatekeeper can be bypassed to run the injected unsigned code, even if the user had set Gatekeeper to only allow code from the Mac App Store.
  • there are lots of shared object files in /usr/lib/[some-file-name].so

    arent those the equivalent of dll files? or close to it?
    • Yes, .so are exact equivalents of .dll, but as all major distributions sign packages as whole, this attack can't be used.

      • I'm not sure what you mean by "sign packages as a whole" since that wording is somewhat ambiguous, but apt, at least, doesn't sign individual packages [debian.org]. The only signature in place for secure apt is the one placed on the package file listing in the repository. That signed file contains the list of checksums (MD5, SHA1, and SHA256) for each package archive in the repository.

      • Yes, .so are exact equivalents of .dll, but as all major distributions sign packages as whole, this attack can't be used.

        The problem still remains that after the package has been installed, a file in it can just be replaced with a malicious version either on disk or in memory.

        • by Imagix ( 695350 )
          You can replace the executable too. This part is blazingly obvious. The more "interesting" part is apparently replacing the file as it passes by during download.
        • by 0123456 ( 636235 )

          The problem still remains that after the package has been installed, a file in it can just be replaced with a malicious version either on disk or in memory.

          To do that, you need to be root. If you're root, you can do anything you want.

  • Laugh (Score:1, Insightful)

    by koan ( 80826 )

    renders Apple's OSX operating system just as vulnerable to exploitation as Windows has been

    Another arrow for my quiver, and I get to say I told you so.

    Shit has always been insecure, remember? It relied on the fact almost no one used Apple "security through obscurity".
    https://pbs.twimg.com/profile_... [twimg.com]

  • Paranoia intensifies (Score:4, Interesting)

    by MacDork ( 560499 ) on Tuesday March 17, 2015 @10:49AM (#49276045) Journal
    XCode is pwned. Android Developer Tools are unsigned. The Android SDK and tools are unsigned. That makes me sad because I work with these tools. I can assume my systems are all pwned at this point and act accordingly...
    • You can build the Android SDK yourself. A lot of open source downloads will tell you the MD5 hash when it downloads it, and I believe Ubuntu actually verifies the hash.

      However, both Apple and Google are compromised by the NSA, so even if they were signed, it wouldn't matter.
    • Also, the Android SDK is downloaded over https, so you don't need to worry about this attack.
    • by Anonymous Coward

      I would suggest switching to a Yubikey NEO for OpenSSH. https://www.yubico.com/products/yubikey-hardware/yubikey-neo/

      That way your key isn't recoverable by anybody, including yourself. Assuming the Yubikey hardware isn't flawed. The downside is that because you literally cannot back up the key, you really should purchase two of them, cross-sign them for revocation, add both keys to all your authorized_keys files, and keep one in storage in case you lose your primary/

      While it's plugged in it could still be u

      • by mlts ( 1038732 )

        Yubikey looks interesting, but I've used eTokens in the past (generated a key on a computer with FDE, imported the key into three tokens, then physically destroyed the HDD that had the key on it since it was giving SMART errors anyway), as a way to have physical security of keys (if I have the three tokens, I know the key isn't going anywhere.)

        eTokens served me well, although it is impossible to find PKCS drivers for them for newer Windows and OS X versions these days.

        They also serve as great ways to counte

    • by AHuxley ( 892839 )
      Re" That makes me sad because I work with these tools. I can assume my systems are all pwned at this point and act accordingly..."
      Yes write any messages on paper, covert to a one time pad and then enter that into the compromised hardware, software, OS, crypto and network.
      Consider future hardware and software buying re tame brands and their help with the world wide wiretap.
  • The degree of response by our government to terrorism does not seem to be justified. We did lose some large buildings and a few aircraft but considering the size and nature of the US the 9/11 attacks were simply a very limp effort and came far from doing major damage to our nation. The three trillion dollar expense of our wars in the mid-east have surely done us more harm than the attacks. And one can only wonder about the massive expense of all the spying that is going on. I also wonder why, consid
    • by Livius ( 318358 )

      The purpose of the September 11th attacks was not to kill or destroy, but to cause the US to betray what few of its principles it still had and to pursue military misadventures that would create more enemies that they would eliminate. It was one of the most successful operations in all of human history.

      The purpose of the response to the September 11th attacks was to expand the surveillance powers of the US government, further the careers of second-rate politicians, and funnel public money to defence contra

On a clear disk you can seek forever. -- P. Denning

Working...