Tag Archives: security testing

Testing cyberspace threats

Posted on by
330

This post was originaly posted by me on blog.sogeti.com

At the time of writing, a two-day international conference is underway in London UK, focused on the threat from cyber-security attacks. It’s true that cyber-security is a threat to the whole online community. We’ve seen a lot of hacks from groups like Anonymous Hackers. These hacks can be used for malevolent purposes, but also maybe for good – like in this video:

The Anonymous Hacker Group threatens Mexico’s Zetas Drug Cartel to release information on their members. I don’t agree on the things Anonymous does, but I certainly don’t agree with drug cartels. But let’s think of this. The drug cartel is holding an Anonymous member hostage and as a response Anonymous threatens to release personal data on the Zetas Drug Cartel. The result will be that the identity of the cartel members will be made public, so everybody will know who they are. It seems it’ll solve a problem that intelligence agencies cannot solve.

But there’s maybe one question. Who checks the data? Anonymous? What if the data is incorrect? Innocent people will be associated with the drug cartel. And what if an Anonymous member has a grudge against someone like you or me?

But hacker groups like these are not the main threat for most companies. Hacker groups can help companies by showing them the flaws in their systems – and when these companies don’t listen, the hackers try and break in – to prove the point. The bigger problems are the sub groups surrounding these hacker groups. Intelligence is often shared with these groups who have a different (and less well meaning) motivation. They try and break into systems whether on your mobile, your tablet, your laptop, your server or even your data centre. Their objective is to make life miserable for you because they just want to have fun.

In my personal opinion, it’s almost impossible to defend against a group like Anonymous Hackers; if they want to break in, they can and they will. This is the same for your house or office. If a real burglar wants to break in, he/she will. But there are also ‘wannabe’ burglars and ‘wannabe’ hackers. They know only a little but they use this knowledge for their own advantage. But you can keep these ‘wannabes’ out – out of you home/office and out of your systems. But how?

Well there are many ways to keep them out, but before you keep them out, you need to know what to protect. Just a lock on the door isn’t enough. That’s why you need to know how secure your application is. Or how safe it should be. Security should be an essential part of the quality of a business process and should therefore be part of all applications developed. So you need to have insight in the security of applications, and this can be done by testing the security.

In the development and maintenance of applications, security should be an essential part of requirements, design and development. And to demonstrate that applications are safe, security should be tested for. Why?

  • Users expect good quality and have the confidence that the application is safe. When no insight into the security risks exists it’s not possible to tell this to the users.
  • From legislation and rules like Privacy Acts, PCI-DSS, SAS70 or SOx, it’s a requirement that security is in order. The proof for this can be found by executing tests.
  • Sometimes it’s necessary to demonstrate that the application is sufficiently safe for various forms of damage. No one wants negative publicity or be confronted with all kinds of claims. Testing shows the status of safety.

Note: Testing provides insight into the quality, but doesn’t improve the application. When bottlenecks are found they are identified and improvements made.

Testing for security risks encompasses many types of tests or reviews including these options:

  • A ‘spotlight security scan’ provides a limited indication of the security of an application. This is a one-or two-day scan on the most critical part of the application, which provides good advice on further steps in application security, particularly to follow-up on any issues uncovered;
  • ‘Functional security testing’ has a strong focus on what the application should not do, and looks at how it might be misused;
  • A ‘code review’, a static security test that looks at the source code. It can be highly effective because it’s done early in the development process, when the application has not been completed (this is the same with Static Analysis). The code review scans the code to show security weaknesses and when done early in the process, creates awareness among the whole project team and stakeholders which can lead to early improvements and major savings for the remainder of the project.
  • A full ‘security assessment’ or penetration testing is a thorough investigation that provides insight into the safety of the application., but also the network activity and the infrastructure.

By gaining more insight into application weaknesses it’s possible to keep the ‘wannabee’ out and create a safer application.

People, the weakness of the EPD (EHR)!

Posted on by
7

Visiting a conference about the Electronic Patient Dossier (EPD) or EHR (Electronic Health Record) gives a good overview of what’s going on in this field where hardware, software, people and processes come together. A lot of vendors are present and a lot of good discussions take place at this conference. It was also quit a modern conference with a kind of a twitter stream via #L2D.

However a lot of security aspects are covered I get a strange feeling during the conference. The question that came up in my mind is: how is the weakest link, the people covered in the security approach we follow at this moment. In this post I’ll explain some weaknesses of the EHR. What can we do as testers to make this weakness visible?

Security aspects of the EPD
The Dutch Electronic Patient Dossier (Electronic Health Record) is intended as a national infrastructure for exchanging medical patient records among authorized parties. The EHR is partially centralized but almost all data is stored locally is the xIS (x Information System) of hospitals and pharmacies. In some countries around us this takes already place.

As you can imagine are there a lot of parties involved in this type of projects. Not only the government but also a lot of software vendors, consultants, and hardware suppliers. The EHR has to address a number of requirements, ranging from scalability and performance to security and privacy etc. With so many parties it’s not easy to have all the responsibilities in place.

During the conference I get a feeling that a lot of security aspects are addressed to the different parties. Using them in practice is the next step, but we’ll see this in the next coming months to years.

