PeopleDAO “exploited” by Google Docs edit
twitter.com
twitter.com
DAO stands for "decentralized autonomous organization." This thing appears to collect transactions via a centralized google form and then complete those transactions if 5 of 9 people vote to perform them. Neither decentralized nor autonomous.
You go through all this effort to establish something fancy using whatever hot defi thing exists but situate it on top of a google form and a spreadsheet just owned by some guy.
Also, I can't believe that the form uses scientific notation for amounts. How unbelievably error prone to miss that one row has a "+" instead of a "-".
The lessons learned should be "holy fuck don't run everything on a google sheet" not "be more careful with how you share links and make sure the signers are uber careful to review 80 rows of boring transactions for single-character swaps."
Unreal: https://twitter.com/The_PeopleDAO/status/1634524761744367616...
"Most DAOs do use spread sheet for collecting information and accounting. What tools do you suggest to use instead?"
I did not realize that was actually how this operated.
https://en.wikipedia.org/wiki/The_Million_Dollar_Homepage
Actually that would be a pretty neat NFT project. With each pixel having its RGB value and a link stored on chain, the entire image could be reconstructed without having to be hosted anywhere in specific.
Dibs on Row 13!
the only people dumber than those who believe this excuse are those that invested in it. 10/10.
How about a solution where the approvers need to forfeit a significant amount into escrow accounts to cover losses and receive a portion of the payout for their efforts and investment. Any payout would be systemically limited to the total amount held in escrow.
Writing this I realize that this perfectly describes a traditional financial institution. Not such a radically new idea.
PeopleDAO held title to property (in the form of Ethereum tokens that were allegedly stolen), making it a club of sorts, but not a DAO.
They really cannot interface with the Real World, without leaking real-world problems into the "perfect" smart contract-driven crypto systems. They can't interface with the real-world financial systems (with stablecoins) and expect it to be always stable (see USDC), they can't interface with people doing real-world chores/tasks and have it reflected in blockchain brownie points aka tokens (like socially-useful DAOs like the one in the article), they can't interface with logistics where people and machines do actual work and fail unpredictable (like blockchain tracking of the supply chain), they can't authenticate artwork purely on blockchain (without paying actual people to guard the artwork), etc.
They just can't. All projects claiming they can are pure scams (of course, I'd be very happy to be proven wrong).
The nearest we can get to having perfect digital systems like cyptoanarhysts and cryptobros (sometimes there isn't any difference) advocate is to give up on the physical world and actually move everything into the metaverse where it doesn't depend on real world messyness, but then a) people will still find ways to mess things up and b) this Matrix-like system still needs electricity.
Just... embrace the messiness. You can't really escape it. Crypto is not special. Blockchains are useful tools, but so far, systems based on them they have not been proven to be strictily better than real-world messyness.
The best use cases for blockchains are those which don't really earn a lot of money for the operators, such as tracking publically visible official data - like university degrees, corporate tax returns and financial statements, fighting fake news, etc. - so they are avoided like the plague.
This has been known and ocassionally touted for AGES. I've attempted to start a couple of such projects and have been following the progress of other projects with similar ideas.
There has been near ZERO interest for them, because there's no currently viable business case for such projects, except "let the government pay for it." Data mining isn't THAT useful if there's no data in there - who would force entities like companies, universities or the SEC to push the data into the blockchain?
I'd be very happy if could find funding for https://github.com/WOTvision/wot1 and I can see a business case for it as a potential platform for legal, paid distribution of news between creators/reporters and distributors like news portals. But even so, no takers.
Or I guess namecoin [1] sounds like it could work with a critical mass for adoption. But it seems to be a real subset of real world problems that are solvable. Things that inherently make sense being protocols and distributed I guess, I'm not sure if there are other classes of problems that could work well as 'web3' things
Fucking lol at their bookkeeping and payout system just being a spreadsheet with no other comparison of truth before submission.
We're on course for DAOs to rediscover the basic principles of our existing financial system within the decade.
At least that was my experience of 20->30. I can't even think of a long sentence that encapsulates my world view anymore, let alone a single word like "conservative", "anarchist" or whatever.
When I was 20 I could have easily done so.
There is no order, only confusion.
But for this? Cryptobros running bookkeeping over Google Docs and collaborating on their project via Discord? Crying to the FTC and FBI, the centralized arbiters their own model casts aside?
By all means, point and laugh. These people and their projects need crucified publicly. It's nothing personal. They were asking for it: this should be obvious, and it should be obvious why. If it's not, they need to find a new line of work.
> We offer the hacker a 10% white hat bounty if he/she would return the stolen fund in next 48 hrs.
I just can't, hahaha. You left your car unlocked with the keys on the dashboard. It's on a boat on its way to a 3rd world country with its plates removed and serial numbers ground off. Good luck.
But when things go wrong they run to the FBI and FTC both run by the government.
> The accounting lead mistakenly shared a link with edit access in a public channel in discord. The hacker gained edit role via the link.
It might not be a real hack in the traditional sense, but hiding critical information so a human makes an incorrect choice is good enough to be considered social engineering for me.
That's like saying passwords are "security through obscurity" because they're also "obscure" random strings, just like URLs.
To try and make my point more clear:
Basic auth password url: https://username:randomSecurePassword@webpage.com
Google docs edit url: https://docs.google.com/randomLongString/edit
How are those two things different, other than one is a password which might be short and insecure, and the other has plenty of entropy? Will you also argue that all shared secrets are security by obscurity?
How they're used? I mean, we can argue that pizzas are wheels because they're circles, but, until you throw one on a car and get where you're going, no one will take it seriously.
URLs get shared, passed around, posted in chats, etc. Passwords don't, or at least everyone knows they're doing something wrong if they do.
In the case of the this doc, if it was privately shared, I don't think anyone would have mistakenly posted their Google password the same way.
There is a point here that the difference between access level grants is not clear enough and the urls should have a clearer demarcation of the level granted, (e.g. sheets.google.com/danger-allows-editing/{secureToken} or sheets.google.com/allows-viewing/{secureToken}.)
STO to me generally indicates there is some backward engineering process, or some vital related knowledge, that can break it, which is specifically not the case here. Secrets are specifically designed to have common forms and functions, you only keep the value itself, or values they were derived from, secret. Obscurity and secrecy have slightly different meanings.
Sorry if this wasn't clear. I was trying to adopt your apparent definition to point out that, passwords and authorizing-links can have identical functional forms. Both depend on maintaining the secrecy of a specific piece on non-design / non-implementation knowledge.
To make this clearer, let's say that your document's authorization link is determined by hashing the document id. If you don't use a salt, then the security of the system depends on the obscurity of your choice of hashing function. If you do use a salt, then your security also depends on the secrecy (and strength) of the salt value.
Since the issue in this case wasn't people reverse engineering the means of generating links to uncover it, the issue was not a dependence on obscurity of design and implementation. The issue was that the users of the system were not aware or forgot that authorization links were a secret or confusion about what level of secrecy was needed for a specific link. This is why I specifically called out a possible design change to the authorization links that would reduce the likelihood of similar human error.
Edit: In general, "security through obscurity" is both a nebulous term and one that often doesn't mean use of obscurity of design/implementation a portion of the security stance, but rather an over-reliance on obscurity of design/implementation without other security measures, such as the use and careful management of strong secrets such as passwords/keys. This potential confusion makes me view the "security through obscurity" term as more of a buzzword than a specific security criticism.
I would say that Google Workspaces' implementation of "Anyone with the Link" authorization was never intended to depend on secrecy (or obscurity or what have-you).
I would say that we'd need to consider a more expansive and open, permissive model than that. "Anyone who has the link can edit this" should not be considered as "hide this URL from anyone you don't want editing it" but rather "This is a world-writable document. Discovery merely depends on getting the link right."
Imagine if this were a massively multiuser Unix system and not the WWW. Your admin creates for you an obscure, long pathname ending in a long base64 filename. It is mode 6777. "Anyone with the pathname" can edit it! Now is the pathname like a password, or is it just a pathname sitting there in the system? Arguably, Unix pathnames are more discoverable than arbitrary Docs links. But the idea is the same, isn't it? A Google Doc/Sheet/Slide/Drive whose permission is "Anyone with the link" may <X> is, when you boil it down, world-writable, no excuses, no ifs-ands-or-buts.
The discoverability is a pretty key difference. If google had a feature that allowed you to enumerate all edit links in their system, then those links would effectively br world writeable.
> I would say that Google Workspaces' implementation of "Anyone with the Link" authorization was never intended to depend on secrecy (or obscurity or what have-you).
If that was true, the link would just use a document ID, the use of a cryptographic hash does imply some intention that these files won't simply be world writeable and that access is intended to be controlled by sharing of the link.
In the specific case, the people using the feature failed to do either. They didn't treat the file as world writeable and they didn't treat the link like a secret. If they had done either, that would have helped.
No they can't. Passwords are specifically intended not to be shared. Links are specifically intended to be shared.
A shared secret is far less secure than one that is not shared, whether the cryptographic backing is the same or not.
In practice, passwords, api keys and other secrets are frequently shared. Many of them, such as some api keys, are clearly intended to be shared between multiple people.
You are correct that sharing these secrets, and the method of sharing can create security vulnerabilities. There is the frequent issue of people accidentally commiting api keys to publix repositories. There are also plenty of stories of people at a company sharing a password to a single account sometimes because the service doesn't provide support for multiple users.
> Links are specifically intended to be shared.
There are many urls that are not intended to be shared because they are viewable by a single account and theoretically a single user.
To make this clear, urls are frequently used in a very similar way to passwords. Oer example that makes this exceedingly obvious is password reset links.
A separate discussion is when it is a good practice to put secrets in URLs. API best practices discourage this and for good reason. That doesn't mean that urls can't be secrets, just that doing that can create additional risks due the expectations the users and systems have about risks.
These risks are why password reset links are usually time limited and restricted to a single use.
In practice, the most important difference between those is about what gets copied when someone shares a link. If the only possible option is to share it with the authentication embedded, you're kind of screwed. I don't think browsers expose the basic auth when you copy and paste from your url bar though.
So if you created a secret, clandestine, world-readable, anyone-comments, blog post with the slug "http://example.com/correct-horse-battery-staple/" would you really complain when someone brute-force or outright guessed your blog post?
YouTube has "unlisted" videos which are unsearchable and unreachable unless you've been shared a link, but do people freak out when someone stumbles across this shared by others?
Just because a Google Workspaces ID is a long, jumbled-up, base-64 string doesn't mean it is a password or a cryptographically secure secret. It's quite different. It's meant to be well-known by anyone who is intended to have access. The "Anyone with the Link" access simply relies on a circle of friends/colleagues keeping the URL to themselves.
Each time, gmail says that "John" will not be able to see the document and offers to make it readable/editable for anyone with a link. It appears in a modal window that blocks sending the message. I must read carefully the modal window to click the correct button. "John" can see the doc because he has a google account, but I'm sending the message to his yahoo email because it's his preferred email.
Anyway, I only have a draft of a math midterm for next week. If a hundred of thousands of dollars were in the line, I'd be very nervous.
So I guess I should just add 'knows speadsheets' to my resume instead of studying and sitting for yet another overpriced exam. Today I learned.
It's as if they didn't know what DAO stands for.
I stay away from people who don't practice what they preach.
An example of an actual DAO was last year's Genesis fractal experimental apparatus (links below). The PeopleDAO used an old-school spreadsheet accounting system (i.e. a Google spreadsheet), and there is nothing wrong with that. The Genesis fractal also used an old-school spreadsheet accounting system.
The same type of "theft" could have also happened to the Genesis fractal, i.e. stealing a password and editing an accounting spreadsheet. However, there was no Genesis property to steal. The Genesis fractal only had pure information stored in their spreadsheets and not title to property. The "theft error" would have been discovered eventually, just like the PeopleDAO discovered their "theft", but the Genesis fractal would simply need to re-edit their spreadsheet and not pursue the thief for the return of any property. This is a fundamental principle and feature of a DAO.
The PeopleDAO's fatal flaw was not understanding the principles of a DAO, meaning they did not understand the concept of decentralization and title to property.
The "PeopleDAO theft" is a wonderful case study for the benefits of a DAO and for the need for educational fractals like Genesis. Dan Larimer invented the concept of Decentralized Autonomous Organization and the word DAO, but it is poorly understood which is why we see heartbreaking theft stories like "the PeopleDAO theft" and the catastrophe surrounding Ethereum's "The DAO" (which was also not a DAO and suffered a similar fate as PeopleDAO). Ethereum's "The DAO" was a smart contract deployed to a "real" blockchain (i.e. it did not use a Google spreadsheet for accounting) but it still fell victim to an entirely predictable fate just like PeopleDAO - it held title to property.
The acid test of whether something is a DAO is determining whether the organization holds title to property. If the organization holds title to property, then it is not a DAO. There are many ways for an organization to use real property involving title (e.g. domain names, physical equipment like servers, land and equipment and anything other tangible, etc.)
If you know someone in the PeopleDAO, it would be well worth their while to read the following blog posts from Team fractally and to reach out to anyone on the Genesis fractal's leader board:
"What is a DAO?", February 20, 2022 https://fractally.com/blog/what-is-a-dao
"What is the Legal Standing of a DAO?", June 28, 2022 https://fractally.com/blog/what-is-the-legal-standing-of-a-d...
"Genesis Fractal Dashboard" https://share.streamlit.io/matt-langston/fractal_governance/...
TL;dr the owner of the form changed the permissions to be literally wide open.
you reap what you sow.
After all, wasn't the saying with shitcoin was that "The code is the contract, and the contract is the code"?
You make your bed, and lie in it.