Woody Leonhard's no-bull news, tips and help for Windows, Office and more… Please disable your ad blocker – our (polite!) ads help keep AskWoody going!
Home icon Home icon Home icon Email icon RSS icon
  • Patch Lady – 31 days of Paranoia – Day 18

    Posted on October 18th, 2018 at 23:19 Susan Bradley Comment on the AskWoody Lounge

    Today we’re taking a break from our normal paranoia to discuss a recent vulnerability.  The headlines imply that a guest user can gain admin rights via this attack.  But that’s not how I’m reading this.  The Windows RID hijacking as per the blog “Assign the privileges of the hijacked account to the hijacker account, even if the hijacked account is disabled.”.  That is the account you attacked can then assign the rights to another account.  IF the account you hijacked is the administrator account you can then assign those admin rights to a lower level account.  So it does hide the fact that one has a back door in the system.  But… here’s the thing… you already had to have been hacked by something or someone before the RID hijacking could occur in the first place.

    Castro, with help from CSL CEO Pedro García, discovered that by tinkering with registry keys that store information about each Windows account, he could modify the RID associated with a specific account and grant it a different RID, for another account group.
    The technique does not allow a hacker to remotely infect a computer unless that computer has been foolishly left exposed on the Internet without a password.
    But in cases where a hacker has a foothold on a system –via either malware or by brute-forcing an account with a weak password– the hacker can give admin permissions to a compromised low-level account, and gain a permanent backdoor with full SYSTEM access on a Windows PC.

    So the real issue is that you were hacked by something else first… and then this obfuscation can occur.

    Sometimes in security it’s hard to get a real sense of the true risk.  We spend hours in TSA lines but aren’t really any more secure than we think.

    Bottom line don’t be quite so paranoid about this vulnerability.  Be more concerned about something you probably have absolutely no control over.  The bigger vulnerability we all should be freaking out over is the Libssh authentication vulnerability.  This vulnerability “it allows anyone to authenticate to a server without any credentials, simply by telling the system that they’re a legitimate user.”  As is written on the Threatpost post, it’s the equivalent of the Jedi mind trick… the attacker can just say “these aren’t the droids you are looking for” and gain access.  Do you know what applications you currently use rely on Libssh?  No, we don’t.

    That my friend is true paranoia.  When we know we probably are at risk, but don’t know what software might be at risk.

  • Patch Lady – 31 days of Paranoia – Day 17

    Posted on October 18th, 2018 at 00:12 Susan Bradley Comment on the AskWoody Lounge

    So you know you’ve been hacked.  Now what?  You can tell your passwords have been reset and you can’t get into your accounts.  You have evidence that a bank account has had funds transferred without your permission.  What can you do?

    Well it honestly depends on exactly the level and damage of the attack.  Financial crimes have a higher impact and thus will often get action.  Low impact crimes, for example where someone is spoofing you online and pretending to be you in Facebook and asking for “friend” requests won’t get police action.

    But what can you do to at least make authorities aware of the problem?  Obviously with any hacking or cyber activity that has a financial impact, immediately call your financial institution.  They can change bank account numbers, put in place positive pay processes to ensure that no authorized transactions get made without your explicit permission.   For high impact intrusions you can contact the FBI or the Secret Service or the Internet Crime Complaint Center.  For lesser impactful attacks you have much less options.

    Think the cyber attack is originating from Azure, or Amazon Web Services?  You can contact them.  And that’s often the best place to start.  See if you can determine where the attack originated from and contact the hoster or ISP that  the attack came from.  Often you can narrow this down by reviewing email header files.

    Tomorrow I’ll talk about the ways you can recover from an attack and some of the investigation tools you can use on machines.