Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Security exposure in Software Update System
Thanks to a couple of alert readers who pointed this one out to me...

Russell Harding has identified a relatively major security exploit in the OS X Software Update mechanism. Basically, since the server does no authentication, it's possible to spoof the update server and install whatever you like. Russell has published an exploit which demonstrates the nature of the problem. The exploit installs a hacked copy of the SSH daemon which allows easy access to any (including root) account on the system.

I don't generally choose to publish security exploit information, but this one seems relatively important! Hopefully Apple will find a way to (quickly) secure the Software Update process.

Thoughts, anyone? Is this a major hole, or is it not really that big of an issue? As a non-technical user, I'm not sure I understand exactly how this exploit could be installed on my machine ... so I'm not sure how worried I should be!

JULY 13 UPDATE: Apple has now released an official patch to cover the Software Update security exposure. It is not available through Software Update (for obvious reasons?), and Apple has included a checksum to verify your download prior to installing, if you wish.
    •    
  • Currently 0.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (0 votes cast)
 
[4,003 views]  

Security exposure in Software Update | 24 comments | Create New Account
Click here to return to the 'Security exposure in Software Update' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
corporate update solution?
Authored by: semios on Jul 08, '02 02:21:58PM

Being able to interpose your own update server could actually be of great benefit both for IT departments and software companies. Imagine a school with some 2,000 computers on campus, they set up their own update server and voila, updating software becomes trivial. I think apple should open it up, so that people could actually subscribe to different update servers (definitely include authentication though). Instead of every application having to implement it's own software update. More security would be required, but this would be nice would it not?



