Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Wednesday September 01 2021, @12:24PM   Printer-friendly
from the government-doesn't-want-you-to-have-encryption dept.

Microsoft Azure Cloud Vulnerability is the 'Worst You Can Imagine'

Microsoft Azure cloud vulnerability is the 'worst you can imagine':

A flaw in Microsoft's Azure Cosmos DB database product left more than 3,300 Azure customers open to complete unrestricted access to hackers since 2019 when Microsoft added a data visualization feature called Jupyter Notebook to Cosmos DB. The feature was turned on by default for all Cosmos DBs in February 2021.

The Microsoft Database Hack Shows That Data Stored in the Cloud Must Always be Encrypted End-to-End.

The Microsoft database hack shows that data stored in the cloud must always be encrypted end-to-end.:

IT security specialist Ami Luttwak from Wiz discovered the vulnerability in the Azure Cosmos DB Jupyter Notebook Feature on Aug. 9 and reported it to Microsoft three days later. Microsoft published this statement saying it immediately fixed the issue. Microsoft thanked the security researchers for their work as part of the coordinated disclosure of the vulnerability. Microsoft also told Wiz via email that it planned to pay out $40,000 for reporting the vulnerability.

On Aug. 26, Microsoft notified several thousand of its cloud customers affected by the issue via email. In the message, the company warns its customers that attackers had the ability to read, modify and even delete all of the main databases. Luttwak managed to gain access to primary read-write keys, which he used to gain full access to customer databases. Because Microsoft could not change these keys itself, the company asked its customers to take action and exchange this primary key of CosmosDB as a precaution. Although the security hole has already been closed, customers should take this step to finally prevent a possible compromise of the databases. Microsoft further writes in the message that they have found no evidence that third parties (with the exception of Wiz) have accessed the keys.

[...] The U.S. Department of Homeland Security's Cybersecurity and Infrastructure Security Agency used stronger language in a bulletin, making clear it was speaking not just to those customers that had been notified, but to everyone using Azure Cosmos DB:

"CISA strongly encourages Azure Cosmos DB customers to roll and regenerate their certificate key".

[...] Luttwak said: "This is the worst cloud vulnerability you can imagine. This is the central database of Azure, and we were able to get access to any customer database that we wanted."

For European Azure cloud customers who have personal data stored in a Cosmos DB instance, there is also the question of whether a precautionary GDPR notification must be sent to the responsible data protection authorities within 72 hours due to a possible security incident.

[...] The hack of Miscrosoft's Azure database shows once again that encryption is the best tool we have to fend off malicious attackers and to keep our data safe.

When data is stored in the cloud, the only way to properly protect this data is end-to-end encryption - free from any kind of backdoor.

See also: ChaosDB: How we hacked thousands of Azure customers' databases:


