The title of this article originally included “…and why you could lose your internet this July”, but that was in Feb. 2012 when I started writing this before that life got in the way.  I’ve left the part about losing your internet but edited it to be more relevant to today.  See the section on “Operation Ghost Click” at the bottom.  These types of attacks are a little better understood these days, but still unknown to much of the public.

The Rogue DNS Attack, a.k.a. “DNS Hijacking” is one of the more misunderstood types of attacks that can open the door for hackers to use all kinds of trickery to steal information you store on or transmit from your computer, like the embarrassing video you took of yourself singing and dancing to MC Hammer wearing your Dad’s very large pants and forgot to delete.  Oh yeah and any password you type into any website.  Even your dog.

What’s that?  You don’t have a dog?  Actually you did… until they stole it.  I guess they also stole your memory of your dog.

 

OK, SO YOU’VE SCARED ME, THANKS A LOT.  SO WHAT IS IT?

To understand them, you first need at least a basic understanding of how DNS servers work.  The short version is that any time you type a website’s name into your browser (bobbycahill.com, to use an example everyone is thoroughly familiar with.), or click a link, etc. your computer first sends the domain name to a DNS server, which responds with the IP address(es) needed to actually reach the server where the website is hosted.

For a more detailed explanation of how the devices in your network fit together, see my previous post, How Does Your Computer Connect To The Internet?

 

I THINK I KNOW HOW DNS WORKS NOW. LET’S HEAR IT!

So in addition to the legit DNS servers you know and love (obviously), there are “evil” DNS servers in the world that would love for you to use their “services” instead.  If your DNS settings were somehow changed to point to one of these Rogue DNS Servers, you’d be in a lot of trouble.  In fact, there’s a possibility you are already pointing to one now and didn’t even know it!  But more on that later.

 

HOW DO I KNOW IF I AM USING A ROGUE DNS SERVER?

We’ll start with the symptoms since knowing how to spot it is usually the most important piece.  First, you may notice your browser behaving strangely.  There are a few scenarios that could be involved, some of which may cause noticeable changes in behavior.

Scenario 1: When you open a browser (any browser), and try to go to a website, some other unexpected page comes up.

 

 

• Often this page will claim it has detected spyware or a virus and that you must download some tool to remove it.  Don’t ever download a virus removal tool advertised in this manner.  The “tool” most likely is actually a virus or maybe in rare cases a red herring to distract you from some other attack.
• Sometimes there is a legitimate reason for the redirect… for example, some public wireless services require you to agree to their terms or authenticate on some local page before they let you get out to the public DNS.  This is (usually) not an attack, but does behave much like one.

 

 

Scenario 2: When you are opening webpages you start noticing that although the webpage you requested is opening, the status bar at the bottom of your browser window is telling you it’s requesting data from some website you’ve never heard before and it happens over and over again regardless of what website you browse to.  But you may eventually get to the site you wanted, so it may seem like nothing is wrong.

There is also a third scenario that may not be noticeable at all:

Scenario 3:  Sometimes you will get a certificate error from a site you have visited before.  There are reasons for a certificate error that are less dangerous (company let their certificate expire or your clock somehow got reset to Jan 1, 1970 and the browser wrongly thinks the certificate expired).  Because of this, or because maybe you have to make a bank transaction NOW or update your facebook status NOW people assume it’s not worth investigating and elect to go to the site anyway, or worse, permanently accept the bad certificate.  If you’ve done this, or the attacker really knows what they’re doing, there may even be no noticeable symptoms at all!

 

SO WHY IS THIS BEHAVIOR BAD???

I’m glad you asked!  You really do ask good questions.  The first of the scenarios listed above is bad for obvious reasons: it prevents you from accessing the internet, essentially making machines useless for the average user.  But then you just call up a computer repair service. Or like my family does with me, call your computer programmer friend/relative because you think the Geek Squad prices are too high, which is like asking your accountant to do your bookkeeping for you for free even though bookkeeping isn’t really his thing… What were we talking about again?  Oh yeah…

The second and third scenarios are WORSE.  Most users don’t notice anything wrong and continue to browse the web, not realizing that you are being redirected to a fake website posing as the real one (Scenario 2) or pointing to a proxy server which can act like ANY website you requested.  For now, don’t worry about what a proxy server is, just know that there are good ones and bad ones.  And in this case, the proxy server can see everything you input and can see and manipulate the responses you are getting from the requested site.  Attacks like this are known as:

 

MAN-IN-THE-MIDDLE (MITM) ATTACKS

