8 ms·

CA bar says attorney records leaked through database flaw, not hack

98 points by leni536 5y ago

blamazon 5y ago
I'd bet this was discovered after attorneys plugged their names into this judyrecords website after it was publicized on HN: "Show HN: Full text search on 630M US court cases" | 20 days ago | 269 comments https://news.ycombinator.com/item?id=30399881 https://news.ycombinator.com/item?id=30399881 "Full text search on 400M US court cases" | Nov 19, 2020 | 163 comments https://news.ycombinator.com/item?id=25150702 https://news.ycombinator.com/item?id=25150702
- hackernewds 5y ago
  So it is a feature not a bug? Was this supposed to NOT be public?
  - blamazon 5y ago
    The attorney discipline records were not supposed to be public, but, inadvertently were accessible in this one public database of hundreds indexed by Judyrecords. No one noticed until it became easily searchable. Once notified all parties, including Judyrecords, moved swiftly to remove the records from public access.
    - hn_version_0023 5y ago
      Doesn’t the public have an interest in knowing which lawyers have been disciplined by the bar? It seems outlandish that this is private?
      - mikeyouse 5y ago
        The public is made aware, I believe this leak included investigations where it was deemed no discipline was necessary. As one example, here’s what Michael Avenatti’s bar entry looks like: https://apps.calbar.ca.gov/attorney/Licensee/Detail/206929 https://apps.calbar.ca.gov/attorney/Licensee/Detail/206929
        hn_version_0023 5y ago
        Ah, I see. Thank you kindly!
olliej 5y ago
Honestly I’m surprised they admitted this. Historically companies and organizations would always blame whatever the current hacking buzzword is. I recall APT being an especially annoying example of this, until that buzzword disappeared and then suddenly everyone’s hackers stopped being APT.
- remram 5y ago
  Yes usually reading from a completely-open Elasticsearch or S3 bucket is labeled "a hack". Good on them for admitting fault.
- musingsole 5y ago
  Likewise, I always thought that "we were hacked!" approach was an attempt to CYA in a legal respect. And the way the word gets used, it covers any usage of a service not explicitly allowed in the Terms of Service. But in this case, it seems they reviewed their terms and realized they hadn't protected themselves FROM A LEGAL STANDPOINT No matter what ivory tower we're talking about, there's never a reason to be in awe of the top.
- codesections 5y ago
  > Honestly I’m surprised they admitted this. I think it's because they're lawyers. I have decidedly mixed feelings about the legal profession, but most lawyers (especially the "establishment" types most likely to be involved in the CA bar) are *very* unlikely to make deliberately false statements (or to fail to correct a past statement, one they learn it was false). In defiance of thousands of lawyer jokes, in my experience lawyers lie the *least* of any large group of humans I've encountered – at least if "lying" refers only to the specific denotation of the words, since lawyers also love to split hairs to say something that's technically true. But the distinction between a "hack" and a "database error" is _exactly_ the sort of hair that lawyers love to split! Source: I'm a lawyer-turned-programmer
rahimnathwani 5y ago
The CA Bar web site has more information (at the same URL that was posted when this happened): https://www.calbar.ca.gov/About-Us/News/Data-Breach-Updates https://www.calbar.ca.gov/About-Us/News/Data-Breach-Updates Notably: - they now acknowledge that it wasn't unlawful for judyrecords to access (and republish) the records that were unlawfully published - they talk about judyrecords using a 'unique method' to access the records; I'm guessing the method is something simple like 'incrementing an integer', and that they are trying to make it seem more mystical.
- arealaccount 5y ago
  If you call it an Insecure Direct Object Reference (IDOR) it still seems mystical
  - richardbarosky 5y ago
    I'd never heard of that acronym before myself. Insecure = no access control/authorization Direct Object reference = URL https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Dire... "Direct Object Reference is fundamentally a Access Control problem."
- itake 5y ago
  My understanding is that 'incrementing an integer' is illegal and may result in jail time. Maybe they used graphql and their api expectantly allowed access to data that it shouldn't of had access too? [0] - https://www.techdirt.com/2013/09/30/dojs-insane-argument-against-weev-hes-felon-because-he-broke-rules-we-made-up/ https://www.techdirt.com/2013/09/30/dojs-insane-argument-aga...
  - ensignavenger 5y ago
    That decision was vacated on appeal- https://arstechnica.com/tech-policy/2014/04/appeals-court-reverses-hackertroll-weev-conviction-and-sentence/ https://arstechnica.com/tech-policy/2014/04/appeals-court-re...
4oo4 5y ago
Are we willing to take bets yet on what was unsecured? S3, ElasticSearch, or MongoDB?
- asperous 5y ago
  It sounds like A01- broken access control. Simply that judyrecords was marching through record ids and the backend was not authenticating that access. The backend I think they said is a relational database. This is the most common security issue right now according to OWASP. You have to understand these issues come the fact that likely lawyers oversaw this project and they picked contractors that were "best value" (low cost). https://owasp.org/Top10/A01_2021-Broken_Access_Control/ https://owasp.org/Top10/A01_2021-Broken_Access_Control/
  - lupire 5y ago
    Seems like the problem is bad programmers, not bad lawyers.
    - iakh 5y ago
      Depends on the contract they drew up
e28eta 5y ago
I don’t pay very much attention to prosecution of cases under the CFAA, but at a surface level this reminded me of the weev / AT&T case [1], where he was convicted for (afaik) incrementing an id and fetching all the records. I didn’t remember the outcome, but it looks like it was overturned later without taking a solid stance on the technique [2] I’d definitely believe other cases have happened in the last 8 years that have done a better job of clarifying the law, but I’m not aware of them. 1. https://www.techdirt.com/2013/09/30/dojs-insane-argument-against-weev-hes-felon-because-he-broke-rules-we-made-up/ https://www.techdirt.com/2013/09/30/dojs-insane-argument-aga... 2. https://www.eff.org/press/releases/appeals-court-overturns-andrew-weev-auernheimer-conviction https://www.eff.org/press/releases/appeals-court-overturns-a...
amelius 5y ago
Most hacks are exploits of a flaw in some software.
- colejohnson66 5y ago
  That’s kindof a tautology. Technically speaking, all hacks requires some kind of flaw, whether intentional (backdoor) or unintentional (bug); You can’t hack something if there’s nothing to exploit.
cheschire 5y ago
Search on judyrecords.com is disabled. Timeline here: https://www.judyrecords.com/info https://www.judyrecords.com/info
awill88 5y ago
I appreciate that they are not memorializing this as a “hack.” That’s a mature stance. However: Sarcasm alert: so the gist is engineering is hard and we should never assume actors within a system will act predictably: you don’t say! Security is hard, but necessary, it’s never convenient. It takes relentless discipline and suspicion, which is dissonant in conventional software team dynamics. I hear it time and time again, “this isn’t an issue” Every time a story comes out like this, I think about how ill-equipped these organizations must be in mitigating these breaches.
xbar 5y ago
In a surprise to no one....
deleted 5y ago
[deleted]

98 points by leni536 5y ago

I'd bet this was discovered after attorneys plugged their names into this judyrecords website after it was publicized on HN: "Show HN: Full text search on 630M US court cases" | 20 days ago | 269 comments https://news.ycombinator.com/item?id=30399881 https://news.ycombinator.com/item?id=30399881 "Full text search on 400M US court cases" | Nov 19, 2020 | 163 comments https://news.ycombinator.com/item?id=25150702 https://news.ycombinator.com/item?id=25150702

hackernewds 5y ago
So it is a feature not a bug? Was this supposed to NOT be public?
- blamazon 5y ago
  The attorney discipline records were not supposed to be public, but, inadvertently were accessible in this one public database of hundreds indexed by Judyrecords. No one noticed until it became easily searchable. Once notified all parties, including Judyrecords, moved swiftly to remove the records from public access.
  - hn_version_0023 5y ago
    Doesn’t the public have an interest in knowing which lawyers have been disciplined by the bar? It seems outlandish that this is private?
    - mikeyouse 5y ago
      The public is made aware, I believe this leak included investigations where it was deemed no discipline was necessary. As one example, here’s what Michael Avenatti’s bar entry looks like: https://apps.calbar.ca.gov/attorney/Licensee/Detail/206929 https://apps.calbar.ca.gov/attorney/Licensee/Detail/206929
      - hn_version_0023 5y ago
        Ah, I see. Thank you kindly!

olliej 5y ago

Honestly I’m surprised they admitted this. Historically companies and organizations would always blame whatever the current hacking buzzword is. I recall APT being an especially annoying example of this, until that buzzword disappeared and then suddenly everyone’s hackers stopped being APT.

