Learning Moments From Security Conversations – Part 1

Attacker With Administrator Rights

This conversation was a discussion of an attacker gaining administrative privileges on a network.  This conversation started out benign enough and yet rapidly escalated into a full on war of words.  I had to spend almost 40 minutes arguing with an administrator over the facts that if an attacker had administrative rights it was then “game over” for their organization.  I could not believe the lengths that this administrator went to prove I was wrong.

What started this fiasco was a discussion of the results of their vulnerability scans and penetration testing reports.  The reason the conversation got tense was that the administrator was arguing about how the penetration tester was able to escalate privilege to administrator.  At the core of the argument was the “Low” rated vulnerabilities that were used by the penetration tester to gain access to the system and ultimately compromise the environment.

I am not sure where this idea/myth actually started, but it continues to persist even today after around 20 years of vulnerability scanning.  That idea is that “Low” rated vulnerabilities are somehow not a threat.  Even when you try and explain that regardless of ratings, vulnerabilities are vulnerabilities, some are just easier to use than others and provide quicker compromises than others.

Another reason this is an issue is that most information security personnel are not penetration testers.  Penetration testing is not so much a skill as it is an art form.  Anyone can take high and medium vulnerabilities and leverage them to compromise an environment.  That is why they are rated so high in the first place.  But it takes a true artist with a tremendous amount of knowledge in networking, operating systems and applications to look at the results of a vulnerability scan, take certain low rated vulnerabilities, pair those with certain other vulnerabilities, compromise a system and then compromise the environment.  Not that this always ends up leading to a compromised environment, but it is not as simple and easy which is why it is a shock when it happens.

What the penetration tester did once they had compromised a few systems is that they discovered a way to escalate their privilege to domain administrator through the use of a keyboard logger on a compromised system.  They then collected the domain administrator credentials and it was “game over”, or at least that was the penetration tester’s and my opinion.

So the first point of contention were those “Low” vulnerabilities that the penetration tester used to gain access to a system on the network.  Somehow the administrator believed that those vulnerabilities were off limits because they were rated “Low”.  I did my spiel on vulnerabilities are vulnerabilities and that even the PCI DSS states that all vulnerabilities must be patched within 90 days (some of the “Low” vulnerabilities were over 90 days old).

Finally the administrator conceded that at least those old vulnerabilities needed to be patched but continued to argue that using any “Low” vulnerabilities were not “fair”.  Fair?  I tossed that back in their face and asked what attacker would play “fair”?  Point taken and we moved on.

The next point from the administrator was that even if the penetration tester had domain administrator privileges, they did not have access to the data bases and encryption keys.  Those rights are kept in a different group away from the domain administrators.

I could not believe what I was hearing.  So I next asked if domain administrators could modify the members to those domain groups.  “Of course,” was the quick answer back.  So our simulated attacker could have created a new domain administrator account and added them to the data base and encryption groups?  “Well, yeah, I suppose so,” was the quiet answer back as the administrator was starting to see where things were heading.

Then the argument moved on to control of network devices and the exfiltration of data outside.  This revolved around the fact that domain administrators did not have access to network devices.  However, the RADIUS server that did control access to the network devices was integrated with their Active Directory environment.  So I asked what would stop someone with domain administrator rights from creating a new account and adding that account to the network administration group which would then be replicated to the RADIUS server.

The silence created by that question was deafening.  The administrator was speechless.  They now understood the gravity of the situation.  They were owned and they really did not like that fact.  Granted we had not taken things that far because it is a pain to clean up.  But the client now understood after 40 minutes of arguing about it, that the game was over and their environment was no longer under their control.

This is the problem that most organizations face.  They see everything framed in the control paradigms they have implemented.  The problem is that attackers do not care about controls or their paradigms.  They just care about getting access to information and they structure their efforts accordingly without regard to a control environment.

This is why monitoring is so very important and why near real-time monitoring can save your life if it is configured properly.  But monitoring only works if rules have been structured around those same control paradigms so that when the paradigms are violated, alerts are generated.

In the above example, alerts that would have raised red flags are:

• Creation of administrative accounts. Such accounts are only rarely created in most environments so when they are created there should be an alert generated and then matched against the account creation request.
• Addition of accounts to administrative groups. As with administrative accounts, there are very infrequent changes made to these groups.  Again when such an alert is generated, there should be a corresponding change request of some sort.
• Changes to configurations of network devices and/or servers. These can be problematic because of volume particularly on “Patch Tuesdays” or whenever you do volume patching.  But matching changes to change tickets pays off in discovering attackers.  Since attackers do not register their changes in the change management system, any changes popping up that do not have a corresponding change ticket are likely to be part of an attack.
• Redirection of network traffic to public IP addresses outside of your business partners or other legitimate IP addresses. Where organizations are most at risk is communications with business partners.  Because of the speed of business these days, a lot of information security people do not sufficiently restrict network traffic between their organization and business partners so that they do not have to constantly make changes.  While that allows near immediate communication flexibility it also allows business partners to be a ready source of attacks and data exfiltration points.
• Significant increases in outbound traffic volume over ports such as DNS that should not have such increases. Attackers do not obey the port protocol rules, particularly if they are trying to avoid changes to network devices.  In the Target breach, the attackers exfiltrated Target’s cardholder data out through port 53 (DNS).  The reason is that because in most instances port 53 will be open and will not have a restriction on IP addresses allowed to communicate with port 53.

But the obvious area that should receive attention are the patching of those medium and low ranked vulnerabilities.  It just amazes me the twisted logic that sometimes gets used to justify putting off applying patches until the very, very last possible moment all because the vulnerabilities being addressed are not high or critical.  As I said earlier and I cannot stress this enough, vulnerabilities are vulnerabilities regardless of their rank.  They make devices/systems vulnerable, hence their name.

I will share another such discussion in a future post.

Advertisement