Here’s how a MITM attack works.  Using mybank.com as an example, you browse to mybank.com.   In the case of a Rogue DNS attack, our computer does it’s DNS request and gets the IP address of a malicious proxy server instead of the real mybank.com.

The proxy server then browses to mybank.com behind the scenes, pretending to be you, gets the resulting page and forwards it on to you as though it were the real webpage.  It basically pretends to be mybank.com.  This by itself wouldn’t be such a problem (maybe slow your browsing down a bit), except now you think you are pointing to the real mybank.com and are likely to enter your username and password, which the proxy server is logging so the owners now have your password and possibly everything you saw while you were on the site.

Not only that, but the proxy server, before forwarding the results to you, can also modify these results however they want before sending them back.  For example, if you search for “how to remove a virus”, maybe there are a few known sites that show you how to remove it and it can hide those links from you so you will have a tougher time finding them.  They can also take a file you are downloading (like a bank statement) and replace it with a virus, or inject malicious code into the PDF, etc.  They can even inject malicious javascript into the webpage that your computer will run.  Hope your browser is up to date!

Or put more simply, once you’re pointing to one of these bad proxy servers, there’s an endless number of tricks they could use to steal your identity and remain undetected.

Since your browser thinks you’re talking directly to Google, which you might have listed as a trusted site, it executes the malicious code.  Or even worse, you log into your web-based email site (gmail, ymail, hotmail, etc.) and your browser tells you the certificate provided by the site is invalid, but because you need to get to your email now (or just don’t know any better), you accept the invalid certificate.  Now the malicious site can act as a SECURE intermediary between you and your site, which means they can see your username, password and everything else you input or view on that site even if the site is “secure”, a.k.a. encrypted with an SSL certificate.

AND YOU MAY NOT EVEN HAVE A VIRUS! At least not yet….

 

HOW CAN I CONFIRM FOR SURE?

There is no way to confirm for sure, because hackers will always try to find ways to outsmart any standard method for protecting against anything.  But for most cases you can do the following:

First, find out which DNS server(s) you are using.

 

Windows:

Click  Start > Run  (or if there is no “Run” option, click “Search programs and files”)

Type the following command and press ENTER:

cmd

This will open up a “Command Prompt” window.  Type the following and hit ENTER to see your network settings:

ipconfig /all

Find your network adapter and look for the line that says “DNS Servers”

 

Linux (and probably Mac – I don’t have one to test with):

Open a terminal window if you aren’t already at a shell prompt, type the following and press ENTER:

cat /etc/resolv.conf

 

Now it can be tough to know if a DNS server is bad just from the IP address.  But if you happen to know what your DNS server was originally and it has changed, this is a bad sign.

If you don’t know what DNS server you should be using, you can try looking up the IP address using the nslookup command (Windows) or host command (Linux – if nslookup not available).

nslookup bobbycahill.com

Use a small website, because huge sites like Google, Twitter, Facebook, etc. do complex tricky stuff to handle their massive loads, so doing an nslookup may give you 15 results and those results may change every so often.

Generally when you run this command it will first tell you the DNS server it used, followed by the IP Address(es) of the domain you entered (in this case, bobbycahill.com)

Then, run the command again, except force it to use a known public DNS server.  I generally use the Google public DNS (8.8.8.8 or 8.8.4.4), but it’s a good idea to pick your own from a database of known DNS servers.

nslookup bobbycahill.com 8.8.8.8

Did you get the same results?  If not, chances are the DNS server you were using is bogus.

 

HOW DID THIS HAPPEN IN THE FIRST PLACE???

There are a number of ways this can happen.  Here are the usual suspects:

Attack 1: HACKING YOUR MACHINE – Someone hacked into your computer and changed your settings.  Probably the least common method, unless you make it a habit to piss off hackers.  (Pro tip: don’t be mean to hackers.  They tend not to be forgetful.)

Attack 2: MALWARE – Someone tricked you into running a malicious application and now you have a virus that is hiding behind the scenes and changing your DNS settings to point to this bad server.  Example: DNSChanger

Attack 3: HACKING YOUR NETWORK HARDWARE – Someone hacked into the DHCP server on the network to which you are connected.  They changed the settings of your previously legitimate DHCP server to point to a Rogue DNS Server.  Now the router is broadcasting the rogue DNS server to all machines that connect to it.

Attack 4: ROGUE DHCP SERVER – This is an even more sneaky attack than the above three.  A Rogue DHCP Server does the same thing as your legitimate DHCP server.  Now any new machine that connects to your network will issue a DHCP request as usual to get an IP address and DNS servers, etc., but instead of the usual single response from your legit DHCP server, suddenly there are two responses being sent.  If your machine picks up the bad DHCP response instead of the legit one, it will blindly start using the Rogue DNS server instead of the good one that your ISP recommended.

