Last month we held the final session of the 2005 Indianapolis Workshops on Software Testing. Dana Spears and I wanted to thank everyone who participated throughout the year.



The attendees for 2005 were:

• Rajasimba Admal


• Andrew Andrada


• Taher Attari


• Charlie Audritsh


• Joe Batt


• Chad Campbell


• Laura DeVilbiss


• Linda Ellison


• Kartik Gaddam


• Mike Goempel


• Jason Halla


• Denise Hebert


• David Holscher


• Jason Horn


• Michael Kelly


• Marc Labranche


• Steve Lannon


• Brian Marick


• John McConda


• Kurt McKain


• Jeffrey Mexin


• Patrick Milligan


• Richard Moffatt


• Susan Morgan


• Kenn Petty


• Vishal Pujary


• Joshua Rafferty


• Mike Slattery


• Dana Spears


• Allen Stoker


• Jon Strayer


• Tate Stuntz


• Kim Titus


• Gary Warren


• Rick Wellinghoff


• Cheryl Westrick


• Chris Wingate

Overall we had 37 attendees, over 30 experience reports, and 9 meetings (we missed one due to poor planning on my part and two due to lack of interest on the topics).

The topics were:

• Database Testing


• Performance data analysis and interpretation


• Unit testing


• Testing in an agile environment


• Open source testing tools


• Assessing test coverage


• Maintaining testing skills


• Automated testing


• Security Testing

We would also like to thank DeVry University Indianapolis and Fusion Alliance for allowing us to use their very nice facilities for free (a rare thing today).

And finally we would like to thank Scott Barber and Cem Kaner for helping us get the workshop off the ground.

We have no meetings planned for 2006, we are focused full time on the 2006 annual Conference of the Association for Software Testing which will be coming to Indianapolis June 5-7, 2006. Following that conference, we may hold a couple of IWST workshops again.

