Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security

Hacker Leaks Passwords For 900+ Enterprise VPN Servers (zdnet.com) 33

A hacker has published today a list of plaintext usernames and passwords, along with IP addresses for more than 900 Pulse Secure VPN enterprise servers. ZDNet reports: According to a review, the list includes: IP addresses of Pulse Secure VPN servers, Pulse Secure VPN server firmware version, SSH keys for each server, a list of all local users and their password hashes, admin account details, last VPN logins (including usernames and cleartext passwords), and VPN session cookies. Bank Security, a threat intelligence analyst specialized in financial crime [...] noted that all the Pulse Secure VPN servers included in the list were running a firmware version vulnerable to the CVE-2019-11510 vulnerability. Bank Security believes that the hacker who compiled this list scanned the entire internet IPv4 address space for Pulse Secure VPN servers, used an exploit for the CVE-2019-11510 vulnerability to gain access to systems, dump server details (including usernames and passwords), and then collected all the information in one central repository.

Making matters worse, the list has been shared on a hacker forum that is frequented by multiple ransomware gangs. For example, the REvil (Sodinokibi), NetWalker, Lockbit, Avaddonm, Makop, and Exorcist ransomware gangs have threads on the same forum, and use it to recruit members (developers) and affiliates (customers). Many of these gangs perform intrusions into corporate networks by leveraging network edge devices like Pulse Secure VPN servers, and then deploy their ransomware payload and demand huge ransom demands. As Bank Security told ZDNet, companies have to patch their Pulse Secure VPNs and change passwords with the utmost urgency.

This discussion has been archived. No new comments can be posted.

Hacker Leaks Passwords For 900+ Enterprise VPN Servers