The first 2 methods can often be prevented using standard best practices for keeping your computer secure like using strong passwords, keeping your software updated, not executing files or clicking links in suspicious emails, etc.

WHAT TO DO IF YOU ARE A VICTIM

If you are already a victim of this attack, fixing it depends on how you were attacked.

If it was a one-time hack that caused it, and no malware was involved, rebooting your machine, reconnecting to the network or forcing a DHCP request will fix your issue.  Now you just need to make sure you update all your software and passwords so you don’t get hacked again.

If you have malware, this is a more general problem beyond the scope of this article, but the first thing to do if at all possible is IMMEDIATELY DISCONNECT the computer from the internet and do not reconnect it until you have removed the malware. If possible, use another machine for any needed research, downloads, etc.  Most malware is designed to be tricky to clean, so if you don’t have a backup image or can’t restore your machine to factory defaults, you may have to call Geek Squad or your local computer repair place for help.  Or you can try some of the how-to videos on youtube.  Here’s one example.

My next article will get into how attack 4 can happen, and what to do if it happens to you.  I will also detail my experience with a Rogue DHCP Server attack in my office.

 

 

A couple extra things I pulled out of the above article because it was getting too long:

NOT THE GOOGLE REDIRECT VIRUS

I included this because I saw a lot of people posting things in forums where they were going to Google and the search results were redirecting them to bad websites.  Often people were responding saying it’s the “Google Redirect Virus”.  There is an actual virus known as the “Google Redirect Virus”, which is a type of browser hijacking virus.  I even recall some discussions about how this is because Google was hacked, etc.

First off, the number one site on the internet is Google.  Since most people use search engines to find practically all information on the internet that’s not from a social networking site, Google tends to be the most common page many users look at.  There are some people that call this issue the “Google Redirect Virus”.  This is because they notice funny behavior while they are clicking links in their Google search results.  But as you will see the problem has absolutely nothing to do with Google, except for the fact that it is programmed to only spring into action when you use Google.  The same thing could be done for any other site on the web.

OPERATION GHOST CLICK

The biggest example of this is an Estonian ring of cybercriminals taken down by the FBI in Nov. 2011 in an investigation dubbed Operation Ghost Click.  (witty, huh?)  This ring used a computer virus to infect millions of computers and trick them into pointing to their Rogue DNS Servers.  The FBI seized a large network of these servers, but since shutting them all down would “break the internet” for millions of victims, they replaced the bad servers with legitimate ones, and they referred the public to a webpage that helps you identify if you’re using one of them.

In fact, there was a period of time in early 2012 where the FBI was no longer able to maintain the Legit DNS Servers that replaced the bad ones, and they were planning to shut them all down.  many were worried that all of the remaining victims would lose internet access.  See the CNBC article titled: FBI: Hundreds of Thousands May Lose Internet in July

I wasn’t worried that this would be a major issue, because who do you blame when the internet stops working?  Your evil ISP whose customer service notoriously drives people crazy.  And those ISP’s don’t like outages, even if they’re not really at fault.  So I’m sure their networking geniuses came up with a way of rerouting traffic to known FBI DNS servers back to a legitimate one so that even victims who were still affected would maybe get a warning page or just redirected as if nothing were wrong.

But does this mean Rogue DNS Servers are no longer a problem?  Very doubtful.  There will probably be new ones popping up all over the place.  Ones not among those seized by the FBI.  So even if you aren’t pointing to one of the DNS servers seized by the FBI, you could still be pointing to a Rogue DNS Server.  In fact, when someone at my company had this problem the link above did not detect it.

At the BostonPHP CakePHP meetup in Feb. 2010, there seemed to be a lot of people who had trouble getting the Apache rewrite module, also known as “mod_rewrite” to work properly, and therefore could not fully take advantage of the CakePHP framework and its powerful features.

The cookbook (CakePHP’s online documentation) touched briefly on this, but because it seemed like such a universal problem, and because I was not able to find a detailed explanation targeted toward beginners anywhere on the web, I decided to write one myself.

The current article can be found at the Bakery here:
http://bakery.cakephp.org/articles/view/troubleshooting-cakephp-installa…

Below is the original text from my original writeup before I later posted the article on the CakePHP Bakery site (and subsequently edited it…):

IF YOU ARE ABLE TO GET YOUR DEFAULT CAKE INDEX PAGE TO COME UP, BUT WITHOUT IMAGES/STYLING/ETC – DETAILED WRITEUP

