"fixed the bug in about 27 minutes"
Good to see that some people take security seriously.
Comcast, Verizon and at least 70 other internet service providers are putting their customers at serious risk in their quest to make money from mistyped web addresses, security researcher Dan Kaminsky says. Speaking at the ToorCon security conference in Seattle, Kaminsky demonstrated an exploit class he dubbed PiTMA, short for …
If they took security "seriously", would they have perhaps not incorporated said bug in the first place? Or are we going to continue rewarding companies for producing sub-standard, buggy and insecure code that we're then given no choice but to execute?
I say spiked shillelagh to the kneecaps for a first offence. Work your way up for subsequent offences. It's the only way to get the clue to register.
You can climb down from your soap box now! To suggest that every programmer should be at the same level of learning regarding securely written code is completely preposterous.
BareFruit put their solution out on trial, and an error returned. Trial and error is still one of the finest methods for learning. Now, if you're unable to learn from your repeated mistakes, then I'd say you're an even worse programmer than one who unintentionally writes insecure code, and should probably consider a change in hobby or career.
So, "Net neutrality" now means that "ISPs should be barred from changing the content of pages they deliver"?
I thought "Net Neutrality Violations" would occur when differential pricing for pumping bytes at varying QoS levels was implemented.
And "small amounts of failed net neutrality can lead to catastrophic effects on internet security"? What is the exact meaning of this phrase? Why not just say that "permission by default policy" (as is the local custom on them Internets) can lead to catastrophic effects?
Looks like the Net Neutrality Offender has become the new Mud That Sticks.
'If they took security "seriously", would they have perhaps not incorporated said bug in the first place?'
Yeah, right. Because people (epecially programmers) are perfect, and it was a deliberate decision to incorporate that bug.
Yeah, right. Because programmers are never under heavy pressure by management to "get it done and out the door yesterday."
Yeah, right. Because programmers are in full control of the compilers and run-time environments that their management decides they will code to, and of the configuration of their clients' systems, so they can ensure that they work as claimed.
yeah right, either you've never written a line of code in your life, or you've written buggy code.
To me the problem here is that if I own a site the ISP can make any subdomains under it show whatever they want. At the moment it seems to be ads, but surely they could put a rival service there. Maybe if someone made cheapmp3s.itunes.com point to a different store and started marketing that address then there would be enough fuss created which would hopefully ensure that when someone owns a domainname people cannot legally redirect subdomains for any reason (mistyped or otherwise)
Remember you pay for the connection, that's all - you should be pathetically grateful if your ISP deigns to offer premium services such as DNS on top of that connection. Its only natural that they should protect their bottom line by forcing you to watch ads. Customers make such unreasonable demands, just the other day I heard of someone complaining that they'd been disconnected for over two weeks! Did the previous year of 72% uptime count for nothing?
I think that is a big harsh. I'm a sysadmin and vastly more concerned about security than most people (including many IT types) and even I'm not going to be down on a company for having an exploit found in their code. Exploits are far too common all over but what counts in a case like this is how quickly they resolve it once notified.
Cookies can be set to different hosts in a domain, that one is a bit of red herring.
But things like flash, active X and Java vulnerabilities, and trust across the domain is compromised a bit.
I imagine the practice is going to stop very soon - one lawsuit will negate all possible advertising revenue, as everyone else will just pile in, and sue away.
Trust in the domain is not a bug - it is what enables the web to work - it is the security holes in ActiveX, Java, Flash and the Browser that enable the penetration. ISPs are just increasing the vector points with this practice, so if they use practices that are not secure or get compromised it is a bit similar to your domain being compromised.
Yes, they do need to stop this practice but unfortunately the pricing models are based on it.
Bugs are not the same as security exploits. With a bug, you have code doing something that it's not supposed to do. With a security exploit the code does exactly what it should do, but there is a use case in which this doing-everything-the-way-it-should actually leads to problems.
This is simply a case of developers making a content delivery system that didn't take legitimate man-in-the-middle manipulation into account. Something that could of course have been prevented if everyone did thorough case analysis, but if you look around the table, and go "have we missed a use case?" and no one mentions this one because no one realises this is possible, there's not much in the way of blame.
That doesn't make it less of a pressing matter to fix, but blaming people on the grounds that they should deliver a perfect product is a rather holier than thou attitude. The product already worked exactly the way it should, but sadly that meant that because ISPs take liberties with DNS returns (there is no information that tells you the non-existent DNS entry you are getting content for is in fact ISP-spoofed) a security issue arose. Bad move on the side of the ISPs really. sending content to make a few more monies, fine; spoofing content to make it seem like it's a valid http request reply, not so fine.
Just a thought.
Lately, the phishing emails I have been seeing have a lot of subdomains like ww9.domain.tld.
I am so innocent about all this that I just took it to be that the malware script had picked up some load balancing on the real domain. Any script that checks URLs for malware will probably hit a 404 error.
But, have the ISP send some junk from these invented URLs and anything could be being injected.
Here are a few [edited] examples from recent phishing mails:
All the above give me an unknown server response, except for shell54.com which blocks access to root.
The 'real' URLs come from the text part of the phishing mails.
Run for cover: where is my tinfoil hat?
If you're a RoadRunner customer, you can disable the 404 redirect they're imposing at the following page:
Now my question is: If I disable the 404 redirect that they're imposing (at the above link), does this protect me from the PiTMA vulnerability described in this article?
...when I pay my (yearly) dues to a registrar, it is my understanding that I also get the right to any sub-domains. So for example, because I paid for blah.com, then www.blah.com, ftp.blah.com or even library.blah.com are mine (and only mine) to use.
So if I understand correctly, these people are trying to make money using domain names which are legally mine.
Isn't that domain-hijacking?
This is a form of DNS hijacking, and website owners should prevent it by:
* Having their name servers handle requests for non-existent sub-domains (e.g. redirect users to the www domain by default)
* Using secure communications always (i.e. always https).
Someone should also maintain a list of ISPs using this technique that other sites can query. When a user queries a non-existent domain from an IP owned by one of these ISPs the domain owner could optionally display a message, "You are seeing this page to prevent your ISP, <insert ISP name here>, from hijacking your request. If you believe your ISP should not be involved in DNS hijacking, please contact your IPSs customer service department. Click here to learn more".
Because there is a cost involved in every customer service call, and calls about DNS hijacking would lengthen the wait time for customers with other queries, I bet the practice would stop soon enough.
No - just no. My domain is not used solely for web services - something I believe to be true for a lot of domains. Why on earth should 'phone2.exmaple.com' redirect someone to www.example.com? The DNS query stage doesn't include service information - so there's no way to tell whether the lookup is for the purposes of web access.
If by "text part" you mean the plain text version of the email, the chances are that those are not the real destinations that you would be sent to. The phishers normally put pseudo-real addresses in there so that you believe them... When you click you normally go to something like http://www.abbey.co.uk.3487ACDAAB9837456872345.example.com/ which most people will interpret as www.abbey.co.uk with the ID of the session after it. It'll quite often be even longer than that to make the real part of the domain invisible.
If I server a page headed with qww.microsoft.com and a load of ads, am I not pushing that page under microsofts branding and thus it's a blatant abuse of their trademark?
Microsod should get onto them about that, could be some beer money for the lawyers there....
Also, there are the other typos that the ISPs (Domain resellers) are making money out of stuff like www.microsotf.com someone is selling these domains which are invariably used for nefarious purposes and are in a dubious legal position regarding trademarks. It's about time they were stopped too. When malware is found on one of these the reseller should cop a fine or have their selling rights removed for putting internet users at risk.
(I'm especially annoyed because by typign is terribel.)
"If by "text part" you mean the plain text version of the email, the chances are that those are not the real destinations that you would be sent to."
With many mail programs set to display only text and not the html nor any other attachments to the email, using the false subdomain with the encoded XSS in the URL makes the URL look even more real [I edited the XSS out for that reason]. Nor did I wish to publish anything which could identify me to the phishers.
No - just no. My domain is not used solely for web services - something I believe to be true for a lot of domains. Why on earth should 'phone2.exmaple.com' redirect someone to www.example.com? The DNS query stage doesn't include service information - so there's no way to tell whether the lookup is for the purposes of web access."
The purpose of the lookup is imaterial, what matters is that it is a non-existent sub-domain. The idea being that they will redirected to a legitimate page on your domain rather than be presented with the ISP's ad page.
No-one's saying that you only use your domain for web services, but it's very unlikely that you are running any non-existent services.
"But things like flash, active X and Java vulnerabilities, and trust across the domain is compromised a bit."
Java vulnerabilities? I think Java applets (the only ones that actually run client-side) are the only "plug-in" stuff that actually has a security sandbox that disables *any* access to the local machine's resources! In fact, you need some weird stuff like permission policies and signed code to actually get any kind of access on the client's computer.
However, I agree (and most of us do) on the fact that domain redirection is:
1 - tampering with DNS, a "basic" internet protocol; breaking RFC's in the process
2 - if the "response" is for an existing domain, this is domain hijacking, which is definitely illegal akin to tresspassing
3 - It opens up nicely an XSS backdoor, which must have malware/worm/botnet writers getting a nice entry point
4 - the ISPs themselves have opened up a pretty nice target for DoS, DDoS, and other kinds of attack. And not just from crackers, but I'm pretty sure some perfectly legal users would like to slam the sites behind this domain hijacking.
Because of point 2, I really hope that those responsible for PiTMA will end up in PMITA ;)
Verizon provides information on how to configure your Verizon supplied router to use DNS servers that don't hijack lookups (basically change the DNS server address from X.Y.Z.12 to X.Y.Z.14) but unfortunately, the directions don't actually match the screens that some of the devices use. (Though anyone techie enough to even attempt to follow Verizons convoluted "opt-out" suggestion can probably figure that out. The other 99% of Verizons customers are screwed, though).
As I understand it, barefruit is not re-directing the URL. They leave the invalid subdomain in the address bar, rather than changing the address bar to a search query. Surely this is worng and even when fixed their security hole, another code issue could be found to exploit. However, I am not against 'Responsible redirection' which is the keyword here. Systems that do redirection from Nomimum, the founders of bind, and DNS in the first place, do use a search engine to redirect the query to a new URL and resultant error pages state what you typed in. Hence an end-user could not be mislead that they are on a genuine subdomain site. examples like money.paypal.com !!
Also ISPs should offer a opt-out to the service for the minority who even notice and opt-out instructions on the resulting search pages. This is then pretty 'responsible redirection'.
Should stick another field in DNS for the default address on the domain, or maybe even just register default.domain and change the resolvers.
So I'd register (for instance) www.microsoft.co.uk and default.microsoft.co.uk then matches for wwq.microsoft.co.uk would fail and get the default.microsoft.co.uk.
www.microsotf.co.uk would get the default address default.co.uk, which I guess would be hijackable again.
It'd mess up the people who already have domains with "default" in them though so a new DNS field for the default address on the domain would be better.
Isn't a 302 (Moved Temporarily) or 303 (See Other) status code the least bad way to implement this (although how many browsers implement 303 I don't know).
It could then redirect to a page which is clearly under the ISP's control.
Personally I think it should be up to the browser to deal with it rather than the ISP but I guess they don't want to pass up a revenue stream.
Biting the hand that feeds IT © 1998–2019