Kaseya Community

DNS Hijack Risk

  • Currently setting up a pilot Kaseya environment and wonder if anyone has considered the following risk.

    Ifa hackermanaged to change the DNS record of the Kaseya server URL, and put another Kaseya server at the new IP address, all of the agents would pop up on this server and be fully exploitable.

    It strikes me that this is a relatively small change to have to make to fully compromise the security of the every site attached.

    Has this been considered as a risk? Are there any authentication options we could enable to remove this risk?

    One solution we have come up with is to configure the routers at each site to allow 5721 traffic to go only to our server, but this is a somewhat inflexible and clunky solution.


    Legacy Forum Name: DNS Hijack Risk,
    Legacy Posted By Username: andrew_mackintosh
  • There's a lot of hypotheticals in there that aren't very likely. I'm not saying this isn't possible, but consider what someone would have to do to accomplish the exploit you've shown. First they would have to compromise your DNS, which is pretty difficult on any up to date DNS server. Next, they would have to point your A record to their own Kaseya server. Up until this point, I feel the exploit is possible. But now we're assuming that someone has spent all this money on the Kaseya software just to exploit someone else's managed PCs. I suppose that given enough resources this lends itself to the "spear phishing" targeted black mail we're all reading about recently... But still, this isn't something your average script kiddie could accomplish.

    If it really worries you, set your agents to check into an IP instead of an A record. If someone manages to steal your IP address without you knowing, you're not paying attention. :-D

    AR


    Legacy Forum Name: Server,
    Legacy Posted By Username: arobar
  • Regardless of all this the person doing this would have to know what your group names are called because if an agent checks-in to a server that dosent have the group it belongs to, it wont check in. So in this situation they would have to compromise almost every server you have tha allows the agent to get to you. Your DNS, and your KServer.

    I am more worried about Kaseya ONLY having username/password access. If someone got your username/password, its over. We need three factor authentication.

    God Bless,
    Marty


    Legacy Forum Name: Server,
    Legacy Posted By Username: MissingLink
  • Unfortunately the part about the group names is not always true. Check-in Policy under the System tab can be modified to allow agents to auto-create machine groups as they check in for the first time, so depending on the check-in policy the group restriction may not hold.

    Also, if the agents use domain names to check into the KServer,it is also not strictly necessary to obtain control over the KServer DNS entry for the spoof to succeed.

    Remember, DNS is hierarchical, with lower-level servers using higher level servers as root hints or forwarders and hosts relying on local DNS servers for name resolution. All it would take is to poison the DNS cache of one of the servers (or worse yet introduce a rogue DNS server or gain access to a legitimate server) along the chain to your agents (at a given location, relying on given DNS servers) andthese agents can be asked to check-in someplace undesirable. But then again, thisonly has a chance ofsucceeding due to negligence of relying on/hosting unsecure DNS servers that the agents use.

    Using IPs is safer but can may require more administrative overhead when migrating your KServer to a different IP/ISP, etc. (unless of course your router(s) get compomised... ahh the diminishing risk can go on and on.... Wink)

    Also, no need to spend money on a Kaseya server, someone can download an evaluation copy for brief and malicious use. Still, I believe an attack of this flavoris highlyunlikely unless someone is really out to get you.

    BTW: Definately agree on a need for multi-factor authentication for admin logins.

    -Ed


    Legacy Forum Name: Server,
    Legacy Posted By Username: bellcpa
  • Ed,

    Mea culpa with regards to the Kaseya demo... I didn't think of that.

    AR


    Legacy Forum Name: Server,
    Legacy Posted By Username: arobar
  • Ed,

    That is true I forgot about that setting. Thats what I get for answering a post at 1am.

    God Bless,
    Marty


    Legacy Forum Name: Server,
    Legacy Posted By Username: MissingLink
  • In regards to changing your KServer's IP address, it isn't really tough. Agents can be set with a secondary KServer address - so you just put in the new IP address there and it will check into either the primary or the secondary if the primary isn't available. Then just change back. However, you have to do this well enough in advance so that the workstations can update (and stations which are turned off obviously won't update until they're turned back on again).

    In regards tomulti-factor authentication, there are ways of handling this. What about making your KServer NOT accessible directly to the outside world? Then put something like a VPN appliance or some other server in front of it - something that won't let you on without a third factor. Or even just a box that requires ANOTHER username and password before you can GET to the KServer. It just makes it a lot tougher for hackers because they'd have to break the first access device before even SEEING the KServer.

    So no, Kaseya doesn't have it built-in, but it CAN be done if you're really that afraid.




    Legacy Forum Name: Server,
    Legacy Posted By Username: warever
  • Its not a matter of being afraid, its a matter of giving your clientsthat warm and fuzzy thattheir networks are protected. Your Kserver is essentially a gate to all your clients networks. We have been challenged on a few occasions by more security consious clients about the fact that it is ONLY username/password.

    Also we have thought about many of the things you mentioned. We even played around with client certificates. The one drawback to any three factor authentication (and the things you mentioned)is client access. When you place these things in front of your Ksever you break chat, remote access by your clients, the get help page for video streaming, etc.We have even thought about using say a .nuke site as aportal to Kaseya there by only allowing kaseya accessfrom the .nuke site. You will still have a username and password but it is easier to add three factor to .nuke than Kaseya.

    As far as making it internal that sorta takes away from one oftheadvatages of the kaseya platform which is a "work from anywhere" setup. I know that if for some reason my internet goes down at the office or it burns to the ground or any number of reasons, all i have to do is go down to the nearest Starbucks and I can continue to support my clients.

    God Bless,

    Marty


    Legacy Forum Name: Server,
    Legacy Posted By Username: MissingLink
  • Marty,

    Putting an extra layer of security in front of the Kaseya server to give access to token based authenticated users only, adds security for admins. But I agree that the drawback is that stations can no longer login anymore, causing the complete client portal not to work anymore.

    So the solution would be that a station should still be able to login using the safe challenge handshake they are currently using (just like a local certificate), but admins should need a token.

    I can not see any way how we could create a situation like that without Kaseya chaning the complete login process.

    Isa change request for two factor authentication for admins already approved?

    Regards,

    Arne






    Legacy Forum Name: Server,
    Legacy Posted By Username: Balgoija