If you are able to get your default CakePHP index page to come up after installing, but without the Cake logo in the top left and without the styling, this article should help you troubleshoot the issue.

A common issue when installing CakePHP is that the main index page will come up, but without images and styling, making your page look kind of like a text and-hyperlink-only html page.

The following image is an example of how CakePHP’s homepage should look when you first install it. And it should look this way without touching ANY of the CakePHP files:

http://www.ibm.com/developerworks/opensource/tutorials/os-php-cake1/fig01.jpg

Many people after installing can get the page to come up, but it looks more like this:

http://www.ibm.com/developerworks/opensource/tutorials/os-php-cake1/fig02.jpg

If you are experiencing this issue, the problem is most likely not with your cake installation, it’s with your Apache configuration… more specifically the problem is that you aren’t using mod_rewrite correctly.

If you are not familiar with mod_rewrite and it frustrates you, don’t feel bad. I’ve installed LAMP servers (and a WAMP server or two) many different ways, through Linux package repositories, compiling PHP, Apache and MySQL individually from source, etc. and I have to say getting Apache to work the way I wanted it to (especially mod_rewrite) was one of the two or three most frustrating things I’ve ever had to deal with in my programming experience.

What is mod_rewrite, you ask? Here’s my quick explanation: mod_rewrite is an Apache module (a piece of Apache you can enable or disable) that basically allows the server to “rewrite” the URL you type into your browser behind the scenes… as well as rewriting any URL’s referenced within the HTML source of the page. You can’t see the rewritten URL’s in your browser’s address bar. Without this, you wouldn’t be able to use the MVC-friendly URL’s CakePHP is designed to use.

mod_rewrite is most likely enabled in your Apache configuration file, usually called httpd.conf (httpd is the name of the daemon process that is the Apache server, so as far as we’re concerned httpd=Apache) The rules for this rewriting are defined in the .htaccess files included with CakePHP.

CakePHP also expects you to configure Apache such that the “DocumentRoot” points directly to CAKEROOT. MAMP, WAMPServer, XXAMP, etc. do NOT do this by default. They usually have a directory called www, public_html, webroot, httpdocs, or something like that and the “DocumentRoot” points there by default. They (*AMP) expect you to either put your website there or in a subdirectory.

Cake’s .htaccess files are written on the assumption that your DocumentRoot points directly to your CAKEROOT directory. While you CAN make CakePHP work in a subdirectory of your DocumentRoot, it requires changes to .htaccess files and maybe even cake config files or index files, etc. And you may run into other issues later when trying to follow instructions that assume you have it working. So if you’re just interested in learning CakePHP, do not waste your time trying to figure out how to bypass mod_rewrite unless you REALLY have to.

HOW TO TROUBLESHOOT THIS ISSUE:

STEP 1) Check for the .htaccess files and make sure they are readable.

Files starting with a “dot” like .htaccess are usually hidden by default. Depending on how your machine is set up, these hidden files can be ignored when copying, especially if you are using a file browser and you have it configured to hide hidden files (usually the default setting).

The safest option is to unzip, untar, etc. in the CAKEROOT folder, but regardless of how you do it, check to make sure the .htaccess files are there and make sure they have the proper permissions so they can be read by the server.

You should be able to find a file called .htaccess in each of the following locations:

CAKEROOT/.htaccess
CAKEROOT/app/.htaccess
CAKEROOT/app/webroot/.htaccess
CAKEROOT/cake/console/libs/templates/skel/.htaccess
CAKEROOT/cake/console/libs/templates/skel/webroot/.htaccess

If you decompressed (unzipped, untarred, etc.) a cake archive you downloaded from the CakePHP site and did so directly in the CAKEROOT directory, these files should all be in place.

If you decompressed an archive, then COPIED the files, especially if you did it using a graphical program like Windows Explorer (of Finder for Mac, someone correct me if I’m wrong), then it’s entirely possible that the files did not get copied.

If you don’t want to manually check for each one you can open a command prompt, preferably as user “root”, navigate to the CAKEROOT directory and run the following command:

find . -name .htaccess

This should spit out a list of .htaccess files similar to the one I gave above.

If the files are there, double check to make sure they have the correct file permissions. If they can’t be read by the server, they won’t be picked up. From the command line, navigate to the CAKEROOT directory again and run the “list (long)” command:

ls -l .htaccess

You should see something like this:

-rw-rw-r– 1 root users 139 2010-01-29 21:54 .htaccess

In this case the file is readable by everyone because there are 3 r’s. If you see this, move on to STEP 2.

If you want to understand how file permissions in UNIX-like systems work, go here:
http://www.perlfect.com/articles/chmod.shtml

