Spammers start using short .gov URLs to trick their victims(thenextweb.com)
thenextweb.com
Spammers start using short .gov URLs to trick their victims
http://thenextweb.com/insider/2012/10/19/spammers-start-using-short-gov-urls-to-trick-their-victims/
12 comments
"never click on links" is impossible advice to follow. Security people often forget that there is a tradeoff between security and functionality. You need to do cost/benefit analysis to decide whether to use a particular feature.
Never click on links until you are on the destination site is the advice I give to friends/family who aren't computer sophisticated. (Up there with Never Open attachments in your email and never install new programs on your computer)
Those two practices, typing in "www.wellsfargo.com" instead of clicking on a link that suggests it will be taking you there, and never, ever, opening any attachment, cuts down on 95% of the malware attacks that these people experience.
Most non-computer users aren't sophisticated enough to understand what links they can, and cannot click on, so they are safer just typing out URLs and navigating from there. It's great advice for those people. Bookmarks make the practice a little more efficient as well.
As much as we computer sophisticates despise the "Walled-Garden" aspects of the Apple Store (and soon, the Microsoft Store) - those should also significantly reduce the amount of malware people end up installing when they add new programs. It may not eliminate it (as we saw when Path uploaded people's Address Book information onto their servers without asking the user permission) - but, between application review + client-side checks on privacy - malware infestations have experienced a radical drop on stock iOS devices vs what a user's computing experience used to be in the Bad Old days of Windows 95/XP in which even _I_ got nailed by a trojan or two.
Those two practices, typing in "www.wellsfargo.com" instead of clicking on a link that suggests it will be taking you there, and never, ever, opening any attachment, cuts down on 95% of the malware attacks that these people experience.
Most non-computer users aren't sophisticated enough to understand what links they can, and cannot click on, so they are safer just typing out URLs and navigating from there. It's great advice for those people. Bookmarks make the practice a little more efficient as well.
As much as we computer sophisticates despise the "Walled-Garden" aspects of the Apple Store (and soon, the Microsoft Store) - those should also significantly reduce the amount of malware people end up installing when they add new programs. It may not eliminate it (as we saw when Path uploaded people's Address Book information onto their servers without asking the user permission) - but, between application review + client-side checks on privacy - malware infestations have experienced a radical drop on stock iOS devices vs what a user's computing experience used to be in the Bad Old days of Windows 95/XP in which even _I_ got nailed by a trojan or two.
I think it is also important to remember that iOS (and similar devices) have a much stronger security model from a technical standpoint (low-level, near complete sandboxing with white-listed permisions). As apposed to most desktop computers where almost every program runs with full user permisions, and in the case of windows 95 (and maybe also XP), that normal user tended to be an administrator.
I don't really think most computer sophisticates have a problem with a walled garden, but rather a problem with a locked down garden. In linux, for example, the standard means of installing software is through a central repository maintained by whoever maintains the OS, and all of the software in that repository is reviewed before being added. The difference is that if the user wants to, they can install software not offered through the repository, and/or add 3rd party repositories.
I don't really think most computer sophisticates have a problem with a walled garden, but rather a problem with a locked down garden. In linux, for example, the standard means of installing software is through a central repository maintained by whoever maintains the OS, and all of the software in that repository is reviewed before being added. The difference is that if the user wants to, they can install software not offered through the repository, and/or add 3rd party repositories.
Unless you're saddled with selinux, in which case, maybe not.
Sites that involve credit cards or banking are in a whole different category. For those I think the best advice is to only use https bookmarks.
In that vein, here's an idea for a browser feature. When someone enters something into a form that looks like a credit card number, bank account number, or bank routing number, black out the entire browser (including the url bar) and require them to type in the domain they think they're submitting to. If they get it wrong they can't submit the form (at least for a few minutes).
In that vein, here's an idea for a browser feature. When someone enters something into a form that looks like a credit card number, bank account number, or bank routing number, black out the entire browser (including the url bar) and require them to type in the domain they think they're submitting to. If they get it wrong they can't submit the form (at least for a few minutes).
Yes, let's cripple online shopping.
Only for sites that you don't already have an account on, and which don't use a paypal-like service. Although since there are consumer protections on credit cards, it might make sense just to warn on bank account and routing numbers.
Only for sites that you don't already have an account on, and which don't use a paypal-like service.
How is a browser supposed to detect either?
How is a browser supposed to detect either?
It doesn't have to. In both of those cases you're not entering your credit card number.
Cookies to indicate previously visited sites.
Couldn't phishers just start having their fake forms send the current form content via ajax every time a new character is typed, rather than only on submit?
If I was a phisher, or similar ilk, I'd be doing this already.
Bitly just posted in the blog comments that they stopped this exploit. That was fast -- yay.
Link to comment: http://thenextweb.com/insider/2012/10/19/spammers-start-usin...
Well, they stopped that one specific redirect "and others" [1], but this will just be a game of whack-a-mole given the huge number of organizations (local, state, federal) hosting sites under .GOV. I'm sure there are tons more redirects lurking on rarely viewed sites under .GOV. It's not hard to find potential starting points [2][3].
[1] labor.vermont.gov/LinkClick.aspx?link=[spam site]
[2] http://www.google.com/search?q=site:.gov+inurl%3Aredirect
[3] http://www.google.com/search?q=site:.gov+inurl%3Alinkclick
[1] labor.vermont.gov/LinkClick.aspx?link=[spam site]
[2] http://www.google.com/search?q=site:.gov+inurl%3Aredirect
[3] http://www.google.com/search?q=site:.gov+inurl%3Alinkclick
This is a problem with the .gov sites. Forget the shortening issue; that any site would happily redirect anything is nuts. I get they're doing it for tracking purposes, in which case, would it be that hard to whitelist the redirect URLs?
Most often I see these things in my referral logs from sites that want to hide which exact page has a link to your content. Common on certain types of web forums, for example. Eg www.forumsite.com/?redirect=yoursite
There are also services like anonym.to for when people try and hide even the host site entirely. I've seen forums that turn all outgoing links into anonym.to links.
There are also services like anonym.to for when people try and hide even the host site entirely. I've seen forums that turn all outgoing links into anonym.to links.
Huh? It makes more sense to use redirects for tracking than to fight it. Why would anyone use anonym.to instead of just turning off referer in the browser?
Because you don't always want someone to know you're talking about them - maybe you're 133t next-gen anonymous hax0rs. Or maybe your forum is "private" and "exclusive" and you have the audacity to believe anyone at all cares.
Of course, anyone who actually cares about infosec stuff would know better than to hand over this data to anonym.to.
Of course, anyone who actually cares about infosec stuff would know better than to hand over this data to anonym.to.
You cannot turn off the referer passing in the browsers of all visitors to your website.
I imagine it would be at least slightly difficult. A .gov blog could link out to any number of domains. Plus, a domain they linked out to three years ago could get taken over and used for nefarious purposes.
This exploit mad the rounds on Amazon.com and others five years ago and was fixed then on any reputable site.
The spiritually same exploit made the rounds on cgi forms (form to mail) 15 years ago, and on mail servers (open relay) 20 years ago.
The spiritually same exploit made the rounds on cgi forms (form to mail) 15 years ago, and on mail servers (open relay) 20 years ago.
I should think the issue is the insecure redirects, not the link-shortening.
The link shortening compounds the issue because it’s opaque — it hides the URL of the spammy site you’ll get redirected to.
This was also a much used trick: http://news.ycombinator.com@1249739877
Although most browsers have implemented a warning of some sort it can still hoax spam-filters that use a regexp pattern which doesn't account for this type of behaviour.
Could you explain the link?
I'm not sure about the "news.ycombinator.com@" bit, but the number can be identified like this:
$ ping 1249739877
PING 1249739877 (74.125.132.101) 56(84) bytes of data.
64 bytes from 74.125.132.101: icmp_req=1 ttl=41 time=395 ms
...
$ nslookup 74.125.132.101
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
101.132.125.74.in-addr.arpa name = wb-in-f101.1e100.net.
...
The part before the @ part is supposed to be the username for HTTP authentication. The complete format is http://username:[email protected] but the password is optional.
Could bit.ly just see if a Location header is sent and if it there is one that is not to a .gov domain to not use the 1.usa.gov shortener?
You misread the article. There are open redirectors on .gov domains (like a naive hit-counter), the shortener just goes .gov -> .gov. Now the shortener blacklists the open redirects as short link targets.
It's a legitimate question. Bitly should do a GET request to the resource before creating the 1.use.gov link. This is standard practice. It should work quite well in this case because the open redirectors under .gov are just poorly programmed; they're not actively trying to avoid detection.
Huh, thanks. I didn't understand this was an active check at link creation time; woosh for me.
Or <meta http-equiv="refresh">, or a java-script redirect, etc, etc?
Trustworthy and Automatic (for the link shortening) do not combine well.
At least the bit.ly service means that the traffic can be gathered and analysed (and presumably those links disabled) to get data about spam clicks.
At least the bit.ly service means that the traffic can be gathered and analysed (and presumably those links disabled) to get data about spam clicks.
The great thing about these URL shorteners is the companies seem to be very proactive when dealing with spam and malware. They don't want to be associated with this crap so naturally they block it when they find it.
The simple and better way is to use WOT (web of trust) extension for firefox and chrome. It really help users from clicking on fraudulent links.
I don't see the threat. This is an only an issue for web users who trust the government more than an arbitrary stranger.