TUCoPS :: Macintosh :: bu-2073.htm

Safari browser port blocking bypassed by integer overflow
Safari browser port blocking bypassed by integer overflow
Safari browser port blocking bypassed by integer overflow

Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

             g . o . a . t . s . e       s  . e . c . u . r . i . t . y         
  g . a . p . i . n . g       h . o . l . e . s      e . x . p . o . s . e . d
                               (323) 306-4576 

attention: due to technical limitations, this advisory cannot be displayed 
correctly. to view with images and video, visit the following page: 
warning: some of the content on this link may offend you and your employer.

We at the Goatse Security labs have been delving into an old (but also new)
class of web exploits originally coined cross-protocol scripting, but now more
commonly referred to as inter-protocol exploitation. 

Goatse Security has a double feature for you, starting with a 0day vuln:

* Safari (and other webkit-based)browser port blocking bypassed by integer overflow

and a technique that, as far as I know, has not been premiered before:

* XHR (XMLHttpRequest) as a vector for mail merging or wordlist attacks in
   XPS/IPE attacks

We're going to show you how these two methods combine like Voltron into a whole
much larger than its parts. At the end of this short advisory you will be able
to take any Safari web browser and make it a spam drone, a wordlist-based logon
cracker for networks, or a relay for payloads to arbitrary daemons. You will be
able to do all of this without passing any shellcode or alerting any IDS to

Let's cover the bug.

First, I would like to give credit to my cat, Gary C. Berries, as the initial
researcher to uncover this bug. Without my cat's assistance as an enterprise
class keyboard-based integer fuzzer this vulnerability would have been left 

Apple is going to learn several lessons here, the most important of which is 
probably not to let an unsigned short pose as anything other than an unsigned 
short. Open up a Safari browser on your favorite chode-sniffing operating 
system. Go to a "banned" port like 25 and you'll get an error:

___Not allowed to use restricted network port___ (WebKitErrorDomain:103) 

Add 65536 to 25 to make 65561 and revisit the site on this new port-- no such
cockblocking. You're good to go. You can now use the Safari web browser as a
device to hit any port on any address with a cross-protocol scripting attack.

HOWTO video! http://vimeo.com/10302434 

List of Webkit-based browsers found to be affected:
OS X Safari
iPhone/iPod Safari
iPad Safari (confirmed with iPad Simulator in SDK 3.2 beta 4 w/ XCode 3.2.2)

The only Webkit-based browser found to not be vulnerable:
Google Chrome

For all Apple's talk of "think different" the only one actually doing so in
regards to browser security is Google. XSS, XPS/IPE, all the traditional
methods fail against Chrome. Google, I don't even care that you are the most
ruthlessly evil corporation in existence anymore. Your stuff just works. You
had me sold at functional reliability. There was a time in my life that I had
large concern about corporate ethics. Now I know that all corporations are
evil. Some more than others. The one who is evil and smart will only ruin you
with malice, where the one that is evil and stupid can ruin you out of both
malice and out of sheer incompetence.

To give this exploit a little of that "je ne sais quoi", we need to come up 
with a good attack vector. Now we're going to show you how Apple didn't just
unearth a decade-old vulnerability and make it viable again a la Microsoft, it
actually becomes more viable to exploit in this new generation than it was at
the time of its inception. When cross-protocol scripting was born, Javascript
was pretty young. There wasn't a whole lot you could do with it then--any bits
of Javascript now called AJAX wouldn't be a cross-browser standard until 2004.

So I looked at this integer overflow and I thought to myself what exactly I'd 
find this useful for. The answers I came up with were:

* Getting idiot Mac-using creative people at bulk mailing companies to click
   on links which spew SMTP envelopes at their internal mailserver, thereby
   utilizing someone else's email reputation to send CPA offers of my own.
* Bruteforcing device passwords via a wordlist and then phoning home
* Reflashing network devices with firmware more fun than the factory default
* Relay exploit payloads to non-HTTP daemons on arbitrary TCP ports
* Get a Safari web browser to do pretty much anything on any TCP port and not
   have any current IDS/IPS in existence be any wiser for it.

