This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How was the SQL injection done? We blocked off admin login

We have the admin login only allowing logins from our HQ (IP limited). Yet, they have all been compromised?



This thread was automatically locked due to age.
Parents
  • I am astonished how basic that attack was. And yet going as forward as a letter at the post office.  I’m also astonished how easy, apparently, it is to modify and create OS files.  Nothing seems locked.

    We have no Admin or Users access from WAN.  That seems to matter not.

    Many months ago I wrote my concerns Sophos were not using TPM modules.  Infineon TPM 2.0 cost just $19.  Bit locker anyone ?

    That said, I’m asking that question again, why some of my desktops were accessing some of those hacker’s WEB site as early as the 4th of April ?  Doesn’t this indicates hackers were able to get tru the firewall and hackers were attacking XG much earlier than the 22nd of April ?

    Paul Jr

Reply
  • I am astonished how basic that attack was. And yet going as forward as a letter at the post office.  I’m also astonished how easy, apparently, it is to modify and create OS files.  Nothing seems locked.

    We have no Admin or Users access from WAN.  That seems to matter not.

    Many months ago I wrote my concerns Sophos were not using TPM modules.  Infineon TPM 2.0 cost just $19.  Bit locker anyone ?

    That said, I’m asking that question again, why some of my desktops were accessing some of those hacker’s WEB site as early as the 4th of April ?  Doesn’t this indicates hackers were able to get tru the firewall and hackers were attacking XG much earlier than the 22nd of April ?

    Paul Jr

Children
  • I have logs in my Graylog server from 3/28 & 3/29 from the "Alternate Attack Host".  All the IPs they hit were NATed to web servers internally, so I don't see how they would have accessed the User Portal on the 3 IPs I have events for.  It DNATs the 443/tcp traffic to my web servers.  Somehow the dashboard alert still states that I was compromised??

  • By default the user/admin ports aren't on tcp/443.  Did you have a user/admin port allowed to the WAN zone on the Device Access page?

  • Big_Buck said:
    Bit locker anyone ?

    An encrypted volume wouldn't have changed anything in this situation.

  • By default the user/admin ports aren't on tcp/443.  Did you have a user/admin port allowed to the WAN zone on the Device Access page?

     

    Want to double check that? ...because my freshly installed Lab XG certainly is configured with 443, while it may not be configured under Device Access tab it certainly is on 443.  By default User Portal listens on 443.  I don't have my admin page exposed to the WAN, only had (now closed) the User Portal.

     

     

    My WAN Network is a /28, all three IPs they hit have DNAT rules to web/mail servers, so those override the ability for User Portal to be accessed.

  • On my v18 tech bench I had userportal on 443 BUT had RADIUS authentication enabled for it. FW reported as not compromised. Related or not. Maybe this FW were never targeted.

  • Based on patterns that we've seen in devices that were compromised vs weren't, we are speculating that a list of known open Sophos devices was compiled by the attackers in advance from a site like Shodan which is why they were able to compromise so many devices in a short period of time.  If your firewall wasn't online or accessible via WAN when this list was compiled it may not have been included.

  • We do not know for sure yet.  Were they able to tamper the BIOS (yes not the UEFI) ?  Or tamper the boot volume ?

    A TPM could be used for other things than just BitLocker "like" behaviour.

    I remain stunned how basic this attack is and yet succeeded.

    I still have no answers why some of my desktops (with Sophos End Point) were contacting many of those hacked WEB sites listed by Sophos.

    Paul Jr

  • I think they got a big enough black eye so not going to beat up on them any more and frankly I was glad to see that they tackled the problem head on instead of denying it or saying it may have happened or could have happened in very small deployments.

    Having said that, the hackers were running shell scripts, modifying permissions on files, creating modifying sql tables, and modifying services on a firewall. There is no excuse for this kind of pwnage. A complete root level access through user portal?  I always turn off ACLs on my WAN and turn off unnecessary services but how many people simply leave everything default specially in home deployments? This relaxed behavior of leaving everything open during initial firewall setup when running the wizard, running all services even when the services are not being used, and exposing management and user portals to the WAN interface by default has finally bit them and possibly tarnished their reputation in the near future. 

    How this got past QA and usual hardening against scripts kiddies would give nightmares to any software developer but dropping bad MR update to XG and then to SG and then getting fully pwned by hackers all in the same month should give sophos a long pause in their whole outlook on where they want to go from here.

  • Hello

    This "New SQL injection attack" ...  Anyone is aware if it was used against anything else somewhere ?

    XG is not the only thing using SQL after all.

    Paul Jr

  • I doubt it. SQL server on XG is running with limited rights, however it has rights to probably write to certain directories.and of course modify tables.

    How hackers were able to chmod scripts in tmp directory  and then download additional files indicates a more sofisticated hack. The rights escalation is what’s so concerning and wasn’t addressed in sophos’ kB article.