My sample exploit uploads some of your private data (your Top Sites, for example) to a server that I control, because that's an easy thing to do when I can run any JavaScript I want. Note that I'm not really collecting any data, as http://lapcatsoftware.com/test/ is a dead link. I used http so that you can see the private data being sent in a packet trace.
Please don't do this when reproducing exploits. Yes, it's just source code, and yes, the url is dead. But it's still source code that, when compiled, will grab your real safari data and attempt to upload to a url that could be switched on.
There's a difference between repro'ing an exploit and weaponizing an exploit. alert(1) is generally the best thing to aim for, or even alert(some user data) to illustrate the point. Whereas upload(some user data, my server) is a bit too close to the moral equivalent of `rm -rf $HOME/*`: all of these illustrate the point, but rm'ing a homedir is generally not a great thing to have in your repro; ditto for uploading real user data.
exmaple.com was explicitly reserved for scenarios like this, which would accomplish the same thing safely.
It may seem like a pedantic point, but it was something I was taught as a pentester: don't weaponize exploits; simply reproduce them. So my instincts kicked in, and it's impossible not to mention it. (That said, I don't mean to make a fuss – it's not a big deal in this case.)
By the way, I found this post via the author's twitter: https://twitter.com/lapcatsoftware I've been following them for about a year now, and their tweets on Mac programming have been quite informative.
Another problem with this demonstration is that by exfiltrating the data via HTTP, even if it ends up in /dev/null on the other side, the user’s ISP and anyone else in a position to sniff packets along the route can now know the user’s top sites.
Why would you run _any_ code with a known exploit on a personal machine with your personal data. At minimum make a new user and run it on there for heaven's sake.
No expert, but even example.com isn't totally safe, right? According to the RFC (https://tools.ietf.org/html/rfc6761), while these domains are reserved, nothing should treat them specially, so there's nothing to stop people having them routed somewhere else at the DNS level.
AFAIK the domain is controlled by the IANA, so it's probably not too big of a security risk. If you really want to be paranoid you can set the site to be 0.0.0.0 or attacker.invalid.
0.0.0.0 is localhost, which is a great way to allow other software running on your computer to take the data and send it elsewhere. It's not a great IP address to use for "invalid".
Yes, 0.0.0.0 really resolves to 127.0.0.1 on Linux at least. Try it.
Not saying 0.0.0.0 should be used in this case, but if you have data sniffing software listening on port 80 or 443 without your knowledge (or really any port at all, but especially a privileged port), you probably have much bigger things to worry about than some ad hoc PoC sending data there.
But by default they won't be routable. I guess you can shoot yourself in the foot and have entries in your /etc/hosts point to your attacker's site, but that's kind of hacking yourself.
The standard forbids (well, "should nots", which is the best you get most of the time) .invalid. from routing. It's supposed to be filtered at the nameserver API level and everything after that (cached DNS, authoritative DNS, registrar, etc.)
.local is a bit problematic since there are RFC's explicitly stating this should only be resolved by multicast DNS which has its own security issues and also fallback lookup is somewhat undefined.
I agree. In my opinion, it would be useful if every browser and API client did something special with that domain. To the best of my knowledge, this is not the case. AFAIK I could easily plug that domain into my unbound servers which my SSL MITM proxy utilize and route traffic to it.
If the client is not aware of a special domain, then you are dependent on the infrastructure to behave in a predictable manor. Attackers can alter that behavior.
It's very unlikely that those reserved domains will be controlled by someone nefarious in the foreseeable future.
I've made it a habit to use them instead of something like "insertyourdomain.com" in example configurations or dummy data for tests (where I perhaps need a valid-looking domain). In the unlikely event that something is ever sent to it, example.com is a much better choice than just some random string, since someone could register it and accept that traffic.
Please don't do this when reproducing exploits. Yes, it's just source code, and yes, the url is dead. But it's still source code that, when compiled, will grab your real safari data and attempt to upload to a url that could be switched on.
There's a difference between repro'ing an exploit and weaponizing an exploit. alert(1) is generally the best thing to aim for, or even alert(some user data) to illustrate the point. Whereas upload(some user data, my server) is a bit too close to the moral equivalent of `rm -rf $HOME/*`: all of these illustrate the point, but rm'ing a homedir is generally not a great thing to have in your repro; ditto for uploading real user data.
exmaple.com was explicitly reserved for scenarios like this, which would accomplish the same thing safely.
It may seem like a pedantic point, but it was something I was taught as a pentester: don't weaponize exploits; simply reproduce them. So my instincts kicked in, and it's impossible not to mention it. (That said, I don't mean to make a fuss – it's not a big deal in this case.)
By the way, I found this post via the author's twitter: https://twitter.com/lapcatsoftware I've been following them for about a year now, and their tweets on Mac programming have been quite informative.