1

I am a developer and I have been looking more into security / pen-testing to make sure my application is secure. A lot of the resources I have looked at mention having a "pen-testing machine/lab/box," which sounds to me like people are using a completely isolated machine for their testing. However I am wondering if it is okay to pen-test on my personal machine where I develop?

I am not sure if the separate machine is used for anonymity, or if it's more the issue of the tools people try out which could possibly infect/corrupt their machine and that people should keep these unknown/questionable applications/tools in an isolated environment as to not harm personal data? I would think most of the stuff out there meant for ethical pen-testing would be safe to work with though?

Personally I just was looking at a few testing applications like Burp Suite and I was looking into trying out some CTFs and such to expand my knowledge while just looking to protect my code and protect my personal data where I can. I figure I should be safe using Burp Suite and trying out some reputable CTFs and challenges.

I was thinking of just splitting up my development/normal-stuff on one VM instance, while having something like Kali on another instance. I also thought about having 2 drives that I would boot from (or swapping drives out when needed) where pen-testing would be done on one drive, and development would be on another drive. I am wondering how much more secure either of these options would be compared to just running everything together on the same drive, but separate VM instances? I believe I have heard of malware being able to infect hardware like a motherboard. If that is true, would it be possible that malware could transfer into another drive that has been plugged in to the infected motherboard, after the infected drive has been removed? If that is possible how likely could that happen? I do believe that if I had both drives plugged in at the same time, and the pen-testing drive gets infected, that there is a higher chance of the other drive being infected. As for everything on the same drive, but different VMs, I have read that malware could pass through the VMs, but depending on settings seemed not as easy to pass through the VM environment. I'm curious if it's easier for Malware to exit out of a VM and infect the host machine, compared to malware passing from one drive to another(I would assume that since VM instances would be running on both of my drives that it would have to pass through the VM, to the main os to then pass to the other drive, unless one drive was accessible to other drive's VM instances)? I would assume swapping drives out would be the safest option, but I would love to hear people's suggestions as well.

Thank you for any help in clearing this up for me.

3
  • I find it easier to manage several purpose-built systems than one gigantic system that tries to install every tool I'll need. – user Mar 16 '20 at 19:25
  • The answer here has a link to VM vulnerabilities: security.stackexchange.com/questions/175931/… I think your question boils down to whether you trust the creators of the pen-testing tools you are using. If you don't trust them, you should write your own. – pcalkins Mar 16 '20 at 19:30
  • Thank you both for your advice. I was thinking about multiple machines, but I felt it would be difficult managing these machines without additional hardware like I/O switches for mouse/keyboard/monitor. I'll take a look at that link thank you. – MXBuster Mar 16 '20 at 20:58
2

There is no reason to overthink your penetration testing setup. As long as you are working with established tools from renowned companies - you mentioned burp as a good example - you can trust them as much as any other third party software you install on your system. There is also no reason to protect your anonymity, as you are doing nothing illegal.

Having worked as a penetration tester for many years, I always liked to separate my penetration testing system using virtualization (VMWare or Virtualbox) for several reasons:

  1. You have a standard image with everything you need. Having a clean image with all the tools pre-configured helps a lot to start new engagements fast. That's especially important, if you work for different clients and do not want to mix up results. This is less important in your scenario, but having a standard image to fall back to, in case anything breaks, is still an asset.

  2. You are flexible concerning the OS. I like Windows as my host operating system, but many of the penetration testing tools I am using, require Linux as OS. While I prefer assembling my favorite tools on Ubuntu manually, others prefer a swiss army knife like Kali Linux, where many tools are already pre-installed and ready to go. Whatever route you want to go, being flexible when it comes to the OS choice can make life a lot easier for you. You can even use multiple OS in different virtual machines if your tool set requires it.

  3. You do not clutter your host OS. Penetration tests tend to require a lot of different tools and installing all of them on your main OS will load it with a lot of baggage in the long run. Managing all those tools and keeping them up to date can become a nuisance. Having them separated in a penetration testing VM deals with this problem, especially if you reset it regularly to get rid of tools you only used once.

  4. Added security when using less trustworthy exploits. In some scenarios you want to verify that an identified vulnerability is actually exploitable, but there is no exploit code available that you feel comfortable trusting. Having a throw-away virtual image makes it easy to experiment with the exploit and clean everything afterwards by resetting to a previous state. Sure, there might be a residual risk of a super advanced hidden malware that exploits a vulnerability to break out of the Hypervisor and infects your host system... but, while that's a cool story, stuff like this happens in real life only very rarely. That's a risk I would be willing to take.

So there are no reasons that makes it mandatory to have a separate VM, and I have several tools on my host OS, just do be able to check some things quickly. Burp again, is a good example that I like to have readily available without powering up a virtual machine.

But, as I mentioned above, it pays off in the long run to have a separate environment, but there is no reason to overthink it.

3
  • EDITED: Thank you for the answer, you make a lot of good points in here, but I'm not sure if the question was fully answered. I am looking to know if I should have a separate physical machine for pen-testing. From what you mentioned it sounds like you pen-test on the same machine you do normal work on? So it seems that as long as I'm using trusted tools and being safe, I don't need to worry about a separate drive? Would it be more secure to have 2 separate boot-drives? I guess it doesn't matter if I did work in a separate VM vs the host OS then either, unless I need VM features? Thank you. – MXBuster Mar 16 '20 at 21:15
  • 1
    @MXBuster - The main message is, it does not really matter. I personally have my pentesting VM on the same machine, because it is the most convenient setup for me. If there are no special requirements in your environment, this will probably apply to you as well. The differences from a security perspective are minuscule and therefore not worth the extra effort. If you want to be extra safe, use a dedicated machine, but it is probably not worth it (from a security perspective alone). So I would say no, worrying about a separate drive is not necessary. – Demento Mar 16 '20 at 21:17
  • Thank you very much. It definitely is more convenient to have everything together in the same machine. I guess if you're safe then there shouldn't be any security worries then. I guess it matters more when you're dealing with malware analysis and other things that could cause damage? This definitely helped with making a choice on what to do. – MXBuster Mar 16 '20 at 21:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.