Subscribe to Software Autopsy        RSS Feed
-----

Importance of security testing

Icon Leave Comment
This is not a hacking tutorial, this is more of idea sharing and the how careless programing practices can lead to security holes which are not apparent, and some of which are rather glaring and very silly, and even after suggestions they are not fixed. The below content is just some basic things I learnt and still learning and just wanted to share what information that I gathered and listed the sources.

Before undertaking security testing, do we understand the
1) Why it is done?
2) What are the risks of not doing it?
3) What is hacking?
4) Knowledge of the tool in terms of what it can do, and what it cannot, what it can break, and what information it can fetch and how to analyze these results.

What is security testing?

Security testing is non-functional testing because no matter what's the nature of the application either web or desktop, itís understood that the application should be secure. For example when some one says they have built a house, it is understood that there will be walls, ceiling, doors, windows and ventilation ,facility for water etc. Now when we say door, itís understood that it should have open/close facility, it can be bolted either from outside or inside, it can be locked and unlocked etc. Nobody is going to install a door that can't be close or that can't be locked; there is no need for a door if it can't be closed and opened, that can't be locked and unlocked. You open a locker in a bank; the banker is not going to ask you, "Do you want locks for that?Ē
Hacking: - Unauthorized access, manipulation of resource by both internal and external users. Access can be modifying, reading and updating the data/information.
Hacking using tools is different than hacking using scripts.

Types of attack

1) Brute force ≠ either manual or automated
2) Phishing
3) Directory Listing
4) SQL injection (for web and desktop application)
5) Cross-Site Scripting
6) URL manipulation attack
7) Buffer overflow
8) Denial of service

Few reasons for an application/web site/web application is being hacked are the carelessness/negligence on part of the programmer, lack of knowledge, no proper code review by other members, unsafe programming practices like not cleaning up memory space when no longer needed, copy and paste code from other web sites blindly etc. Though there is process in place programmers, do not follow strictly. Not only web applications but also applications deployed for a desktop too could have security loopholes which could allow an attacker access to sensitive data on the system to which he/she wouldn't have access otherwise. Once an application is deployed into production environment it is a fair game.

Using automated tool has one limitation; it is designed to work under predefined boundary, and works only for the known issues or predefined list of issues. As and when new issues are found the list needs to be updated. The list can be stored in a database or can be read from library file or dll(s). What if they are compromised. But it doesn't mean that automated tools shouldn't be used at all. There should be a balanced combination of manual and automation.

Loopholes in the application can be present right from the design stage or the application architecture.
The only solution is to keep patching up the security holes found. Best examples are the operating systems like Windows, Linux, Mac, Web browsers like IE, Fire fox etc. The end user of the application is the biggest security threat to the application.
Before using automation tools analyze the application in question to find the loopholes in the system, by using the application

How to analyze the application/web site

To analyze the application manually for a website/application start interacting with the application. If there is a log in page or screen trying various combinations for user name and password including valid and invalid input?
1) Valid inputs would be a valid user name and password
2) Invalid inputs would be special characters which cannot be accepted in the user name and password fields.
3) Try using the SQL statements within the password/user name field, check the response of the application/log-in page

Most of the applications/ web sites that are developed are not susceptible to sql injection attack because the programming language offers some kind of inbuilt protection.
How to check
Try logging into various web sites where log-in page is present, with SQL statements/ combinations in the user name and password. Sample inputs used
1) ' OR''=1
2) ' OR Exists(select * from <table name> where <user name field>=<user name> and <password field> like "%<any character(s)) and '='
3)Crafting the following SQL statements for a user 'jake' we can log in as user 'jake' into the system by using any of the following method if SQL injection is possible.
Does jake's password have a w in it?
' OR EXISTS(SELECT * FROM users WHERE name='jake' AND password
LIKE '%w%') AND ''='
Does jake's password start with w?
' OR EXISTS(SELECT * FROM users WHERE name='jake' AND password
LIKE 'w%') AND ''='
Does jake's password have an w followed by d?
' OR EXISTS(SELECT * FROM users WHERE name='jake' AND password
LIKE '%w%d%') AND ''='
Is the fourth letter of jake's password w?
' OR EXISTS(SELECT * FROM users WHERE name='jake' AND password
LIKE '___w%') AND ''='
' OR EXISTS(SELECT * FROM users WHERE name='jake' AND password LIKE '%w%') AND ''='
' OR EXISTS(SELECT * FROM users WHERE name='jake' AND password LIKE '__w%') AND ''='
Information source : www.sqlzoo.net
If this log-in fails it means SQL injection attacks are not present in the log-in page at least.