Comments Filter:
  • Pulse Security Advisory - 22 Mar 2019. Seems to have patches..
    So not updated interweb facing stuff, nuff said..
    • by Anonymous Coward
      yeah, but that doesn't make this less of an issue there's telecoms, government agencies, and banks on that list
    • Ah, that's why my parent company updated all its Pulse stuff in April.

  • Okay (Score:5, Insightful)

    by ledow ( 319597 ) on Wednesday August 05, 2020 @07:53AM (#60368639) Homepage

    Let's be clear:

    A VPN is a proxy that you use, owned, operated, secured, and potentially interfered with by the third party that you pay to do that.

    Literally, a VPN is nothing more than giving you data/packets to a third-party "securely" and hoping they'll pass them on "securely".

    If you are buying a VPN hardware / service like that, you're placing all your trust in that entity to secure your network - no different to letting them plug in a cable in your office, or your servers, or whatever is exposed to the VPN interfaces.

    If you're doing site-to-site, why do you need a third-party?
    If you're doing point-to-point (teleworker), why do you need a third-party?
    If you're trying to hide your online identity, why would you WANT a third-party who has your credit card?

    It's not like this stuff isn't baked into all the modern OS nowadays.

    And it's "cloud-based", which just pisses me off. So it's a VPN service that you don't even have control over to update yourself?

    Why do businesses go out of their way to introduce random third-parties into the handling of their corporate, client and internal data?

    • Why do businesses go out of their way to introduce random third-parties into the handling of their corporate, client and internal data?

      For the same reason they do that for a host of other things: it is less expensive in the short run.

      Or at least can be made to appear less expensive due to the way cost accounting typically works. The value of security doesn't usually appear on a balance sheet so it is up to a person to explain why it is worth spending enough to have in-house security people who are motivated by a direct interest in the company's performance and reputation, as opposed to contractors who are several orders removed from tho

      • by rho ( 6063 )

        It may be worse than that. The security people may be the ones recommending these third-party solutions because it gives them a goat to sacrifice if something goes wrong. "It's not MY fault, the vendor screwed us!" Covering your ass is job priority #1 in our modern world.

      • by GoTeam ( 5042081 )
        I can hear in my head the words of a previous employer now "I heard that hackers can VPN passwords away. Make sure we get rid of ALL VPNs!!!!" I'm so glad I left that place...
    • Let's be clear:

      A VPN is a proxy that you use, owned, operated, secured, and potentially interfered with by the third party that you pay to do that.

      Literally, a VPN is nothing more than giving you data/packets to a third-party "securely" and hoping they'll pass them on "securely".

      If you are buying a VPN hardware / service like that, you're placing all your trust in that entity to secure your network - no different to letting them plug in a cable in your office, or your servers, or whatever is exposed to the VPN interfaces.

      If you're doing site-to-site, why do you need a third-party? If you're doing point-to-point (teleworker), why do you need a third-party? If you're trying to hide your online identity, why would you WANT a third-party who has your credit card?

      It's not like this stuff isn't baked into all the modern OS nowadays.

      And it's "cloud-based", which just pisses me off. So it's a VPN service that you don't even have control over to update yourself?

      Why do businesses go out of their way to introduce random third-parties into the handling of their corporate, client and internal data?

      I can answer this. I use to maintain pulse secure vpn servers, actually. We had a lot of high-profile customers. Like names of things I'm sure you've all used, even if you don't live in the US.

      The short answer is their own staff either doesn't want to maintain or doesn't know how to configure VPN servers. In the same way you would go to rackspace to rent a VPS or dedicated server or go to AWS to host virtual machines, these companies would rather pay someone to configure and maintain their servers.We al

    • by ZESTA ( 18433 )

      This story is about physical VPN servers owned by enterprises that happen to be Pulse Secure appliances (which are basically off the shelf servers running Linux and the VPN software on top).

      This is not about a VPN service.
      It is not "cloud based"

      All of these comments seem to be missing that.

      How is running a different piece of software on your own hardware any different that running an appliance? Are you saying that vulnerabilities only exist with hardware/software packages? Are you suggesting that every comp

  • For heaven's sake if your business is over 10 people. Get your own VPN. Hire a consultant to do the IT work via a service agreement, (probably 1k every month)
    For every 50-100 employees there should be at 1 Skilled IT guy to help keep the services running. Including an internal VPN to your offices.
    That is correct Network engineers and other IT services are not cheap. They will require a middle class salary, and competitive benefits (health care, vacations, 401k...) But making sure your business runs secur

  • Stored in plaintext (Score:4, Informative)

    by LenKagetsu ( 6196102 ) on Wednesday August 05, 2020 @08:41AM (#60368709)

    No sympathy. Storing passwords in plaintext needs to be a crime at this point.

    • Are they stored in plaintext or intercepted at login by having a bot running on the VPN host? I don't think we can say for sure just from this summary. It doesn't matter how secure your password hashing is if you can just grab the password from the incoming logins.

      • I'm very far from an expert on this, but I thought the idea was that the client hashed the password and the server compared the hashes, so that the password was never sent to the server. This isn't the case then?
        • If the client directly hashed the password to the same standard as stored on the server, then you can just modify a client to send your stolen hashes to get logged in. So it may be sent hashed, but it would have to have another transformation on the server side before comparing with the server hash or it would be pointless. I would think they just trust the SSL transit if the certificate is good.

        • browsers don't hash. you'd need mandatory JavaScript and any exception would become the point of attack. Instead the connection should be encrypted and the server does the hashing instead - so yes, that means more complexity and points to leak the information... but the secure connection keeps it 1 to 1 so either the browser or the server are at risk; then it becomes a degree of breach problem for both ends.

          One should consider a server breach of account credentials to be a big problem as if they were not ha

          • you'd need mandatory JavaScript and any exception would become the point of attack

            Authentication via TLS client certificates wouldn't require JavaScript. In any case I think most of these web-based login systems depend on JavaScript anyway; might as well put it to good use.

            "Hashing" is the wrong approach, though. With a mere hash function computed on the client either the server is looking for an exact match against a stored hash, in which case the hash is the password and the server is storing it in plain text, or else the server needs to know the shared secret so that it can validate t

            • "Hashing on both the client and the server could help mitigate password reuse and certain kinds of server-side data breaches but won't do anything about replay attacks"

              ^ bingo, best comment on this article as of now
      • This is what I'm confused about. I use to maintain those servers. Pulse secure servers usually want you to defer to an external auth server by default. Like openLDAP or AD or oauth or something. So the creds aren't stored on the server itself. Now, if you just buy those servers and use it as the auth server, then I believe those are stored in a DB (SQL, I believe) in the OS of the machine. Now are those entries in the DB hashed? I can't say for sure. Pulse kind of blackbox those machines so I can only guess
  • I mean, you have to be particularly moronic to do so, and even more so if your boss forces you to do it.

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Working...