Heartbleed Bug: All you need to know Huma Hamid12:20 AM 1 comments

This was my fourth guest post here for the Knowledge Tester's blog. It was written in response to a well known security bug Heartbleed found in the OpenSSL. This post was also placed among the five best blogs on 5Blogs. It was published on April 21, 2014. Here is a copy of  the full post from Knowledge Tester's site.

(This is a post by Huma *)

Many of you have already heard about the Heartbleed bug, but like many others into testing, this news seized my attention and I wanted to talk about it. This bug has not only questioned our assumptions about a secure Internet, but also put the chaotic nature of the Internet under the magnifying glass. Almost every one of us uses Internet for services like emails, instant messaging, banking, shopping or social media and Heartbleed bug has impacted many of the widely used websites. Here is a little overview of that ugly vulnerability which has been recently discovered in the OpenSSL library, how to find out if you are impacted, a possible cure and what lessons can we learn from this bug?

What is SSL?
The Secure Sockets Layer (SSL) is a commonly used protocol for managing the security of a message transmission on the Internet. It ensures privacy between communicating applications and their users on the Internet through the use of cryptography and encryption. SSL has recently been succeeded by Transport Layer Security (TLS), which is based on SSL. TLS and SSL are an integral part of most Web browsers (clients) and Web servers.

What is OpenSSL?
OpenSSL is an open-source implementation of the SSL and TLS protocols. It is a toolkit implementing the basic cryptographic and utility functions, written in C programming language. Being an open-source project, it is managed by a worldwide community of volunteers. This is responsible for putting the S in HTTPS (formally HTTP). Some of the popular companies, which use OpenSSL, are Google, Yahoo, Instagram, GoDaddy, Etsy, Pintrest, Flicker, Netflix, YouTube, Dropbox, GitHub and Wikipedia.

What is the Heartbleed Bug?
The Heartbleed bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This bug allows stealing the information protected, under normal conditions, by the SSL/TLS encryption, according to heartbleed.com. Google’s security team and Codenomicon (a software security firm) discovered this bug independently. It is said that Google’s security team found the bug while auditing for the third-party applications being used by the Google, and Codenomicon unrevealed it while attacking their own website with an exploit code to uncover any security vulnerabilities in case of a hacking attempt. Both companies found that a little glitch in the OpenSSL implementation made it possible to access secure data existing on a web-server using OpenSSL, which includes critical information like usernames, passwords, encryption keys and certificates. According to Security Intelligence Blog, when exploited on a vulnerable server, it can allow an attacker to read a portion — up to 64 KB worth— of the computer’s memory at a time, without leaving any traces. A large number of websites were reported to be affected by the Heartbleed bug. Among these, there were big and popular names like Google, Twitter, Flicker, GoDaddy, Netflix and Instagram. Many of these websites are now patched. Mobile applications using OpenSSL are also affected. CVE-2014-0160 is the official reference to this bug.

How the Heartbleed Bug Works?
What is said to be a programming mistake and not a design flaw was introduced in February 2012 through Heartbeat Extension (RFC6520 standard) for the TLS and Datagram Transport Layer security (DTLS) protocols. This also explains the name Heartbleed, a bug which is result of the Heartbeat extension and bleeding out important information from the memory. The mentioned bug affects OpenSSL version 1.0.1 and 1.0.2-beta releases. Technically talking, TLS heartbeats are actually the “keep alive” packets between communicating parties to keep the session open even when they don’t have any official data to exchange. Both sender and receiver share heartbeats, which consist of a reply and a matching response. In the Heartbleed bug, while sending a request, a sender is able to not only send valid data (later used to confirm the response) but also requests extra information to be sent as part of the response. In response, a Heartbleed affected server not only sent the matching response shared earlier by the sender, but also runs off the end of its data and scoops up whatever else is next to it in memory and could fit in the response message, without ensuring if sender is authorized to see that data or not. This data leakage may include information like user credentials, credit card information, confidential documents, session keys, encryption keys and much more. You can read more about the code for request and response messages looks like here. The simplest explanation of the Hearbleed bug is presented by a web comic at http://xkcd.com/.

