Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet

Phishers Build Deceptive Links with DNS Wildcards 245

Posted by timothy from the pointy-pointy-then-annointy dept.
1sockchuck writes "In the continuing evolution of the phisher, the latest scams are crafting deceptive email links that include a bank's URL, but send victims to a phishing spoof site. The phishers are combining wildcard DNS, URL encoding and redirection services to construct the URLs. Netcraft has examples of emails that presented barclays.co.uk in the URL but sent clicks to a spoofed page at a server in Moscow. A DNS cache poisoning attack over the weekend also highlights the potential use of DNS tricks in 'pharming' (phishing using redirection rather than bait emails)."
This discussion has been archived. No new comments can be posted.

Phishers Build Deceptive Links with DNS Wildcards More

Phishers Build Deceptive Links with DNS Wildcards

Comments Filter:

  • Help on the horizon for Windows users! (Score:5, Funny)

    by EmptyBuffalo ( 649938 ) * on Monday March 07, 2005 @09:49PM (#11872652) Homepage
    Wow! Talk about a great opportunity to educate the masses - now we've just gotta pharm the www.microsoft.com/help website to www.slashdot.com!!! ;)

    • Re:Help on the horizon for Windows users! (Score:5, Funny)

      by LMCBoy ( 185365 ) * on Monday March 07, 2005 @10:16PM (#11872832) Homepage Journal
      Slashdot.org...it's DOT COM!
      </homestar>

      • Re:Help on the horizon for Windows users! (Score:5, Interesting)

        by oirtemed ( 849229 ) on Tuesday March 08, 2005 @01:07AM (#11874154)
        Actually, this is an issue. My library, at a major university, had a document that you used to "evaluate" web sources. They used the TLD as a determining factor of value, listing .org as a non-profit organization, as well as labeling other tlds (ie: .com commercial). I explained to my class that restrictions on domain names are not there, and a TLD is meaningless, aside from .edu/gov/mil etc. My professor emailed them my corrections, though I do not know if they incorporated them yet.

  • Just don't read emails from the bank (Score:5, Interesting)

    by The Amazing Fish Boy ( 863897 ) on Monday March 07, 2005 @09:50PM (#11872658) Homepage Journal
    Tell the bank that you won't be reading any emails from them, and that they'd better send you snail mail or phone you. If they say that won't be possible, just go elsewhere and let (a) the first bank know why you won't bank with them, and (b) the second bank know why you are banking with them. Provide this information in letter format.

    • Just don't read emails from the bank-Digital Faith (Score:2, Insightful)

      by Anonymous Coward
      So I guess all that GPG, Digital certificates, Digital Documents, S/MIME thing isn't working out.

      Were's a technical solution when you need it?

    • Re:Just don't read emails from the bank (Score:4, Insightful)

      by log2.0 ( 674840 ) on Monday March 07, 2005 @10:08PM (#11872785)
      I know for sure that everytime I log into my netbank, it warns me about "Do not give your password to anyone, even us...blah blah blah"

      I think most banks do what you are saying its just that there are so many STUPID people out there who fall for these OBVIOUS (to us at least) scams.

      It is very frustrating that people fall for things like this and those dodgy African "lottery" wins that you didn't even enter.

    • Re:Just don't read emails from the bank (Score:5, Interesting)

      by jagapen ( 11417 ) on Tuesday March 08, 2005 @12:11AM (#11873777)
      I get notification email messages from my credit union monthly. When I signed up for the account, I had to enter a 'security phrase', and every email they send includes that phrase. If it doesn't have the phrase, it's phish.
      Simple. Effective. Can be defeated, but it would take orders of magnitude more effort.

    • No you can get e-mails and not worry (Score:4, Insightful)

      by Sycraft-fu ( 314770 ) on Tuesday March 08, 2005 @03:09AM (#11874811)
      Just log in as normal. If any company that I do bussiness with apparantly sends me an e-mail, I don't bother to check if it's real or not, I also don't bother to grab the link, not as much for security but out of laziness (I use pine). I just go and log in to their site as normal. If there is something they need, it'll get my attention.

      Thus you don't need to worry about getting phished, but you don't need to exclude a convienent method of communication.

      My bank actually doesn't do e-mail, they call me if they want my attentino, security reasons, however Paypal and eBay are both pretty much e-mail only. Not supprisingly, the phishes I do get are usually for those, not my bank.

  • Very confusing (Score:5, Informative)

    by tyleroar ( 614054 ) on Monday March 07, 2005 @09:51PM (#11872667) Homepage
    I could see how this would be very confusing for most people. What one of the redirectors does, is actually load the normal bank page from the bank's server, and then load a pop up with a form to submit private details from the phisher's server. The site is down, so I can't check it, but I would imagine that the pop up window is made so that the Address bar is not showing and people can't easily see that it is a bad URL.

    • Paypal got it right (Score:5, Interesting)

      by jdreed1024 ( 443938 ) on Monday March 07, 2005 @10:28PM (#11872919)
      The site is down, so I can't check it, but I would imagine that the pop up window is made so that the Address bar is not showing and people can't easily see that it is a bad URL.

      Paypal got this right. When the Phishers started going after them in earnest, they sent a bunch of e-mails to registered users saying "Paypal will never ask you to click on a link in e-mail". And all their e-mails about transactions or special offers say "If you would like to do this, enter www.paypal.com in your browser, and then click on tab $foo and then link $bar". It's a bit more effort for the consumer, but it eliminates the "Is this a real or fake e-mail" problem - if it contains any hyperlink at all, it's fake.

      My credit card does the same thing. I get automated notifications that say "Your new statement is available online. To access it, go to www..com, and click on "My Statement".

      • That should have said www.<my credit card company>.com. Stupid HTML.

  • Its very simple... (Score:4, Informative)

    by scsscs ( 669925 ) on Monday March 07, 2005 @09:52PM (#11872677)
    Don't enter sensitive information into a form linked from an email.

  • That's it (Score:5, Funny)

    by Anonymous Crowhead ( 577505 ) on Monday March 07, 2005 @09:54PM (#11872693)
    Time to scrap this whole "DNS" thing. I don't know what it is, but it sounds dangerous.

    • Re:That's it (Score:5, Funny)

      by ScrewMaster ( 602015 ) on Monday March 07, 2005 @10:02PM (#11872745)
      It stands for "Defensive Nuclear Strike". What that has to do with the Internet and email fraud I don't know.

    • Re:That's it (Score:3, Interesting)

      by Matey-O ( 518004 )
      You're moderated as funny, but it'smore sad really. The Arpanet was created for open interchange of information, and the Internet won't be complete until all the loopholes that open interchange creates are sealed off.

      How long til your ARP packet includes a public key proving you are who you say you are?

      • How long til your ARP packet includes a public key proving you are who you say you are?

        Dunno mate, but I bet the crack for it is out within 2 days.

        Can't we just get together and agree that the internet isn't safe enough for banking, credit card details or personal information yet?

        How about Banks start opening their own ISPs? That way they will be able to check their own records to see if transactions were fraudulent. You trust Banks with your house/CC details/wills/valuables already, why not trust the
        • Can't we just get together and agree that the internet isn't safe enough for banking, credit card details or personal information yet?

          The thing is, it's plenty safe. This is a solved problem - the solution is cryptographically signed e-mail. The problem is, no one uses the solution.

      • Well, wireless networks freqnently use VPNs for access, and PKI can be a component of VPN authentication. IPSec, I beleive, by definition, uses PKI. Wired links for semi public use - university labs, say - also frequently go through something more serious then arp/dhcp; VPN or PPPoE or something. As for local network access, ISTR something new out of Cisco where the routers/switches can do some kind of host analysis to make sure that they arn't virus/worm infested. I guess, something like Punkbuster on mul
      • It's not a problem of openess, but one of trust. You can still have open interchange of information on the net, you just can't have any trust, at least not for most things.

        ARPAnet was designed assuming that everyone on it would be government/research. There wasn't any worry about jackasses, if you were, you'd just get your access yanked. The Internet is open to all, thus lots and lots of assholes (espically anonymity beings out the worst in assholes). So some assumptions that were orignally made aren't val
    • "Looks like our site has been 66.35.250.150'ed!"
  • I was kinda worried that I haven't read much with dns poisoning and phishing.

    It's a rather obvious way in if you think about it.

    I suspect it has happened before, but what the public doesn't know won't hurt them? Up until now anywya.

    What about BGP poisoning! Oh the humanity.

  • Remember when... (Score:4, Interesting)

    by Anonymous Coward on Monday March 07, 2005 @09:55PM (#11872699)
    Just a little while ago Network Solutions thought it would be cool to redirect all nonexistent domains to a valid host in the form of website?

    Remember when ICANN even thought of listening to Network Solutions?

    Hope you do. Mental Bookmark.

  • Who has money any more? (Score:5, Funny)

    by bigtallmofo ( 695287 ) on Monday March 07, 2005 @09:56PM (#11872705)
    After sending all my money to various Nigerian organizations, I wish I had some money for someone to siphon in a phishing scam!

  • The problem with simple rules to avoid Phisers (Score:5, Interesting)

    by soft_guy ( 534437 ) on Monday March 07, 2005 @09:58PM (#11872723)
    is that they aren't so simple. They are also not logical common sense rules either. The phishing site might look exactly like your real site. Plus, the url might look right if the Phisher used a trojan to install a hosts file on your box.

    If this isn't solved definitively, it could destroy e-commerce.

    • I Agree. However I don't think there will ever be a good solution with trying to secure the internet side of the equation, there are just so many tricks one can do with users and their perception of what is ok, until you make it user proof there is now real security.

      I believe that the real solution to this is to make YOUR MONEY more secure, the weak link IMO is that credit cards fraud and identity theft are far to easy to get away with. Lets put in place a secure money system that does not rely on the secu
    • Plus, the url might look right if the Phisher used a trojan to install a hosts file on your box.

      If a trojan is installed on your box, it could be keylogging or any number of other things anyways. At that point I think you're past worry about being phished, you've already been landed.
    • That's not true. The simplest rule to avoid Phishers is easy and infallible. DON'T CLICK ON THE LINK IN THE E-MAIL! Just take an extra second and a half to open your browser and either type in the address or (if you just need to click) click on the "Favorites" or "Bookmark" entry for your bank, Paypal, or wherever.

      If you do this, you will not be taken in by a phishing exploit, ever.

  • DNS cache poison can be stopped (Score:5, Informative)

    by Anonymous Coward on Monday March 07, 2005 @10:09PM (#11872788)
    DNS cache poison can be effectively stopped by using the correct DNS caching program. Basically, it is important to use a strong psudo-random number generator to determine the DNS query ID. Ideally, we have the same psudo-random number generator determine the source port of the DNS query.

    To the extent of my knowledge, only two recursive DNS servers have this level of DNS poison protection: DjbDNS' dnscache [cr.yp.to] and MaraDNS [maradns.org].

    It is also important to have bailwick protection. Basically, the recursive DNS server needs to look at a DNS reply, and filter out any answers not in the bailwick. Older DNS servers (and possibly poorly written embedded DNS caches and recursive servers) will get a reply like "www.paypal.com has the ip 10.1.2.3" to the question "what is the ip for www.phisherscum.com?", and incorrectly cache the data for www.paypal.com instead of saying "I didn't ask for paypal.com's ip, so I'll ignore this data as being out of bailwick".

    Additionally, it improves security to restrict which IP addresses are allowed to make remote DNS queries. This is best done at the firewall level (don't allow any UDP connections to port 53 from the internet at large unless you have some domains hosted by the machine in question). This stops malicious servers sending a large number of requests to your dns server for www.paypal.com, and a number of bogus answers "www.paypal.com has the IP of some phishing site in China; remember this until 2007", until one of the answers looks valid and fools your DNS server.

    In summary, by using a secuirty aware DNS resolver, you can minimize, if not eliminate the chances of being vulnerable to bogus DNS data.

  • Passwords should work both ways (Score:5, Interesting)

    by kebes ( 861706 ) on Monday March 07, 2005 @10:18PM (#11872848) Journal
    I've often thought it was weird that the credit card company would call me, and ask all kinds of questions to make sure I'm really me, before they would tell me/ask me something (like make sure that it was really me who made a big purchase or whatever).

    I usually ask them to give me some info from my file to prove that they actually are the credit card company they appear to be, or I call them back using the number in the official documentation.

    I think passwords/authentication have to work in both directions. Perhaps e-banking would be more secure if the banking site had to show you proof of authenticity (for example, you ask the system a question about your file, and see if it responds correctly). In practice, this might involve some additional headaches, but I think it could work.

    Perhaps the simplest scheme is that you enter your login info, but if you then complete a transaction without getting back the "correct" authentication answer, you call your bank immediately... they block the transaction, you change your password, and it is flagged immediately as a scam.

    Thoughts?

    • Re:Passwords should work both ways (Score:4, Interesting)

      by Dionysus ( 12737 ) on Monday March 07, 2005 @10:25PM (#11872904) Homepage
      In Norway, online banking has two password associated with the account. One permanent, and one one-time password. Both must be correct to get access to the account. So, even if a phisher got both password, the one-time password wouldn't be useful after that session anyways.

      Don't know why the US online banks don't have a similar system.

      • Re:Passwords should work both ways (Score:4, Informative)

        by ScrewMaster ( 602015 ) on Monday March 07, 2005 @10:35PM (#11872965)
        Because U.S. consumers are driven largely by convenience. The banking/credit system is a big part of the problem, sure ... but so are bank customers that get annoyed at security measures. I've seem people swear at a teller that asks them for an I.D. I'm the other way around: I get irritated if they don't make sure I'm who I say I am. In any event, both consumers and the banks are going to have to change if we don't want to go back to hiding our money beneath a loose floorboard, or stuffing it in our mattress.

        • Because U.S. consumers are driven largely by

          convenience

          And still they use checks... I have not used those for 17 years, used debit/credit cards or online banking since then.

          My back has single use 4-digit code that are sent in bactches of 80 codes. You use your user id (that was not sent you by mail, you got it personaly from bank) and that single-use number to log in system. That was in 1980s when you used modem to connect online bank. When internet banking started, they add another security measu

      • some banks are even worse than that... I found one bank that protects your account with a single password that must be less than 6 digits long and purely numeric. I find this ridiculously insecure to the point of bordering on criminal. to make things even funnier, the bank's newsletter a couple months back had a section in it dealing with how to pick a secure password for online use, only problem is that their own system will not LET you follow any of the rules in their article! I sent them an email asking
      • In sweden we have similar systems too. The one my bank uses is you get a number that is valid for 5 minutes when you attempt to login. You type that number into a little piece of hardware, press enter and you get a new number that you type into the web browser. You have to do repeat the same thing everytime you want to make a transcation too. Seems pretty safe...

        Do you just need a regular password to login and make transactions on american banks? That sounds really weird in that case.

    • I think passwords/authentication have to work in both directions. Perhaps e-banking would be more secure if the banking site had to show you proof of authenticity (for example, you ask the system a question about your file, and see if it responds correctly).

      I think this is already in place and widely used, although the present implementation seems quite hypocritical to me.

      Supposedly at least, and someone might correct me on this, my understanding is that this is what protocols such as https are s

      • " The bank verifies itself via a certificate issued by a third party (such as Verisign) that your web browser's distributor has decided to trust."

        If you knew how lax gui browsers really are with certs you'd shit yourself.
    • Only one serious problem... Who goes first...

      Obviously, I'd prefer that the bank tell me something out of my personal file before I give them any information. However, if they dial the wrong number (or have been convinced to dial the wrong number), I certainly wouldn't want them to give out any secret information about me to strangers before I authenticate with them (along with the fact, that a lot of the "secret" information is given to so many places that breaking into any one of them would give you ac

      • Or call you and your bank at the same time, passing messages back and forth. Aka, a man-in-the-middle attack.
      • In a world where people actually gave a damn about security, you and your bank would swap public keys when you opened an account (in person, at a physical branch).

        Then it doesn't matter who initiates future communication, because all messages can be authenticated against the sender's public key.
        • Yes and no. In the context of a phone call, that doesn't make a lot of sense. I'd have to care about my private key, which I'd need some way to put into a phone in order to secure the connection. (Which in my personal case means, I couldn't talk with my bank if I wasn't at my home because I ain't caring my private key for my bank with me all the time, and I'm surely not using my standard e-mail key for it, if my e-mail key gets broken that's really bad, and could potentially be embarrasing, if my bank ac
          • Remember, I said "in a world where people cared about security". Not running random code on the same computer you keep something as important as your private key is a part of that. ;)

            I'm setting myself up for a fall here, but I'm pretty secure that I'll never have a problem with phishers because a) I'm suspicious as hell, and b) there is fruit on the tree that's much lower hanging.

      • There are schemes which allow two parties to validate to one another (as opposed to one-way) without either revealing their secret. Effectively:

        • Alice generates a random value, and sends it to Bob.
        • Bob perferms an operation on the value using his secret, and submits it to Alice.
        • Alice performs an operation on this value of Bob's (or another random value generated by Bob) and submits it to Bob.
        • If both Alice and Bob are satisfied with the responses, the transaction continues.
    • "Perhaps e-banking would be more secure if the banking site had to show you proof of authenticity"

      The SSL certificate that the bank's site presents to you when you connect is all the proof you need that your traffic is not being intercepted.

      Unfortunatly, today's browsers hide the information about who the certificate was issued to away in a separate screen. IMO the subject of the certificate should be displayed in the status bar, where Firefox currently prints the hostname of the displayed site (needlessly, since that information is already in the address bar!)

      But this isn't perfect. The certificate authorities treat the x509 dname as a unique block of text, rather than making sensible use of all the fields. Thus my bank presents a dname of "CN = www.ebank.hsbc.co.uk,OU = Terms of use at www.verisign.com/rpa (c)00,OU = Terms of use at www.verisign.com/rpa (c)00,O = HSBC Holdings plc,L = Sheffield,ST = South Yorkshire,C = GB".

      IMHO our current CAs have buggered up the job, and deserve a good slapping. Instead of allowing a random company to buy its way into the CA market by paying off Netscape and Microsoft, we should ditch the present model for high-risk uses such as online banking.

      Banks should issue their own (self-signed) certificates. When you open a bank account, you are supplied with the SHA1 and MD5 hashes of the certificate that the bank uses; the first time you visit the bank's web site, your browser throws up the "unidentified certificate" warning. You then eyeball the certificate, note that the hashes match those you have been provided with, and import the certificate into a store for future use.

      The annoying thing is that we could do this *today*, if only people would start giving two shits about their security.

      Maybe after a few thousand people get ripped off by identity thieves, people will start caring.
      • "Banks should issue their own (self-signed) certificates. When you open a bank account, you are supplied with the SHA1 and MD5 hashes of the certificate that the bank uses; the first time you visit the bank's web site, your browser throws up the "unidentified certificate" warning. You then eyeball the certificate, note that the hashes match those you have been provided with, and import the certificate into a store for future use."

        That's pretty good. I'm not sure my elderly mother is gonna grok this though

  • In other news.. (Score:4, Funny)

    by pherthyl ( 445706 ) on Monday March 07, 2005 @10:20PM (#11872868)
    The recommended solution to this problem is to bypass DNS and type in all IP addresses by hand.

    I can sell you attractive hand made table of domain to IP mappings for the top 25 sites on the internet for just $5!
    • The recommended solution to this problem is to bypass DNS and type in all IP addresses by hand.


      I can sell you attractive hand made table of domain to IP mappings for the top 25 sites on the internet for just $5!


      Oh shoot, I hope IPv6 doesn't catch on soon, or I'll get carpal tunnel for sure.
    • You must have already read the Microsoft advisory [microsoft.com] on that matter:

      The most effective step that you can take to help protect yourself from malicious hyperlinks is not to click them. Rather, type the URL of your intended destination in the address bar yourself. By manually typing the URL in the address bar, you can verify the information that Internet Explorer uses to access the destination Web site. To do so, type the URL in the Address bar, and then press ENTER.

  • FireFence extension idea (Score:5, Interesting)

    by me at werk ( 836328 ) on Monday March 07, 2005 @10:21PM (#11872880) Homepage Journal
    This extension for firefox (FireFence, you know, what you put around a pharm...) would keep track of https (and, have the option to do http) ips. It would keep a log of the ips of ALL your https sites, to see if they're in the same range. For example, google:

    [20:17] * Dns resolving www.google.com

    -
    Found 2 addresses
    dns: www.google.com nick: addr: www.google.com ip: 64.233.187.99
    dns: www.google.com nick: addr: www.google.com ip: 64.233.187.104
    -
    [20:17] * Dns resolved www.google.com to 64.233.187.104


    For this, it'd see they were in a similar range and not be too worried. If it suddenly noticed google was going to 192.168.1.100 (meh) then it would throw up alarms, "This site has a radically different address". Of course, that would be the defaults, there would be options to have it alert you for all ip changes and show you the list of past ips, optionally look it up on arin/ripe/apnic and see who owns the ip, all sortsa stuff.

    Preferably it'd come with a list of known good sites, for paypal and a few banks or whatever.

    I think a firefence would work a lot nicer than just the spoofstick, but I know NOTHING about coding one, just about what I'd want it to do.

  • Spoofstick (Score:5, Informative)

    by Omniscientist ( 806841 ) <matt@ba d e cho.com> on Monday March 07, 2005 @10:22PM (#11872881) Homepage
    Spoofstick [corestreet.com] is a Firefox extension that might help in avoiding phising scams. It displays "the most relevant domain information". Looks like its available for IE too.

    • Re:Spoofstick (Score:2, Interesting)

      by me at werk ( 836328 )
      Why get spoofstick for IE? The Netcraft Toolbar [netcraft.com] (used in TFA) shows the country that the server is located in even! That's much nicer.

      • Why get spoofstick for IE? The Netcraft Toolbar (used in TFA) shows the country that the server is located in even! That's much nicer.

        Well, except for the fact it requires IE and Win2K or better. Kind of leaves out Mozilla/Firefox/Konqueror/Safari/Opera/Linux/Mac users. Frankly, I don't feel safe surfing with IE even with all the current security patches anyway. I do agree that showing the country the server is in is a nice feature, but it's not worth the price I'd have to pay (i.e. use IE [pun not inte

    • That's great if your bank never has to change its IP address...

      Of if a phisher gets the banks old IP...

      In that sense it is more harmful that if it didn't exist. You're trusting the phisher, whose identity your scheme just confirmed the authenticty of.

  • It takes some evangelizing (Score:4, Insightful)

    by erick99 ( 743982 ) <homerun@gmail.com> on Monday March 07, 2005 @10:23PM (#11872895)
    I tell anybody who will listen - If you want to log in to your bank, then go to your banks URL yourself, manually, without the aid of a click-thru in an email or another website. Type in yourself. I doubt I am redundant enough but I try. We should be able to get to the point that nobody would ever click on an URL in an email to get to their bank or anything else on the web that has some connection to their money or wealth or whatever.
    • This still won't protect you if your hosts files is hosed.
      • mod parent up. most slashdot dumbasses don't know what a 'hosts' file is. malware is already tampering with it. here's how it works in a nutshell:

        bankofamerica.com = phishers_ip_addy

        So, even when you type in 'bankofamerica.com' in the browser's address bar, you still go to the bad guy's web server. ok?
        • The next obvious step is adding a new CA with the malware. So, https://www.bankofamerica.com would work just fine, with NO evidence whatsoever of any wrongdoing.

          Of course, if you're going through all that trouble, just install a keylogger and be done with it.

  • Links (Score:5, Interesting)

    by ScrewMaster ( 602015 ) on Monday March 07, 2005 @10:29PM (#11872924)
    My solution to this problem (since I have a girlfriend that likes to click anything interesting) was to have my mail server redirect all links embedded in incoming messages to a local page that says "don't do that." I also strip all attachments, executable or otherwise, and stick them in a protected folder on the server. That way no-one can click on a link, or accidentally execute an attachment.

  • My Anti-Phisher Scripts (attached) (Score:5, Interesting)

    by cjsnell ( 5825 ) on Monday March 07, 2005 @10:29PM (#11872925) Journal
    I became fed up with this crap invading my inbox, so I decided to take some action. Most phishing scams are run by novices and use pre-packaged PHP pages which dump the collected info into a file or e-mail it out to an address for collection. The solution to this is simple: generate a ton of bogus information and submit it to their form processing script.

    To do this, I use Acme Software's http_load [acme.com]. http_load takes, on its commandline, a filename containing a list of URLs to request. It then proceeds to send GET requests just as fast as the server can handle them. The trick is to use my Perl script to generate the http_load "loadfile".

    First, my script. This could definitely be improved so that it fashions names and street addresses from dictionary words. For now, I just use random junk. To make this script work, you need to look at the phishing scam's HTML source. Find all INPUT tags. Any TYPE=HIDDEN name/value pairs must go in the url_base definition, since the server expects these to be static. The rest (all of the form fields) should go in the @inputs array.

    #!/usr/bin/perl

    ## antiphisher.pl
    ## (c) 2005 Chris Snell
    ## c-j-s-n-e-l-l_A-T_-_g-m-a-i-l_D-O-T_C-O-M
    ## You better be damned careful because this
    ## script can get you in an arseload of trouble!

    # You'll need to install the String::Random module
    use String::Random;

    # How many URLs are we going to generate? I
    # suggest using about 80 or so, to keep
    # http_load from being overwhelmed. We will
    # run these URLs for a few minutes and then
    # generate a fresh batch
    my $COUNT = 80;

    my $rand = new String::Random;

    # this array contains all INPUT tags whose values
    # are user-supplied (ie. input fields)
    my @inputs = qw { firstname MI lastname card_number card_cvv card_pin username password };

    my %rand_input;
    my $i = $COUNT;

    while ($i-- > 0) {

    # iterate through the list of inputs
    foreach my $an_input (@inputs) {

    # generate an 8-digit random value
    # for each, and store it in the rand_input
    # hash
    $rand_input{$an_input} = $rand->randpattern("........");

    # The input will likely contain
    # non-alphanumeric characters, so we get
    # rid of those. This has the nice side
    # effect of giving us inputs of
    # radomly-varying lengths
    $rand_input{$an_input} =~ s/[^a-zA-Z0-9]//g;
    }

    # This is where you specify the URL of the
    # script that will process the form
    # submission.
    # Note that I have defined a few static inputs
    # here, which were derived from TYPE=HIDDEN
    # INPUT tags in the phisher's form. You might
    # want to change the values to make sure that
    # the phisher is not able to associate your
    # e-mail address with your attack.
    my $url_base = 'http://logon.personal.wamu4u.com:280/login/script .php?hdnVal=1&h
    dnSi=37503603&txtUserID&pwdPasswo rd';

    # construct the final URL from our base and
    # our random inputs
    foreach my $param (keys %rand_input) {
    $url_base .= '&' . $param . '=' . $rand_input{$param};
    }

    # Print the URL to stdout
    print "$url_base\n";

    }

    ################## END OF antiphisher.pl #######

    Now you'll need to run http_load with a fresh batch of URLs every minute or so:

    #!/bin/sh

    while true; do
    ./antiphisher.pl > urls.txt
    http_load -parallel 30 -seconds 60 urls.txt
    done

    I have another script that uses LWP::UserAgent to make the requests, which I wrote when a crafty phisher rejected submissions where HTTP_REFERER was not his phorm.

    E-mail me with questions c-j-s-n-e-l-l_A-T_-_g-m-a-i-l_D-O-T_C-O-M

    Chris

    • Re:My Anti-Phisher Scripts (attached) (Score:4, Informative)

      by cjsnell ( 5825 ) on Monday March 07, 2005 @10:32PM (#11872944) Journal
      Jeez, Slashdot really munged my indenting. I hope you guys can make sense of that. I have a bunch of variations on this script that I did not post. Here is a little snippet to generate real-looking credit card numbers, PINs, CVVs, and expiration dates and add them to the URL:
      my $card = $rand->randregex('\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d ');
      my $pin = $rand->randregex('\d\d\d\d');
      my $cvv = $rand->randregex('\d\d\d');
      my $zip = $rand->randregex('\d\d\d\d\d');
      my $mo = $rand->randregex('0\d');
      my $yr = $rand->randregex('0\d');

      my $url_base = 'http://203.98.132.60/~temp/combinatie/yabe/ovy.ph p?subject=C
      ard&redirect=success.htm&CardType=Vis aDebit&submitBtn=Continue';

      $url_base .= '&Card=' . $card;
      $url_base .= '&Pin=' . $pin;
      $url_base .= '&CVV2=' . $cvv;
      $url_base .= '&Zip=' . $zip;
      $url_base .= '&LunaExpirare=' . $mo;
      $url_base .= '&AnExpirare=' . $yr;
    • One would hope that all the banks would have a massive farm of distributed PCs which would automatically do this (stuff the phishers web site(s) with bogus and "hot" credit card numbers) as soon as a phishing attempt was detected by one of their honeypots.

      The cable and DSL companies could even loan the banks gigantic blocks of temporarily unused IP addresses, so that the phishers would have to throw out all of their real customers data along with the random noise.

  • Why is this still an issue? (Score:2, Insightful)

    by Anonymous Coward
    I can't believe that these kind of tactics still cause problems when any and all 'phishing' (I hate that word) tactics would fall flat if people simply got a clue and stopped clicking links in their email. That's been the common thread of every method so far.

    I suppose it's a bit much to ask for for the general internet populace to get a clue, however. Still, a warning hardly seems necessary here considering I'm pretty sure most Slashdot readers understand not to click banking links in their email for any r
  • can anyone provide more information about this 'DNS cache poisoning' thing? the article and wikipedia (and several other pages I got from google) don't explay how this 'attack' is done.. it sounds serious.
    • From my reading of the article...

      You break into company X
      You insert a dns record into their DNS records, eg barclays bank.
      All hits on Barclays Bank then go to the IP address coded in the local DNS.

      THe effects are localised but if you broke into a large ISP and did this it would catch a lot of people.

      • You missed the cache part (Score:5, Informative)

        by highcon ( 857286 ) <paul@highcon.h[ ]ip.net ['ome' in gap]> on Tuesday March 08, 2005 @01:02AM (#11874116) Homepage

        No. That is not cache poisoning, since it doesn't poison a cache. All DNS servers will cache records that they had to look up. It works like this: Someone queries a DNS server, asking what IP an address maps to. This DNS server doesn't know, and must query another server to find out. Our DNS server sends the query out to another DNS server that would know the answer (the authoritative server for that domain) and waits for a response. When it receives this response, it answers the original query and caches the response so the next time the same query is made it has the answer.

        What the attacker does is sends out several (as in, a LOT of) queries to a DNS server for a name, say bank.com. Then, the same attacker sends out several (!) spoofed answers to this query, saying that bank.com maps to a certain address, which is actually some server the attacker controls. The goal is that your bogus response will beat the real response and be accepted by the target DNS server. If the attack is successful, this bogus answer is cached, so when someone else goes to look up bank.com from that particular DNS server, they get the IP of the attacker's server.

        The trick is that a DNS server will pick a random number that it assigns to the query sent out to the next DNS server. The response must contain this number for it to be accepted as authentic. The attacker very rarely can know what that number is, hence the large amount of query and answer packets that must be sent out (you are essentially trying to get lucky and hope that one of your fake response packet's number matches one of the server's query packets). In a perfect world, these numbers would be truly random and an immense amount of bandwidth would be required to get enough packets to the server to have a shot at guessing correctly. However, many of the DNS servers pick random numbers out of a much smaller field than they should.

    • Re:DNS cache poisoning? (Score:4, Informative)

      by swmccracken ( 106576 ) on Tuesday March 08, 2005 @01:02AM (#11874117) Homepage
      Serious yes, but been around a long time.

      One example of a cache poisining attack is for a DNS server to provide 'extra answers' for a query.

      eg: dns resolver (for an ISP) asks ns.network.net for the records for www.network.net, because some user wants to look at it. No problem it says, and gives back the address of www.network.net.

      However, if ns.network.net was malicious, it might also give the address of www.bank.com. If the resolver then accepted this address of www.bank.com and entered it into its cache, well, www.network.net has just taken control of www.bank.com. :-)

      (This is why various DNS resolvers have features to ignore additional answers to queries, or ignore answers outside the 'bailiwick' of the server, or things like that. Glue records do make the situation more complex than I've described.)

  • Related methods (Score:5, Insightful)

    by photon317 ( 208409 ) on Tuesday March 08, 2005 @12:43AM (#11873986)

    It would be trivial for the spyware which is rampant on the average user's wintel PC to alter their network settings to point the user at custom DNS servers run by the spyware companies. These could act as dns caching proxies for the most part, but then selectively fail to resolve sites the spyware companies don't want you to see, selectively redirect your queries to the webservers they do want you to see, and in the hands of the nefarious, spoof your bank site too. Until the massive gaping holes in the average user's wintel PC are closed, complex infrastructure exploits are really a waste of time. It's so much easier just to seize their PC and have your way with it.

  • First time (Score:2, Interesting)

    by Cliff.Braun ( 825786 )
    Oddly enough, I just recievedd my first phishing attempt recently. It might have worked, but for two things. The page looked totally legit, right down to the avoid online fraud bit. The things that made me think it was a phishing attempt were the fact that I don't have a Washington Mutual account, so they wouldnt send me an email, and the fact that it went to 211.121.x.x, rather than the URL. I recently got online checking with my new bank, but I wont ever click a link to get there.

  • Just had a seriously troubling thought.... (Score:3, Interesting)

    by pg110404 ( 836120 ) on Tuesday March 08, 2005 @02:25AM (#11874619)
    Suppose through spyware/malware/trojans/virus/whatever, a virus writer were to scan your web browser history, find out what bank in particular you visit, then simply modify the local HOSTS file buried under the system32 directory to point to a specific IP address.

    They could then design a login page that doesn't even have to be encrypted (I'm sure most people wouldn't bother to notice) which mimics the real bank's login page. They give one or two "failed" login attempts before redirecting the browser to the real site.

    Instead of hijacking dns in some weird way, it simply instructs the local computer to resolve certain DNS entries to something defined locally. After the user thinks they got their password wrong, the phisher's web server redirects the user to the real bank's login page.

    This would be something that is entirely possible (virus spread by active x, email, whatnot) and monitors the web browser history for recent activity for a list of known banks, and once that user does their online banking, spoofs the local machine to go elsewhere for subsequent banking. The user doesn't know what happened, and in the meantime types in their banking information that would reveal bank accounts, etc.

    Once successfully mined, the bad guys might send an 'abort' sequence to remove all evidence of what happened and move on to the next guy, thus making it hard to track what really happened. Since that entry would be removed from the HOSTS file when that happens, most people would assume they got a string of bad luck for a few login attempts and all seems to be well again (only it's not, since that personal information is now made not quite so personal anymore).

    Just suppose this virus created keeps a low enough profile for long enough, even having a firewall antispyware and virus scanner might not help you out.And DNS wildcards are totally sidestepped.

  • DNS is the achilles heel (Score:4, Insightful)

    by venomkid ( 624425 ) on Tuesday March 08, 2005 @02:44AM (#11874722)
    I've said it before...

    DNS is the achilles heel of the web. Take down/redirect/spoof/molest DNS, and it doesn't matter how many redundant whatevers and caching whothingies you have.

    Nobody's getting to you.

    And they may be getting to somebody else.

    But DNS isn't glorious, so we'll keep spending the time/money on other things...

  • Call me sick and sadistic, but...... (Score:3, Interesting)

    by pg110404 ( 836120 ) on Tuesday March 08, 2005 @02:54AM (#11874766)
    I think spammers/phishers deseerve a special place in hell. I got an email supposedly from first ebay then a different one from paypal and yet another from washington mutual bank(?) concerning my account information. Since I've never set up an account with any of these, I knew instantly it was a phishing scam.

    Not only that but when I hover the mouse on the link, it shows the target URL at the bottom and resolved to a fixed IP address (e.g. http://219.44.99.123/ as an example. I just made this address up) rather than point to their respective DNS names.

    So (this is the sick and sadistic part comes in), I figured I'd fill out their forms with my "personal" information which is entirely made up. Everything on the form was invented. The name, the address, everything, including the credit card number. After doing that, I sent a copy to abuse@ebay.com, etc.

    On one occasion, I got a response email stating there was a problem with my credit card information and I needed to reenter it.

    The probem here was that I use the first 4 legitimate digits for visa, but the other 12 digits were entirely fictional and the checksum digit did not match.

    I've been toying with the idea of using a credit card number generator and getting past that specific problem, but what if the number that the cc generator picks happens to be a legitimate credit card number and some poor shmuck gets charged? I'm not quite that sadistic.

    I wonder if my bank would be gracious enough to issue me a defunct credit card that I could use specifically for this purpose. Failing that, what we need is a list of banned credit card numbers, so when these scammers try to use them, there's a trail that leads the authorities right to their door to haul them away and give them what they deserve.

    The way I see it, they took the time to write me for my information which they'd use to screw me, and the least I should do is to return the favor and give them just enough to make them think they got away with it but in fact they expose themselves to getting caught.
  • Comment removed based on user account deletion
  • One of the many nice things about Gmail is that, whenever you receive one of these dodgy phishing e-mails, it puts a big red banner above it saying "Danger! This may not be from whom you think it is", or words to that effect.

    I'm not sure if anyone will read this warning, but it seems like a step in the right direction. And one interesting way in which webmail can provide a feature that's not feasible for normal e-mail clients.
    • Not feasible for normal e-mail clients? Our email servers do this too. Our local server tags the message with an additional header. A little mutt coloration marks these messages special, not to mention that human readible portion of the header appears right before the start of body.

      As nifty as gmail is and all, most of the their "new" features have been available for years in mail clients like mutt. It's mostly a case of people not knowing to turn on the functionality that gmail is now giving everyone

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close