ITS 4550 - Fraud Prevention and Deterrence

Chapter 9, Web and Database Attacks

This lesson presents material from chapter 9. Objectives important to this lesson:

1. Attacking web servers
2. SQL injections
3. Vandalizing
4. Database vulnerabilities
5. Cloud computing aspects
   

Concepts:

Chapter 9

The chapter begins with some hints that a web server may have vulnerabilities that a server administrator may miss, overlook, or not have in today's list of things to handle. The list that should be addressed begins on page 215:

• server defects and misconfigurations - this covers servers that allow hackers to steal information, to enumerate them, to run scripts and executables, and to run DoS attacks
• browser and network risks - browsers are meant to interact with servers, which are part of the network; we need to guard against captured traffic being of any use to the attacker
• client side risks - as we have discussed, attacks can take place on the client's machine, harvesting information and planting malware

The text addresses server side issues for several pages:

• general issues that apply to any server on a network, which the text reminds us is critical for a company that has no brick-and-mortar presence, and must rely on its web presence as the only face its customers see
• comments and actual functional code in web pages - on page 216, we see an example of a documentation comment marking a section of code that sends mail to several servers, plus actual server URLs and email addresses in that block of code
• buffer overflow - this topic is rarely explained, so I will offer this video from Computerphile, which has the best discussion I have seen about why a buffer overflow could cause code to actually be executed. This video was presented in week 3 of the ITS 4050 class, so it will be review for some of you.

   

• denial of service attacks - the text gives us a brief idea about defeating a single-source DoS attack: block traffic from it; this is best done dynamically by firewalls that can notice the kind of traffic such attacks produce and write new rules to reject such traffic

• distributed denial of service attacks - the text realizes that a distributed denial of service attack is harder to defend against, due to the variety of sources of the attack packets, and due to the volume of packets being sent by the attacker's zombie army.The text mentions four variations on distributed denial of service attacks:
  • Ping flood - The idea here is to send a ping request to the broadcast address of the network a target machine is on. This can be a problem if there are a large number of devices on the target network (and they all respond). This is a reasonable argument to segment your network in a way that your important devices are on small subnets. Another approach would be to configure devices to refuse response to broadcasts.
    
  • SYN flood attack - In chapter 6, we discussed using TCP packets in a SYN-connection port scan. Knowing which ports are open, the attacker can flood them with SYN packets requesting connection, preventing legitimate connections from taking place.
    
  • Smurf - The same thing as a Fraggle attack, which uses UDP packets, except that Smurf uses ICMP packets. Essentially, the attacker impersonates the server to be attacked, and sends pings on its behalf to other networks. The victim is flooded with responses. This reference indicates that this can be an obsolete attack if servers are configured to refuse this kind of traffic, but a large enough volume of it would still be a problem.
    
  • Fragmentation attack - This attack requires that the attacking packets be segmented (broken into smaller pieces) in a way that prevents their nature from being recognized by network or server defenses. The attack only takes place when the segments are reassembled into the actual payload the attacker meant to send.
• banners - Banners are default messages sent by a web server in response to a telnet request. When they were invented, their purpose was to make connection to the server easier. Obviously, this was not considered from a defensive point of view. Page 218 shows us a typical banner that displays a server's IP address, its default page, and other general information. This information can be changed by an administrator. The image below depicts the result I received from a quick attempt to read the banner of the main Baker web server.
  
  
  
  As you can see, I saw an IP address and a URL, but I could have gotten that less intrusively. Also, there was no banner from the server.
• more general advice - set permissions wisely, do not share error messages with users/hackers, and harden servers by removing services that they do not need to provide
  

Our author moves on to a short discussion of SQL attacks. (He seems to like to call it "sequel". I have heard it called by its initials more often, but both are correct.) Injecting an operating system command is also possible, as shown in the following video, another selection from Computerphile. This time Dr. Pound discusses what might be happening on the server side when an injection attack takes place.


As the text points out, the defense against injection is to validate the inputs gathered from a user. Don't trust that a user will enter what you ask for. It is more than checking for a valid entry in a web form. It is checking for attacks as well.


For those who want more information about the nature of an SQL attack, in that last video Dr. Pound was pointing us to another Computerphile video containing those details, this one by Tom Scott.

The very destructive attack described by Mr. Scott leads us into the next topic, vandalizing web servers. As you can see in the lists of vulnerabilities and attack vectors on the rest of the pages in this chapter, there are many ways a web server can lose its functions and its contents.

• We should all be believers in validation of user input at this point.
• We should hope that web masters scrub their servers, deleting unauthorized scripts regularly. Since this is probably not continuous, and since it will never happen on servers set up by attackers, we have to watch out for scripts running on our computers, provided by web pages.

Use the remainder of the chapter as reference material in your submissions for Assignment 5 and Project 5, assigned this week.