How to check for the Heartbleed bug?
There is already a patch out, which has fixed this bug. Most websites have already upgraded to the latest patch. Administrators of the impacted web-servers also need to upgrade to the latest fixed patch. There are following ways, which can help users to find if a web site is still vulnerable to the Heartbleed bug or not.

Chromebleed – A Google Chrome’s add-in originally developed by Jamie Hoyle that uses a web service created by Filippo Valsorda to checks if the URL of the page you have just loaded is affected by Heartbleed. If Heartbleed vulnerability is found then a Chrome notification is displayed to the user.

FoxBleed – A Firefox add-on, developed by Fabian Bräunlein, which can help a user identify all vulnerable websites he is visiting and notify whether they are affected by the Heartbleed vulnerability.

Heartbleed Security Scanner (Mobile) – A security scanner for Android devices, which helps detect whether a device is affected by the Heartbleed bug in OpenSSL and whether the vulnerable behavior is enabled. It is developed by Lookout, a mobile security company.

Heartbleed Cure?
So far, the best you could do as a user of any impacted website, is to check if the website got affected or not. Let your service provider know about possible vulnerability and ask them to upgrade to the latest code patch. Once, they upgrade, go ahead and change your user credentials.

I tried this for the following and here are two different results that you may get:

http://www.khaadionline.com

https://www.labelstore.com

Lesson Learned
In the Heartbleed bug, there are many lessons to be learnt. From development and testing point of view, the biggest lesson learnt is “never let your guard down against the data you are receiving”. Also, “always double-check the inputs before giving it control of your application”, and “always look for data leakage bugs and never ignore buffer overflows”. A while back, I shared a post on Data Tampering, where I discussed the way user inputs can be tampered to test the vulnerabilities associated with invalid input data. Also, the bug raised questions about the credibility of open source tools. The open source applications have made great contributions for the software community, however there is a need to put in place more reliable practices of software development to avoid such bugs making their way to the released code. It is very important to review the ways in which the open source code is developed, tested and maintained before publishing to be used by the public. It also requires better and more effective processes to be followed by the companies using the open source code, by conducting frequent code reviews to uncover such vulnerabilities before they hurt. We may not be able to fully eliminate the bugs, but we can at least try to minimize their chances of being uncaught.

What are your thoughts on the lessons learned?

* Huma Hamid has been a regular contributor to KnowledgeTester.org, so I am taking the word ‘guest’ out of this post. Her previous thoughts were about Good Testers, Data Tempering andWasted time. She not only has an excellent systems view of the things but also digs into details when needed. Thanks for your thoughts Huma and I hope that Knowledge Testers would like this post.

Read More

Good Testers Revisited! Huma Hamid12:07 AM 0 comments

This was my third guest post here for the Knowledge Tester's blog. This post was better planned the first two here and here. For quite sometime, this post remained among the top five most visited posts. It was published on March 14, 2014. Here is a copy of  the full post from Knowledge Tester's site.

(This is a guest post by Huma*)

Good testers are not easy to find!

Good testers not only know the art of testing, but also offer great versatility and wide range of skills in getting the software testing job done, effectively. Different projects offer different set of challenges, and good testers are those who respond to each challenge and help their project teams build a better software by being creative, smart and through in their approach. Following are some of the strategies used by testers, which make them good for themselves and for their teams.

