22
Apr
16

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.

Advertisements

13 Responses to “Learning Moments From Security Conversations – Part 1”


  1. April 27, 2016 at 7:28 AM

    Excellent write-up! So many times I was faced with technical staff that was completely in the dark on what Penetration Test is (and shocked that it is not a simple nmap or Nessus scan) and how to interpret / read the results.

  2. 2 James Glaves
    April 26, 2016 at 3:46 AM

    I can’t help but feel some kind of defence is needed for the sysadmin in this case – (s)he appears to be getting rather battered in this discussion! I, like many, sit in both camps – IT Ops and InfoSec. My organisation is small, so cannot possibly afford the resources required to completely separate the duties. It is my role to keep the network and systems functioning, respond to new business requirements, and keep everything secured, patched and adhere to our PCI DSS obligations. I’m being pulled in all directions. Everything is high priority. So coming at vulnerability management from a purely “every vulnerability is a vulnerability” perspective regardless of the risk ranking is not realistic for most organisations. Keeping systems patched is a constant evolving task, which feels relentless. All the scanning providers out there, Tenable, Qualys and alike classify vulnerabilities into Low, Med etc for a reason. And PCI allows CVSS re-scoring for a reason. To allow some pragmatism for poor souls that are under-resourced, over-stretched and as much as they desperately want to patch every single vuln on the network – it simply isn’t feasible. This was probably one of dozens of areas this sysadmin was responsible for. If (s)he spent all the hours patching these vulnerabilities – some other area would have inevitably suffered. Perhaps log reviews wouldn’t have been as thorough – then (s)he would be in for abuse that “every security log event could be significant and should be reviewed”. Patching is tough and a thankless task – it breaks things, it can have unforeseen knock-on effects, it takes time and energy. Yes – the sysadmin appeared to have got over-defensive when having faults pointed their way – as I would to be honest. It isn’t pleasant post pen-test having multiple flaws in your network pointed out. It takes a strong character to not take it personally and accept without some attempt to redeem yourself. I can see how some arrogant, jumped up pen tester, rubbing it in how they’ve just “owned” your entire infrastructure and it’s “game over” for your organisation would make anyone want to find some glimmer of hope – “yes, but you didn’t gain control of the network itself, only Windows”. Alas to be shot down with a RADIUS server final nail in the coffin. I hope as much effort that was put into the pen test, was also put into assisting the sysadmin improve matters afterwards.

    • April 28, 2016 at 3:05 PM

      You are welcome to you opinion, but if you are wasting time re-scoring CVSS, IMVHO, you are doing a lot of work for nothing. In my experience, people that go through the effort of re-scoring do it for one and only one reason and that is to clean up their miserable vulnerability scans. In the end, a vulnerability is just that, a vulnerability regardless of what score you assign.

      Yes, we did help this and other admins and security folks out of their delusions regarding their security. For a lot of people, this is a HUGE learning process because they have had no real exposure to real penetration testing.

      • 4 James Glaves
        April 28, 2016 at 3:24 PM

        That’s quite a leap isn’t it? CVSS re-scoring surely has a value and a place in any balanced environment juggling security vs. usability. You seem to hold a very binary opinion on vulnerabilities. Yes, you are of course correct – it is, in theory, a vulnerability for a Windows host to cache a number of logins, to enable a login in the event of AD being unavailable. Your view is this must be remediated by way of disabling the feature? In my view no… there is another, very useful tool at our disposal in real-life complex production environments, to assess the risk by way of CVSS rescoring. Not in an attempt to hide anything, but to apply some common-sense and reasonable judgement to a risk. A DoS vulnerability exposed on a heavily firewalled internal server, can of course be re-scored from an immediate failure, to a lower risk if accepted by the business. Your words sometimes come across quite judgemental and arrogant… “delusions regarding their security”. You of course must see a lot of poorly designed infrastructures, people lacking in skill, and many vulnerabilities showing up on Nessus scans. But there is always another side to things.

      • April 29, 2016 at 5:05 AM

        The are ways other than shutting down a service to remediate a vulnerability. You can increase monitoring of the situation. Further restrict firewall rules. Use your IDS/IPS to detect potential attacks or misuses. There are lots of tools in information security’s tool belt to address vulnerabilities.

        It is just in my experience, organizations that go through a lot of re-scoring are wasting a lot of time because it is not an easy effort and those that try to re-score end up getting frustrated by the documentation required. Under the PCI DSS, you must document your rationale for the re-scoring with detailed description of how you came to that rationale. Not just the age old “we didn’t think the score was justified”. In the hundreds of organizations I have dealt with, I have only encountered two that actually had a valid and well supported group that re-scored vulnerabilities for their organizations. Both were Fortune 100 companies, so they had the manpower to burn on such an effort.

        In the end, the effort put forth re-scoring vulnerabilities probably would have been better focused on securing the existing environment, giving people time to think about what they are doing and getting a good night’s sleep.

  3. April 25, 2016 at 5:58 PM

    I fully agree with your list of items that should be monitored. But, there is one big thing you missed – special privileges assigned. Reason that this has to be monitored is that with golden ticket attack, you don’t need to add anyone to admin group in order to give him admin privileges. You just create such ticket and person has admin privileges even without account being created.
    We have implemented that in our sec monitoring solution, and we are tracking any anomaly change.

    • April 28, 2016 at 3:10 PM

      Good catch. Thanks.

  4. 8 Kyle
    April 23, 2016 at 11:35 PM

    How old was the admin? A lot of the guys who have been in the industry since the 90s or earlier come from an age where security meant sticking hardware firewalls in front of everything and they completely ignore software vulnerabilities unless they have a blazing red flag. This attitude was most damaging during the beginning of the “app age” in the 2000s when there was a lot of focus on hardening networks but any script kiddie could come along and dump entire databases through their shitty PHP front end. Even within PCI this old attitude is apparent as many areas can go into minutiae but app security merely amounts to making sure you use “secure coding practices”.

    I haven’t met many people without a grey/blackhat history who truly understand that 99% of exploits come from chaining multiple small vulnerabilities.

    • April 25, 2016 at 8:30 AM

      Actually, it was someone that I would have considered would know better given their certifications. I’ve found information security professionals from all ages that are great to questionable, so how long they have been around typically does not matter. It’s what I call the “hacker mentality” that is what these people are missing. They just do not see the world from the point of view of how to do something to a network given the results of a vulnerability scan.

  5. 10 Adam
    April 23, 2016 at 9:09 PM

    Here’s how our butt got kicked on a pen test years ago. The sysadmins didn’t think that having the IE setting of “Automatically detect proxy settings” enabled by default was a big deal and managers being what they are agreed. How could it be a problem? We didn’t have a WPAD DNS entry so no one could use it anyway. Because, you know, it takes a lot of effort to change a GPO to turn the check box off and they have a lot higher priorities!

    So the pen testers noticed the broadcasts for it so they set up a fake proxy server and captured authentication hashes from the local subnet. Only allow DNS updates from authenticated devices? Why would we ever do that? No one can get in our buildings. They then brute-forced some hashes. They then attempted to map a drive to the administrative share on every device, just once per device. That’s an “access denied” not a “failed login” so no one noticed because those happen all day long. They got a hit on a server. Why? Because that user used to be on the help desk and they gave the help desk admin access to servers to restart services. But not domain controllers. That would be stupid! We’ll get around to removing rights. It’s just not a priority. People don’t complain when they have too many rights.

    The testers logged on to that server and found a service running under a domain admin account. They grabbed the hash and used it to logon to a domain controller and enable the account of a departed domain admin. She hadn’t been gone for 120 days yet so the account was still in place but disabled. No one noticed. Why hadn’t her account been removed from domain admins? Because it was disabled so no one could use it, of course. How could it be a problem? Anti-malware on servers? Not a chance. It slows the servers down too much!

    They also got hit by the W-2 phish. I am so glad I do not work there anymore.

  6. April 23, 2016 at 3:58 PM

    Very nice story! Seems to be the standard situation of every pentester / pci consultant minimum once in a lifetime :-). I was once kicked out by the customer after such a discussion with a bunch of SysAdmins trying to tell them they are pwned.

  7. 12 KDemonds
    April 22, 2016 at 4:45 PM

    that was not an administrator you were talking with, that was a keyboard jockey that did not fully grasp the concept of the domain admins group until the conversation.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

April 2016
M T W T F S S
« Mar   May »
 123
45678910
11121314151617
18192021222324
252627282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,846 other followers


%d bloggers like this: