[HN Gopher] CA bar says attorney records leaked through database...
___________________________________________________________________
CA bar says attorney records leaked through database flaw, not hack
Author : leni536
Score : 69 points
Date : 2022-03-12 17:22 UTC (5 hours ago)
(HTM) web link (www.reuters.com)
(TXT) w3m dump (www.reuters.com)
| e28eta wrote:
| 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-
| aga... 2. https://www.eff.org/press/releases/appeals-court-
| overturns-a...
| 4oo4 wrote:
| Are we willing to take bets yet on what was unsecured? S3,
| ElasticSearch, or MongoDB?
| asperous wrote:
| 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/
| lupire wrote:
| Seems like the problem is bad programmers, not bad lawyers.
| iakh wrote:
| Depends on the contract they drew up
| amelius wrote:
| Most hacks are exploits of a flaw in some software.
| colejohnson66 wrote:
| 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.
| olliej wrote:
| 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.
| musingsole wrote:
| 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.
| remram wrote:
| Yes usually reading from a completely-open Elasticsearch or S3
| bucket is labeled "a hack". Good on them for admitting fault.
| codesections wrote:
| > 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
| cheschire wrote:
| Search on judyrecords.com is disabled. Timeline here:
| https://www.judyrecords.com/info
| awill88 wrote:
| 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.
| blamazon wrote:
| 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
|
| "Full text search on 400M US court cases" | Nov 19, 2020 | 163
| comments https://news.ycombinator.com/item?id=25150702
| hackernewds wrote:
| So it is a feature not a bug? Was this supposed to NOT be
| public?
| blamazon wrote:
| 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 wrote:
| 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 wrote:
| 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/20692
| 9
| hn_version_0023 wrote:
| Ah, I see. Thank you kindly!
| rahimnathwani wrote:
| 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
|
| 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.
| richardbarosky wrote:
| Related links I've added to judyrecords.com/info
|
| https://www.law.com/therecorder/2022/03/10/bowing-to-pressur...
|
| https://firstamendmentcoalition.org/2022/02/fac-letter-to-ca...
|
| https://s3.documentcloud.org/documents/21409065/response-to-...
| itake wrote:
| 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-
| aga...
| asdfasgasdgasdg wrote:
| It's not the incrementing the integer that was the problem.
| It was the knowingly accessing records that you know you
| shouldn't have access to. If judyrecords had a method of
| crawling pages that involves incrementing integers, that
| isn't a problem on its own. If they were using that method
| with a good faith belief that they were accessing data they
| had the right to access, that's fact is what makes it an
| entirely different scenario than what happened with weev.
| corey_moncure wrote:
| What does "shouldn't have access to" mean? The web server
| has a permissions system that determines what access level
| to grant in response to any request. If you are granted
| access to a valid request then what other interpretation
| can there be apart from the server decided you "should
| have" access?
| asdfasgasdgasdg wrote:
| > What does "shouldn't have access to" mean?
|
| It means that the stakeholders of the system, normally
| its owners, do not mean for you to have access. Here's
| one way you can estimate whether the owners intend that
| you should have access. Imagine an in-person conversation
| with the owner or controller of the data, or their most
| knowledgeable representative. If you asked them verbally
| whether you may access the data, and they said, "no,"
| then you "shouldn't" have access to the data.
|
| > If you are granted access to a valid request then _what
| other interpretation can there be_ . . .
|
| See above. This is also the interpretation that will be
| relevant in court if you are sued or arrested, so mark it
| carefully.
| [deleted]
| [deleted]
| rosndo wrote:
| Huge difference between this and weevs case. weev did what he
| did knowingly and maliciously.
|
| Intent matters, weev knew his access wasn't authorized.
| Judyrecords didn't know they were accessing non-public data
| by incrementing the integer, weev did.
| ensignavenger wrote:
| That decision was vacated on appeal-
| https://arstechnica.com/tech-policy/2014/04/appeals-court-
| re...
| slavboj wrote:
| On jurisdictional grounds, not the DOJ interpretation of
| the CFAA.
| ensignavenger wrote:
| That is true, but the court also expressed skepticism on
| the CFAA interpretation- but since the jurisdiction was
| wrong, they didn't need to make a ruling on the CFAA.
|
| I am unaware of any case going to trial using that
| interpretation of the CFAA since, though.
| rosndo wrote:
| > I am unaware of any case going to trial using that
| interpretation of the CFAA since
|
| Which interpretation would that be? That unauthorized
| access is illegal?
| [deleted]
| infogulch wrote:
| IMO the standard should consider both industry best practice
| for securing sensitive data in proportion to the sensitivity,
| as well as intent. Like it's harder to argue breaking and
| entering if you secure a door with a bent clothes hangar or
| carabiner vs a padlock, even a bad one. (Clarifications
| welcome.) Incrementing integers are like the carabiner, a
| botched JWT token implementation might be like a bad padlock,
| etc.
| joshuaheard wrote:
| "Unique method" means we didn't think of it beforehand.
| arealaccount wrote:
| If you call it an Insecure Direct Object Reference (IDOR) it
| still seems mystical
| richardbarosky wrote:
| I'd never heard of that acronym before myself.
|
| Insecure = no access control/authorization
|
| Direct Object reference = URL
|
| https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Dire.
| ..
|
| "Direct Object Reference is fundamentally a Access Control
| problem."
___________________________________________________________________
(page generated 2022-03-12 23:00 UTC)