First Steps In Security Testing

For about couple of months I've been interested in security and penetration testing. In my opinion, it's the most difficult area in testing at all, because it's the most technical one. The main challenge is to understand all processes, all data flows and all technologies, that are used in application. If you are in developing team, then it's a little bit easier – you can ask (or see, if you have admin privileges) some things, but it's still quite difficult to see and understand the whole picture of all processes.

Second challenge is motivation. Security bugs are not common ones, so you can spent a lot of time and effort (especially if you are a newer in this area) before you find some serious bug. As all bugs – not all security bugs are worth to fix. For example, if you can inject some SQL in admin component, which is being used only by one admin user, then probably project team doesn't want to spent time and money for fixing that (admin user can corrupt application and data anyway, event without SQL).
As a tester I am getting excited when I find bugs, not when I can see that application is pretty good. So for me browsing the application for 2 hours and not finding anything is quite boring. Which is bad for the project, I know, but I guess this is where the difference between tester and QA is.

The barrier to entry into security testing is quite high, however, the excitement of finding the security bug is also high. In my opinion, security bugs are the most important ones: better not to ship fully functioning but insecure software (especially if you have some payment system – even small possibility to loose money during transactions can be worse than delaying production).

And by security bugs I mean all bugs that violate one of the 3 characteristics:

• availability – does somebody using this bug can disable some services?
• integrity – does somebody can corrupt some part of the application?
• confidentiality – does somebody can get access to information which he doesn't suppose to get?

So I decided to write some steps, which every tester can perform to check basic security level of you application.

1. URL parameters
Study URLs of your application. URL with parameters looks like this: https://www.somedomain.com?lang=en&accId=10054366&name=irinaivanova, where lang, accId and name are parameters and en, 10054366 and irinaivanova are values.

Basically, three cases are possible here:

• URL contain some sensitive data, that can be stolen by third party. By sensitive data I mean password, legal code, telephone number. In our example, I would say that name=irinaivanova is sensitive data.
• You can modify values of parameters in URL to access some third party data. For example, if you have log in system and you give id of account or user in URL, then you can try to change that id for random number – likely you will get the access to other account without any password (and get his privileges). In out example we have parameter accId=10054366, which stands for account id. You can see what happens if you change the value: accId=1, accId=0, accId=10054365 etc (bonus tip: admin account with all privileges will likely have id 1, -1, 0 or 10000000, where number of zeros can be taken from your account id).
• You give info that is actually unnecessary. For example, such value as name you can take from database through account id. URL is not good place for spare info.