remram 5y ago
Yes usually reading from a completely-open Elasticsearch or S3 bucket is labeled "a hack". Good on them for admitting fault.
musingsole 5y ago
Likewise, I always thought that "we were hacked!" approach was an attempt to CYA in a legal respect. And the way the word gets used, it covers any usage of a service not explicitly allowed in the Terms of Service. But in this case, it seems they reviewed their terms and realized they hadn't protected themselves FROM A LEGAL STANDPOINT No matter what ivory tower we're talking about, there's never a reason to be in awe of the top.
codesections 5y ago
> Honestly I’m surprised they admitted this. I think it's because they're lawyers. I have decidedly mixed feelings about the legal profession, but most lawyers (especially the "establishment" types most likely to be involved in the CA bar) are *very* unlikely to make deliberately false statements (or to fail to correct a past statement, one they learn it was false). In defiance of thousands of lawyer jokes, in my experience lawyers lie the *least* of any large group of humans I've encountered – at least if "lying" refers only to the specific denotation of the words, since lawyers also love to split hairs to say something that's technically true. But the distinction between a "hack" and a "database error" is _exactly_ the sort of hair that lawyers love to split! Source: I'm a lawyer-turned-programmer

rahimnathwani 5y ago

The CA Bar web site has more information (at the same URL that was posted when this happened): https://www.calbar.ca.gov/About-Us/News/Data-Breach-Updates https://www.calbar.ca.gov/About-Us/News/Data-Breach-Updates Notably: - they now acknowledge that it wasn't unlawful for judyrecords to access (and republish) the records that were unlawfully published - they talk about judyrecords using a 'unique method' to access the records; I'm guessing the method is something simple like 'incrementing an integer', and that they are trying to make it seem more mystical.

arealaccount 5y ago
If you call it an Insecure Direct Object Reference (IDOR) it still seems mystical
- richardbarosky 5y ago
  I'd never heard of that acronym before myself. Insecure = no access control/authorization Direct Object reference = URL https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Dire... "Direct Object Reference is fundamentally a Access Control problem."
itake 5y ago
My understanding is that 'incrementing an integer' is illegal and may result in jail time. Maybe they used graphql and their api expectantly allowed access to data that it shouldn't of had access too? [0] - https://www.techdirt.com/2013/09/30/dojs-insane-argument-against-weev-hes-felon-because-he-broke-rules-we-made-up/ https://www.techdirt.com/2013/09/30/dojs-insane-argument-aga...
- ensignavenger 5y ago
  That decision was vacated on appeal- https://arstechnica.com/tech-policy/2014/04/appeals-court-reverses-hackertroll-weev-conviction-and-sentence/ https://arstechnica.com/tech-policy/2014/04/appeals-court-re...

4oo4 5y ago

Are we willing to take bets yet on what was unsecured? S3, ElasticSearch, or MongoDB?

asperous 5y ago
It sounds like A01- broken access control. Simply that judyrecords was marching through record ids and the backend was not authenticating that access. The backend I think they said is a relational database. This is the most common security issue right now according to OWASP. You have to understand these issues come the fact that likely lawyers oversaw this project and they picked contractors that were "best value" (low cost). https://owasp.org/Top10/A01_2021-Broken_Access_Control/ https://owasp.org/Top10/A01_2021-Broken_Access_Control/
- lupire 5y ago
  Seems like the problem is bad programmers, not bad lawyers.
  - iakh 5y ago
    Depends on the contract they drew up

e28eta 5y ago

I don’t pay very much attention to prosecution of cases under the CFAA, but at a surface level this reminded me of the weev / AT&T case [1], where he was convicted for (afaik) incrementing an id and fetching all the records. I didn’t remember the outcome, but it looks like it was overturned later without taking a solid stance on the technique [2] I’d definitely believe other cases have happened in the last 8 years that have done a better job of clarifying the law, but I’m not aware of them. 1. https://www.techdirt.com/2013/09/30/dojs-insane-argument-against-weev-hes-felon-because-he-broke-rules-we-made-up/ https://www.techdirt.com/2013/09/30/dojs-insane-argument-aga... 2. https://www.eff.org/press/releases/appeals-court-overturns-andrew-weev-auernheimer-conviction https://www.eff.org/press/releases/appeals-court-overturns-a...

amelius 5y ago

Most hacks are exploits of a flaw in some software.

colejohnson66 5y ago
That’s kindof a tautology. Technically speaking, all hacks requires some kind of flaw, whether intentional (backdoor) or unintentional (bug); You can’t hack something if there’s nothing to exploit.

cheschire 5y ago

Search on judyrecords.com is disabled. Timeline here: https://www.judyrecords.com/info https://www.judyrecords.com/info

awill88 5y ago

I appreciate that they are not memorializing this as a “hack.” That’s a mature stance. However: Sarcasm alert: so the gist is engineering is hard and we should never assume actors within a system will act predictably: you don’t say! Security is hard, but necessary, it’s never convenient. It takes relentless discipline and suspicion, which is dissonant in conventional software team dynamics. I hear it time and time again, “this isn’t an issue” Every time a story comes out like this, I think about how ill-equipped these organizations must be in mitigating these breaches.

xbar 5y ago

In a surprise to no one....

deleted 5y ago

[deleted]