[ Reply to This | # ]
corporate update solution?
Authored by: nhl00 on Jul 08, '02 02:31:17PM

In my opinion these are two different problems - the first problem (security) I would rate as moderate. If I understand it properly, the exploit requires that you on the same network as the target machine (they go through you, as opposed to you "reaching out and touching someone") So you can root a co-workers machine. Not good, but you could do that just by sitting at their desk...

As for allowing other software to update - it would be awesome if my software update automatically checked for all of my softare. No need to troll version tracker and compare release versions!

just my $0.02 worth
Frank



[ Reply to This | # ]
corporate update solution?
Authored by: junkie on Jul 08, '02 06:46:42PM

I agree that apple should find a way to open this up to other developers - but it also seems like the security issues should not be underestimated.

One thing I am wondering about this problem is that how do we know that people won't exploit the vulnerability as Apple is sending out the patch for the problem. Seems like a particularly bad security problem to use public pressure to fix.



[ Reply to This | # ]
No worries
Authored by: Moo0 on Jul 08, '02 02:50:29PM

This is more or less the same as what is happening with the latest winamp bug, where the auto-update function can be overflowed. One could then execute malicious code.

As long as you can trust your connection, this isn't much of an issue. DNS poisoning and spoofing is not something easy to do (though altering someone's DNS entry could be easy when you have either physical or remote access).

But, if you suspect your DNS server isn't reliable, then much more can go wrong. Who says your email isn't "screened", or your ssh sessions? If the traffic is routed properly and a different IP is given for an address, a lot more can happen.
This would work as follows: you connect to pop.server.com, which the DNS server gives IP 10.0.0.67 for but should be 213.45.38.212. You then connect (unknowingly) to the 10.* server which simply connects to the 213.* server and passes on any information; but can alter, monitor and spoof any data in between.

Hey, nobody said the internet was secure...



[ Reply to This | # ]
No worries
Authored by: Mikey-San on Jul 09, '02 02:38:41AM

Um.

No.

If I start an SSH session with a remote host (let's call it "Leet Remote Box"), I don't give a crap what's in between me and Leet Remote Box. Not the guys running the DNS boxes, not my provider, not even Miss Cleo.

It's encrypted via whatever encryption algorithm you've defined, and can't be read in transit as plain text--Secure SHell sessions look like garbage between hosts. If it didn't work like that, you may as well be using freakin' telnet. Here's where I shudder.

Nothing is truly secure (this Software Update thing isn't really new, since Windows Update and Debian's package update system, to name a few, also use straight http lookup requests in their update process), but SSH is certainly a Good Thing(tm).

My dual, shiny copper discs.


-/-



[ Reply to This | # ]
No worries - not entirely so
Authored by: Moo0 on Jul 09, '02 03:57:35AM

Yes, SSH traffic is supposed to be secure. But, you CAN intervene between a host and client; as long as the client thinks it's connecting to the host; and the host to the client.
It's unlikely for this to be undetected if the client has connected to the host before (an alert will be shown by ssh, stating the fingerprint has changed) and/or knows it's fingerprint which the client *should* always check. The user is usually noted on *NIX systems when conencting, from which IP it connected last time. This should alert the client.

Maybe i'm not clear enough, but here's how things should happen:
-client connects to server 1
-server 1 connects with server 2
-server 1 decrypt data between s1 and s2, and s1 encrypts data again for client

See http://www.kb.cert.org/vuls/id/786900 as well. If the user connects for the first time, or simply doesn't read the warning properly when the fingerprints differ from a previous connection - you have a hacked session.



[ Reply to This | # ]
How Apple could fix it (and open it)
Authored by: Anonymous on Jul 09, '02 04:35:30AM

Hi!
This exploit (same as the one possible on ssh, but there you will be warned) is called "man-in-the-middle-attack".
But it would be simple for apple to provide a public_key/signature with future "original installations", so all future data from Apple could be verified (they can also use gpg-signing or so, the point is, every mac needs to have a way to "proof" the software you download is indeed from Apple and no-one has hampered with it.
The benefit of this is, a corporate administrator can add (and add the public-key) for local update-servers.

However, for Apple, there is a bootstrap problem, to bring the public-key to every mac, you need to receive the correct one once - but it is not feasible for anyone to prevent the transfer of the correct public key on the long run. (Checkout the GPG or OpenSSH-Hompage on how to validate transfer public keys)

I hope this is helpful to clarify the situation,
iSee



[ Reply to This | # ]
How Apple could fix it (and open it)
Authored by: escowles on Jul 09, '02 08:51:10AM
There is a golden opportunity for Apple to distribute a public key for validating future Software Update releases: Jaguar. Assuming it's like 10.1 where they are going to distribute CDs, they could include it in the Jaguar CD and install it by default.

For that matter, since openssl is already installed by default, they could also switch Software Update to use SSL-encrypted communication, which would allow them to use the public key to validate the update server, in addition to the packages once they're downloaded.

They could also have a public key and a new version of Software Update for download at their website (https, of course, so it can be verified to be Apple).

-Esme

[ Reply to This | # ]

Article has changed
Authored by: Mad Hatter on Jul 08, '02 04:23:19PM

I downloaded the text early today when I read about this exploit on MacInTouch. In the interim it has now removed some of the more serious how-tos and such regarding spoofing and impersonating.

You end up downloading what you think is an Apple Security update for sshd for instance, and a backdoor is installed. You're hacked, your machine can be used as a zombie, or to stage a DoS attack. It allows someone who knows about the hack to login to anyone - and it doesn't show up!

I was troubled to see this depth and the tools to 'demonstrate' this exploit published. I think he went too far. Maybe CERT and Apple were notified and didn't take action or take it as a real threat in "reasonable' time frame.

I hope some of the security packages that do more than basic firewall will or already do help block or log and alert on such an attempt.



[ Reply to This | # ]
Article has changed - NOT!
Authored by: Mad Hatter on Jul 08, '02 04:59:05PM

I just checked and there are TWO versions of the exploit, the one linked to in the article on MACOSXHINTS ( http://www.cunap.com/~hardingr/projects/osx/ )and the link from the mention on MacInTouch which has a more detailed descrption. ( http://www.cunap.com/~hardingr/projects/osx/exploit.html )

I only read the exploit this morning, and OS X Hints links to another page that has a link to "exploits" page.

Sorry.



[ Reply to This | # ]
Why shouldn't he demonstrate the exploit?
Authored by: Moo0 on Jul 09, '02 02:20:35AM

It's quite common for security holes to be demonstrated, even if it is to show you how simple it can be done. Don't feel threatened by the fact that a 'step-by-step' tutorial is given. I would have come up with more or less the same procedure.



[ Reply to This | # ]
Why shouldn't he demonstrate the exploit?
Authored by: chbrosso on Jul 09, '02 09:08:36AM
The exploit is demonstrated here

[ Reply to This | # ]
Digital signatures
Authored by: calroth on Jul 09, '02 05:44:21AM

I reformatted my hard drive over the weekend, and had to install a lot of patches to bring myself up to date. So, I was thinking, why doesn't Apple provide capability for digital signatures and use them for its updates? Basically, don't trust the Internet for transport, but trust digital signatures to make sure what you're installing isn't a hacked version of sshd...

As mentioned, getting Apple's public key to the masses could be difficult. It really should have been bundled in with Mac OS X in the first place. Or could be bundled with Jaguar. Of course, you'd have to check the fingerprint or blindly trust that nobody's substituted Apple's public key with their own... but then, how many people have checked the fingerprints on the root CA certificates in their web browser?

An easy way to implement all this is to allow digital signatures in Disk Copy, and simply distribute all Software Update updates as disk images (mounting them automatically). There's already been tips today about how disk images allow encryption via AES and how to do MD5 hashing... Apple should implement authentication as well.



[ Reply to This | # ]
Software Update server
Authored by: SkyProf5 on Jul 09, '02 09:57:18AM

Doesn't Software Update only access Apples servers?
It would seem the hacker would have to install his malicious code there for Sofware Update to access it?

Someone mentioned DNS spoofing; but then everyone using that DNS has bigger problems.



[ Reply to This | # ]
Software Update server
Authored by: Miniluv on Jul 09, '02 02:41:59PM

It is supposed to only hit the Apple servers, however Apple uses a name, such as software.apple.com, so that they can change machines if need be without impacting the end user. This is a Good Thing, however it means that if I intercept your communication with your DNS server I can send you wherever I want, and give you whatever software I want.<p>
Even if they didn't use a name, but instead used an IP, I can still spoof the transactions if I so desired. This is what's called a man-in-the-middle attack, and it's pretty old in terms of techniques. It's not an easy attack, but still very doable.<br>



[ Reply to This | # ]
Don't use Software Update to...
Authored by: asxless on Jul 09, '02 10:44:03AM

There is a very simple solution until the patches are released. Don't use Software Update to actually 'update' your system.

FWIW I just use "Software Update" to notify me of available updates and then go get them for Apple's site. Yes, I have to wait a few days for the downloads to be available but except in rare circumstances the update is not necessary to install immediately. I find this delay to be beneficial, in that I don't get stung by the early release install bugs and I have a copy of all the important updates in case I need to do a 'ground zero' OS X install ;)

asxless in iLand



[ Reply to This | # ]
Do not use Software Update to...
Authored by: Paul Burney on Jul 09, '02 11:15:35AM
FWIW I just use "Software Update" to notify me of available updates and then go get them for Apple's site. Yes, I have to wait a few days for the downloads to be available but except in rare circumstances the update is not necessary to install immediately.

Unfortunately, that isn't much more secure (if at all) than using Software Update. This problem hinges on DNS poisoning. If I go to all the trouble to get your machine to think my IP address is apple.com, it wouldn't be much more work to copy the apple.com website and place my tainted binaries in the download section.



[ Reply to This | # ]
DNS Poisoning is not a show stopper
Authored by: asxless on Jul 10, '02 01:38:55AM

DNS Poisoning is a problem but it does not have to be a show stopper since you can avoiding DNS poisoning hacks and verify that the pages and downloads are coming from the correct machine, by bypassing DNS and using the valid IP#s.

For example, the link to the OS X 10.1.5 update is on....
http://www.info.apple.com/support/downloads.html
where:
www.info.apple.com internet address = 17.112.147.32
www.info.apple.com internet address = 17.112.147.33
www.info.apple.com internet address = 17.112.147.34

the download is kicked off from...
download.info.apple.com internet address = 17.112.147.90
download.info.apple.com internet address = 17.112.147.91

and the actual download is from...
a1568.g.akamai.net internet address = 65.65.70.235
a1568.g.akamai.net internet address = 65.65.70.234

What I do is the substitute the real IP#s in the URLs to avoid using DNS servers and verify that the pages/downloads are coming from the correct machine.

asxless in iLand



[ Reply to This | # ]
Only now
Authored by: Glanz on Jul 09, '02 11:57:48PM

It is only dangerous now that it has been made public. Getting a malicious update is less than possible from the update site. Don't forget folks, that we are not "windozers"....



[ Reply to This | # ]
Only now. . . that's what Gates said
Authored by: mirzu on Jul 13, '02 03:39:36AM

"security through obscurity" doesn't work



[ Reply to This | # ]
Installation Security and OSX
Authored by: kdawkins on Jul 09, '02 11:58:47PM

The suggestion to use various authentication methods to validate SW sources is appreciated AND there is NO substitute for practicing good backup habits ESPECIALLY prior to upgrading system software.



[ Reply to This | # ]
And how does this work exactly?
Authored by: Rosyna on Jul 10, '02 08:03:43PM

I see it can work fine for a *local* machine. It just overrides the request. But how would this work for a machine not on the same subnet? Even then, the spoofer needs to get access to the victims streams. In a switched or completely routed network (no hub) how is this possible? Anyone?



[ Reply to This | # ]
It works like this...
Authored by: Accura on Jul 12, '02 05:19:25AM

I got hired by an ISP about 4 months ago and are undergoing training, i;ve been using macs ll my life and sarted to play with *nix when i installed OSX PB. Now taking into account that i've only been doing DNS stuff for abou 2 months i could set up an new DNS subdomain and dirvert for a false ASU page. This does require root access to at least the primary name server. i'm not good enough with any *nix to do this. Also remember the closet you get to the / dir in the DNS chain the more wide spread this would be. now if i can do this with only 2 months basic traingin on how NS works how easy would it be for some one who as been playing with *nix for years. If your going to reply to this saying how much moe sucure NT is to access (not that i would think so conidereing this is a mac only site) don't even bother, there is no way you could pull an argument off with that.

Sorry about my spelling,like all computer users i spent to much ime ditching english at school



[ Reply to This | # ]
Official fix release
Authored by: nagani on Jul 13, '02 10:16:04AM

Apple has released a security update last night Friday:

http://docs.info.apple.com/article.html?artnum=75304



[ Reply to This | # ]