The government for example makes the laws and legislations for this, a ministry is involved. One of the  qualifications is the GBZ (Goed Beheerd Zorgsysteem) translated from Dutch stands for well-managed care system. Also are some ISO certificates involved for the hospitals. Information security is addressed to the government.

The infrastructure security is mostly addressed to the parties that maintain the networks, they must deliver the right exchange, manage the connections and deliver a high uptime.

Building save applications is a task of the software vendors. The Secure Development Lifecycle, assessments and penetration tests must be in place there.

People weaknesses above these aspects
What I missed at the conference is the people aspect in this situation. Because if the information security, infrastructure security and the application security are in place but the people are not aware of security of misuse the information, they are in that case the weakest link. People are standing above these three pillars and have influence on all of them.

Here are some possible threats:

  1. People use the UZI pass of each other (UZI pass is personal authentication card to get access to the systems). If people use the cards of each other together with the secret password of somebody else, all information is available for the person that isn’t authorized to see the data. (Remark: this is only the data the owner has access to)
  2. 2. People don’t lock the PC. If people are working behind their desk with patient dossiers, they walk away without locking their PC everybody will have access to the open dossiers at the PC.
  3. 3. Username and password under the keyboard. How often does this happen? Post-its under the keyboard with the username and password written on it? Keyboards, agenda’s and sometimes the monitor are the places to search for usernames and passwords.
  4. 4. Use an MP3 CD to avoid the Windows lock. A friend of mine works in a hospital in the Netherlands. To avoid the Windows lock of the PC they put a MP3 CD, in the drive and play the whole day music with the sound of. The effect of this is that the PC doesn’t lock. PC’s unattended of medical personnel can be used by everyone. The local dossiers are all available. What if you just saw a celebrity walking in the corridor? Just open her dossiers to see what’s wrong?
  5. 5. Printed dossiers at the desk of the employees, or what my neighbor told me a bunch of dossiers on the lap of patient in wheelchairs that is moved from A to B. Open and visible for everyone, We can do our best but they pass all security, firewalls and an authentication cards.
  6. 6. Duplicate authentication passes, according to the formal process is this not possible, but my sources told me there are a lot of them in hospitals for example.

The role of testers in these weaknesses
As you can imagine it’s hard to test these vulnerabilities. Information security can be assessed with for example a security audit at the processes. The infrastructure can be tested with a penetration test and the application with an application security assessment. But the people aspect, the weakest link with those vulnerabilities cannot be tested in one of these types of tests.

Secondly all these issues occur after go live, how often are you still involved at that moment? Most of the testers act in earlier phases.

However, with the awareness in mind, with knowledge from earlier projects you can address some of these things during reviews of designs, processes or during the test phase.

The role of organizations and the government
Organizations, like hospitals and pharmacies, who use this type of software, have in my opinion the responsibility to make people aware of these vulnerabilities. Once I saw a campaign to make people aware of the value of passwords. A big picture of a piece of underwear with the text: “A password is like underwear, you don’t share them”.

The safety of the systems can be pushed from this side. Logging all the request and taking some samples of this data base to check of only people that are involved in a certain process can check this. This way can make it a little bit “Celebrity checking proof”.

The government has in my humble opinion besides a monitor function also the responsibility to make all parties that are involved aware of this aspect. Via standards like ISO and HL7, IHE can they motivate companies.

Because as long as human beings are involved in the process and they use of software they will always be the weakest link of the security spectrum. You can test what you want, 100% secure doesn’t exist.

Please let me know, what is your opinion about this topic? How can we make big projects like the electronic health record secure, if we talk about the people aspect?

20 ways to test the login function

Posted on by
18

