full-disclosure - CDMA and 4G Android hacking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Wed, 10 Aug 2011 16:25:02 -0700
From: coderman <coderman@...il.com>
To: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: CDMA and 4G Android hacking

On Wed, Aug 10, 2011 at 8:24 AM, Nick Kralevich <nnk@...gle.com> wrote:
>... I read about a recent attack you performed against
> Android phones via CDMA and 4G.

i did not perform the attacks. only observed and toyed with the attackers.

> I was wondering if you could share more information with us about the
> attack, so that we could protect our users.  Any additional technical
> details you could share with us would be greatly appreciated.

some suggestions:

the attackers were able to use non-privileged apps to continually
invoke voice search, possibly other services. as you know, voice
search sends voice data to google servers... over the 3G or 4G
connection, which in this situation provided the attackers with an
open mic. (and they can intercept, so you won't see anything on your
end.) why isn't voice search always over HTTPS? why can it be invoked
continuously?

any apps that communicate in clear text are bad (exposing attack
surface to anyone on the network). apps that do unsigned updates in
the clear are even badder. why does google let these things into the
market?

apps that store private information in clear text are bad. apps that
store sensitive authentication credentials for other services in the
clear on the device are even badder. why does google let these things
into the market?

escalations from unprivileged sandbox'ed app exploit (see above) to
kernel or uid0 are bad. perhaps you could offer a large bounty for
these?

can i have a "paranoid mode" of operation? here is a short list of
only some things i had to do not to become a victim when using Android
over malicious networks last week:
 - root my phone to have access to what i need to secure it. (yet
rooting itself indicates vuln!)
 - kernel rootkit my phone to neuter certain syscalls, or block them
from certain apps by UID
 - hard disable certain devices entirely via /proc, /sys, or kernel rebuild
 - build my own kernel modules to do secure networking (tap, iptables)
 - reverse/hack insecure services and apps because Android permissions
are too coarse
 - monitor anomalies via adb shell and respond to incidents (kill
-STOP the spy processes, etc.)

i could go on, but i fear these concerns are falling on deaf ears. (or
to be generous, those that care find their objections overruled by
mgmt.)

last but not least, you could always attend DEF CON and find these
issues yourself. i spent two days interacting with these attackers and
learning quite a bit. i am sure you would too...

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/