Several of the above-mentioned people voiced an interest in keeping things going in 2006 (conference or not!). While Dana and I will not be organizing meetings any time soon, we are happy to help anyone else in the Indianapolis community organize a workshop if they want the help. We have the website (I'm happy to purchase the 2006 domain), a mailing list (which we will not share, but are willing to send emails to on your behalf), and Dana and I can help you find a location and facilitate. Just drop us a line and we'll be glad to help.

Thanks again!

Last month we held the December session of the Indianapolis Workshop on Software Testing. The attendees were:

• Andrew Andrada


• Charlie Audritsh


• Mike Goempel


• Michael Kelly


• Marc Labranche


• Kenn Petty


• Vishal Pujary


• Tate Stuntz

The topic we focused on for the five-hour workshop was security testing.

The first experience report was from Tate Stuntz. Tate spoke about a company that approached him with a "security event" and they had asked him to audit their system to help them track down the problem. He gave an hour-long experience report, I'll do my best to summarize.

He found the root cause to be based on a development team using web application code from a previous project. The code had worked in production for the first application, but had failed for the second application. The failure was due to order of magnitude change in the number of concurrent users in the system - it was a failure in the systems ability to keep unique sessions. In the first (smaller) system, there wasn't enough load to notice the problem. In the second (much larger) system, the users were able to "jump" into another users session and see their records. A big security no no...

It turns out the Session ID generator didn't generate unique numbers after users authenticated. He found some basic coding errors leading to the problem:

1. There were no unique constraints on the Session ID table.


2. They were using the Java random number generator, which I guess has a known issue of using the system clock as it's seed. So any calls at the exact same time generated the same random number for multiple users. They should have used something like SecureRandom which has higher security standards.


3. Each thread instantiated a new class for the random number generator. They did not use a singleton.


4. They did not have enough auditing features in the system to tell what had happened once they started receiving helpdesk calls about "events."


5. They never expired a session. They remained active indefinitely.


6. They made the fundamental mistake of relying on code they didn't know anything about and failed to test because it had been used previously.

After listening to his presentation I thought of James Bach's SFDPO heuristic and how that might map to some of the problems identified. I figured any of the following would have identified some of the problems:

Structure: Code Review and/or database review
Function: Testing for session time out and just about any load testing
Data: Monitoring the database during session generation and testing for the unique constraint
Platform: Testability features like logging, monitoring, and alerts
Operation: Threat modeling

The next experience report came from Marc Labranche (also a long one - I did my best with the notes). Mark had several experiences and ideas to share; all under the broad theme of cracking desktop applications (not web apps - the current hot topic).

His first suggestion was to look for anything on the disk that the software trusts as good or safe and then change those files for the desired effects. For example, for authentication done at install time you can use tools like regmon and filemon available for free at http://www.sysinternals.com to easily see all the file/registry reads/writes being done by the program. He also recommended using Hex Workshop (http://www.hexworkshop.com/) and PE Explorer (http://www.heaventools.com/) for tasks like this.

His next suggestion was to modify the code by using jump inverting. In jump inverting you find test conditions in code and change 1byte of the jump instruction to it's negative. Whatever un-wanted behavior is now changed. This can be easily defeated by developers who use critical routines elsewhere for unrelated reasons, but it works for many applications. Also, a simple checksum will many times prevent this from working. More tools: softIce (http://www.compuware.com) and PE Explorer (http://www.heaventools.com/) again.

In a direct example from Marc:

Basically, every conditional jump routine has an inverse. The classic one being JZ and JNZ (jump if zero and jump if not zero). Basically by changing one byte in your program I can change something like

If(registration_code_ok)
{
Run_app();
}
Else
{
BAD_USER();
}

To something like:
If(registration_code_ok)
{
Run_app();
}
Else
{
BAD_USER();
}

With this change, as long as my registration code is bad the program will run. This can also be applied to checks like if(correct_cd_in_drive) and if(has_remote_license_key)

He also provided a quick reference: http://www.jegerlehner.ch/intel/IntelCodeTable.pdf

He next tackled thread/code injection. A process can use the windows API (MSDN.microsoft.com) to allocate memory in another process's memory and execute it as a thread in the target process. This new thread then has access to all of the memory from the inside, bypassing any operating system RAM protection. This can be done with a combination of the following win32APIs and a little ingenuity: ReadProcessMemory, WriteProcessMemory, SuspendThread, and ResumeThread.

Suspend a thread in the target application, overwrite the next few bytes to allocate process local memory and start a thread (loading a DLL is a very easy way to do this). Resume the thread that does our bidding and then suspends it's self at the original ProgramCounter address. Copy the original code back in and resume the thread as if nothing had happened. Make sure you do not corrupt the heep/stack.

There are other ways to do this if the program detects the above somehow. You can prevent having to use suspend/resume if you make a high priority thread that has the following code: While(true); and then your injection thread should be running realtime priority. The whole system will pause except for your injection thread.

He then tied that in with the classic buffer overflow. Using the same or similar process as local code injection, you exploit the overflow with remote code injection.

He wrapped it up by talking about some of the things he thinks we'll see in the future, like exploits for PCI BUS master mode.

Every PCI card in the system is given the ability to become the BUS master for an unlimited amount of time. In this mode, the PCI card has full access to system resources including the CPU and RAM. Nothing is sacred in this mode; the card can modify any location in RAM as well as any of the CPU control registers. Any security your O/S may have built in is disabled.

Following Marc, I talked about security testing with WebScarab and Ethereal. Something I've been talking about a lot lately. We looked at some examples, hacked into my email, and looked at a previous exploit in a major online retailer (it's been fixed). I also shared some comments and insights from a book I just finished reading: Stealing the Network: How to Own a Continent. It's excellent. I found it both entertaining and very informative.

Overall, I think we all had a blast. It was a lot of fun, A LOT of good dialog. Thanks again to all who attended.