(designed using http://www.keepcalm-o-matic.co.uk/ )

Preventive, Not Just Defensive

Do testers “only” find bugs or break software? Probably not, as good testers do not limit their talents just to that, but also contribute towards building a better software. Good testers are not just defensive, they are also preventive in their approach. They constantly look for potential areas of risk, vulnerabilities and user unfriendliness and help their teams identity and avoid such issues during early stages of software development. This helps in saving cost of fixing a bug late in a project.

Explorer, Not Just Verifier

Should testers only focus on verifying functional requirements? For projects with half-known and ever changing requirements, only focusing on the written requirements is to inherit the ambiguity and incompleteness of those requirements. Good testers not only make sure that written functional requirements are fully and correctly implemented, but they are also curious and creative enough to explore and hit the corner cases. Using less common test scenarios, different set of test environments and unusual test dataset are a few possible ways, which can be helpful in early detection of bugs.

Spontaneous, Not Just Pre-Scripted

Is sole creative work of a tester limited to write long and run pre-scripted test plans? No, good testers should be able to write short, focused and easy to execute test plans, offering enough flexibility to respond to constantly changing requirements of a product. Good testers are spontaneous and smart to learn, write and execute tests on-fly and do not always rely on pre-scripted test plans to guide their work. Issues with lengthy and pre-scripted test plans have been highlighted by many leading figures of the software test industry. Such test plans eventually lose value as they become boring due to repeatedness, stale due to changes in the product and take too long to run, thus lacking focus on a particular area for testing and finding bugs. For good testers, tests which require repetition of steps and manual work, automation is probably the best bet!

Automation, To Compliment Manual

Good testers can chose wisely between manual and automated tests, and they know how and when to use both and complement each other for better test coverage. If a product is constantly changing or too complex to automate, good testers prefer doing it manually. If not, they give the repeated and tedious job of running regressions tests to test tools. It helps them save time and resources, which they use to develop robust test tools for efficient and effective regression testing.

Diligent, Not Idle

To be idle is a short road to death, and to be diligent is a way of life! [Buddha]

Good testers do not sit idle and wait for a product to finish, but work diligently with their fellow developers(aka programmers) during all phases of a software development life cycle. They do so by providing constructive feedback during early phases of a product design through reviews. They run testing scenarios which can help them identify bugs, write automated test scripts to be run on nightly builds, or develop smart test tools for regression testing.

Try New, Not Just the Same Old

One test strategy doesn’t fit all types of projects. The most exciting part of a tester’s job is to try a fresh and effective test strategy each time, which fulfills a project’s specific demands. Good testers are open to ideas and willing to try new things which can help them do better at their jobs.

Use Both, Numbers and Instincts

Good testers use both their gut feeling and numbers to make better test strategies. They run meaningful reports to know more about trends for test results, bugs (reported, resolved or outstanding), areas with least or most impact and risks associated, and so on. Good numbers, combined with testers’ instincts help them act promptly and give attention where it is needed.

What do you think makes a good tester?

* Huma is one of the good testers I know and has been a regular contributor to Knowledge Tester. Her previous guest posts were about Data Tempering and Wasted time in testing. She is no strangers to the readers, so I don’t think I need long introductions. Thanks Huma for a great post and keep sending them and hope that readers enjoy it.

Read More

Data Tampering Technique in Software Testing Huma Hamid11:59 PM 1 comments

This was my second guest post here for the Knowledge Tester's blog. It was related to one of the security testing techniques, I was learning. It was published on December 9th, 2013. Here is a copy of  the full post from Knowledge Tester's site.

This is a guest post by Huma *.

Secure web applications are critical in today’s world where everyone has an extensive online presence; thus, it is vital to protect these applications from external threats and malicious attacks. A large number of web applications offer a wide range of services including personal banking, retail and shopping, social media, access to medical services and patient records, social security services and document repositories. Majority of the web applications require some sort of data security, so that unauthorized access to the application and unintended use of the data can be restricted. In such a scenario, security testing of a web application becomes vital as it not only helps in validating an application’s security services but also in identifying potential security flaws. Programmers do their job by writing secure applications, however software testers also need to be well aware and equipped with the tools, which can help them in exposing the security vulnerabilities of  these applications.

(the original photo is here)

Security breach to a web application can be tested in a number of ways, including tampering with data. Data tampering is mostly viewed as a hacking technique, however, it can be equally useful for security testing of a web application. I have found this to be a very useful and interesting technique, so I thought that I should share it with my fellow software test engineers who are not yet aware of the usefulness of this powerful but simple technique.

Since, a large number of online applications use HTTP Protocol for communicating on the web, and parameters can be conveyed as requests (using the GET and POST methods) from a client application to a remote server. Data tampering can reveal the data being sent from a client to a server and from a server to a client; thus, making it possible to manipulate and alter the values entered into the web form, by completely ignoring the restrictions and constraints imposed by a web interface.

In order to manipulate these GET and POST methods, a data-tampering tool would be required which would serve as a proxy, placed between the client and the server. This tool would allow a tester to completely bypass the web interface and send altered values directly to the server side applications. These altered values can mess with the backend application in a number of ways (violating boundary values and character ranges) and can be very helpful in revealing security loopholes in an application’s design.

Data Tampering Examples

As mentioned earlier, a good example for using the data tampering technique could be testing of the boundary values and character ranges for a field given on the web interface. Let’s say that an input field on the web form allows only 1-20 characters for a text field. For an invalid partitioning test, sending 0 and 21 numbers of characters through the web interface would be a good test. But to make sure that it is not just the web interface, which enforces the validation rule, try sending the tampered data directly through the POST parameter. If database or the backend application doesn’t enforce a similar validation rule, you might end up crashing the application.

One of my favorite examples is of an online book selling application where a hacker made money by ordering a negative number of books. The web interface for the bookstore asked its users to select the purchase quantity for the books using  a drop-down list.  A hacker altered the entered value using a data-tampering tool, and entered a quantity of “-1”.  The developer had only enforced the range validation at the web interface level and not at the backend application level. The price for the order was calculated to be –x USD and the hacker actually ended up receiving a refund on his credit card. Imagine the damage that could have been caused if a value other than -1 was entered.

This technique can also be helpful in inserting SQL, XML, or command line injections to test an application’s defense mechanism against malicious data revealing and corruption attacks.

Data Tampering Tools

So far, I know about the following tools that can be helpful in exposing an application’s robustness again data tampering attacks. These are free and easy to use.

Tamper Data

It is a Firefox Add-on, which can be used to view and modify HTTP/HTTPS headers and post parameters.

TamperIE

It is a utility that enables tampering of HTTP requests using an Internet Explorer.

Fiddler

It is a web debugging proxy that enables manipulation and editing of web sessions. It not only permits viewing and alteration of requests but also their responses. It also supports multiple browsers like Internet Explorer, Chrome, Safari and Firefox. It is much more flexible and powerful than the first two and also my personal favorite

Since, possibilities of damaging a web application through data tampering are endless, therefore, it is my recommendation that data tampering techniques should be used by software testers to ensure that their application is resilient to such attacks.  

* Huma Hamid is one of the driving forces behind this blog and it is her second guest post. Where as the first one was related to a discussion on wasting time in testing, this one details a web testing technique. She has an excellent view of the general systems in action and then relates how software testing fits in it. Thanks for your thoughts Huma and I hope that Knowledge Testers would like this post.

Read More

Time Wasted in Testing is Contextual Huma Hamid11:14 PM 0 comments

This was my first guest post here, for the KnowledgeTester blog. It was published on July 4, 2013. I am re-posting it here for keeping a history of my online presence. Here is a copy of  the full post from Knowledge Tester's site.

In a recent blog post by Majd, where he mentioned the time spent on non-testing activities to be time wasted, caused some stir within the blog followers. This lead him to write another post about the same topic, but later post looked at the non-testing activities as “supporting activities”.

After going through his posts and the response he received from the knowledgeable readers, I found this whole discussion very much contextual. I am still wondering if there exists an absolute list of activities, where we can draw a line between valuable or wasted testing activities? In different teams and different test cultures, testing activities are perceived very differently. It heavily depends on the organizational culture, test culture and most importantly it depends on the value a test team adds to the overall product development life cycle.

Having first-hand experience of working with a very fast paced test team (in an Agile based development environment), and later becoming part of a test team following a traditional software development model, heavily dependent on a through test documentation, I strongly feel that the concept of time wasted during testing really depends on the environment in which testing is being done.

In the former case, it seems like that the main focus of a test team essentially revolves around making sure that an application is quickly and smartly tested, activities like creating virtual machines, generating test data, writing and maintaining test plans or even reporting and verifying defects (as Majd has also mentioned) seem to take a heavy toll on the perceived value of testing. In an environment like this, fastest and correct delivery of information and shortest feedback loop plays an important role in a team’s success.  Test teams take a great pride in sharing the numbers like “how quickly their smoke test plan was executed and how briskly a build’s health status report was shared with the stakeholders”. In such a team, the term sooner the better holds a real value. Keeping that in view, the context in which Majd has pointed out the “non-testing” activities could be considered as a time wasted in performing the overall testing job, because it apparently has no perceived value in meeting the “need for speed”.

On the other hand, a traditional and documentation based development environment focuses more on the accuracy, completeness and coverage of the test specification to ensure that the requirements are correctly perceived and met, hence in this context the discussion about non-testing activities takes a completely different meaning. Writing better documents, (sometimes perfect documents) can take a test team’s significant time and effort. It seems like that such a test team is more likely to spend time on the activities like writing and maintaining documents, scheduling document reviews and waiting for moderation and approval. Test build arrival can take months; hence, there is no sense of urgency in terms of updating the stakeholders about a build’s health status, until and unless a complete test round is finished (this also depends on how many testing layers a team has in place to ensure a short feedback loop). The completeness and accuracy of testing is heavily dependent on perfect test documents. In such a scenario, it is impossible not to spend time on writing good documents. Whenever, documentation is by-passed due to short of time, the test team cannot proceed further without a heavy churn and eventually suffers from a sense of guilt for not writing perfect test specifications which could ensure a full and accurate test coverage. So, for such a team documentation might come first and testing comes later. Having said that, this reminds of an experiment conducted at my previous company, where a university research student was conducting an academic experiment on the efficiency of exploratory vs. traditional testing approaches.  Our test teams were asked to become part of his experiments, where the whole test group was divided into two teams. First test team was asked to run tests after writing test specifications using traditional testing approach, whereas the second test team was expected to perform exploratory testing by writing quick and brief test sessions. I was randomly put into the team, which was expected to perform the experiment using traditional testing approach i.e. writing detailed test cases before performing actual testing of the application. Since, I have always counted myself a true Agile tester spirit, hence becoming part of a traditional test team was disappointing for me, because I felt that my time will be wasted in writing tests and I won’t be able to find more bugs quickly like the other team who didn’t have to write detailed test documentation. As I expected, I spent most of my time struggling with writing test specifications, which in my eyes was an effort of lesser value and least significance. But now, as I work in a team where definition of valuable testing activities starts with good test documents, I feel less bad about writing test specifications. Hence, in my view this discussion is contextual. It really depends on the environment you are working in and the perceived value of the activities a tester is performing. As a reader, you may disagree to that! Just a reminder to myself, I still am a true Agile tester spirit. When I cannot find a way without writing documents, I try finding ways doing that quickly, smartly and efficiently. For me, value of speed and accuracy still matters! – :)

(* Huma is one of the few people who forced me to start out a blog on software testing. I had the pleasure of working with her in a team where we had lengthy discussion on the role of testing, being Agile, how to force the whole team to think about quality etc. etc.. Thanks to Huma for sharing her thoughts on this topic)

Read More