We summarily implemented all of these things, but I'm going to show you how to
do the first one since the code is trivially altered to do many of the others.
Also because it is the most fun and easy way to monetize this particular vuln,
and I'm hoping other people will make use of it before Apple patches!

(The best part of our first cross-protocol scripting PoC release:
was seeing how many other people used it to summarily ruin every IRC network
that exists. What can I say? I love being an enabler.)

What you'll need:

* A PoS web browser from Apple
* An MTA that ignores synchronization and is error tolerant

For the latter you may be asking, what MTA ignores synchronization? Well, more
than one of them do out of the box. They generally cost five figs and are
intended for the direct email marketing industry. I'd love to tell you which
ones I got working but unfortunately I'm under NDA with them. Their software is
really good and central to my business and I paid a metric ton of cash for it,
so I would like to continue receiving updates and support and also not be sued.
I asked for permission to mention their name in a Goatse advisory but they were
none too pleased with the idea. So you will have to just make an educated
guess. There are only so many pieces of SMTP software that will cost you the
price of a decent car.

Regardless, ignoring synchronization ain't exactly a bug, it is a feature. 
This advisory is not about who writes a good SMTP server for sending bulk!
So, to initially send our first mail I tried a classic document.getElementById
and a parentNode.submit(), but found this particular vector for XPS didn't work
in Safari. So for the first wave of testing I used a multipart/form-data 
enctyped POST with a document.formname.submit. 

PoC video here: http://vimeo.com/10383253 

So now that I know that its possible to send an email, I'll want to make a mass
producing industrial line out of this bitch. We'll want a silent and deadly bit
of javascript in an innocuous page which continually refreshes a child iframe
when it is done sending its current batch of emails, whilst the child will
scrape mailing list and potentially other merge data from a function referenced
from the parent node in the DOM tree.

The parent frame is gonna look something like this:

While the child m9.html will look something like this:

action="http://target.mailserver:65561/" id="weevil">
So, there you have it. XHR is practically like some sort of God-damned voodoo, and now that it's out of the box with unblocked ports I hope ya'll have fun with it before patch time. I know this particular advisory was a little tl;dr but we're tired of people saying that this is all according to the HTTP RFC and isn't a big deal or a vulnerability (here's lookin at you, Secunia). If this is how web browsers are supposed to behave, all you security people have got a heap o trouble to look forward to. If ya'll want to hear more about this technique and get more example codes, you can check out the first issue of http://plzadvise.com/ PLZ advise, out May-ish. There will be a more substantial paper there. With love, Goatse Security --- About Goatse Security --- We are people that do shit. You may not like what we do, but we get shit done. http://www.people.com/people/article/0,,20351567,00.html "Spencer Pratt Leaves The Hills to Fight Cyber Crime" This is who you're going to be working with. Inane, whitepaper-writing idiots who have the intelligence and depth of a reality TV show star. Go back to work. Sit at your desk. Breathe the stale air under the pale glow of the flourescent lights and remember: you're on the same side as Speidi. At Goatse Security, we don't really care about fighting cyberterrorism or cyber crime or whatever. We are pioneering new classes of exploits, new methods of evading IDS and new ways to use computers as tools to make shit happen. Our minds won't be owned by some liar's system of ethics, but they are for rent to any God or government (or corporation or criminal organization) that will write a check of sufficient size. We invite you to stop pretending you care about making things more secure and just admit you're too unskilled to be a real mercenary. --- Greets --- GNAA my cat, Gary C. Berries for being the initial discoverer of this vulnerability g0udatron[gapp], Rucas, Jacksonbrown, Hephaestus Security sloth, Joseph Evers, girlvinyl, Sam Hocevar, Jesus Christ the once and future king, and all men who love merriment --Signature_Tue__23_Mar_2010_15_28_30_-0400_p0c31=nD1jGAWzYr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFLqRZj5Zqjhz/9XfMRAuH/AJwL8Q8uEhRSpkYvLSve31iCL+WRRgCgiF0n vQGX1xZsYDfPy1QPTHrKPNU=8a6r -----END PGP SIGNATURE----- --Signature_Tue__23_Mar_2010_15_28_30_-0400_p0c31=nD1jGAWzYr--

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH