it was fun! i assume we have come to an understanding - security, like anonymity, is best as public good that floats all boats UPSTREAM (even if current reality far from vision of ideal). hopefully a good arrangement not needlessly obstructed... best regards, except to the surreptitious surveillance-ers; you're the outlier here! love, codermange --- many of the best detections for advanced attacks involved not-quite consumer hardware and customized systems for distributed storage, observation, and processing. this is way beyond the budget, skill, and time afforded even modestly technical users for most intents and purposes. however, sometimes simple measures to thwart attacks combined with a keen situational awareness can identify sophisticated attacks with less technical means. anomalies signal to attempt counter measures and initiate in depth scrutiny. --- consider the following, - baseband attack against mobile target: + cannot "hot patch" running image, as some changes take effect during initialization. force push results in restart. anomaly #0. + battery longevity one third what expected, distinct transition post-baseband-push for longevity of full charge - power consumption doesn't lie. anomaly #1. + abnormal signal power level for well known location for cell link. anomaly #2. + outbound dial attempts cannot put cell radio into lower bitrate audio call mode - outbound dial attempts fail - serious anomaly #3. (workaround of making call immediately on boot appears effective, and keeping a call in voice mode appears to thwart data exfiltation when no wifi uplink avail. + (technical but possible) pushed baseband needs to pass authentication of image; signature valid, revision same as prior mtd partition archive version, however sha digests do NOT match! this is not expected for the same build version. anomaly #4. --- consider the following, - BIOS attack with post-boot re-infection vector triggered once graphics mode transitions from console to graphical display: + target hardware is a match and supported, however, root file system is XFS, ZFS, or other unsupported *nix variant. attempt to persist by injection on file system using kernel fs funcs and data structures (this gets around FDE by interacting before luks/mdcrypt/loopaes/cryptoloop layer) thus causes kernel panic. anomaly #0. [note: A for effort++ by setting a not-again flag after first attempt. this prevents the kernel panic from becoming a persistent DoS as the next boot attempt will complete normally into graphical desktop. Subsequent reactivation follows similar fail safe of next boot succeeding after post boot persistent hook failure and kernel panic.] --- consider the following, - SMS MitM attack against Android mobile target: + normal delivery of SMS using a client such as TextSecure that checks for delivery confirmation on SMS, (do NOT use fire-and-forget like majority of text clients). attack introduces latency on confirmation due to radio mode switching between high rate exfiltation mode and low rate SMS with additional MitM proxy processing latency added as well. this results in messages initially showing "Message delivery failed" before shortly then confirming successful transmisssion. anomaly #0. + abnormal signal power level for well known location for cell link. anomaly #1.
On Wed, Jan 22, 2014 at 07:38:17AM -0800, coderman wrote:
consider the following,
- BIOS attack with post-boot re-infection vector triggered once graphics mode transitions from console to graphical display: + target hardware is a match and supported, however, root file system is XFS, ZFS, or other unsupported *nix variant. attempt to persist by injection on file system using kernel fs funcs and data structures (this gets around FDE by interacting before luks/mdcrypt/loopaes/cryptoloop layer) thus causes kernel panic. anomaly #0.
Is there any way to save any evidence of this kind of attack, to use to help fix the vulnerability? ... and to provide to the EFF, ACLU, or other interested parties that may want to litigate? Any info, links, etc. appreciated.
On Fri, Jan 24, 2014 at 10:07 AM, <fre3frizt@riseup.net> wrote:
... Is there any way to save any evidence of this kind of attack,
as stated earlier, you can use technical means to monitor at this level. software defined radio with the right decoding, good position, proper antennas can obtain full bits. even without specific decoding, measuring signal levels at various frequencies compared to baseline is also useful. and of course, you can always improve decoding after the fact. directly accessing flash storage and comparing firmware images in a way otherwise not possible. instrumenting and modifying software to verbosely report on anomalies and make it likely attempted attacks will fail unsuccessfully. (see also camouflage) the list goes on and on and on,
... to use to help fix the vulnerability?
help fix vulnerability? i am sympathetic to your intent, but these exploits are the product of a large, well funded process. they take advantage of positioning in the middle, or next to your endpoint. they're churned out like an assembly line. "saving evidence to fix" is like asking for a digest to add to your antivirus blacklist... in this model, success is measured by doing less badly. not by protecting or fixing.
... and to provide to the EFF, ACLU, or other interested parties that may want to litigate?
i have alluded to this before: multiple constraints limit what i can disclose, and those groups are not likely to be helpful in specific scenarios. general efforts to eliminate public funding for CNE would be useful, however!
participants (2)
-
coderman -
fre3frizt＠riseup.net