March 30, 2021

On Jan. 11, Ubiquiti Inc. [NYSE:UI] — a major vendor of cloud-enabled Internet of Things (IoT) devices such as routers, network video recorders and security cameras — disclosed that a breach involving a third-party cloud provider had exposed customer account credentials. Now a source who participated in the response to that breach alleges Ubiquiti massively downplayed a “catastrophic” incident to minimize the hit to its stock price, and that the third-party cloud provider claim was a fabrication.

Update, Dec. 5, 2021: The Justice Department has indicted a former Ubiquiti developer for allegedly causing the 2020 “breach” and trying to extort the company.

Original story:

A security professional at Ubiquiti who helped the company respond to the two-month breach beginning in December 2020 contacted KrebsOnSecurity after raising his concerns with both Ubiquiti’s whistleblower hotline and with European data protection authorities. The source — we’ll call him Adam — spoke on condition of anonymity for fear of retribution by Ubiquiti.

“It was catastrophically worse than reported, and legal silenced and overruled efforts to decisively protect customers,” Adam wrote in a letter to the European Data Protection Supervisor. “The breach was massive, customer data was at risk, access to customers’ devices deployed in corporations and homes around the world was at risk.”

Ubiquiti has not responded to repeated requests for comment.

Update, Mar. 31, 6:58 p.m. ET: In a post to its user forum, Ubiquiti said its security experts identified “no evidence that customer information was accessed, or even targeted.” Ubiquiti can say this, says Adam, because it failed to keep records of which accounts were accessing that data. We’ll hear more about this from Adam in a bit.

Original story:

According to Adam, the hackers obtained full read/write access to Ubiquiti databases at Amazon Web Services (AWS), which was the alleged “third party” involved in the breach. Ubiquiti’s breach disclosure, he wrote, was “downplayed and purposefully written to imply that a 3rd party cloud vendor was at risk and that Ubiquiti was merely a casualty of that, instead of the target of the attack.”

In its Jan. 11 public notice, Ubiquiti said it became aware of “unauthorized access to certain of our information technology systems hosted by a third party cloud provider,” although it declined to name the third party.

In reality, Adam said, the attackers had gained administrative access to Ubiquiti’s servers at Amazon’s cloud service, which secures the underlying server hardware and software but requires the cloud tenant (client) to secure access to any data stored there.

“They were able to get cryptographic secrets for single sign-on cookies and remote access, full source code control contents, and signing keys exfiltration,” Adam said.

Adam says the attacker(s) had access to privileged credentials that were previously stored in the LastPass account of a Ubiquiti IT employee, and gained root administrator access to all Ubiquiti AWS accounts, including all S3 data buckets, all application logs, all databases, all user database credentials, and secrets required to forge single sign-on (SSO) cookies.

Such access could have allowed the intruders to remotely authenticate to countless Ubiquiti cloud-based devices around the world. According to its website, Ubiquiti has shipped more than 85 million devices that play a key role in networking infrastructure in over 200 countries and territories worldwide.

Adam says Ubiquiti’s security team picked up signals in late December 2020 that someone with administrative access had set up several Linux virtual machines that weren’t accounted for.

Then they found a backdoor that an intruder had left behind in the system.

When security engineers removed the backdoor account in the first week of January, the intruders responded by sending a message saying they wanted 50 bitcoin (~$2.8 million USD) in exchange for a promise to remain quiet about the breach. The attackers also provided proof they’d stolen Ubiquiti’s source code, and pledged to disclose the location of another backdoor if their ransom demand was met.

Ubiquiti did not engage with the hackers, Adam said, and ultimately the incident response team found the second backdoor the extortionists had left in the system. The company would spend the next few days furiously rotating credentials for all employees, before Ubiquiti started alerting customers about the need to reset their passwords.

But he maintains that instead of asking customers to change their passwords when they next log on — as the company did on Jan. 11 — Ubiquiti should have immediately invalidated all of its customer’s credentials and forced a reset on all accounts, mainly because the intruders already had credentials needed to remotely access customer IoT systems.

