How a Hacker Proved Cops Used a Stingray to Find Him
politico.com
politico.com
Furthermore, they allegedly already had his ip, so why bother with a stingray? They could simply tell his cell carrier to provide them with all his location data (as well as further dates).
It seems to me that they went fishing with their stingrays because they didn’t in fact know his real IP address and only knew from a source or other mistakes his approximate whereabouts.
It wouldn’t surprise me if they only had his VPN’s IP and were just looking for everybody connecting to the VPN in the stingray range and this is how they found him.
Remember that getting subscriber data/metadata from ISPs requires a warrant, and that a single tower location could cover a 6-12 sq. km. area (plenty of space to hide in)
Getting a search warrant is easy, but not getting one is even easier & leaves no paper trail.
https://en.wikipedia.org/wiki/Enhanced_9-1-1#Wireless_enhanc...
Of course, that was old GSM days, it may be something completely different today in 3G/4G/LTE, but so is on the other hand the location hardware and algorithms of carriers.
But no, no handoffs were needed to track you very precisely even back then. There were ways around, but given the poor opsec in the case, it is doubtful something like that was used here.
> Rigmaiden eventually pieced together the story of his capture. Police found him by tracking his Internet Protocol (IP) address online first, and then taking it to Verizon Wireless, the Internet service provider connected with the account. Verizon provided records that showed that the AirCard associated with the IP address was transmitting through certain cell towers in certain parts of Santa Clara. Likely by using a stingray, the police found the exact block of apartments where Rigmaiden lived.
Police found him by tracking his Internet Protocol (IP) address online first, and then taking it to Verizon Wireless, the Internet service provider connected with the account. Verizon provided records that showed that the AirCard associated with the IP address was transmitting through certain cell towers in certain parts of Santa Clara. Likely by using a stingray, the police found the exact block of apartments where Rigmaiden lived.
The take-away here, is that end-to-end protocols by neccessity as currently written send the src IP in the packet. If we'd designed IP to send the src IP as a payload, and had encrypted payload (TLS style) and then only had the destination IP in the outer packet, things might be different.
I've asked this question over the years since the 1980s: Given that we thought source based routing was a thing, its understandable we designed for simpler times with src IP in the packet but given its not a thing now, and privacy is, why do we still send the src IP in the packet? It doesn't mean anything useful, to most agents. NAT/CGN devices don't actually care, they want you to be consistent about which interface you arrive on, and the 5-tuple has it, but other things could be used which have no end-to-end impact. Beyond the NAT/CGN boundary, nobody cares, routing is solely on the destination and the ASN of the transits. Once at the destination, the payload is available, to find the originators address, to return things.
Src IP is not actually neccessary, in the IP layer. (in theory)
The parties cannot obtain the shared secret the usual way, the Diffie-Helman exchange. It cannot be performed, because it requires back-and-forth communication, which we are trying to establish in the first place. Of course, we'd still need to use certificates signed by public authorities to deal with the standard MitM concerns.
The alternative would be for the sender to use the recipient's public key to encrypt the source IP address. That would require a DNS-like system that would store and serve public keys corresponding to a given IP address you are trying to communicate with. This is something doable, especially in IPv6 world where you don't really have to reuse IPv6 addresses, but it leads to all kinds of practical problems, figuring out which is probably best left as an exercise for the reader.
The real interesting question is what happens when you get owned by what you didn't write?
Technically, the client could encrypt their IP with the y=H(g^{scr}) key (result of the DH KE) and send (Enc(y, IP), g^{rc})-- where H is the oracle, g^s server public key, rc <session nonce>*key (or generally 1 time key). The server can then compute the same key (g^{rc}^s and then apply H) and decrypt.
So the second and third paragraph contradict a bit each other, which was the sole reason for my clarification. I am not stating you as wrong or anything; I was just augmenting, so other readers don't get the wrong impression and decouple Diffie-Hellman KE from public key cryptography.
P.S. The remaining issue is to make sure the server does not have to decrypt the IP for invalid connections etc (that is avoid DOS or leaking secrets as we are operating on not trusted ciphertext).
Any examples? I honestly don't see any problems here.
Throw onto that the trust issue - such IP certificate repositories are very quickly able to determine who is communicating with each other, and at what time. Whilst this is currently possible anyway, current methods are less centralised, more expensive, and more visible.
You'd have to go full onion
theoretically, multiple keys can share an ip-hash, but the handshake will fail if the intended recipient doesn't have the expected keypair[2]. so far this hasn't been an issue, but you are better off if you know the destination's pubkey beforehand.
[1]: https://github.com/cjdelisle/cjdns
[2]: https://github.com/cjdelisle/cjdns/blob/master/doc/faq/doppl...
* To return ICMP error messages ("destination unreachable"), otherwise you'd have long timeouts.
* Ratelimiting outside the server (e.g. DDOS protection). Many ISPs do actually filter source IPs. (Of course you can't on the backbone, any there are plenty shady AS.)
* Leaving it off won't help against correlation attacks.
* Most applications will need it, so it makes sense to have it in the network layer instead of coming up with incompatible implementations above.
I was making statements about the road not taken: we have dst IP in the packets, from before BCP existed.
If the third party amplifiers in this scenario can validate that the traffic is spoofed, it cuts out amplification attacks.
These kinds of discussions seem utterly divorced from the reality of networking to me.
Which also didn't fly for obvious reasons. src,dst pair as part of a tuple was just simpler.
Realistically (and unfortunately), if you don't want to be tracked then you're going to need to do some combination of tunneling, proxying, and encrypting.
I like your thoughts, but I don't understand how it would have helped in the Hacker-Verizon-Stingray case.
First, an analogy: Suppose no one ever wrote a return address on postal letters. People wrote only the destination. The recipient has to open the envelope to see who wrote the letter. The postal system still works and it's way more private. However, if the authorities are watching your particular mailbox at your house, copying the outside of every incoming and outgoing letter, what privacy have you gained? They still know who you wrote to and who replied.
Now back to the Hacker-Verizon-Stingray case: When the hacker connects to Verizon, his phone must identify him as a Verizon customer at some protocol layer. The identifying info could be IMEI, IMSI, or Verizon account number. Otherwise anyone could use Verizon for free if there were no account. Likewise, when Verizon transmits info back to the hacker, Verizon has to know which cellphone it should go to, or at least which cell tower.
In your design, the outbound packets from hacker to Verizon contain cleartext destination IP, but the src IP is encrypted. Fine, but then the Stingray finds the Verizon account number associated with that connection -- that info being available at some protocol layer. The Stingray then watches for any connections from Verizon back to the hacker that use the same Verizon account number. The Stingray thus collects both sides of the connection just as before. Am I missing something?
You do understand that the IP that the return traffic is destined for has to initially be addressed to the IP of the NAT device, not what the client thinks its IP is, right?
Furthermore, eavesdropping for metadata on the line is one of the lesser privacy concerns for most people. What really matters are privacy violations by the providers higher up the stack, where the address of both endpoints must be known to enable communication.
I was, for example, using VPN services and Tor well before 2008. And I've never been more than a gray-hat hobbyist sort of "hacker". Anyone seriously into criminal activity who didn't reliably hide their IP address was a fool, even then.
My point isn't to dump on Rigmaiden. It's just that articles like this contribute to the FUD about privacy being impossible now. The reality is that most criminals have horrible OPSEC. Especially when they're just getting started. And then they're careless about historical connections.
Article title: “proved”
> Rigmaiden had received boxes and boxes of criminal discovery that would help him understand how the government planned to prosecute its case. In the penultimate box, he saw the word “stingray” in a set of notes.
The authorities were exposed because of poor OPSEC as well. They weren't supposed to ever mention “stingray”.
EDIT: while we're here, do you have a single "start here" article/site for the basics of less-poor OPSEC?
https://blog.cyberwar.nl/2016/02/some-elements-of-intelligen...
https://www.opsecprofessionals.org/official/081103_DOD_OPSEC...
http://www.opsecprofessionals.org/training/OPSEC_Training.pd...
https://www.slideshare.net/grugq/OPSEC-for-hackers
https://grugq.github.io/blog/2013/06/13/ignorance-is-strengt...
https://theintercept.com/2015/11/12/edward-snowden-explains-...
http://thefifthcolumnnews.com/2017/03/tradecraft-introductio...
You might also enjoy my guides:
https://www.ivpn.net/privacy-guides/advanced-privacy-and-ano...
https://www.ivpn.net/privacy-guides/online-privacy-through-o...
Whether the law allows or should allow the use of such devices, and whether with or without a warrant is up for debate, but it can't allow hiding their use, not in an open society with due process. It was always bound to be the case that some judge would think so, that some police note would leak this, that some police office would testify about it, that a Snowden would leak it, or that the public would figure it out anyways (especially when it comes to active devices).
So I wouldn't blame bad OPSEC on the part of the police here for anything. (Not that you are. Just saying.)
The defendant in the story, BTW, is not very sympathetic. In general, for test cases, one wants a sympathetic defendant. That's because judges are at least somewhat biased, typically. A judge has to imagine a much more sympathetic defendant and set of circumstances in order to convince themselves to continue with a line of argument that leads to the defendant being cleared on a technicality.
Security through obscurity has limited and unpredictable usefulness. Good OPSEC can delay a leak, maybe. But OPSEC is still much harder for defenders than attackers.
The article doesn't mention it, but SURELY agency planning about this particular secret covered the next steps to take when it leaked.
Ordinarily good OPSEC has defense in depth. Secrets should have limited useful lifetime. "Stingray" as a secret doesn't: once bad actors know their phone locations can be targeted, they can't un-know it.
It should be obvious to the holders of secrets when they leak, so they know they're compromised. Having this "Stingray" crop up in a big mess of bankers' boxes full of court docs isn't obvious.
Security by obscurity needs a plan B ready to roll at any time.
Much better is transparent security, where the tech is well known, the actual secrets have limited useful lifetimes (key-rotation and forward secrecy for example), and reasonable controls exist (search warrants in this case).
If law enforcement executives don't know this, they need to go back to school. But they probably do know it, and they're practicing security-by-obscurity on their plan B.
(I don't defend somebody who stole large quantities of taxpayers' money. Not at all. But the rule of law--search warrants--is vital.)
Edit - I recall reading that years ago in Tsutomu Shimomura's book 'Takedown' (published in 1996). Outside of this, I have no other reference. It's a good read BTW. https://www.amazon.com/Takedown-Pursuit-Capture-Americas-Com...
"Use of stingray technology goes back at least 20 years [ <= 1994]. In a 2009 Utah case, an FBI agent described using a cell site emulator more than 300 times over a decade.... "
"...Shimomura was sitting in the passenger seat of a Raleigh Sprint technician's car, holding a cellular-frequency direction-finding antenna, and watching a 'signal-strength meter display its reading on a laptop computer screen.'"
This sounds, perhaps, functionally equivalent to a modern stingray, but I suspect it was not operating as a cell-site simulator. The hardware/software required at the time to "man in the middle" Mitnick's cellular calls would not have fit comfortably with Shimomura in the passenger seat of a car and would not have run smoothly on a mid-90's era laptop. Also, the bandwidth required to forward the connections would have only been achievable over directional microwave or landline which seems unsuitable for use in a moving vehicle. However, this was the dawn of digital cellular networks. The calls would not have been encrypted in any way at the time so tracking the source of specific emissions using triangulation would have been fairly trivial, especially with the assistance of a Sprint technician with access to the CDMA code Mitnick's handset was using at any given time.
Actually, I just checked and it seems Sprint didn't launch its PCS network until later that year[0] so it's possible the network in question was analog(?), making simply "listening in" even easier, without having to simulate anything.
[0]http://articles.baltimoresun.com/1995-11-16/business/1995320...
It would be laughably easy by today’s standards. Cloning AMPs phones (with ESN/MIN from “trashing” and bootleg Motorola service software) was within the reach of bored teenagers, but the elusive “vampire phone” required decoding the control channel. This was “hard” at the time.
It could be done with the right service equipment or say, suitably hacked firmware for something like an OKI 900...
No stingray required, you could indeed do everything passively. Very different times. Today you could probably do it all by dragging a few blocks around in gnu radio’s grc tool.
hn.algolia.com/?query=rigmaiden
"Several months later, in April 2015, the New York Civil Liberties Union (the New York State chapter of the ACLU) managed to do what no one else could: successfully sue to obtain an unredacted copy of the NDA that the FBI had law enforcement agencies sign when they acquired stingrays"
Really the term hacking could use more consistent sub-definitions per type. Social engineering is well established but there isn't even a uniform term for quickly conveying the nuance of say cracking DRM offline vs getting in a server.
For example, can your carrier supply you with a whitelist of their towers and then ignore everything else? Or the legitimacy of each tower could be signed cryptographically by the cell providers? Of course you have to trust the security infrastructure of your cell provider, but that seems slightly better than just trusting everything by default. (Disclaimer, I know nothing about cellular infrastructure...)
[0] https://cellularprivacy.github.io/Android-IMSI-Catcher-Detec...
[1] https://github.com/CellularPrivacy/Android-IMSI-Catcher-Dete...
Obviously this is fiction. Romance or thriller?
Like many cases involving stingrays, the charges were essentially dropped once challenged in court.
There should really be some sort of CPU/power budget enforced by one's phone on a per page basis. If there's no user action going on, a page should only be allowed to run a certain number of instructions.
P.S. Yes, people are paying power and time (cpu/personal) to watch ads to pay (?!) for websites and provide private information.
1) If you do it from home, the govt already knows where you live, or you can use proxies, or Tor, or a VPN.
2) If you don't do it from home, you are practically anonymous if you change your mac address and use someone else's wireless network, which are ubiquitous today in airports, restaurants, etc.
Which is not retained indefinitely. If you're not committing a crime, that footage will be gone in 30-90 days.
For someone so paranoid about privacy as to not even own a "dumb" phone, I was curious what type of computer/internet setup they would be using to work around all the privacy traps such as broswer fingerprinting, traffic analysis, deep OS and hardware exploits, linguistic analysis, etc. etc.
While it wouldn't erase every hint of your presence, it takes a correlation of data to track someone; disparate trackable info is insufficient.
[1] https://puri.sm/posts/purism-librem-laptops-completely-disab...
The main drawback have been that people rarely label apartment doorbells anymore, so if you don't know which button to press you're in trouble. Another is getting hold of old friends if you don't know their email address (I don't have Facebook either).
Overall, I'm fairly content with the situation, and am seriously considering not getting a new one. Another benefit is that I'm more likely to bring my laptop if I go somewhere, and thus when I do connect to the internet and have time to kill, I often get work done instead of mindlessly browsing HN/reddit or playing games.
My phone is indispensable for the kind of work that I do, I literally couldn't do my job without it.
- Async communication (slack/email) can be checked at your computer.
- Voice calls are usually done with your computer anyway.
- If you are on call, an old-fashioned pager can be used.
Frankly, although I do have a smartphone, I wouldn't want a job where I was required to use it, or one where I was expected to be available at all times unless on call.
Does Slack have better uptime than email?
Does the office have redundant ISPs?
And the jobs that require a phone often come with a phone provided. So you still don’t need one yourself.
If I need to participate in on-call rotation or similar, I expect the employer to issue a phone. For a remote job, I will obviously get one myself -- but then strictly for job-related activities.
(by the way, if anyone is looking for an experienced infrastructure engineer/"DevOps" guy, give me a cal...errh email)
You probably don’t realize nor intend this, but that can be a large red flag for your candidacy from the other side of the table, particularly if the role involves security because you’re broadcasting a slight misjudgment of your threat vectors and exposure. The number of resumes most folks go through, expecting ravens from Winterfell will get you dropped fast. Torvalds could probably get away with making initial hailing frequencies that difficult, but you or I should just buy a phone number of some kind, as much as it sucks.
The phone isn’t the problem if you apply opsec correctly, buy the right one, and operate it like a compromise hazard. (It is.)
Anyway, point is, if you need a temporary phone while job hunting, try google voice? I hate google now but this may help temporarily, or maybe you could find a better provider (other than google, that is).
Good luck with the job hunt!
This is a little extreme, but I've started turning off my phone or putting it in airplane mode when not expecting a call.
In addition to not being as distracted, I've had a marked decrease in spam calls - I think they tend to mark phones that repeatedly send them straight to VM as "cold".
It is known that complete operating systems run on every chip on that phone of which you don't have knowledge of or access to.
To think a software security solution provided by an OS, a pretty high-level abstraction when considering hardware, of the ability to turn off the radio is insane in these days and ages.
Furthermore with permanent batteries (or with a backup battery hidden inside) being off to the user doesn't mean anything either.
Assuming such an exploit exists, I don't think I'd be targeted with it. It's my understanding three letter agencies tend to hoard that sort of thing, not blast them at random privacy aficionados.
> the eavesdropping technique "functioned whether the phone was powered on or off."
https://www.cnet.com/news/fbi-taps-cell-phone-mic-as-eavesdr...
I would hope that the FBI would not override airplane mode on a smart phone... what if they did so while a suspect was actually on a plane?
A warrant doesn't give police the right to endanger others IIRC...
Nothing would happen. Just like nothing happens to the thousands of people who forget to switch their phones to airplane mode every day.
I would think a phone with a removable battery would otherwise serve your concerns.
The sentence was about permanent batteries with an aside about how technically a remove-able battery phone could still have power somewhere with it removed.
I leave it off most of the time, but I have to be on-call for my day job every few weeks and can't really not have a phone then and still keep my job.
It's a shame that phones are so closed and proprietary. I looked into changing a phone's IMEI number, and turns out that's illegal in most places and a serious no-no. How can there even be a law like that??
I agree that the vast majority of those that will have trouble are intentionally engaged in illegal activity. But, at any given time, there must be both fair fair number of people who are unintentionally committing illegal acts and those who are falsely believed by law enforcement to be committing illegal acts.
There is an argument to be made that everyone should be more careful about privacy, thereby increasing the cost (and opportunity cost) of invasive investigations and forcing law enforcement to be more selective about the degree of certainty they have before employing more invasive investigation techniques.