NetWorks Group Blog

As penetration testers, we get a lot of joy out of compromising Windows networks. They are basically our favorite targets because of how insecure they are by default. Microsoft has always favored backward compatibility over security, and while it is possible to really lock down an AD (Active Directory) environment, it takes a lot of effort. While setting up an organization’s network in the first place, many admins take the stance of, “Let’s just get it working, and then we’ll add security on afterwards.” Nine times out of ten, they never go back and enable the security features until after there is an incident.

We often hear from prospective clients that they have a third party perform external penetration testing every year, and it never finds anything serious, so if the attackers can’t get in from the outside, why bother testing anything else? At first, the logic seems sound – Using a castle as an analogy for the network: You’ve built a castle with really strong walls. – If nothing can breach the walls, then the squishy villagers, the rulers, and the royal jewels inside are safe and secure. This thinking follows the traditional 90’s style of network architecture, where the only route into the corporate network was through the border firewall, through the modem – the one hardline into the office.

 It happens all the time. A new penetration test work order comes into my inbox, and the customer is asking us to test only a handful of external IP addresses. A quick WHOIS request shows me that the customer owns an entire class C of public IP space, and that they didn’t even include their public webserver in the scope. In an ideal world, I’d get in touch with our Project Manager. We’d get in touch with the customer, and we talk about the scope, the customer would say it was a simple mistake, and give us a full list of IP addresses they control.

Adobe, MySpace, LinkedIn, and many other large organizations have had major password breaches in the last few years. Breaches where attackers have exfiltrated usernames, email addresses, passwords, and in some cases, plaintext password hints and other data from the company’s database. The initial response is always, "Log into that service, and change your password before the hackers get in and take over that account!" The sad truth is that it’s rarely that account that matters – it’s the other accounts where you (or your users) used the same password and email address that you’re (or they’re) already using on the compromised account with another service.

In light of new PCI-DSS requirements stating that SSLv3 no longer meets the specification for “strong cryptography” prescribed by PCI standards, we wanted to give you a brief history of how the industry got here and why SSLv3 is no longer considered secure.

I had a completely different article typed up, however after catching up on my morning news and seeing a huge amount of controversy regarding Coordinated Vulnerability Disclosure (CVD) from Microsoft, I decided to reach out to the NetWorks Group Community and help our customers (past, current, and prospective) understand what that means to them.