Last week I`ve visit 4 different customers, a telecom operator, a insurance company, a government department and a IT-company. With all these customers we had a discussion about security testing. At this moment these organizations don’t test application security enough.

In each of these conversations I explained how a functional tester can test the login function of an application and how a security (minded) tester would do that. Between these two there is a difference. Functional tester will stop after 4 or 5 test cases. A security tester will execute at least 19 or more test cases, with a totally different point of view.

This post describes a couple of these test cases. If you have more of them please let me know so I can add them to the post. If you are a (functional) tester you can use these examples during your test execution.

1) Correct combination of username and password
The most basic test is a correct combination of username and password, everybody knows the expected result. But once it will happen that even a good combination doesn’t work. Possibly caused by a miss configuration of the application.

2) Incorrect combination of username en password
For example a correct username and a wrong password. Or use a password that exists in the database but is linked to another user. If the combination is wrong, most of the times you don’t have access to the application behind the login function/page and you get an error message.

3) Correct username and empty password
Most of the applications are coded in a way that you don’t have access to the application with this test case. But in some situations “something unexpected went wrong please check the error log”

4) Correct password and empty username
In this case you could expect the same result as in the test case before. And this is true most the time and where a lot of (functional) testers will stop. Because the application fulfills the expectations that are given by the functional design and/or requirements. But there is much more. There are more risks and more opportunities to enter the application; even without logging in.

5) Check the meaning and information in the error
Information and information leakage is food for hackers. Specific error and stack traces are full of information that can be misused by hacker. There are three possibilities of errors that can occur if you have an incorrect login.

  • Incorrect combination of username and password
  • Incorrect username
  • Incorrect password

Only the first one is correct. The second and third are useful from the usability perspective but gives an evil one too much information. Because if you get the message password is incorrect you know already half the access code.

8 ) Correct login, logout and go back with the browser button
If a session isn’t closed at the servers end and you go back with the <BACK> browser button, sometimes you can go on with the session you created earlier in the process. This means the logout function isn’t functioning correctly. What can happen?

For example in an internet café: if people start directly after somebody is ready and they go back they can access your personal data. Think about email functions that are on social network sites. If they change your password in a password you don’t know they can do what ever they want. They can see which registration emails from other companies thyere are in your inbox and ask for a new password

Tip: if you’re using internet at a public computer be sure what you’re doing and always close the browser after surfing on the internet.

9) Go directly to a page without use of the login function
Maybe this test case is a little bit strange but it will work many times. What to do: Login with a correct combination of username and password. Go to a specific page behind the login functions that requires the login. Copy and paste the URL and logout. Now you start the test and you paste the address in the URL field (without using the login page). If you go directly to this page without logging in, the owner of the application has a big problem and also all the users that have an account. Everybody that knows the direct URL can have access.

10) Check the sustainability of the session
What time is needed to do business in an online shop? 2 hours without any actions at a site? 2 days? 2 months? I know some webmail clients whereby the session is valid for many years. This is not an issue people can misuse directly, but in combination with other vulnerabilities they can misuse it easily. Therefore log in with a valid account, go away drink a coffee, a beer and have a sleep. If you come back and the session is still valid (when you can use it without a new login) you have an issue!

Tip: In my opinion  more than 20 minutes without any actions at a specific site should lead to a new session.
<added later: this 20 minutes is based on experience. For a better theory see the comment below of Danil>

11) Check if the login function is already HTTPS
The ‘S’ from HTTPS stands for Secure. This means the message is encrypted during transport. If the login page is HTTP and the conversation after login is HTTPS the first step is unsecure. Because the message is in plain text the first request to the server.

The login page (before you fill the fields with your credentials) must be HTTPS.

12) Change the ID into an ID of another account
If you’re browsing through an application and you see in the header or in the URL an ID that is directly related to your bank ID, personal ID username or anything else, try to change is in someone else. This is also possible a lot. A couple of months back a colleague of mine tested a banking application where this happened. If he wanted he could use every account that client had for transferring money and much more. To test this login a couple of times and check of if the ID is static (each time the same) if this happens you can try this test case and maybe it works fine (thus wrong)!

13) Copy the ID and past this in another browser
If you can go on with the session in a new browser you have also a big problem. People that steal you session can go on with this doing a lot of things you don’t like. With another browser I mean really on another browser and not only on other tab in your current browser. The best way to test this is sending it to another computer and go on with this session (don’t shut down the session in the first browser before the second one is open).

14) Delete the ID and continue browsing
Does they ID in the cookie or URL really has value in the conversation between your client and the server? Delete step by step all ID`s and continue browsing. Check which ID has really value. Hopefully this is not you account number of banking number. Because if this is true you can execute another test, changing the number.

15) Check the possibility of SQL-Injection
Sometimes everything works fine and all requirements are in place. But what is SQL-injection is possible and you can enter the application using a statement to login? Try in the application under test a single quote or 1’ or ‘1’=’1. If this becomes code instead of simple data at the background and the database execute this it happen sometimes you can login in. There are a lot more SQL-Injection possibilities. Search at the web for more differences.

16) Multiple times incorrect password
Locking accounts after 3 or 10 times a incorrect combination isn`t true or false. What more important is, is the requirement described in the functional or technical design? Because the choice of an account lock after 3 incorrect attempts isn`t true or false. But you have to know the consequences.

An application where a lock of account doesn’t occur  is capable for a brute force attack. This is an attack where hackers try to guess your username or password. They use a tool that systematically try all options.

In case an account lock another problem  occurs. This is a lockout. If a account isn`t available after three times a incorrect login you can`t use it anymore until you call the helpdesk, or start the procedure to get a new password. With this lockout you can make complete companies unavailable.

Locking account or not isn`t true or false but make the choice between them bases on the risk and mitigation you can take.

18) Login in two different browsers with the same account
Have you ever tried this in your application under test? Sometimes it happens that the conversation with the first one is broken, ore that action executed in the first are displayed in the second. This means most of the time you have one session (the same) at the server instead of two. Because you set up to different connections.
Most of the time does this mean that the procedure to set up a connection doesn’t work correct.

These twenty test cases mostly can`t derived from the documentation or other oracles. Therefore knowledge and skills are important  to execute these test cases.
Requirements around these actions aren`t either in the documentation, therefore using formal test design techniques isn`t enough. You need also some creativity to explore the application.

If you have more test cases to test the login function let me know.

<added later>Oops while I’m numbering only get to 18, but 20 sounds better

worth reading in the context of this post is,  Test Ideas for login screens & Login Session by Santhos Tuppad