Skip to content

Instantly share code, notes, and snippets.

/dabblet.css

Created March 10, 2013 12:20
Show Gist options
  • Save anonymous/5128348 to your computer and use it in GitHub Desktop.
Save anonymous/5128348 to your computer and use it in GitHub Desktop.
Download ZIP
Untitled
Raw
dabblet.css
body
{
text-decoration: none;
background: #ffffff;
font: 1em Georgia;
color: black;
margin: 1cm 1.5cm;
}
.content
{
margin: 0;
font-size: 1em;
float: right;
border: Solid 2px green;
/* padding: 0px; */
width: 79%;
background: lightgrey;
}
.leftcolumn
{
font-size: 1em;
float: left;
width: 20%;
border: Solid 2px green;
height: 100%;
text-align: center;
background: grey;
}
h1
{
font-size: 1.6em;
font: Arial;
background: yellow;
color: navy;
font-weight: normal;
}
h2
{
font-size: 1.3em;
font: Arial;
background: red;
color: white;
font-weight: normal;
}
h3
{
font-size: 1.2em;
font: Georgia;
font-weight: bold;
}
h4
{
font-size: 1.0em;
font-weight: normal;
text-transform:uppercase;
}
p
{
line-height: 1;
/* text-indent: 2.0em; */
}
.code
{
text-decoration: none;
font: "Courier New", Courier, monospace;
font-weight: normal;
text-indent: 2.0em;
}
.navlink a
{
margin: 0px;
padding: 0px;
list-style: none;
color: blue;
background: white;
}
.navlink a:active, .navlink a:hover
{
background: blue;
color: white;
}
.centeralign
{
text-align: center;
}
.rightalign
{
text-align: right;
}
.nobullet
{
list-style-type: none;
}
Raw
dabblet.html
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>csf_ch6_aa</title>
<link rel="stylesheet" href="Prac1Task1.css" type="text/css" />
<link rel="icon" href="../images/favicon.ico" type="image/x-icon" />
</head>
<body>
<p id="top"></p>
<div class="leftcolumn">
<p class="navlink"><a href="#bottom">Bottom of Page</a></p>
<p class="navlink"><a href="csf_ch4_ill.htm">Chapter 4</a></p>
<p class="navlink"><a href="csf_ch6_aa.htm">Chapter 6</a></p>
<p class="navlink"><a href="csf_ch8_hash.htm">Chapter 8</a></p>
</div>
<div class="content">
<h1><a id="aa" name="aa">Actual Attacks</a></h1>
<p>Now that we have discussed how attackers scan a target system, let’s look at a few attacks that are commonly used. Obviously this won’t be an exhaustive list, but it will provide you some insight into the attack methodologies used. In <a href="./notfound.htm">Chapter 4</a> we discussed denial of service attacks and some tools used to cause these attacks. In this section we will look at other sorts of attacks and the techniques and tools used to make them happen.</p>
<h2><a id="sqlSI" name="sqlSI">SQL Script Injection</a></h2>
<p>This may be the most popular attack on websites. In recent years, more websites have taken steps to ameliorate the dangers of this attack, but my informal surveys still find about one-third of websites susceptible. This attack is based on passing structured query language commands to a web application and getting the website to execute them.</p>
<p>The way the most basic SQL injection works is this. Many websites/applications have a page where users enter their username and password. That username and password will have to be checked against some database to see if they are valid. Regardless of the type of database (Oracle, SQL Server, MySQL, etc.), all databases speak Structured Query Language (SQL). SQL looks and functions a great deal like English. For example, to check a username and password you might want to query the database and see if there is any entry in the users table that matches that username and password that was entered. If there is, then you have a match. The SQL statement might look something like this:</p>
<p class="code">'SELECT * FROM tblUsers WHERE USERNAME = 'jdoe' AND PASSWORD = 'letmein'</p>
<p>The problem with this, while it is valid SQL, is that we have hard coded the username and password. For a real website we would have to take whatever the user entered into the username field and password field and check that. This can be easily done (regardless of what programming or scripting language the website is programmed in). It would look something like this:</p>
<p class="code">'SELECT * FROM tblUsers WHERE USERNAME = ' &ldquo; + txtUsername.Text +' AND PASSWORD = ' &rdquo; + txtPassword.Text +&rdquo; ' &rdquo;.</p>
<p>If you enter username 'jdoe' and password 'letmein', this code produces the following SQL command: </p>
<p class="code">SELECT * FROM tblUsers WHERE USERNAME = 'jdoe' AND PASSWORD = 'letmein'</p>
<p>Now if there is a username jdoe in tblUsers, and the password for it is letmein, then this user will be logged on. If not, then an error will occur.</p>
<p>SQL injection works by putting in some SQL into the username and password block that is always true. For example, suppose you enter 'OR X=X' into the username and password boxes. This will cause the program to create this query:</p>
<p class="code">SELECT * FROM tblUsers WHERE USERNAME = ' ' OR X=X' AND PASSWORD = ' ' OR X=X'</p>
<p>Notice we start with a single quotation mark (') before the OR X=X. This is to close the open quote the attacker knows must be in the code. And if you see ' ', that essentially is a blank or null. So what we are telling the database is to log us in if the username is blank, or if X=X, and if the password is blank, or if X=X. If you think about this for a second, you will see that X always equals X, so this will always be true.</p>
<p>There is no significance to 'OR X=X’; it is simply a statement that will always be true. Attackers try other similar statements, such as the following:</p>
<ul class="nobullet">
<li>' or 'a' ='a </li>
<li>' or '1' ='1 </li>
<li>' or (1=1)</li>
</ul>
<p>This is only one example of SQL injection; there are other methods, but this is the most common. The defense against this attack is to filter all user input before processing it. This is often referred to as input validation. This prevents an attacker from entering SQL commands rather than a username and password. Unfortunately, many sites do not filter user input and are still vulnerable to this attack.</p>
<h2><a id="crossSS" name="crossSS">Cross-Site Scripting</a></h2>
<p>With cross-site scripting, an attacker injects client-side script into web pages viewed by other users. The key is that the attacker enters scripts into an area that other users interact with. So that when they go to that part of the site the attacker’s script is executed, rather than the intended website functionality. For example, assume a shopping site allows users to review products. Rather than typing in a review, the attacker types in JavaScript that redirects the user to a phishing website. When another user views that &ldquo;review,&rdquo; the script will execute and take them to the new site. Again, this can be prevented by simply filtering all user input. As of this writing, all the major online shopping portals, such as <a href="http://amazon.com">Amazon.com</a>, do filter input and are not susceptible to this attack. However, many smaller sites are still susceptible</p>
<p>This attack, as well as SQL injection, illustrate why it is critical that all IT personnel be familiar with security, not just security administrators. If more web developers were more familiar with security, these two attacks would not be widespread.</p>
<h2><a id="passC" name="passC">Password Cracking</a></h2>
<p>Doing password cracking is easiest when one can actually get physical access to a machine. This is not as difficult as it sounds. Many organizations (such as universities) have kiosk machines were one can use the system with minimal/guest privileges. A skilled hacker can use this access to gain further access.</p>
<h2><a id="oph" name="oph">OphCrack</a></h2>
<p>A very popular tool for cracking Windows passwords is OphCrack. OphCrack can be downloaded from <a href="http://ophcrack.sourceforge.net">http://ophcrack.sourceforge.net</a>. It is based on an understanding of how Windows passwords work. Windows passwords are stored in a hash file in one of the system directories, usually C:\WINDOWS\system32\config\ in a SAM file. SAM is an acronym for Security Accounts Manager. The passwords are stored as a hash. (Hashes will be discussed in detail in <a href="./csf_ch8_hash.htm">Chapter 8</a>, &ldquo;Encryption.&rdquo;) What Windows does is hash the password you type in and compare it to the hash found in the SAM file. If there is a match, then you are logged in. Now to prevent someone from copying the SAM file and taking it off to try to brute force it, as soon as Windows begins the boot process, the SAM file is locked by the operating system. What OphCrack does is to boot to Linux and then get the SAM file and look up the hashed passwords in a large table of hashed values it has, looking for a match. If it finds one, then the matching text in that table of hashed values is the password. You can see OphCrack in <a href="#fig6_5">Figure 6.5</a>.</p>
<p><a id="fig6_5" name="fig6_5">Figure 6.5. OphCrack.</a></p>
<p class="centeralign"><img src="../images/fig6_5.jpg" alt="ALTERNATIVE TEXT" /></p>
<p>This tool is remarkably easy to use. Just put the OphCrack CD into the machine, reboot. During the boot process you can press F12 for a boot menu and tell the system to boot from CD. You will then start OphCrack. It should be noted that longer passwords (as of this writing longer than 10 characters) are usually not crackable by OphCrack.</p>
<p>Now assuming OphCrack is successful (it isn’t always), what can the attacker do with this? At best he or she simply got the local machine admin account, and not a domain account. Well, this can be used to then gain domain access. One simple technique is to create a script that will in turn create a domain admin account. The script is simple:</p>
<p class="code">net user /domain /add localaccountname password</p>
<p class="code">net group /domain &ldquo;Domain Admins&rdquo; /add localaccount</p>
<p>Now obviously if the attacker executes this script it will not work. One must be a domain admin for it to work. So the attacker saves this script to the all users startup folder. The next time a domain admin logs on to this system, the script will successfully execute. But the attacker may not want to wait until that happens. So in order to speed up the process, the attacker causes some minor problem in the system (changes settings, alters configuration, etc.). In many organizations, the tech support personnel are in the domain admins group. When a tech support person logs on to the system to correct the problem, the script will successfully run.</p>
<p class="rightalign"><a href="#top">Top of Page</a></p>
<p id="bottom"></p>
</div>
</body>
</html>
Raw
dabblet.js
// alert('Hello world!');
Raw
settings.json
{"view":"separate","fontsize":"90","seethrough":"","prefixfree":"1","page":"result"}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment