It's honestly quite pathetic, but not at all unexpected these days. I do sometimes wish that when the negligence is so gross (sending API keys in the response of an unsecured request?) that the government would issue a fine. If you don't feel that your developers are security minded, there are many computer security professionals around the globe available to help. Maybe using some of those hundreds of millions of VC dollars for a quick audit would be the norm if there were actual penalties for this kind of reckless behavior.
> I do sometimes wish that when the negligence is so gross that the government would issue a fine
I also think that there must be a line between getting hacked because some 5th level transitional dependency had a memory overflow bug which made it possible for the attacker to push some sensitive data in the response headers vs "auth? what auth?".
Very hard to exactly define it though, where it should lie, other than the extreme examples.
For non-Germans who wonder about the name: It’s a combination of the prefix "zer" [0] "denoting an aspect of dissolvement and asunderness" (similar to English "dis" solve - dissolve) and Forschung (Research).
Of course it works. Extreme reversing by 'Zerlegung' in all its constituent parts by whichever means (not necessarily 'zerstörungsfrei') for the purpose of 'Forschung'.
YYYY-MM-DD is the standard in Germany, most people don’t know that and essentially no one (including in official documents) uses it. Never seen it anywhere outside computer nerds who like sortable dates. So yeah, DD-MM-YYYY is the normal way here.
I would add that if DD comes first, the format is usually DD.MM.YYYY. Or DD/MM/YYYY, which is more common in the UK. Rarely have I seen dashes when not following the ISO 8601 YYYY-MM-DD standard.
I was taught DD.MM.YYYY in school (90s). This is the de-facto standard (short) date format in Germany and by far the most commonly used one.
First because it’s consistent with the longer written out date format used in German: „19. Januar 2022“ (19th of January 2022) – note the dot after the 19.
Second because it’s also consistent with how it’s spoken. The dot denotes ordinal numbers in German and that’s also how the date is spoken: „Neunzehnter Erster Zweitausend Zweiundzwanzig“ or “nineteenth first two thousand twenty and two”.
Dashes and slashes are highly likely to be confusing to people if used in that context, though advisable if you are using any other date format because then at least people will be weirded out and likely pay closer attention if there’s anything going on with that date.
It is true that DIN 5008 (which defines rules for word processing and does have some weight in professional circles) recommends YYYY-MM-DD, however this way of writing the date never took hold in Germany (just because it’s part of a norm doesn’t make it commonly used or accepted) and DIN 5008 does actually allow for DD.MM.YYYY.
YYYY-MM-DD is, as far as I know, merely a recommendation in DIN 5008, not in any way the standard in Germany, either officially or informally. DIN 5008 does allow for DD.MM.YYYY (with the dots and without spaces), Duden recommends spaces after the dots.
I looked it up again, you were more right than me ;) If you speak German, you can read about it on Wikipedia [0], essentially it was the only format from 1996 till 2001, but because it was completely ignored, they went back to allowing DD.MM.YYYY, since 2020 it also includes that the old format is only to be used for national mail.
To be pedantic that still requires assuming the author is using a sane convention (RFC3339) or convention including sane formats (ISO 8601) and not something ridiculous like %V-%W-%O or %Y-%D-%M. Thankfully the sane convention seems highly likely.
Same. I have some "core" accounts that I make sure to keep very well protected, like Paypal, Gmail, Amazon etc. But the 2nd tier accounts from hundreds of random shopping websites etc I just don't expect to be kept secret at this point, there are just so many of them, and the data itself isn't particularly juicy.
I still need to hear a real world case where data breaches are harmful other than annoying spam SMS.
EDIT: re the downvotes - I guess it's ok to ask crypto people all the time about real world cases but then not to accept any questions about real world cases elsewhere...
Real world case: 2 friends from Brazil got their identity stolen after a governmental database leak, thieves opened up a few credit lines and now both are fighting to get their credit history cleaned up.
It's been more than a year, they have a pretty strong case to get rid of it but... Brazilian bureaucracy is slow and convoluted, it's been more than a year and neither can get any credit and get non-stop calls from banks and collection agencies.
Oh, totally in agreement with you there; consumer credit is toxic and dehumanizing to begin with. But I think the fraud potential is what will make it go away; smaller players will stop taking credit seriously, and government and megacorps will come up with something more invasive.
A data breach at your bank, insurance company, etc. allows for much more targeted phishing attacks.
I get calls from “Visa and Mastercard customer service” because they don’t know which one I have and are playing the numbers game. “Hi Mr. ceejayoz, I’m calling from Chase about account x2093” with Chase’s 1-800 spoofed on caller ID will catch a lot more people.
Could you post your full contact details? I am looking for your name, address, date of birth, and phone number. If it isn't too much trouble, please include all email addresses and relevant passwords, your tax ID, mother's maiden name, usual prompts and answers to security questions and your SSN if in the US.
The downvotes are coming because your comment comes over as shallow.
For you or for bunch of people on HN or that are somewhat tech literate it might be a mere annoyance.
There is far more people who have email/phone number but they don't understand much more. They get scammed every week or two as I read on local news. Scammers get free information that can be used to target a person and they use it.
Just type into google "man scammed out of life savings"
Phone numbers are annoying when they leak mainly because there's a risk you end up being targeted by scammers. Nano ledger leaked my contact details a few years ago and I now get regular calls from people with North African accents trying to talk me into investing into whatever crypto scams they are trying to sell. Apparently Nano Ledger owners are exactly the type of gullible fools these geniuses like to target.
At least for email, I have a spam filter that catches most of the crap.
Neither my email nor phone number are very secret of course. I actually give out business cards, have some address information on my website (because you have to in Germany). Same for my phone number and email address.
I don't understand the objective for these scammers. Surely someone who buys a hardware wallet knows at least a little bit about security and would thus be a very bad mark for a scam?
Alternatively, perhaps someone who has invested in one crypto item/scheme might be a good prospect for a second crypto item/scheme.
Someone who owns a hardware wallet is probably a much better than the average person as a prospect to target for an altcoin or NFT purchase, for example.
1M order exposed and 200k customer and workers data exposed just because an AuthKey is allowed to query all customer data instead of user specific data.
this means most likely a junior developer built this service, and on top graphQL is used which is built relational first / security is one step away.
it sucks that companies grow fast in the tech scene, try to make their wealth using technology without really understanding it.
Growth hacking 101: ignore security; it's never too late to work on security; the worst that can happen is some wrist slapping; security is a luxury problem.
IMO this is a cultural problem. Coupled with a general lack of experience of majority of people working in our industry.
People learn how to do certain programming tasks in one way, and instead of trying to fully understand "what" and "why" they're doing it, they just keep doing it. This approach works fine in a computer class, or in internships, but it breaks down when comes to writing secure apps.
It is similar with SQL injection: using prepared queries is not really difficult. I'd even claim that it's easier and simpler to write compared to string concatenation. But "knowing" about them takes time, curiosity and preparation. But making queries via string concatenation is how people used to learn.
Another thing is over-engineering (the wrong kind): it is more difficult to write tens of classes rather than doing what the task requires, but some people still do it because that's how they learned to program.
There are no shortcuts, unfortunately. So far we've solved this partially by using slogans: "Just use BCrypt" was a popular one a few years ago. But honestly I don't think this is enough.
We need more mentorship (for the beginners) and more peer reviews (for the experienced).
NCEES briefly toyed with the idea of a Professional Engineer license for software but it went away due to lack of interest. I think it would take the initiative of employers or regulators to make it happen, and the former is not likely since it works against their own incentives (it effectively gives more leverage to those with the license)
> also why on earth do you need to expose your suppliers (sendgrid) api keys to the frontend
It's the other way round: you need to make sure not to expose sensitive parts of your configuration to the client. That's an extra step you can forget about (or fail to consider in the first place).
Excellent comment and the current business structures have made it even worse:
If the security incident is actually really terrible, simply fold the publicly-facing company and pivot with all the IP in the IP company. Maybe white-label it, or maybe just wait a little and start the exact same type of company under a new brand. Only the papers get a slap on the wrist.
Non-technicals can bikeshed[0] all day long about UI. "Move that a little to the right, what about cornflower blue?" but have to sit around looking useless when it comes to discuss the engine that will drive that UI. People don't like to feel useless, so they don't talk about the tech.
I think this is the reason most software just flat out sucks. It's easy to use if you ignore the part where it doesn't work half the time.
But its a solvable problem: oblige all decision takers to get training on the IT side and get all IT staff to get training on how to explain/communicate what they do.
Gleefully declaring you are non-technical in a tech company is like gleefully declaring you are illiterate in a publishing house. Publishing houses just refuse to hire people who can't read rather than getting the executives hooked on phonics.
Most companies don't consider themselves "tech" and there is a lot of space for people who refuse to learn "technical mumbo jumbo" like just basic use of web browser or getting at least some knowledge of how browser is working.
I would push back a little bit that this is the sole reason (and thus not quite as solvable a problem as one might think). A couple other reasons that help explain why a lot of software sucks:
1) Unlike other engineering disciplines, there is not strict adherence to codified standards. It's easy for me to argue that my solution is adequate, even when if yours may be objectively better. An electrician or civil engineer has much less leeway for creativity because they are constrained by codes, standards, and industry-accepted best practices where adherence/compliance is culturally ingrained. Software, by comparison, is very much the Wild West.
2) It's very easy to change. Because software is relatively easy to change, it means configurations are often less stable. Especially at scale (and combined with the lack of standards), this can cause problems.
3) It's relatively cheap to implement (superficially at least) and there's a low barrier for entry (superficially at least). Software doesn't have the culture of other engineering disciplines regarding accreditation. I'm not a huge fan of credentialism personally, but it can provide a stop-gap in terms of skills, especially when those doing the hiring don't know how to properly assess those skills.
Nobody will care until there are real monetary penalties for data breaches. The GDPR technically mandates those but it has a major enforcement problem.
> The tenantConfig however can be accessed without any restrictions. And the information delivered there is quite interesting: API keys and URLs for various services that are apparently used by the Gorillas/eddress infrastructure. Among them we found API keys for Sendgrid and Slack webhook URLs.
I suspect that they thought this was a clever way of allowing tenant applications to host their own configuration somewhere which the application would fetch and use. It's a whitelabelled application by the sounds of it. Pretty shocking but I can't think of any other line of reasoning.
I could not derive from the article that they are shady. All it said is that they receive money from National Endowment for Democracy, just as Thomson Reuters Foundation. I am not sure why this is shady per se. Maybe you can explain?
Bellingcat was crucial in identifying the Tiergarten killer and the corresponding researcher was invited to court as a witness[1].
Never. There are too many people using too many technologies with too many deadlines and constant turnover. It will always be possible to find a service with simple vulnerabilities.
I also find it just fascinating, that anyone would pump hundreds of millions in a service which is a copycat anyhow and doesn't even own the IP on the only thing that could potentially differentiate them from their competitors.
I mean, hiring desperate people and students to make deliveries in a couple if cities at a loss seems not to be the greatest feat. Services like Uber at least have some tech in-house which is mildly innovative. But this is just pathetic.
It’s like Kevin Smith says in one of his “evening with” DVDs:
We think that only the best of us are making money but If you can consistently make even a small return on the investment money, you basically have a job as long as you want it. They don’t care if it’s crap, they just care if you give them more money than they started with.
Building applications is a complex problem. If you want a secure system, then security details have to be carefully considered at every layer (DB, API, front-end). Doing that requires expert security employees/consultants, time and money. On the other hand, profits are driven by new features, first to market and sales.
Companies can build insecure systems (that are profitable) much faster and much cheaper than they can build systems that are profitable and secure.
It has been my experience that security is seen as a necessary evil. It's not seen as a benefit or feature that customers want. Security employees/consultants are often seen as road-blocks or obstructionists. I think this is largely why technical security has been replaced by compliance. Just check the box mentality. When they get hacked they can say, "but we were compliant and we'll do better next time".
IMPO, that basic conflict explains why systems are repeatedly compromised and why companies nor customers really care about good technical security.
This is what I think when I hear about a company being attacked by someone inside their development/ops team or the latest 0day.
Ideally there should be measures in place to mitigate these worst case scenarios but those are legitimately hard, expensive, and require commitment at all levels of the company.
This wasn't that. The worst vulnerability was caused by a very basic mistake that was more at the level of fundamental competence than security expertise. If you're going to use GraphQL you need someone who knows about GraphQL. It's been out a while now, they aren't that hard to find.
77 comments
[ 3.1 ms ] story [ 170 ms ] threadI also think that there must be a line between getting hacked because some 5th level transitional dependency had a memory overflow bug which made it possible for the attacker to push some sensitive data in the response headers vs "auth? what auth?".
Very hard to exactly define it though, where it should lie, other than the extreme examples.
https://www.theverge.com/2021/11/14/22781341/fbi-email-syste...
https://zerforschung.org/posts/zapptales/
What could go wrong? Everything.
[0]: https://en.wiktionary.org/wiki/zer-
EDIT: If Germany has the same conventions as The Netherlands, DD-MM-YYYY is probably even more common
First because it’s consistent with the longer written out date format used in German: „19. Januar 2022“ (19th of January 2022) – note the dot after the 19.
Second because it’s also consistent with how it’s spoken. The dot denotes ordinal numbers in German and that’s also how the date is spoken: „Neunzehnter Erster Zweitausend Zweiundzwanzig“ or “nineteenth first two thousand twenty and two”.
Dashes and slashes are highly likely to be confusing to people if used in that context, though advisable if you are using any other date format because then at least people will be weirded out and likely pay closer attention if there’s anything going on with that date.
It is true that DIN 5008 (which defines rules for word processing and does have some weight in professional circles) recommends YYYY-MM-DD, however this way of writing the date never took hold in Germany (just because it’s part of a norm doesn’t make it commonly used or accepted) and DIN 5008 does actually allow for DD.MM.YYYY.
[0]: https://de.wikipedia.org/wiki/Datumsformat#DIN_5008
- full name, date of birth and email have been leaked by multiple websites;
- phone number was leaked by Facebook (added it for 2FA many years ago);
- address information can be found in the public database of the Chamber of Commerce.
That doesn't make negligence okay, but at least Gorillas and Flink both gave me a €15 discount on my groceries in return.
EDIT: re the downvotes - I guess it's ok to ask crypto people all the time about real world cases but then not to accept any questions about real world cases elsewhere...
It's been more than a year, they have a pretty strong case to get rid of it but... Brazilian bureaucracy is slow and convoluted, it's been more than a year and neither can get any credit and get non-stop calls from banks and collection agencies.
Someone could have sent out 200k emails to steal money from 200k people.
I also store all leaked data just for fun. Guess what someone can do when they are out for you?
Writing an API which doesn't leak is very easy. I think it's reasonable to keep security.
I get calls from “Visa and Mastercard customer service” because they don’t know which one I have and are playing the numbers game. “Hi Mr. ceejayoz, I’m calling from Chase about account x2093” with Chase’s 1-800 spoofed on caller ID will catch a lot more people.
For you or for bunch of people on HN or that are somewhat tech literate it might be a mere annoyance.
There is far more people who have email/phone number but they don't understand much more. They get scammed every week or two as I read on local news. Scammers get free information that can be used to target a person and they use it.
Just type into google "man scammed out of life savings"
https://abc7chicago.com/remote-access-bank-account-scam-phon...
At least for email, I have a spam filter that catches most of the crap.
Neither my email nor phone number are very secret of course. I actually give out business cards, have some address information on my website (because you have to in Germany). Same for my phone number and email address.
Someone who owns a hardware wallet is probably a much better than the average person as a prospect to target for an altcoin or NFT purchase, for example.
I use Android's Call Screening and no scammer has ever made it to me.
Personally, I just let unknown numbers go to voicemail.
this means most likely a junior developer built this service, and on top graphQL is used which is built relational first / security is one step away.
it sucks that companies grow fast in the tech scene, try to make their wealth using technology without really understanding it.
also why on earth do you need to expose your suppliers (sendgrid) api keys to the frontend
it's not about ignoring security as if it's extra work, it's about not being qualified enough to do a reasonable job.
security is hard, but this is going out of your way to expose your system.
People learn how to do certain programming tasks in one way, and instead of trying to fully understand "what" and "why" they're doing it, they just keep doing it. This approach works fine in a computer class, or in internships, but it breaks down when comes to writing secure apps.
It is similar with SQL injection: using prepared queries is not really difficult. I'd even claim that it's easier and simpler to write compared to string concatenation. But "knowing" about them takes time, curiosity and preparation. But making queries via string concatenation is how people used to learn.
Another thing is over-engineering (the wrong kind): it is more difficult to write tens of classes rather than doing what the task requires, but some people still do it because that's how they learned to program.
There are no shortcuts, unfortunately. So far we've solved this partially by using slogans: "Just use BCrypt" was a popular one a few years ago. But honestly I don't think this is enough.
We need more mentorship (for the beginners) and more peer reviews (for the experienced).
It's the other way round: you need to make sure not to expose sensitive parts of your configuration to the client. That's an extra step you can forget about (or fail to consider in the first place).
If the security incident is actually really terrible, simply fold the publicly-facing company and pivot with all the IP in the IP company. Maybe white-label it, or maybe just wait a little and start the exact same type of company under a new brand. Only the papers get a slap on the wrist.
Nobody really cares. Security isn't a topic ever.
Founders pay you VC money to fly across the country to talk for days about UI wireframes, but nobody ever cares about where or how you store data.
I think this is the reason most software just flat out sucks. It's easy to use if you ignore the part where it doesn't work half the time.
[0]https://en.m.wikipedia.org/wiki/Law_of_triviality
Most companies don't consider themselves "tech" and there is a lot of space for people who refuse to learn "technical mumbo jumbo" like just basic use of web browser or getting at least some knowledge of how browser is working.
I would push back a little bit that this is the sole reason (and thus not quite as solvable a problem as one might think). A couple other reasons that help explain why a lot of software sucks:
1) Unlike other engineering disciplines, there is not strict adherence to codified standards. It's easy for me to argue that my solution is adequate, even when if yours may be objectively better. An electrician or civil engineer has much less leeway for creativity because they are constrained by codes, standards, and industry-accepted best practices where adherence/compliance is culturally ingrained. Software, by comparison, is very much the Wild West.
2) It's very easy to change. Because software is relatively easy to change, it means configurations are often less stable. Especially at scale (and combined with the lack of standards), this can cause problems.
3) It's relatively cheap to implement (superficially at least) and there's a low barrier for entry (superficially at least). Software doesn't have the culture of other engineering disciplines regarding accreditation. I'm not a huge fan of credentialism personally, but it can provide a stop-gap in terms of skills, especially when those doing the hiring don't know how to properly assess those skills.
Unreal.
They have also recently analyzed Djokovic's test certificate: https://zerforschung.org/posts/djokovic-pcr-test-en/
Stuff like that is super interesting. I love this investigative journalism. Another one I find captivating is: https://www.bellingcat.com/
https://declassifieduk.org/cia-sidekick-gives-2-6m-to-uk-med...
Bellingcat was crucial in identifying the Tiergarten killer and the corresponding researcher was invited to court as a witness[1].
[1] https://www.theguardian.com/world/2021/dec/15/germany-convic...
Never. There are too many people using too many technologies with too many deadlines and constant turnover. It will always be possible to find a service with simple vulnerabilities.
Security assessment should have been part of due diligence.
Now I know investors don't care much about this, but they should, lest they want to see their investments on the news in not so flattering colors.
The ROI on just jamming the gas pedal actually means that “horrific accidents” don’t affect profit all that much.
> Gorillas has experienced extreme growth in recent weeks and also raised another absurd 290 million US dollars in venture capital
it does not seem absurd considering the current market valuations of online retailers.
I mean, hiring desperate people and students to make deliveries in a couple if cities at a loss seems not to be the greatest feat. Services like Uber at least have some tech in-house which is mildly innovative. But this is just pathetic.
We think that only the best of us are making money but If you can consistently make even a small return on the investment money, you basically have a job as long as you want it. They don’t care if it’s crap, they just care if you give them more money than they started with.
How did they check the scopes? Did they use these API keys to make requests? Would that be legal?
Companies can build insecure systems (that are profitable) much faster and much cheaper than they can build systems that are profitable and secure.
It has been my experience that security is seen as a necessary evil. It's not seen as a benefit or feature that customers want. Security employees/consultants are often seen as road-blocks or obstructionists. I think this is largely why technical security has been replaced by compliance. Just check the box mentality. When they get hacked they can say, "but we were compliant and we'll do better next time".
IMPO, that basic conflict explains why systems are repeatedly compromised and why companies nor customers really care about good technical security.
Ideally there should be measures in place to mitigate these worst case scenarios but those are legitimately hard, expensive, and require commitment at all levels of the company.
This wasn't that. The worst vulnerability was caused by a very basic mistake that was more at the level of fundamental competence than security expertise. If you're going to use GraphQL you need someone who knows about GraphQL. It's been out a while now, they aren't that hard to find.
<input type="hidden" name="userId" value ="{{session.userId}}">
I'm sure you can guess what it's used for and what it's not compared against.