Sometimes the joys of waiting for tools is you simply can’t wait. No matter how happily the tools will take care of the grunt work without getting tired or bored, sometimes you can’t let them.
Time is rarely on your side when it comes to work and sometimes the schedule just won’t allow waiting for the tools. When it comes to testing like dynamic analysis of a website, sometimes the schedule further restricts your time so you do not impact other dev or testing work. You probably do not have exclusive access to the testing environment after all and rapid, automated testing of a web site can have a significant impact. You might be restricted to after hours scanning. You will probably have to finish the testing by a certain date and maybe the tool just can’t meet that deadline give the other constraints.
As good as the software security tools can be, they still lack a lot of smarts and judgement. We humans can know when we are approaching a deadline and adjust our approach accordingly. We can change priorities. We can say we’ve seen enough of this and decide to concentrate on that. We can decide if a certain type testing is providing a lot of false positive we should focus on testing that provides true positives. We can decide to call an issue systemic if we see the same results over and over and over again so there is little reason to keep testing for it if we need to spend the time we have elsewhere.
The tools can’t do that. They just chug merrily along doing the drudge work. The same thing over and over and over no matter how long it takes. The very thing that makes them great at doing that tedious stuff can make them very bad at meeting a deadline.
So we have to do it for them. We have to provide that judgement for the tools.
We know the schedule and need to judge how the tool is progressing against that schedule. If it isn’t going to make it, we need to make the changes the tool can’t make on its own. Lots of false positives on one test, turn it off. Lots of true positives one a particular test call it a systemic problem and stop testing it so there is time for other tests. Have a web page with a whole lot of fields on it to be tested, exclude it from the main test and do it separately so that one page doesn’t consume too much of the testing time. Maybe the website is on an under-powered server and on a slow connection and reducing the number of testing threads may actually speed things up. If the tool seems to think its session has expired and keeps logging on, maybe its in session testing relies on a part of the gui that the testing bypasses and you need to switch to out of session detection so it stops wasting time logging in when it doesn’t have to.
Sometimes we do not have the luxury of waiting for the tools to do their jobs. Since the tools don’t get bored, they don’t watch the clock. We can and we must. We know how to take short cuts and can make the judgement call when we know it is necessary. We poor, easily bored humans need to provide the judgement the tools can’t.
We’ve all been newbs at one point or another in our lives. Have you ever been an experienced newb? Of course it happens. Just because you’ve got years of experience doesn’t mean you don’t encounter new processes or new procedures. You need to pick up a new skill. You get handed a new tool. You change jobs and the new company does things differently.
It can be tough to an experienced newb. You’ve done it all before. You don’t want to ask questions. You don’t want to show how rusty some skills are. You don’t want to look like a newb or a n00b. (Yes there’s a difference!) You’re supposed to be an old pro. You know your fellow techies aren’t always gentle with newbs and can be evil to n00bs. RTFM! But reading the manuals is tough when you’ve been doing things for so long because you may know 90% or 95% of what’s there and you have to wade through everything to find that 5% or 10% you don’t know. You can’t search for it because you don’t know what you don’t know. Or your find the new stuff but maybe the new company uses different terms and a different language and things aren’t clear. (Especially fun coming out of the US DoD work where they can NEVER use the standard terms. Ever do the side-straddle-hop? You probably know it as the jumping-jack.)
Despite seventeen years in the information security business, I find myself in that situation now. I’m an experienced newb. New company, new processes, new procedures, new report standards. I’m no longer following processes and procedures I helped create and writing reports I’m used to writing. I’m an experienced newb.
I can flounder around and slowly figure things out costing time and money or I can check the ego and start asking questions. Ego checked.
How do you all do…?
What’s your standard on…?
How long do you spend doing…?
I”m rusty on this, is it really as simple as…?
Hats off to my fellow Cigitalites. These guys sure seem to welcome the newb questions even from an old pro and answer them eagerly.
I’m working through my time as an experienced newb. Past that necessary ego check and off to learning how we do business. It’s been fun and I expect it will continue to be.
VirtualBox’s seamless mode is a pretty neat way to work with a virtual machine and a great way of working with two different operating systems at the same time in an almost seamless way. Windows from both the host machine and the virtual machines can exist side by side almost as if they are the machine. No more working with the virtual machine in its own isolated window. It does require having the VirtualBox Guest Additions installed on the virtual machine but once installed you are ready for seamless mode. To get to seamless mode you use ctrl+l if you have not set a different host key.
On a single monitor things are pretty simple and seamless mode mostly just works. On a dual monitor system you can get some strangeness.
First, I am working with a Windows 7 host with Kali Linux and Samurai WTF virtual machines for security testing. I have not tried other Linux distributions this way yet but if there are issues there the fixes may be similar.
Setting up a VM to use dual monitors is simple using the VM’s display settings. Set the monitor count to 2 and increase the video memory until you get to at least an acceptable amount if not more like I have. VirtualBox will let you set too low a memory setting so watch this! Continue reading “Dual Monitor Linux Virtual Machine Strangeness”
I don’t recall PortSwigger’s Burp Suite being around the last time did much web application testing. It may have been but I do not recall it and I did not use it. I am using it now and of course that means getting to know a new tool. While I’m waiting for some of Burps tests to run, I figure I’d give a shout out to the best of the Burp Suite tutorials I’ve found out there. Security Ninja has some excellent ones.
Burp Suite Tutorial – Sequencer Tool
Burp Suite Tutorial – Intruder Tool
Burp Suite Tutorial – Repeater and Comparer Tools
I just got done triaging the results of an AppScan website scan all the way through. I’ve done it before but never on a production run. It has always been partial triages before on training runs. After seven years of secure code review, I have triaged a lot of static analysis results from a variety of tools before and I’ve gotten quite good at it. I know once you get to know the tool and know how it spits out it results, which rules are almost always reliable, which are sometimes reliable and sometimes wrong, which are often wrong, you can work pretty quickly. Work some hard issues, switch to some easy ones for a break, back to hard. Adjust that based on the schedule if you need to focus on the most important stuff and do not have time to do it all. For source code scanning, I have gotten pretty good at it.
This was quite a bit different. The results of a dynamic, black box scan of a website are quite a bit different than a static analysis scan of source code where everything is laid out before you. It’s automated pen testing followed by verification still against that black box. As I’ve said before my pen testing skills are rusty from disuse and it has been a few years since I have evaluated a web application outside of training sessions. Like the pen testing, it’s a bit rusty. No well established rhythm in my triaging muscle memory.
We have a technical oversight/sanity check person working with us which is really nice in general to provide fresh eyes on things like this but it is really nice when you are in a new job in a new company. You are good at the way you do things but not necessarily the way the new company does things so having somebody around that is good at the company way is nice. Since this first time through with the new guys I made sure to ask questions and made sure I wasn’t wandering off down the rabbit hole. I was shocked at how quickly these experienced folks said they could triage things on these web scans. As I looked at the results before me I thought there was no way I could get close to that speed.
And I didn’t.
But between the triaging cheat sheets with experienced here where the rules are good, here’s where they are prone to false positive guidance and diving in I started to find that rhythm. Figure out the tool’s display, what to look at to verify the finding or dismiss it. Find the pieces to replicate the results manually. Get to know the HTML in front of you and set the search feature right you can progress through false positive weeding out fast in some cases like when a custom error page is mistaken for a result. I didn’t come close to the speed the old pros can do but I can see how they do it as I find that rhythm and scrape the rust off the lesser used skills.
I love the Internet.
I have been putting together a pen testing virtual machine lab to work through Georgia Weidman’s Penetration Testing: A Hands-On Introduction to Hacking book that just came out. It’s been years since I’ve done much of this and there are all kinds of new tools to use doing it so I want to scrape the rust off my skills. Part of the lab setup is a Kali Linux virtual machine on VirtualBox. I am used to setting up fairly lean Linux VMs to play with so I started off with just a 15 GB virtual disk and installed Kali to that disk.
Georgia has you set up a number of additional tools into the Kali Linux system and as I was installing the Android SDK and components for the mobile pen testing I ran out of room on that virtual drive. Ugh!
I didn’t want to create a second drive and I didn’t want to start over so I hit Google. Turns out VirtualBox includes a way to expand the size of the virtual disks and Jonathan Mifsud has an excellent how to on his blog. He is working on a Linux host and I am on a Windows host but there wasn’t much difference. Now I had a larger virtual disk.
Unfortunately that new free space was not right next to the main partition so you cannot just expand it into the unused space. I had to move the swap partition to the end of the drive and open up the free space right next to the partition I wanted to expand. Luckily there’s a good blog post by Eugene at trivialproof.blogspot.com. Since I’d already increased the size of my virtual disk I skipped down to step 4. Booting with the Kali Linux live ISO image I used GParted just as described and restructured my virtual disk.
Now I’ve got plenty of space and can keep on setting up the system to follow along with the book.
I’m sure there are other ways to have skinned this cat but those were the ones I found fast. Hard not to solve problems with the Internet these days if you at least know something about what you want to do.