Researcher Still Being Pursued By Russian Bank Over Last Year's Mistaken Trump Connection Story
from the every-weapon-deployed dept
The war on security researchers continues. But then, it's never really shown any sign of abating, has it? Report after report comes in of security researchers being threatened with lawsuits or arrest simply for finding and reporting security breaches.
The war on Jean Camp continues to this day, with the researcher on the receiving end of multiple legal threats from the American law firm representing Kremlin-linked Alfa Bank. Camp came under fire from the bank last year, after a story came and went mistakenly insinuating a Trump server was in engaged in lively conversation with Alfa Bank's servers during the run-up to the presidential election.
That was back in March. Law firm Kirkland & Ellis sent legal threats and communication retention demands to Camp. In addition to demanding she retain all communications possibly relevant to Alfa Bank's vendetta, the firm also threatened to file CFAA charges.
Nothing has improved over the last several months. The law firm's tactics now apparently include the use of FOIA laws to grab even more of Camp's communications. The Intercept reports on the latest developments in the Alfa Bank case.
Alfa’s lawyers went beyond scary lawyer boilerplate, demanding that Camp not only turn over all of her related communications with members of the media, but also divulge her full correspondence with the anonymous Tea Leaves, presumably for the purpose of unmasking and pursuing them. As a professor at a publicly funded university, Camp’s official correspondence is subject to public disclosure.
Alfa Bank seems keen on discovering who the mysterious security researcher "Tea Leaves" is. The pseudonymous researcher was instrumental to the mistaken claims published by Slate in its original report on the supposed link between Trump and the Russian bank. A letter sent by the law firm in May demands Camp turn over "Tea Leaves'" real name, title, and work address if she's in possession of that information.
Another letter in June expanded Alfa's demands, ordering Camp to turn over communications and other information related to her work with other security researchers. The latest letter, dated August 3, shows Alfa -- through Kirkland & Ellis -- serving up a public records request for
"All emails sent, received, or deleted by Professor Camp from University computers or systems using her University or personal email accounts that include any of the keywords "Alfa," "Alpha," "Alfa Bank," "Alpha Bank," "Trump," "Clinton," "Russia" or "Tea Leaves."
Considering this all took place shortly before the election, this request has the potential to sweep up a great number of communications not directly related to Alfa Bank's case. But even if it were more limited, it would still be disturbing. Alfa is looking to out other security researchers Camp has been in contact with, presumably in hopes of nailing a few of them to the wall for drawing mistaken conclusions about Trump server traffic.
The Intercept's Sam Biddle notes this clearly isn't what legislators had in mind when crafting public records laws.
Although public records laws typically don’t distinguish between U.S. citizens and foreign entities that use them, the purpose and spirit of such laws are generally understood to be a means of making government activities transparent for the public interest. Camp works for a public university and is a government employee, of course, but it’s hard to imagine laws like Indiana’s Access to Public Records act drafted with the well-being of Russian financial mega-institutions in mind.
This is likely true, but ultimately it makes no difference. The law cannot forbid companies from using public records laws to obtain information. (And companies know it.) After all, companies are made up of people and proxy records requests aren't just for bullying by foreign banks. Muckrock does this all the time, acting as an intermediary for requesters who don't live in the states they're requesting records from. Some laws prevent out-of-state requests. Muckrock's proxies work around this limitation. The use of a US law firm is more of the same, even though most records requesters aren't normally looking to destroy the target of their requests.
Oddly, the PR firm representing Alfa Bank has been the only entity to respond to requests for comment. And it has done so with as much spin as possible. As Biddle reports, BGR Public Relations claims the nearly-yearlong issuance of threats and demands to Jean Camp isn't illustrative of Alfa Bank's end goals. It just wants to "get the facts straight." Apparently, straightening things out means endangering Camp's career and, potentially, the livelihoods of every researcher she spoke to about Alfa Bank server traffic.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: foia, jean camp, tea leaves, threats
Companies: alfa bank, kirkland & ellis
Reader Comments
Subscribe: RSS
View by: Time | Thread
the only fact I draw from their activity is the "Embarrass us and we will destroy you and everybody you talked to if we can".
[ link to this | view in thread ]
Why Not...
[ link to this | view in thread ]
They can always ask...
Seems like any e-mails to or from Tea Leaves might be exempted. Any additional potentially responsive e-mails could be rejected using the rule the banks bought:
Might not be entirely (or even very) fitting, but they would get points for irony. Most of the e-mail that remains would likely be campaign ads and other junk mail.
[ link to this | view in thread ]
I never understood
No good deed goes un-punished. The only security report should be a public one.
Security is nothing but an after thought for applications and businesses. Just enough to stave off legal liability and fuck the rest.
Security will be serious when we finally do these things.
#1. A programing language and compiler that focuses on security from the ground up... no exceptions.
#2. Zero 3rd party protocols like the PKI racket/confidence con.
#3. No backdoors/reversible encryption/recovery agents and software only security components.
#4. The presence of a physically attached "encryption key" circuit that is physically capable of accepting/using a physical or software based key but is physically incapable of reading or reporting on its own key!
Security is a joke, humans suck at it because of fear. fear of losing the key causes businesses to create recovery agents or back-doors are put into every fucking thing that handles encryption.
[ link to this | view in thread ]
Re:
Nah. This White House is impossible to embarrass. They simply have an expanded number of meanings for "Get the facts straight."
[ link to this | view in thread ]
Re: Re:
[ link to this | view in thread ]
Re: I never understood
I'm not sure what exactly you envision there. Different things require different security, and security protocols change. Putting the security in the language only changes where the bugs could be - it doesn't get rid of the bugs.
[ link to this | view in thread ]
Re: Re: I never understood
This would be where things like buffer overflows, and incomplete data sets, specially crafted packets, and unhandled exceptions are handled with security in mind. If you can attack vulnerabilities in the programing language then everything built on top of those vulnerabilities are also vulnerable.
Take PERL, a relatively high level language. I was watching a video where a developer destroys the language. Basically because the compiler would allow a person to use untyped data, he could make any perl program execute malicious code the moment he has access to provide data in just about any variable. I wished I could find the link to it but I just cannot remember where it was... maybe a TED talk. Hopefully someone can remember and post the link here.
For security reasons... programming languages should be strongly typed! Sure there are a number of ways to help protect against this, but if you just don't allow for it to begin with... you never have to worry about it.
So in short programing languages should be written to pretty much prevent any ambiguous code execution as much as logically possible.
[ link to this | view in thread ]
Re: Re: I never understood
[ link to this | view in thread ]
Re: Re: Re: I never understood
Are you cognizant of various operating system safeguards upon over running ones memory space? How does the language used stop these attacks?
You imply that it is possible to eliminate all potential bugs that could possibly affect code execution - do you really believe that?
[ link to this | view in thread ]
About that...
Alfa is looking to out other security researchers Camp has been in contact with, presumably in hopes of nailing a few of them to the wall for drawing mistaken conclusions about Trump server traffic.
When the story first came out I figured it was just a stupid mistake on the security researcher's part, making a connection that didn't actually exist. People make mistakes, it's not that big of a deal honestly, story over.
With how fanatical they are apparently being in demanding everything however, going on a gorram crusade to 'set the record straight' I'm starting to revise my opinion and suspect that there might in fact be a bit more to it than that. Whether that be the original findings being a little too close to actual evidence they don't want found, or wanting to scare anyone else from investigating their doings for purely innocent reasons(promise!), their actions leave me with the impression of attempting to send a message to scare people off at the least.
[ link to this | view in thread ]
That stupid banks needs to get a response with a least one pony reference and "snort my taint"!!
[ link to this | view in thread ]
What is the expression, a lie goes around the world before the truth even gets it's pants on?
Worse for this guy of course if he got meme'd. At that point, all hope is lost.
[ link to this | view in thread ]
[ link to this | view in thread ]
Re: Re: Re: I never understood
ie: there is much more to it than just the language used
[ link to this | view in thread ]
Re:
[ link to this | view in thread ]
Re:
[ link to this | view in thread ]
Re: Re: Re: Re: I never understood
There will ALWAYS be risk of outside interaction from anything, not just from a hyper-visor. Technology is advanced enough for outside forces to affect computing with limited accessibility and with more advancement an external computer may be able to see the contents of another systems RAM remotely without shielding and potentially inject code physically into the machines circuits completely bypassing all physical circuit and software protections. The point is that we perform risk mitigation on these things by changing how we constructing languages, libraries, and compilers along with physically shielding them from interference. None of these are even new concepts, just poorly implemented as requirements dictated with little forethought for expediency.
[ link to this | view in thread ]
Re: Re: Re: Re: I never understood
Not going to play your troll game.
A mechanic is more than capable of telling an Engineer what is wrong with their engine design without being an Engineer. The same reason we can all understand the weakness behind a tumbler locks without being lock smiths.
We are over reliant on idiot "professionals" with a long list of credentials but full of stupid! Seen it so damn many times...
[ link to this | view in thread ]
Re: Re: Re: Re: Re: I never understood
What happens when you build your house upon unstable ground? Same concept applies elsewhere.
If you put your pristine unbreakable language upon corrupted hardware, you're going to have a bad day.
[ link to this | view in thread ]
Re: Re: Re: Re: Re: I never understood
Really? Please explain the IOT botnets.
[ link to this | view in thread ]
Re: Re: Re: Re: Re: I never understood
And yet you claim that strengthening one link will make the entire chain stronger.
[ link to this | view in thread ]
Re: Why Not...
Paying to sort through them should not be a barrier as that can backfire to others asking for legitimate documents. But, I like the way you think.
[ link to this | view in thread ]
Re: Re: Re: Re: Re: Re: I never understood
[ link to this | view in thread ]