How it works

For example user name is entered joe and password constructed something this was ' OR''=1, the sequel
statement generated in the background would be select * from users where username='joe' and password =
How to prevent this from happening
1) Proper escape sequences i.e. escape sequence for comment characters in sql
2) Input validation

Phishing

Though phishing cannot be stopped, but if the source code of the web page is not encoded (view->source) it can become very easy task to do it. The attacker can copy the code by viewing the source of the page, and make an exact replica of the web site very easily. Now if the source of the page is encoded, it makes the attacker's task difficult to replicate the site. If the source is not displayed, only the UI can be replicated, but if the source is displayed, not only UI, but also the content of the page can be copied. As an example consider a shopping web site in which people can order products on-line and use credit to make payment. User searches for products and adds them to his/her shopping cart, and checks out, and makes payment using credit card/debit card. Searching results in dynamic data, and if this dynamic data is displayed in view-> source of the page, the attacker can search for the products, copies the code, pasting it in note pad, making the exact replica of the shopping web site. The next step is to host the web site with the similar sounding name or create a new web site all together, and make little changes, and make it very attractive, offer discounts which a buyer cannot refuse. People search for products, add to shopping cart, and fill out the shipping address, and make payment through credit card. Now
when they enter the credit card details, the attacker captures it along with the security code and password. The buyer will assume that he/she will get product, but has no clue that their bank account has been compromised.
A capable attacker and inject his/her own code into the source code is available for plain view. Just because the attack hasn't happened, doesn't mean it safe. It is till someone figures it.

Directory Listing

This happens when the attacker can list the file on the server by inserting a random path/ file after the URL. As the file is not found on the server, if the server will list out the file on the severe as the requested file name or path doesn't exist. Even worst is the attacker can execute commands using this kind of an attack. This can be avoided by parsing the URL and also create index page in every directory so that when a requested resource is not available the default index page is loaded.

Giving free information

In the URL is not good practice to show the extension of the page like .asp, .aspx, .jsp is displayed. This gives an attacker very valuable information. If the extension is .asp, .aspx itís bound to be hosted on a windows server, if its .jsp is could be hosted on a UNIX/Linux based server. Giving away this information, the attacker can figured weakness by using a search engine and use it very effectively.

Another way to give free information is to display proudly "This site powered by <software> and <version>", well version need not be displayed though. Well this gives attacker very valuable information, using popular search engines to retrieve the active vulnerabilities, active means vulnerabilities which have not been fixed yet. Using this information the attacker can take advantage of the vulnerabilities to the maximum advantage, and there is no defense. If the attacker takes advantage of just one of the vulnerabilities some temporary fix can be applied, but if all the vulnerabilities are exploited at same time what would happen? If water is leaking from just 2 or three holes, it can be patched quickly, but what would happen if there are hundred holes and waters leaks from all the hundred holes at the same time, which hole will be fixed first and what the effort is. This scenario fits perfectly and though it sounds scary, unfortunately this is true in case of software, because no software is bug free and its takes time to fix depending on if itís simple or complex to fix. The other thing is by fixing one security hole it can open already existing one, which were previously un-known, or create new one. It is like traveling on an unknown road with left and right turns at every corner, the traveler doesn't know which turn to take as there is no knowledge of what is in store at left side or right side.
Password reset/ forget password method

