In collaboration with the Censored Planet at University of Michigan and Breakpointing Bad, Information Controls Fellowship Program Fellow Ben Mixon-Baca recently designed, deployed, and tested a radical new way to identify leaky apps that expose users to a variety of threats due to poor or missing cryptography. Dubbed CryptoSluice, the tool—which is also presented in a paper that is currently under review—utilizes a form of modified content sifting to identify apps associated with flows that have repeating byte patterns in anonymized and obfuscated data. The innovative methodology employed by the new tool preserves user privacy by automating app attribution from real-time internet flows without storing raw payloads or packets to disk (raw payload never leaves memory).
If you’re a vulnerability researcher or network operations team manager, this is major news. Deploying CryptoSluice will allow you to finally forgo deductive reasoning and reverse engineering when looking to determine which network flows are putting your users at risk and which apps are responsible for generating those flows. In their place? A far more accurate and less time-consuming inductive approach that also happens to comply with the Menlo Report’s guiding principles by extracting app-related cryptography information from gateway internet traffic in a privacy-preserving manner (with CryptoSluice, no human being ever views raw packets—and no payloads are ever written to disk).
Read on to learn more about what CryptoSluice does and how you or your organization can use it to detect problematic apps and better protect user privacy on your network.
What Is CryptoSluice?
CryptoSluice offers researchers and network operators a new tool to proactively identify apps whose poor cryptography poses a threat to actual users. Its inductive approach enhances overall network security by eliminating deductive guesswork and the need to respond retroactively to active threats—and its heightened emphasis on user privacy opens a new door for conducting ethical computer research on live network traffic.
The novel development of CryptoSluice was guided by two key principles:
- Apps with repeating byte patterns can easily fall prey to surveillance, censorship, or targeted attacks (and therefore such patterns should never be used); and
- In order to preserve user privacy, researchers should never view the raw payloads of actual users, nor write them to disk.
In isolation, these two principles serve as fairly unimpeachable pillars in a security researcher’s ethos. When combined, however, they present a seemingly impossible task. Without obtaining visibility into actual user packets or payloads, how is a researcher supposed to determine which network flows in the data are putting users at risk (due to repeating byte patterns) and which apps are responsible for generating these problematic flows?
The answer for Mixon-Baca and his collaborators—Diwen Xue and Dr. Roya Ensafi from University of Michigan, and Dr. Jedidiah R. Crandall from Arizona State University—was to come up with a way to perform all raw payload analysis in memory. Though this was yet another seemingly impossible task, the team accomplished it by designing a four-stage pipeline capable of identifying apps that fail to satisfy best practices (i.e., use repeating byte sequences) while handling traffic rates on the order of 10 to 100 Gbps.
In Stage One of CryptoSluice, transitive sampling is used to strike the right balance between reducing traffic volume while still collecting enough data to identify apps that utilize repeating byte patterns. Stage Two then employs modified content sifting (tweaking the original algorithm, which was designed to detect worm propagation) for in-memory payload analysis. Once the modified content sifting is complete, Stage Three of the tool’s methodology utilizes in-memory post processing to log invariants before Stage Four’s information retrieval of anonymized/aggregated information completes the four-stage pipeline. Together, these four stages result in researchers being able to obtain app attribution from real-time internet flows without ever viewing or storing raw payloads from Internet traffic.
And it works. When deployed across a major university’s network for a period of 30 days, CryptoSluice identified 105 apps with poor or no transport layer security. Six of these apps—some with millions of downloads worldwide—were subsequently reverse-engineered and confirmed to be putting users at risk by requesting suspicious permissions or employing insecure cryptography (or none at all).
How Do I Start Sluicing?
Anyone interested in identifying apps that are operating insecurely on their network are encouraged to reach out to [email protected] or Mixon-Baca directly ([email protected]) to discuss deployment options. The tool and corresponding paper are currently under review and will be made publicly available upon acceptance.
From an ease of deployment standpoint, researchers should be aware of three key items:
- CryptoSluice requires use of the PF_RING library. Note that a license is required to run the Zero Copy of PF_RING (academic institutions, however, do not have to pay).
- Separate drivers for the network card need to be installed and loaded before that functionality can be used.
- An approval process, similar to that which was followed and obtained by the developers of CryptoSluice, should be carried out prior to deployment on a network with live users.
Looking to the immediate future, Mixon-Baca intends to continue running CryptoSluice, further expand its deployment, and add additional features. He also encourages other researchers to independently investigate and validate the six apps that were initially identified by CryptoSluice’s methodology and confirmed through reverse engineering to be putting users at risk. Those six apps are (1) Kuaishou, (2) Fliggy Travel (Taobao Trip), (3) Quark Browser, (4) Speedin VPN Accelerator, (5) Royal Flush, and (6) Ctrip. Reverse engineering of all 105 apps that were identified during CryptoSluice’s 30-day deployment is also encouraged to further vet and confirm this novel methodology.
Questions? Comments? Want to share what you’ve discovered?
Reach out to the CryptoSluice team [email protected] or Mixon-Baca directly ([email protected]).
Note: This post is Part Two of a two-part series on Mixon-Baca’s work with CryptoSluice. Part One, provides a snapshot overview of the methodology’s inductive approach as well as insights gained from deploying CryptoSluice through a major university’s Internet gateway over a period of 30 days.
About the program: OTF’s Information Controls Fellowship Program (ICFP) supports examination into how governments in countries, regions, or areas of OTF’s core focus are restricting the free flow of information, impeding access to the open internet, and implementing censorship mechanisms, thereby threatening the ability of global citizens to exercise basic human rights and democracy. The program supports fellows to work within host organizations that are established centers of expertise by offering competitively paid fellowships for three, six, nine, or twelve months in duration.