/
Dev%2FAdvanced_Deanonymization_Attacks.mw
160 lines (83 loc) · 4.76 KB
/
Dev%2FAdvanced_Deanonymization_Attacks.mw
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
{{Header}}
== Covert Channels ==
This page is a brain-dump all known covert channels and mitigation ideas. A brushed up version for users will be written later when countermeasures are deployed.
See also:<br />
[[Advanced Deanonymization Attacks]]
ticket:<br />
[https://phabricator.whonix.org/T540 Covert Channels Meta Ticket]
=== Topics ===
Intro
choices: Some can be eliminated outright, Other channels need to be degraded sufficiently). Good news is it is possible to defend against them all but not without cost.
All problems linked (keystroke dynamics, cpu-induced network latency, TCP ISN CPU temp-induced timer skew, DRAMA cross-vm keystroke monitoring, cpu-cache crypto sidechannels).
covert channels are part of TEMPEST category of attacks. Cryptographers had to deal with them forever but they pose serious problems for systems aiming to isolate untrusted malicious processes. They can be classified as snooping on activity outside a VM or being able to communicate secretly with the outside world.
***
keystroke fingerprinting:
Excellent paper on covert channels in general:
https://www.usenix.org/legacy/events/sec06/tech/shah/shah_html/jbug-Usenix06.html
cpu stress solution for keystrokes? not effective
Question: How to delay keystrokes?:
https://stackoverflow.com/a/33134735
Answer: funnel all system input events through a local network interface which you inject random latency in. On host so its system wide.
uinput is the kernel input device API but needs C expertise to write a program to do this directly.
usbip? - in mainline.
--Not a solution for PCI input devices - most of PCs.
network latency: iperf stress tool or Ethan's netfilter_queue soltion
alternatives:
https://superuser.com/questions/67659/linux-share-keyboard-over-network
https://unix.stackexchange.com/questions/46363/share-keyboard-over-network-as-separate-device
https://github.com/Blub/netevent/wiki/Share-devices-over-the-net
netevent cobbles netcat host/client together. set on loopback. Run as service with client as localhost. Apply netfilter_queing on loopback to introduce random delays. Pros: kernel solution, display server agnostic. (It uses uinput interface to capture all events)
New research results on obfuscation - no working tool. Contact them and ask if they can write one?
https://github.com/vmonaco/keystroke-obfuscation
https://github.com/vmonaco/keystroke-obfuscation/issues/1
***
block tcp isn firewall? rewrite tcp isn?
Not possible and needed for security anyway. Are a part of all modern OSs
https://events.ccc.de/congress/2006/Fahrplan/attachments/1211-23c3hotornotpres.pdf
https://events.ccc.de/congress/2006/Fahrplan/events/1513.en.html
https://events.ccc.de/congress/2005/fahrplan/events/798.en.html
http://sec.cs.ucl.ac.uk/users/smurdoch/talks/eurobsdcon07hotornot.pdf
https://www.lightbluetouchpaper.org/2006/09/04/hot-or-not-revealing-hidden-services-by-their-clock-skew/
23C3 Slide 30:
Run CPU at full load
Inefficient and must be done with
care since different types of tasks
can have varying temperature ef-
fects
CPU stress must be full load - (what about c-states and temp? Is there a technique less damaging to hardware?) - mitigation for TCP ISN. Maintains constant CPU temperature hence foils skew patterns in timers/crystal clock.
on host out of reach of malicious code in vm.
***
cpu activity induced latency:
QoS solution by Ethan White
Concept originally proposed in 23C3 slides and has now been realized.
Status: Awaiting deployment as a host and GW package.
***
very dangerous - process in anon vm can sniff keystrokes in other vms unmasking and stealing user data. /Scenario: JS in browser can pull this off:
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/pessl
Test PoC:
https://github.com/IAIK/drama
memory stress - DRAMA attack mitigation
stress-m2
in parallel (i.e., the attacker’s core is under stress) made any measurements impossible. While
no false positive detections occurred, only 9 events were correctly detected. Thus, our attack is susceptible to
noise especially if the attacker only gets a fraction of
CPU time on its core.
NUMA combined with CPU pinning also described as valid mitigation. Problem is NUMA environments exist for server systems only for the most part.
on host out of reach of malicious code in vm.
"In
this attack, the spy and the victim can run on sepa-
rate CPUs and do not share memory,
i.e.
, no access
to shared libraries and no page deduplication between
VMs. "
***
crypto side channels:
vcpu pinning to physical to guarantee no cross cache attacks on cryptoand make other attacks harder.
***
See also:<br />
[[Advanced Deanonymization Attacks]]
ticket:<br />
[https://phabricator.whonix.org/T540 Covert Channels Meta Ticket]
{{Footer}}
[[Category:Development]]