While at Stockholm for the EuroSTAR 2007 conference I managed to conduct testing on a public booth and have collated some simple lessons on Exploratory Test Documentation.
I read James Bach’s post on Amateur Penetration Testing a few weeks before going off to Stockholm for the EuroSTAR 2007 conference. While there I managed to recall some of his techniques while using a few of the free test training booths provided by the Stockholm authorities in their fair city.
Michael Bolton gave a talk about his Tester’s Notebook. From which I gleaned a few tips in effective notebook usage.
Lessons from both Michael and James led to the production of this post.
While I reviewed my notebook pages covering my time in Stockholm I found my notes on some booth exploration where I found a vulnerability on a booth in Stockholm.
I include those notes here to try and illustrate a few lessons about exploratory test documentation.
Lesson one: Develop better handwriting than I have so you can read your notes at a later date.
Note: I made these notes @ Eurostar, after I conducted the testing. The title “Eurostar” does not mean that I conducted the testing @ Eurostar itself. The title “Eurostar” on the page tells me where I sat when I wrote the info. I have not included the name of the venue hosting the booth, just in case the owner of the venue hasn’t fixed the problem. I did raise a defect report. I left it in their suggestion box.
Lesson two: write down what you did
This scrawl tells me the order I tried to do things:
I tried to get hold of a pdf and either use the download dialog, save dialog or some other dialog on the screen to access the file system. But no luck - unresponsive pdf links and I could not find a way to access them (so many unresponsive file types - zip, doc, EVERYTHING seemed locked down, so I stopped trying that attack).
I tried a few shortcut keys that I know, but none of them caused any visible effect that I could figure out how to exploit.
I used the Shift+Alt+PrintScreen control key that James mentioned in his blog post (which I didn’t know about until I read it there) and that created an interesting display, but again nothing that I could figure out how to exploit.
And then…. “E”… well I didn’t even finish writing it as a word because a diagram seemed more appropriate.
Lesson three: use diagrams, and don’t worry about the formality
This booth had a little icon on the top right which took me to the manufacturer’s site - great. I found support forums there and manuals so I had a quick browse around for any info that could help me, and I read a whole bunch of useful hacking info about config files and key shortcuts I could enable, but first I had to get to the file system, and I had not figured out how to do that.
But wait a minute… the manufacturer has a .exe download link, and when I click on that I get a file save dialog. And as soon as a file browse dialog gets displayed, I can access the file system. And then the opportunity to exploit becomes available. So at that point I reported the vulnerability.
So much for the self promotion of a secure booth manufacturer.
Lesson four: Make notes during the session.
Lesson five: If you don’t make notes during the session - make them as soon as you can afterwards.
Fortunately I had a very short testing session and could retain it in memory until I managed to write it down.
You will need a Github account to comment. Or you can contact me with your comment.
I reserve the right to delete spam comments e.g. if your comment adds no value and its purpose is simply to create a backlink to another site offering training, or courses, etc.