Creating Your Own Vulnerabilities
This past week I went to DerbyCon, which is a security conference in Louisville, KY. Whenever I go to these conferences I learn something new. This time was no exception. I went to a talk by Ben Ten, who is a Penetration Tester, but before this he did cyber defense. Ben’s main point was that many times he is able to gain access to the company’s assets without ever using an exploit.
There are multiple ways Ben can get into a company, but once he is in the network, either via FTP, USB drive, wifi, etc, he eventually can get himself into every aspect of the organization without using an exploit. Normally all we hear on the news are new zero-day (previously unknown) attacks against companies, who then lost all their data. Not using an exploit at all, seemed just wrong.
As an example, he explained how a company put him on a separate VLAN with no traffic. This VLAN though was connected to a development server. This server had a configuration file for testing. This file also had some credentials in it. Low and behold those credentials worked somewhere else. Slowly but surely Ben moved around the network using all the tools Microsoft had built in. He wasn’t exploiting any hole in Microsoft’s products, and even if the client patched fully, they wouldn’t have been able to stop him. What they needed to do was lock down their network correctly. Many internal administrators are overworked and don’t have enough time to do everything fully. This is why configuration files are left over when an administrator is no longer using them or Remote Desktop ports, that were used for troubleshooting, remain open.
While I think patching is being drilled in as something that we have to do constantly, the low hanging fruit of cleaning up after troubleshooting or building a new server, should be just as important. Just because something is on an internal network no longer means it is protected by the