“Ubiquiti had negligent logging (no access logging on databases) so it was unable to prove or disprove what they accessed, but the attacker targeted the credentials to the databases, and created Linux instances with networking connectivity to said databases,” Adam wrote in his letter. “Legal overrode the repeated requests to force rotation of all customer credentials, and to revert any device access permission changes within the relevant period.”

If you have Ubiquiti devices installed and haven’t yet changed the passwords on the devices since Jan. 11 this year, now would be a good time to take care of that.

It might also be a good idea to just delete any profiles you had on these devices, make sure they’re up to date on the latest firmware, and then re-create those profiles with new [and preferably unique] credentials. And seriously consider disabling any remote access on the devices.

Ubiquiti’s stock price has grown remarkably since the company’s breach disclosure Jan. 16. After a brief dip following the news, Ubiquiti’s shares have surged from $243 on Jan. 13 to $370 as of today. By market close Tuesday, UI had slipped to $349. Update, Apr. 1: Ubiquiti’s stock opened down almost 15 percent Wednesday; as of Thursday morning it was trading at $298.

149 thoughts on “Whistleblower: Ubiquiti Breach “Catastrophic”

  1. Susan Bernard

    I am curious to know how the unauthorized access to the LastPass account of an IT admin occurred. If you glean more information about that particular initial compromise, please let us know.

    1. JayG

      Susan – I agree. I wonder if they hacked the LastPass account, or what?

    2. Robert Russell

      LastPass doesn’t require 2fa on your account so phishing the master password is possible.

      1. John

        LastPass does requires 2FA only if you’ve enabled it in your browser.

        1. JamminJ

          From what I understand, it is still possible to reset 2FA, with access to just the master password and recovery email. Meaning that your password database is still only protected by a master password, and their cloud service and add or remove extra authentication.

          In contrast, KeePass has a local database and any number of multi-factor 2FA key providers can be combined to form a composite key. No way to reset or recover.

          1. Tristan Mayshark

            it’s not actually possible to “reset” your master password on lastpass without destroying all related information.

            That is, you can reset the account master password, but once you do you no longer have any access to anything which had previously been stored. So, that’s not an attack vector.

            1. JamminJ

              Yeah, read my comment again.
              I said, “reset 2FA”…. as in, you still must know the master password.

              LastPass has control over everything except the master password and the actual data it encrypts.
              As such, Social Engineering could potentially make 2FA ineffective, just like it does with using SMS for 2FA.

              So although using LastPass technically means you can use 2FA… it has some weaknesses and isn’t as good as users being able to control both factors.

        2. Kelv1n

          That is a contradiction in terms.. since it’s optional, it’s not required!

          1. Infosec Pro

            Required to log on to accounts for which it is optionally enabled. LastPass does not require it on all accounts, only on accounts for which the account owner chose to enable the option.

        3. Jacob

          No LastPass doesn’t/didn’t *require* 2fa. It’s an add-on service you had to pay for. It’s probably the same old story of an internet account protected by a weak or reused password without mfa protections. It’s 2021 and this is still a rampant problem even with people that know better.

          1. TheCyberGuy

            You’re wrong. They provide two forms of 2FA that do not require a subscription to implement.

            You should probably read up on things that you comment on before spreading misinformation.

            They have the “Grid” 2FA for free, and I believe that the Microsoft Authenticator 2FA is also free.

            You still have to pay for other forms of 2FA though, such as the Yubikey.

    3. Henk

      Must be via browser or local privileged access; and the user storing the master for ease of use (LastPass does have that function I recall; but warns when enabled).

      1. Susan Bernard

        Henk, that makes the most sense. I see so many people storing passwords in their browser like this–something I’m never comfortable with. If the user has stored his/her LP master pw in Chrome and is synching Chrome logins and settings across devices, it’s just a matter of breaching that user’s Gmail account to access passwords stored in Chrome. Not everyone has enabled 2FA on their Google login, of course.

    4. Craig D

      The article actually says “privileged credentials that were previously stored in the LastPass account “. The way it’s worded is a little ambiguous. If the information was “previously stored in the LastPass account”, when and how exactly did the credentials get out of the LastPass account. Was that part of the breach? It’s just odd and slightly ambiguous wording.

      1. Greg V

        Sounds like they had an export of this former employee’s LastPass password file.

        1. Susan Bernard

          Aha! Greg, that’s gotta be it. He exported to CSV but failed to secure (or permanently delete) the clear text CSV file. Yikes. Look at the damage one tiny human error can do to an entire organization.

  2. BobUpndown

    I love how the employee that works in security has all the answers AFTER the hack…how about he thinks about this stuff before the attack and saves himself and us all form his vitriol!

    1. Timh

      The company wasn’t interested in mitigation after the attack.

      Doesn’t sound like a company that would spend money on security before the attack, does it?

    2. Mahhn

      You sir are silly.
      This: “I love how the employee that works in security has all the answers AFTER the hack”
      is the same as this: I love how the Doctor that works in viruses has all the answers AFTER the sickness”

      1. joe dee

        Doctors treat, they do not prevent, that is up to the individual. A thing called freedoms.

    3. Kenneth

      You understand that he is a contractor who was contracted after the breach was detected right? That’s what the article says. Stop speed reading.

      1. TimH

        “A security professional at Ubiquiti who helped the company respond to the two-month breach beginning in December 2020”

        Doesn’t say or imply either contractor or perm. staff.

    4. JustASecurityGuy

      In big corporation, it’s all about money. One security administrator yelling around about security holes and how to patch them, usually is not loud enough. Sad but true for many Fortune 500. It is indeed harder to steer Titanic.

      1. blake

        thats what happens when you are pushing security from the bottom. Security needs to be a top level spot. Officer or equivalent

        1. Phil

          The Krebs ran a story where he suggests doing that, after going into how most of the top companies are still making IT security a 2nd-rate priority

          1. Thomas

            2nd priority is one thing which is especially troublesome at a tech company like ubiquiti. Seems I made a good choice avoiding their stuff. Always had an Apple-like feel to it, overpriced average stuff nicely packaged. (To be fair apples hardware is nowadays actually top-notch).

            Anyway what I find more worry some is the prevalent pseudo-security like where I work. Stupid password rules that makes everyone write it on a post-it because on top of that you need to change it every 60 days. Guys, we all already have a badge for building access. Update it to a smartcard and give everyone a reader? All laptops ship with a fingerprint scanner. But IT disables it. Intranet sites are 90% http. So basically any authorization to apps is pointless as a disgruntled employee could easily get access if he wanted to by stealing SSO tokens.
            At the same time we can just plugin any usb device without restrictions. Yeah it’s great for convience but then don’t go pretend to do something about security if the good old “drop USB sticks in parkinglot will 100% work”.

    5. JamminJ

      I love how you are a perfect example of Monday morning quarterback.
      Hindsight being 20/20 and all.

  3. Watching and Waiting

    Can you say “Jail” baby!

    I doubt that stock price most recent cited by NK in the article isn’t gonna hold up for long. Indeed it is down 6+% intoday’s session on NYSE

  4. Roberto

    It is even worse: Ubiquiti forced all users to use cloud-based authentification even for accessing your controller software on a local network with a local client. This was not even properly communicated but deployed by one of the regular maintenance updates. A lot of people raised security concerns within the community already.

    I hope there is a class action lawsuit anytime soon.

    1. Jeff Rathbone

      That’s not true at all. I run 2 controllers neither of which have to be connected to their cloud in order to be accessed or function.

      I’ve been hypercritical of Ubiquiti lately with the development of their UniFi product line as they have a significant firmware development problem going on right now. But what you mentioned simply is not true.

      That being said, I do not use their UDM or CloudKey product lines. I have stood up one UDM-Pro as a side project for a church, but I don’t recall if you had to utilize a cloud account for that 100%. I know they had local users, I just don’t recall if a cloud account was REQUIRED on setup. But I know for a fact that if you roll your own controller, you do not have to attach it to one of their cloud accounts.

      1. John

        You have to have to use a cloud account to set up the newer line UDM/UDMP, but you can disconnect the controller from their cloud after the initial setup to my knowledge.

        1. Martin

          This is also true of the CloudKey Gen2. After the update there is no way to setup the device with only local accounts, even when doing a factory reset. Your only option is to associate it with a Unifi account, and then disable remote access. But even then, this leaves you with an “Owner” account that still authenticates to the Unifi servers and grants access. There is no way to disable it. Ubiquiti is dead to me.

        2. Martin

          This is also true of the CloudKey Gen2+. After the update, there is no way to setup the device without logging into a Unifi account. Your only option is to use the cloud account, then add a local admin, then disable remote access. This removes the device from the Unifi cloud service. But even then, this leaves you with the Unifi “Owner” account permanently entrenched on the device, and that account can be used to log into the controller by authenticating against the Unifi account used to setup the device, and there is no way to disable it. Ubiquiti is dead to me.

    2. JamminJ

      It must really depend on the product line. I only use their access points and switches, so layer 2 only. No cloud key, just the controller running on a Linux box.
      I think I remember creating an account for ui dot com, but I was able to disable remote access immediately.
      Since I run my own controller, I can keep it on a VLAN with no access to the internet. Periodically I can enable access just to pull firmware updates. Which I guess might be risky now.

  5. Steve C#

    Brian, Many companies use Ubiquiti wireless access points for their wireless networks. I imagine these were also affected. This would have serious implications.

    1. Jeff Rathbone

      I would only see that being a problem if the company was attaching their controller to their cloud system. In my organization, it is not cloud connected. I’m very confused from the article stating that all device passwords need to be changed as that information shouldn’t be in the UBNT cloud. The devices communicate with an on-premise controller, the controller can be accessed by the cloud, but there shouldn’t be any association between the device passwords themselves and the UBNT cloud.

  6. Yyz

    I purchased a Unified Dream Machine (UDM) from Ubiquiti when it was first released. I was horrified that the setup procedure REQUIRED the device to configured with cloud based service run by Ubiquiti.

    After using the UDM for about 2 months I was never comfortable with the way their system needed to communicate with their service to function. I performed a factory reset and sold the device on eBay because it was past their allowed return date. I’m glad to have gotten rid of the device.

    I also have their Edge Router X, a nice device that has no such requirement.

    1. Jokerstein

      It was the case, IIRC, that you could NOT disable to cloud access for a while on the Dream Machines, but now you can, once you’ve created a privileged local account.

      That’s absolutely the first thing you should do.

      I HOPE that Ubiquiti learns from this, and allows these things to be set up without requiring any internet access, or allows you to set up a strong password locally before connecting to the internet.

      Ubiquiti used to be be a REALLY great product range between consumer and enterprise, but they caught a bad case of Marketing, and went down the crapper. It was one the case that relatively unsophisticated folks could do a simple, default install of their Unifi kit, and be secure. Not so much now.

      Whenever I set up a new Unifi system for my customer, I always have my handy Edge Router X available…

      1. Yyz

        I got rid of it before they changed that option, apparently.

        Even so, the fact it was that way at all gave me pause. They must have had enough complaints about that ridiculous requirement.

        Additionally, I found the device to be overly confusing and difficult to configure. I went back to my old, but easy to use Apple AirPort Extreme. I wanted 2 independent wireless networks and found it much simpler to just add a 2nd used AirPort Extreme attached to a separate vlan on the trusty Edge Router X.

        Much simpler and less expensive too! Probably more secure as well.

      2. trog

        > but now you can, once you’ve created a privileged local account.

        How do you do this? Just been looking through the interface and can’t see the option, nor the option to disable remote access.

        I just bought a UDM five days ago to trial as we’re moving into a new office and I’ve heard good things, but I was stunned to discover this requirement to use an online account to login. If I can’t easily disable it along with remote access, this story is enough to make me return it.

        1. yyz

          Return it! I found the configuration so confusing, I gave up and sold it on ebay for nearly the same price as I paid for it because it was past the allowed return date.

        2. Jokerstein

          I don’t have the interface in front of me right now, but IIRC:

          1. Go to the device in

          2. Create a local administrator account – make sure it has super admin privs.

          3. Select “Advanced” then “Disable Remote Access”.

          A simple web search should give you the exact steps.

  7. CaptHMM


    At last check (a few months ago) you can still setup and provision the controller and APs without having to use the cloud-based account. They don’t make it obvious, but the local option is still there, or at least it was quite recently.

    1. Yyz

      Using their cloud based service should be opt-in. I lost their trust long before this problem was discovered. They’re not doing security right.

    2. Martin

      Not on their CloudKey Gen2 and UDM devices. It is not possible to configure the devices without using a cloud account. It also leaves a permanent Unifi “Owner” account enabled on the device that can authenticate against the Unifi servers and grant access, EVEN IF you disable Remote Access.

    3. Martin

      Not on their CloudKey Gen2 and UDM devices. It is not possible to configure the devices without using a cloud account. It also leaves a permanent Unifi “Owner” account enabled on the device that can authenticate against the Unifi servers and grant access, EVEN IF you disable Remote Access. There is no way to disable this account.

  8. L2k...

    How are individuals supposed to keep their data safe when corporations won’t be accountable?

  9. Annie

    Reading some of these people commenting on defense… it’s easy to comment on some people’s ability to defend and find out what happened after the fact when you don’t know the politics of the organization, or how advanced the attackers actually were. Sounds like the attackers knew what they were looking for and what to do. Attacking is easy. You find one hole and get it. Defense is a lot harder because you have to plug all the holes and you have to prove why you need security mechanisms, and management doesn’t always agree because it’s an “acceptable risk” and they have “insurance”. The fact that the team was able to find out what happened after the fact is actually amazing. Some teams aren’t even that good.

    1. pestaa

      Attacking is easy? But enabling multi-factor authentication on a root level AWS administrator account is hard?

      1. Jerome Patrick

        Exactly! Did everyone miss this fundamental?

    2. John

      “Ubiquiti had negligent logging (no access logging on databases) so it was unable to prove or disprove what they accessed, but the attacker targeted the credentials to the databases, and created Linux instances with networking connectivity to said databases”. I think this alone is damning. I don’t think you can say they had good logging when they don’t log who accessed their data, which most companies will tell you, is their most valuable asset.

      Also some of the wording such as “targeted” and “attacking is easy” is disingenuous. The only thing we know is an IT person got popped and they used those creds for initial access and the AWS root account didnt have MFA.

      The creds is par for the course of attacks, but no MFA on an internet accessible highly privileged account, like AWS root, is not acceptable by any organization.

      1. Watching and Waiting

        Your point is on point, John, and you, pestaa, and Jerome are correct. However, you all missed what was behind the original poster, Anne’s, comment. Anne seems to work in an enterprise that, perhaps like Ubiquiti, decided the risks they assume were acceptable. In other words, Anne works somewhere with idiot leadership and frustrated IT folks.

        I suspect Anne’s experience is more common that we realize and points to the real issue – corporate leadership. In all likelihood that failure of people at the top stems from a desire to make the books look good, ignorance, distrust of the IT folks giving advice (they really would not be seen as core to the entity’s mission as they do not make whatever product or service the entity sells), and a willingness to put profit above the concerns of their customers.

        Smart IT folks can do nothing without support from on high.

  10. Stratocaster

    Ubiquiti is well-named: breaches to its products are everywhere. “countless Ubiquiti cloud-based devices around the world”

    1. yyz

      “This notice may constitute attorney advertising”….ugh

  11. Matthias Urlichs

    As usual, companies that manage to get all of hardware, software *and* security right are few and far between.

    Their hardware is actually quite nice, so taking these devices offline and installing OpenWRT (or something similarly reasonable and non-cloudy) on them is likely to be a very good idea.

  12. Louise

    Ha ha ha ha.

    This on Ubiquiti Wiki:


    In 2015, Ubiquiti revealed that it lost $46.7 million when its finance department was tricked into sending money to someone posing as an employee.[16]

  13. deek

    It’s interesting that no one is talking about the need for a whistleblower to inform the public. If the security community or even the public accepts zero transparency from a major company like Ubiquiti, then we are all to blame for their failures.

    I’m not someone who likes a lot of “rules”, but it seems to me that Ubiquiti and a lot of other large corporations would benefit from regulation around data breaches.

  14. Austin Rivet

    For those who own Ubiquiti devices and/or run Ubiquiti networks and have yet to take action, at the very least you should:

    a) Change your Ubiquiti cloud account password (
    b) Enable 2FA on your cloud account

    Ubiquiti has fairly comprehensive documentation on the different sets of credentials used in Ubiquiti products and services.

    Unfortunately I don’t think there’s going to be a one-size-fits-all approach to mitigation. It’s going to depend on which devices you are managing and what your environment looks like. Again, at the very least fix-up your UI account and then take a look at that document to see which credentials sets are applicable.

    1. Martin Diers

      In this case, 2FA would do nothing. The 2FA secret is stored in the database, and once one has root access, all those secrets are revealed. Anyone with the secret can create a valid TOTP code.

      That’s what’s so scary about Ubiquiti’s behavior on this thing. They have completely broken trust, leaving the only safe option as: DON’T use a Unifi firewall. Have a local admin account; Disable remote access to DMP or CloudKey; and block all outbound ports from DMP/CloudKey at the firewall except for NTP; download firmware updates manually.

  15. The Sunshine State

    Another great article, keep them coming !

  16. SeymourB

    You know, I always looked longingly at those excessively expensive cloud devices Ubiquiti put out, when all I could afford were EdgeRouters and the like, which all use local accounts and local configuration.

    Now I don’t feel so bad.

    I hope the people who got my passwords on ubiquiti appreciate that those passwords are unique to each website so gfl using them on another website.

  17. Bill Dachelet

    tiny typo – missing “not”.

    The attackers also provided proof they’d stolen Ubiquiti’s source code, and pledged to disclose the location of another backdoor if their ransom demand was met.

    should read:

    The attackers also provided proof they’d stolen Ubiquiti’s source code, and pledged to disclose the location of another backdoor if their ransom demand was NOT met.

    1. BrianKrebs Post author

      No. The attackers said they’d tell Ubiquiti where the backdoor was if they paid.

      1. Bill

        Thank you for pointing out the text was correct. I did not understand. Pledging to disclose the location of another backdoor if their ransom demand was met is on a higher level of ugly than I was thinking.

  18. Paul

    “The attacker(s) had access to privileged credentials that were previously stored in the LastPass account of a Ubiquiti IT employee” ……. I’m guessing reused breached credentials….. user: Admin…..Password: Dumbass1!..

  19. Lindy

    I wonder if anyone at Ubiquiti was fired in November 2020….hmmmmm….

  20. DataHoarder

    Can’t wait to get my hands on this data, is it selling anywhere on the darkweb?? Thanks a lot Ub!qu!t!

  21. Sean

    I was immediately suspicious of this company and it’s products as soon as it “hit the scene.” Convenience is often the number 1 selling feature, even if it’s not really there. You either understand what you’re doing or you don’t, lots of white space in your config pages doesn’t change anything.

  22. Sev

    The article doesn’t say that an employee’s LastPass account was accessed. It only says that the information that was accessed was PREVIOUSLY stored in an employee’s LastPass account.

    “Adam says the attacker(s) had access to privileged credentials that were previously stored in the LastPass account of a Ubiquiti IT employee…”

    So this is only provided for completeness with regard to what Adam said and isn’t really relevant to the narrative.

  23. Eric Nix

    I’m curious if anything more than changing passwords and enabling 2FA is needed. Is there any way to tell if anyone accessed your devices? I would be concerned that a packet sniffer would be installed and could obtain information/passwords etc.

    1. El monito

      That’s where the biggest issue is. The article mentions that source code was part of the breach, which has potential value in the black market.

      Once your product source code is available, it is easy to find vulnerabilities and test them. Unfortunately, that will the lesser of evils.

      If the company didn’t pay, a more nefarious actor that paid could have already injected itself in the software pipeline. Because the article implies bad security practices, a proper incident response wasn’t probably part of their culture, and the extent of this is really unknown.

      In other words, the article headline is accurate. It is “catastrophic .” This goes beyond changing passwords and access to your systems, the device software can’t be trusted either.

  24. Doug Bostrom

    Remote access is a key feature of Ubiquiti’s system. Lots of this gear is remotely managed as a basic requirement.

    Which is why UBNT of all companies should have been more vigilant about this, and especially more forthcoming and more proactive as suggested.

    > “I was immediately suspicious of this company and it’s products as soon as it “hit the scene.” Convenience is often the number 1 selling feature, even if it’s not really there. You either understand what you’re doing or you don’t, lots of white space in your config pages doesn’t change anything.”

    That remark is a clear indicator that the comment isn’t informed by actual experience w/UBNT gear.

  25. Doug Bosttrom

    Remote access is an inherent requirement for this gear in many installation contexts, so disabling RA is a non-starter (unless engaging in multi-day journeys to strange places to do minor configuration changes/updates/etc. is acceptable).

    Which is why UBNT hopefully has a very good excuse for why the breach happened, and of course is why UBNT should have been more forthcoming and more proactive as suggested.

  26. Belli H.

    Brian, do you think more and more companies are following this sort of lead?

    Either downplaying and/or blaming a third party vendor for a breach that was ultimately their fault in either not addressing it quickly and/or taking it serious?

    Reading this, I am so glad (or feel lucky) that I didn’t go with Ubiquity when setting up the offices last year. it was close, and they were one of the final two choices but it was decided to go with another vendor.

  27. John Lin

    I’m curious about this IT guy. Does everyone in IT at Ubiquiti have the God mode IAM role?

    1. Matt Little

      The root account has to live somewhere. 2 people (2 lastpass accounts) can each store it. 1 shared lastpass account can store it.

      Security is about defense in depth. Did the lastpass account use MFA? Was AWS configured to write to an SNS topic and deliver an alert every time a root credential was used in any region? Was AWS configured to write to a different SNS topic and send an alert email/other every time an instance was launched in the production subscription?

      There are a lot of unknowns here.

      The article is quite good (as usual) and the illustrates all of the usual suspects are on the field. Legal is downplaying it or outright restricting the truth in order to protect the company. There is a lack of effective security being pushed down from the top. You can have the most aggressive security officers in the industry but if they’re not enabled and its not given a priority, it simply doesn’t happen effectively.

  28. OJ Bender

    A cloud-based credential store for IT admins? WFT? Is this their interpretation of professional, secure operations? I wonder what the NIST otr ISO27 auditor would say. What a fail.

  29. Tim Tanner

    I went back through my emails because I realized I’d never seen this account notice, only to find out that it went to my spam. I asked two other people with accounts… same thing. Really curious how many people never saw that original notice and how a company the size of Ubiquiti can’t craft an email that doesn’t get caught in spam, especially considering it’s the only email from them that has ever been filtered into spam for me.

Comments are closed.