2. ID smart card authentication
In Estonia ID smart card authentication is very popular. If your application use this authentication you should test at least one case: log in with your ID card -> log out -> try to log in again in the same tab. I can bet that your application allows you to log in for second time and doesn't even ask the PIN code. This is actually browser plugin bug, not your application's, but it is possible to block second logging in without PIN code (for example, try to do same case in some internet bank page – you can't because they block second logging in in the same tab).

3. Cookies
If your application use cookies – you should test them.
Good article about cookies with simple test cases – Website Cookie Testing, Test cases for testing web application cookies?.

4. JavaScript injections
The simplest JavaScript injection is <script>alert('Vulnerability!');</script>. If you insert this script into field and process the form – you will get a dialog window with 'Vulnerability!' text in it, if your application has JavaScript vulnerability. Tip: it is more likely to execute JavaScript if you can save data in you application. For example, if you have field for name and can see this name in view mode, then try to insert script instead of name.
If you can execute such simple script that means that a bad guy can execute some more serious and harmful stuff.

5. SQL injections
Good article about SQL injections with examples – SQL Injection – How to Test Web Applications against SQL Injection Attacks.

6. Source code
Study source code in browser (mouse right click – View page source). Even if you can't understand the code you can note sensitive data, if there is one. For example, in the browser source code you can see JavaScript content, so your application should not contain data that you don't want to share in JavaScript variables.

Bonus: WTF character
There is such character as right-to-left mark. If you insert that then your further inserted text will be reversed right-to-left (it is used in Arabic languages). Beauty of this character is in his possibility to reverse the whole content of you page. For example, if users can insert comments on you page and somebody will insert this character, the whole you page will be mirrored and if you haven't heard about this character you will never know why! And it's really hard to find it in you database (to remove harmful comment).
I've already wrote post about it – WTF is this Character?



These are only first the easiest steps in security testing. I assume, that many testers have already heard about them, so I hope to write some more interesting and complex stuff as soon as I get smarter at this.

Some Random Facts About Passwords

In this post I've collected some facts and interesting resources about passwords.

1. https://howsecureismypassword.net - site that shows how long it would take a desktop PC to crack your password.

2. Can You Trust Your Browser With Your Passwords? - good article where author analyses how most popular browsers work with saved passwords. The most secure is FireFox, then Internet Explorer and the least secure is Chrome.

3. Password use by user type:

Password Authentication from a Human Factors Perspective: Results of a Survey among End-Users
4. How I bypassed 2-Factor-Authentication on Google, Facebook, Yahoo, LinkedIn, and many others. - in this post Shubham Shah describes how he managed to bypass it.
As for me, I tried to use 2FA system, but it was too inconvenient for me: if cookies are disabled or are deleted after closing the browser then you can't save the safe device, so every time you should get secret codes to mobile phone. I decided that this complexity is not worth it.

5. Is Pavlovian Password Management The Answer? - Lance James suggests a very simple and genius idea about protecting the passwords: the expiration of password should depend on its complexity. For example, if user creates a password that can be cracked in 3 days, the password should expire in 2 days. So if user doesn't want to change it too often he have to chose a complex one. And the whole beauty of this system is that it doesn't limit users, but trains them.

6. Google Glass Snoopers Can Steal Your Passcode With a Glance - how passwords (especially PIN codes) can be stolen offline using video cameras. The most shocking fact for me was that "a $700 Panasonic camcorder’s optical zoom was able to catch a PIN typed on a glare-obscured screen from 44 meters away".

7. Mikko Hyppönen and Sean Sullivan (from F-Secure) are talking about strong passwords:


8. Good TED talk about how users choose their passwords and what web site owners can do with it:

Bug As Art

Interesting article about how bugs can be beautiful: Bugs are Beautiful: Apple Maps’ Unintentional Art by Mike Brown.

Some iOS Maps glitches: http://www.flickr.com/photos/pedernorrby/sets/72157632277119513
Google Earth glitches: http://www.postcards-from-google-earth.com
The Sims glitches (likely black humor): http://www.tumblr.com/tagged/sims%20glitches

How To Do Convinient Mobile App

Some interresting raw facts from article How Do Users Really Hold Mobile Devices? by Steven Hoober about using mobile devices.
Most of apps, that I am using on my Android phone does not take into account fact, that red areas exist.

How people hold and interact with mobile phones:


Two methods of holding a touchscreen phone with one hand:


The two methods of cradling a mobile phone:


Two-handed use when holding a phone vertically or horizontally:


Surely there is more interesting and useful information in the article, so I advice to read it as well, not only to look pictures.

The Pareto Principle

I can't tell that it is very useful principle, but it nice to know:
Roughly 80% of the effects come from 20% of the causes

In testing it usually means that 20% of the bugs cause 80% of the crashes. In my practice it actually works.

Good more detailed article: Understanding the Pareto Principle (The 80/20 Rule). Surely read the last paragraph "Concluding Thoughts". The important thing in this principle - it is an observation, not a law of nature.

Memory Issue On Mars

Photo by ASA/JPL-Caltech/MSSS

A computer glitch on NASA's Mars rover Curiosity has forced the robot to switch to a backup computer while engineers try to resolve the problem. In the meantime, Curiosity's science work is on hold, and the spacecraft is in a minimal-activity state known as "safe mode" while its backup computer is updated with the command codes and parameters it needs to take over the rover's full operations. "We're still early on in the process," said Richard Cook, Curiosity project manager at NASA's Jet Propulsion Laboratory in Pasadena, Calif. "We have probably several days, maybe a week of activities to get everything back and reconfigured."

About reasons:

The computer problem is related to a glitch in flash memory on the A-side computer caused by corrupted memory files, Cook said. Scientists are still looking into the root cause the corrupted memory, but it's possible the memory files were damaged by high-energy space particles called cosmic rays, which are always a danger beyond the protective atmosphere of Earth.

The source: NASA's Mars Rover Curiosity in Safe Mode After Computer Glitch

UPD

"I don't expect there to be any long-term impact," project manager Richard Cook told Reuters. But "it's probably too early to tell." The $2.5 billion robotic geology station was in the middle of analyzing its first samples drilled out from the interior of a rock when its primary computer developed a problem on Wednesday.

Article: Computer glitch suspends NASA Mars rover operation

UPD2
Fixed:

PASADENA, Calif. - NASA's Mars rover Curiosity has transitioned from precautionary "safe mode" to active status on the path of recovery from a memory glitch last week. Resumption of full operations is anticipated by next week.

Article: Curiosity Rover's Recovery on Track

How To Crack 4-Digits PIN On Android With Frost

Tilo Müuller and Michael Spreitzenbarth did a very interresting research at Erlangen University in Germany: they unlocked a mobile phone using so called cold boot attack. The most important part, on what is based the research, is that RAM contents fade away more slowly if RAM chips are cold.

In this paper, we aim at recovering valuable information from encrypted smartphones. Roughly speaking, we analyze the characteristics of the remanence eff ect on smartphones, prove that Android's boot sequence enable us to perform cold boot attacks, and show that valuable information can be retrieved from RAM. To this end, we present our recovery tool Frost (Forensic Recovery of Scrambled Telephones). Frost can be loaded to a smartphone after we got physical access to it, and without the need to have user privileges on it. We carry out our experiments exemplarily for Galaxy Nexus devices.

Detailed research description with pictures: FROST: Forensic Recovery Of Scrambled Telephones
Technical report: Forensic Recovery of Scrambled Telephones
Easy readable article in Forbes: "Frost" Attack Unlocks Android Phones' Data By Chilling Their Memory In A Freezer


Cracked 4-digit PIN

How ATM Were Hacked

Some stories about hacking the ATM.

In Lithuanian town Šiauliai students cheated the Swedbank ATM in quite easy way. They inserted their own cards into ATM, entered the sum which was available for those accounts, but when the ATM gave the cash they took only 1 note from the middle of the pack. The ATM thought that cash wasn't taken so it took them back and didn't decrease the account total sum. In that way student stoled about 13000 EUR.
Unfortunately the end of the story is not so wise. When the bank suspected the fraud they closed the account. Naive students went to the bank telling that they lost their cards, where they were arrested.

The source is article (in Russian, 18.03.2004) in Baltic internet portal. In the article comments is written that same system was actually applied earlier in Finland. And that this trick you can do only on the old models, the new ones decrease total sum anyway and the "forgotten" cash is going to the special compartment. Later workers count these "forgotten cash" and verify the info. If it match - then they increase the sum.

In the same comments is written one more interesting detail: if you request sum which is 10 times larger than you have in you account, then ATM is giving you cash sum which it has. In way like "ATM has only 10000 EUR".


And the newer one story about hacking the ATM in Estonia.
The left one is correct and the right one is with hacking devices on it:


Above the screen there is a camera which simply records the PIN code:


In the card reader area is an additional card reader, which copies some info from inserted card magnetic tape:


Later cheater copied info from the inserted card to the blank card and simply used the fake card and PIN code to take cash from random ATM.
Source articles (in Estonian): Postimees, Delfi.

Exuses vs Reasons in Software Testing

Interesting article 8 Common Excuses in Software Testing by Mike Brown, who blames testers for did not found bugs. In comments you can find another article Why would I need excuses? by Tony Bruce, who said that testers don't need excuses for missed bugs, they have reasons.

Of course both of them are right: the first one is talking about lazy testers and the second one - about I-will-do-my-best testers. But I think that actually there is point to decide should you blame yourself for missed bugs or not. And the answers depends on personal nature - does blaming helps you to be more attentive next time? If does - so let it be excuses.

As for me, excuses are more productive than reasons: I'll better believe in that I am capable to do better testing, than that I did my best and there are missed bugs in the result. So if you consider for example lack of time for regression testing as excuse, you will try to use your time more productively.

The Sience Of Debugging by Matt Telles and Yuan Hsieh

I strongly recommend to read this book - The Science Of Debugging by Matt Telles and Yuan Hsieh. I really like how and what authors are writing about bugs. Especially I liked the Chapter 2: Case Studies of Famous (and Not So Famous) Bugs with summaries and points what we should learn from the others' mistakes. Don't be confused with the "debugging" word in the title - book is also interesting and useful for the testers who just find the bugs, not reduce them.

Also I recommend to read a short article History's Worst Software Bugs by Simson Garfinkel, which shortly describes some of the cases.