If you do not see 3 r’s, assuming you or root has the privileges needed to modify the file, you can fix this by going to each folder that has an .htaccess file and running the following command:

chmod a+r .htaccess

STEP 2) Find your apache configuration file(s)

I know WAMPServer has a system tray icon you can click through to get to the httpd.conf. I assume MAMP, XXAMP, etc. are similar, but not identical.

If you do not know how to access your Apache configuration files, start by checking the documentation for whatever server software you are using (MAMP, XXAMP, WAMP, etc.) because although they all seem pretty similar, they are most likely not all the same.

Keep in mind the following rules (at least the ones I’m aware of) about Apache configuration files:

-Since *AMP servers are designed to make server administration more simple, it’s usually called httpd.conf, but it DOESN’T HAVE TO BE.
-It can actually be more than one file… you can include other config files from within httpd.conf.
-If you find a file called httpd.conf, it doesn’t necessarily mean it’s the one being used… there are situations where you might have more than one httpd.conf in your system.

So again, your *AMP documentation is your best bet for finding the correct file. Once you know how to access the correct file (or files), note it down somewhere. You will need this later.

STEP 3) Find out if mod_rewrite is enabled.

The easiest, most definitive way to find out if mod_rewrite is enabled on your server, if you can get it to work, is to find your CAKEROOT/index.php file and add the following line of PHP code somewhere:

phpinfo();

Then when you open your cake page again, you will see the PHP Info page first, followed by the broken cake page like the pic above. If you can get this to work, this will make it WAYYYYYYY easier to troubleshoot your Apache issues. Therefore I will make this the one exception to my earlier rule about not modifying the cake files until you get Apache working properly.

mod_rewrite

About 3 tables down or so in your PHP Info page (the contents of this page varies depending on your php build an php.ini settings) look for a table called “apache2handler”. Towards the bottom of the table you should see “Loaded Modules”. Somewhere in that list you should find mod_rewrite. If you DO NOT find it, mod_rewrite is NOT enabled. Remember this…. we will go over what to do about it later in the post.

DocumentRoot

You can also find out what your true DocumentRoot is by looking at this PHP Info page. A little further down, there will be a table entitled Apache Environment. Find the DocumentRoot field and remember the value you see there. This will also come in handy later.

IF FOR SOME REASON YOU CAN NOT GET THE PHP INFO PAGE TO DISPLAY, you will have to make sure you are sure about which Apache configuration file or files are being used and go on to STEP 4.

STEP 4)

Check that you have the following set up in your Apache configuration file(s) (from STEP 1)

Search through them for the following lines:

This line loads the driver/library for the rewrite_module (another name for mod_rewrite):
LoadModule rewrite_module libexec/mod_rewrite.so

This line ENABLES the rewrite_module:
AddModule mod_rewrite.c

This line sets the DocumentRoot of the server. This can be in multiple places, so make sure you know where all of them are:
DocumentRoot CAKEROOT

If any of these lines are not there or are preceded by a hash (#), then you need to add them or remove the hash.

When making changes to files like this, don’t forget to take measures to make sure you can roll back your changes if needed. Remember the following guidelines:

1) Do not touch the file until you have made a backup copy of the file.

For example, I recommend you copy httpd.conf to something like httpd.conf.20100220. (today’s date stamp) so later on you can find the latest working copy if you break something else and need to quickly roll back.

2) Never delete or change any existing code in the file, always comment it out. In apache configuration files, you do this by preceding the line with a hash (#).

3) You should also add a comment on the previous line with a note about what you changed and when (and if you really want to be careful, the reason why). Include your name in case your project ever becomes collaborative.

Examples:

#Modified by Bobby 2/20/2010 for the CakePHP tutorial
#DocumentRoot “/some/wrong/root/folder”
DocumentRoot “CAKEROOT”

#Added by Bobby 2/20/2010
LoadModule rewrite_module libexec/mod_rewrite.so

#Removed by Bobby 2/20/2010 to prevent overlap
#Alias /cake/ “CAKEROOT/app/webroot”

STEP 5) If you made changes to the Apache configuration files in STEP 4, RESTART APACHE. You’d be surprised how many people forget this.

If you do not know how to restart Apache, refer again to your *AMP documentation. It may vary from version to version.

Now your CakePHP homepage should load correctly and you are now ready to continue with the tutorial.

If you still can’t get it to work, the CakePHP Cookbook has some info about how to use Cake’s “Pretty URL’s”. Go here:
http://book.cakephp.org/view/333/A-Note-on-mod_rewrite

If you have any questions/comments/corrections, either post a reply or message me directly.