Original Submission #1Original Submission #2Original Submission #3

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 5, Touché) by Rosco P. Coltrane on Wednesday September 01 2021, @12:33PM

    by Rosco P. Coltrane (4757) on Wednesday September 01 2021, @12:33PM (#1173225)

    Microsoft - proudly supplying unstable and insecure software since 1975, and sticking fast to the tradition.

  • (Score: 2) by PiMuNu on Wednesday September 01 2021, @12:55PM (6 children)

    by PiMuNu (3823) on Wednesday September 01 2021, @12:55PM (#1173227)

    > When data is stored in the cloud, the only way to properly protect this data is end-to-end encryption - free from any kind of backdoor.

    This is interesting. M$ (and google, amazon, etc) are doing their best to obfuscate the boundary between HDD and cloud, because cloud means lock-in. That seems to go contrary to this concept.

    Also, is it standard practice to e.g. encrypt DB entries (for example if my CMS is hosted on M$ et al)? What's the CPU overhead to that?

    • (Score: 2, Informative) by Anonymous Coward on Wednesday September 01 2021, @01:11PM (3 children)

      by Anonymous Coward on Wednesday September 01 2021, @01:11PM (#1173233)

      Standard practice is to go with whatever is cheapest (short term).

      • (Score: 0) by Anonymous Coward on Wednesday September 01 2021, @05:09PM (2 children)

        by Anonymous Coward on Wednesday September 01 2021, @05:09PM (#1173309)
        Many large organizations seem willing to move stuff to the "Cloud" for various other reasons even if it'll cost more.

        Disclaimer: I'm currently helping out in a team that's being paid to help move stuff to the Cloud. Doesn't look cheap to me. But of course why should I care? :p

        Hey if they wanna pay more to make it easier for the NSA and Five Eyes to datamine them, we're happy to make it our business.

        But seriously if you can't run your datacenter cheaper than MS's datacenters in Hong Kong/Singapore (the last I check real estate and labor costs aren't that cheap in those places) then maybe you should actually find out what you're doing so badly wrong and improve.
        • (Score: 5, Insightful) by Unixnut on Wednesday September 01 2021, @07:36PM (1 child)

          by Unixnut (5779) on Wednesday September 01 2021, @07:36PM (#1173388)

          > Many large organizations seem willing to move stuff to the "Cloud" for various other reasons even if it'll cost more.

          Well yes. I have experienced the same. Usually it is because it is faster to add capacity in cloud than on-prem. I put the problem down to "Developers".

          Modern developers seem to not care one bit about efficient resource allocation, if their app/website thingy with 4 layers of frameworks and random libraries pulled in from the internet gets bogged down in execution, they just spin up more resource without a care as to how it is provided.

          They call themselves "Cloud native developers", and so far all that seems to be is someone who can pull in random bits off the internet into some kind of aesthetically pleasing (to management) yet ultimately unsupportable online app, all the while consuming a few racks of server power to do in essence simple computations.

          Problem is they are popular with businesses now. Managers and sales droids love to sing the praise of "how we are are cloud native company", so these developers correspondingly are given a lot of influence in the company. So when their app gets bogged down in client demos, in production, or their build pipeline requires so much resource to assemble it all that it drags out releases beyond client deadlines, their instinct is to request more resources to run it.

          Problem is, you can't just magic servers there and then. Unlike AWS, where you are always a few clicks away from apparently unlimited resources, in on-prem deployments if you want more resource, we have to buy it, get it delivered, rack it up, etc.... Especially now with the silicon shortage, we are getting 6 month lead times for delivery of hardware.

          So when the app gets bogged down, the developers shift the blame on the IT department, saying we can't provide the service needed to run the app, and the company should "move with the times", and go "fully cloud native". The only reason it has not happened yet is because every time they tried to shut down the IT department and migrate the entire stack to the cloud, the accountants have a mini heart attack when they see the cost to replicate the compute power in the cloud (it is a hell of lot cheaper at our scale to do stuff on prem with a private cloud, rather than use the public cloud providers).

          So we currently run hybrid cloud and on prem, but their push to be fully in the cloud is relentless.

          IMO the main problem is the developers who request the resource are not the ones who pay for it. I am sure if their bonus and salaries were directly tied to the costs of running the code they wrote, we would see an explosion in computational efficiency. However it isn't like that, they request it, we have to provide it, and the accountants pay for it. I can't imagine what the politics is like between the division heads, but it must be entertaining to third party observers.

          • (Score: 2) by mobydisk on Thursday September 02 2021, @06:18PM

            by mobydisk (5472) on Thursday September 02 2021, @06:18PM (#1173804)

            Modern developers seem to not care one bit about efficient resource allocation...they just spin up more resource without a care as to how it is provided.

            Sometimes that is the right approach. It is a trade-off between development dollars -vs- deployment dollars. Suppose I have $0.5 million to develop and launch a product. That's only gonna get me a couple of engineers for a year. It might be better to spend the recurring cloud costs than the up-front development costs. It could be that developing the efficient system would have cost me another $200k that I didn't have and the product never came to be. But the inefficient product is out there, generating revenue.

            Also understand scale-out designs are often inherently inefficient. For example, an in-process in-memory database is very efficient, but it can only be accessed by one server. A SQL database located on a separate box with a load-balancer and a cache is less efficient but more scalable.

            I can't imagine what the politics is like between the division heads

            It should be an engineering + finance decision not a political one. My employer has a team in a similar spot: the team spends more cloud $ than any other team (for good reason), so they are under constant pressure to save money, so they have fewer build servers in their CI pipeline than the other teams. But that's dumb: if those build servers save the company development money, then they should spend it. This happens when a department head looks at a top-level budget line-item and attacks the biggest number.

    • (Score: 4, Insightful) by ElizabethGreene on Wednesday September 01 2021, @01:32PM (1 child)

      by ElizabethGreene (6748) Subscriber Badge on Wednesday September 01 2021, @01:32PM (#1173239) Journal

      There are three types of encryption relevant for databases.

      At-Rest - encryption on disks/blobs/LUNs
      In-Transit - encrypt in transit between the server and client
      Both of those types of encryption are transparent to the application.

      I believe the OP is referring to the last type of encryption, Cell/Row/Application level encryption. In this, the app (or the data access layer of the app) encrypts the data before or as it gets into the database. This is far less common than the above options.

      It sounds like this vulnerability wouldn't have been mitigated by either at-rest or in-transit encryption, only application level encryption.

      • (Score: 4, Informative) by lentilla on Thursday September 02 2021, @04:15AM

        by lentilla (1770) on Thursday September 02 2021, @04:15AM (#1173563)

        Just to expand a little on why application-level encryption for databases is quite rare. After all; encryption is a good thing; right? The complication is that implementing this ranges from convoluted to completely negating the use of a database in the first place.

        Take a (contrived) example. You have a database containing a table called payoffs. It has the following columns: name (a string), picture (a JPEG as a series of bytes), and bribe (an integer). Now, let's say we want to find the names of those recipients of considerable largess:

        select name from payoffs where bribe > 10000;

        The great benefit of using a database is that the application can offload all the work of storing and retrieving that information. Database engines - now a very mature technology - have wickedly clever code that does this efficiently, quickly and reliably.

        (At this point, it is worth pointing out that end-to-end encryption between the application and the database server is likely being used (it certainly is best practice). The application doesn't need to know - it doesn't care - end-to-end encryption is transparent and easy. Nobody can "wiretap" the network in-between and read the communications.)

        Now let's say we want to encrypt the data itself. Threat case: we want to ensure people see only junk if they somehow download a copy of the database (or have admin-level access to the database server). Not difficult, we simply encrypt the contents of each cell. (Someone with a copy of the database can still see "metadata": the names of the fields, and the number of fields, but at least they are unable to easily read the data.)

        We now have a problem. No longer can we ask the database server a simple query like the above SQL example because the database engine can not see the data to make a match (specifically, the amount of the bribe). In order to do a query, we have to download the entire database and run the query locally. Which more-or-less defeats the entire purpose of having a remote database server.

        Of course, hybrid solutions are available. One could store the name and the bribe amount in the database, but encrypt the contents of the picture. That way we could do queries per normal - provided whatever we encrypt is merely stored rather than being matched against, this would be a viable strategy. No doubt there are other strategies.

        So; in summary; the reason that databases are rarely encoded on an application-level is that it nixes the primary benefit of using a database engine: the ability to run queries on the data. Hybrid solutions provide a way to selectively work around these issues, but at the end of the day, your database needs to be secure at both a network and a physical level. At the point where you need to ensure security of the actual data, you really must have complete control over your database and The Cloud in not a viable solution.

  • (Score: 5, Insightful) by janrinok on Wednesday September 01 2021, @01:16PM (7 children)

    by janrinok (52) Subscriber Badge on Wednesday September 01 2021, @01:16PM (#1173234) Journal

    Time and time again we have seen attempts to pass laws giving some parts of government and law enforcement access to all data on the internet. In effect by using backdoors, they don't want your data to be secure. This aim, of course, entirely contradicts the advice being given here: all data in the cloud should be encrypted - and not by the cloud company itself.

    There is no such thing as a secure back-door to encryption.

    • (Score: 3, Informative) by PiMuNu on Wednesday September 01 2021, @01:22PM (5 children)

      by PiMuNu (3823) on Wednesday September 01 2021, @01:22PM (#1173236)

      > all data on the internet.

      Which, to be clear, means almost *every single financial transaction and bank account* in the world.

      • (Score: 2) by MIRV888 on Wednesday September 01 2021, @01:39PM (3 children)

        by MIRV888 (11376) on Wednesday September 01 2021, @01:39PM (#1173241)

        The NSA doesn't care. They are up in everyone's biz. They have been from the outset of the interwebs. National Security trumps (lol) your rights. It's as simple as that.

        • (Score: 2) by PiMuNu on Wednesday September 01 2021, @02:10PM (2 children)

          by PiMuNu (3823) on Wednesday September 01 2021, @02:10PM (#1173247)

          My comment wasn't really about rights, which is very abstract. It was more about the (trillions) of $ of transactions that are vulnerable to these back doors.

          Remember, the NSA are not L33t black ops. They are a bunch of coke addled cowboys.

          • (Score: 2) by HiThere on Wednesday September 01 2021, @03:00PM (1 child)

            by HiThere (866) Subscriber Badge on Wednesday September 01 2021, @03:00PM (#1173264) Journal

            I suspect that *some* members of the NSA are, indeed, "L33t black ops". Those, however, are unlikely to be the ones making decisions. I'm not as sure about the "coke addled cowboys". And even the "L33t black ops" don't necessarily have morals, ethics, and goals that you would find acceptable. Or, indeed any of those qualifications.

            --
            Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
            • (Score: 3, Interesting) by PiMuNu on Wednesday September 01 2021, @03:35PM

              by PiMuNu (3823) on Wednesday September 01 2021, @03:35PM (#1173275)

              They had a case a few years back where one of the NSA guys leaked some data - in the court case all sorts of dirty washing was aired, it turned out that for example the NSA guys all used the same password (something crass like admin123) for their database, with the usual snarky office politics going on. I can't find the case now, maybe someone else has access. OTOH I have lots of searches for "CIA NSA leaks" in my browser history which will probably make some TLA happy.

      • (Score: 1, Troll) by aristarchus on Wednesday September 01 2021, @07:09PM

        by aristarchus (2645) on Wednesday September 01 2021, @07:09PM (#1173378) Journal

        But not the identity hashes of SoylentNews. Just saying.

    • (Score: 3, Insightful) by DannyB on Wednesday September 01 2021, @03:23PM

      by DannyB (5839) Subscriber Badge on Wednesday September 01 2021, @03:23PM (#1173272) Journal

      Time and time again we have seen attempts to pass laws giving some parts of government and law enforcement access to all data on the internet. In effect by using backdoors, they don't want your data to be secure.

      Oh, but they do claim that they want it to be secure!

      They say that surely these mere nerds can figure out a way to make the data both secure against undesirable disclosure, yet insecure against desirable disclosure to your friendly government. Don't worry about the government, they can be trusted! And if you don't believe it, just ask them. Think of government as a helpful friendly older male sibling. A big brother of sorts.

      It should be simple for the geeks. Only two requirements.
      1. Totally secure and unhackable by anyone. Ensuring total privacy of data.
      2. Insecure and easily hackable whenever there is a court order, or some government official wants to know something but doesn't want to trouble the court with such a minor nuisance request in between donut breaks.

      That is a very short and thus easy list of requirements.

      --
      People today are educated enough to repeat what they are taught but not to question what they are taught.
  • (Score: 3, Informative) by Freeman on Wednesday September 01 2021, @02:17PM

    by Freeman (732) on Wednesday September 01 2021, @02:17PM (#1173251) Journal

    It's pretty simple. In the event that you didn't used to send your data anywhere and now you propose to do the whole cloud thing to save a bundle of cash. You are opening yourself to a whole new set of attacks, that you didn't used to have to worry about. Sure, the whole, security through obscurity isn't really security. Still, in the event that your data wasn't online, now it is, and that opens a whole new can of worms, security wise. Also, large cloud infrastructures, make nice juicy targets. Sure doesn't help when they botch things themselves, either.

    --
    Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
  • (Score: 5, Insightful) by bradley13 on Wednesday September 01 2021, @02:36PM (2 children)

    by bradley13 (3053) on Wednesday September 01 2021, @02:36PM (#1173255) Homepage Journal

    ...there is only someone else's computer.

    While the big companies may do a better job at security than some rando, when they fail they fail big.

    The C-suite executives think they can reduce or even scrap their IT department by moving stuff into the cloud. Just as an example: how many companies either don't make backups of their cloud data, or make backups but leave them in the (same!) cloud?

    Using somebody else's computer makes sense in certain scenarios. However, imho those scenarios are pretty limited. The larger the company, the less sense it makes, because they can (and should) do more in-house.

    --
    Everyone is somebody else's weirdo.
    • (Score: 4, Insightful) by DannyB on Wednesday September 01 2021, @03:25PM

      by DannyB (5839) Subscriber Badge on Wednesday September 01 2021, @03:25PM (#1173273) Journal

      While the big companies may do a better job at security than some rando, when they fail they fail big.

      While what you say it true, Microsoft doesn't want to limit themselves to only failing big.

      --
      People today are educated enough to repeat what they are taught but not to question what they are taught.
    • (Score: 2) by Tork on Wednesday September 01 2021, @05:55PM

      by Tork (3914) Subscriber Badge on Wednesday September 01 2021, @05:55PM (#1173335)

      Just as an example: how many companies either don't make backups of their cloud data, or make backups but leave them in the (same!) cloud?

      I don't know the answer to that. What I do know is when I worked at a place with in-house IT nobody was bragging about how awesome their backup strategies were, either. "Oh I just copy it to a USB drive. I found a bunch on sale!" To quote the immortal Henry Jones: "Our situation has not improved." I did work at a place where I felt it was done right. but I'm pretty sure there were lotsa big salaries being drawn that the management thought was an undue burden.

      --
      🏳️‍🌈 Proud Ally 🏳️‍🌈
  • (Score: 4, Funny) by Opportunist on Wednesday September 01 2021, @04:08PM (2 children)

    by Opportunist (5545) on Wednesday September 01 2021, @04:08PM (#1173287)

    Cloud, English, word for fluffy looking thing in the sky, homophone to klaut, German, imperative plural of "klauen", to steal.

    • (Score: 0) by Anonymous Coward on Thursday September 02 2021, @01:15AM (1 child)

      by Anonymous Coward on Thursday September 02 2021, @01:15AM (#1173500)

      More often third person singular present tense. er klaut = he steals.

      • (Score: 2) by Opportunist on Thursday September 02 2021, @07:28AM

        by Opportunist (5545) on Thursday September 02 2021, @07:28AM (#1173602)

        I prefer to consider it the imperative plural, as in "klaut!" (command to a group of people to "steal!").

        I mean, it is like some kind of invitation or prompt, don't you think?

  • (Score: 4, Insightful) by Gaaark on Wednesday September 01 2021, @08:15PM (3 children)

    by Gaaark (41) on Wednesday September 01 2021, @08:15PM (#1173391) Journal

    Microsoft could release a patch that completely wiped out all data and backups, destroying everything every user had and these sheeple would still go "Well, it could have been worse: i'll just reinstall windows and hope for the best".

    Come on people: get a real OS...or say it with me: "Baaaa, baaaaaaa, baaaaaaaaaaaaaaaa"

    Sheesh.

    What will it take?

    --
    --- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
  • (Score: 3, Informative) by turgid on Wednesday September 01 2021, @09:01PM (1 child)

    by turgid (4318) Subscriber Badge on Wednesday September 01 2021, @09:01PM (#1173407) Journal

    Microsoft's new slogan: "We don't want your business. Take it elsewhere."

    • (Score: 3, Funny) by DeVilla on Tuesday September 07 2021, @06:03PM

      by DeVilla (5354) on Tuesday September 07 2021, @06:03PM (#1175415)

      Well, you can't accuse them of customer lock-in. Your data can be migrated out through no effort on your part.

(1)