If the password rest/forgot password is weak, it can be used effectively to launch other kind of attacks like denial of service attack, steal passwords etc. By weak it implies that the user enters email address, and instead of displaying a message "Reset instructions are sent to the email address mentioned", messages like "Password rest instructions are sent to your mail address <[email protected]>". Not only does it confirm that the email address right, but also the user can copy the mail address displayed for future use. Another case is the attacker enters invalid email address, the system displays a message
"There is no record of the email address", which confirms to the attacker that its not valid mail address and the attacker can try another mail address.

In case the authentication system has a mechanism such that after 3-5 times the account is locked, the attacker and enter wrong password 3-5 times and get the account locked which is a denial of service attack.
Now the email address is correct, the attacker can use the mail address and subscribe to any kind of information with this address, flooding the email address. How many web-site subscriptions can the email account holder block? Ultimately the account holder has to delete his address and create new one.
The attacker can also trick the account holder to download malicious software like a spy ware, malware, or send a link to an infected website, get the contacts of the account holder and send the malicious link to the contacts.
Hidden input fields another bad practiceís is to use hidden input fields in a web page.
Refer to this web site why hidden fields should not be used
http://advosys.ca/pa...ity.html#hidden

Traffic monitoring

Web site usually user get and post methods to communicate with the server. Tools like tamperie, webscrab can be used to not only view, but also modify the data sent to the server. For example user log in, or price of a product etc. If authentication information like password is sent without encryption, passwords can be stolen without any effort.

Brute Force

Brute force attack is a type of attack in which the various string combinations for user name and password are repeatedly entered in the user name and password field until a correct combination clicks and the attacker is able to log-in. This attack is permutation and combination type of attack in which various permutation and combinations of keys are used. The time and resources required to crack the password depends on the length key used to encrypt the passwords, usually exponential. This is usually automated attack; no one sits at the terminal and keeps banging the keyboard till the password is cracked, usually a small script is written which generates combinations of strings. Before launching the attack the basic application is analyzed for the minimum and maximum number of characters for user name and password.
Refer this link from
http://en.wikipedia....oretical_limits
Interesting read about brute force attack
http://searchsecurit...-force-cracking

Prevent

To prevent this from happening first step is to limit the number of attempts for unsuccessful log-ins. For safety reasons keep the number to three. After three attempts lock the account for 24 hours. Using captcha to make sure that itís a human and not a script is good idea, but OCR it can be circumvented.
http://en.wikipedia.org/wiki/CAPTCHA
Simple way is to display confusing message such as "either user name or password is wrong" and locking the account after 3 unsuccessful attempts. When the user has to unlock his account an email can be sent to alternative email, and that email should not be displayed, because the real user would know the alternative email address, again this is just an assumption.

Cross Site Scripting

A clear picture of cross site scripting can be found on wikipeida.
http://en.wikipedia....-site_scripting
The above extract is from the document which is not complete yet. Still working on it, once its done will update the content.
For example there is a message board/forum where users can exchange solutions for problems. An attacker can insert a script in response to a post and save the post. Next time another user visits that post the browser executes that script while it renders the page. Depending on the nature of the script inserted the script can read sensitive information stored by browser like cookies, session information or even rewrite the contents of html page.

Some examples can be found here.

https://www.owasp.or...pting_%28XSS%29
Cross site scripting can be avoided by properly sanitizing the user input and proper escaping i.e. proper output encoding by the programmer.
URL Manipulation Attack
This article should be an eye opener
http://news.softpedi...ckers-Used-URL-
Manipulation-to-Extract-Data-206356.shtml
URL manipulation or parameter manipulation is very simple and yet very effective way.
The URL consists of parameters (http://en.kioskea.net/contents/attaques/manipulation-url.php3), and modifying certain parameters an attacker can access pages to which the attacker does not have access. The attacker can use trail and error method and succeed. This method can be used for traversing the directories too. The above mentioned URL has the examples which can give a better understanding.

0 Comments On This Entry

 

October 2017

S M T W T F S
1234567
891011121314
151617 18 192021
22232425262728
293031    

0 user(s) viewing

0 Guests
0 member(s)
0 anonymous member(s)

Recent Entries

Search My Blog