27 Jul
2013
27 Jul
'13
6:21 a.m.
I found this bit about hazards uniquely faced by internation travelers
very interesting:
Q: Do you think organizations are understanding and taking the threat
among these new mobile attack vectors seriously yet? Are security
managers really getting it? Why or why not?
A: The most-security-aware organizations are taking these threats very
seriously. They're destroying phones after taking them to hostile areas
with known malicious carriers, they're limiting what information gets
copied to the default inbox/contact list on devices, they're limiting
what applications can be installed on devices which have access to
enterprise infrastructure.
[...]
Q: In your presentation, you specifically referred to some of the threats
mobile users are facing now while traveling internationally. What are
you observing?
A: There are two major threat categories when it comes to international
travel, the malicious foreign carrier and the enterprising private
mobile attacker. These threats result from the fact that citizens of a
foreign country generally have no rights to privacy and no official
recourse if their information gets stolen while they are in the foreign
country. I already spoke about how foreign carriers have total control
over devices which are associated with their networks. Probably the most
alarming thing we've seen happen in our tests is how foreign carriers
can steal the cryptographic seed values from soft-tokens installed on
smartphones. One take-away I'd love to get across to all of your readers
is to never let soft-tokens become a solution to be relied on for
organizations which have a large number of international travelers.
[...]
http://www.csoonline.com/article/print/733691
I'm wary of distortions, outright bullshit, and vague handwaving by
security industry guys. As usual, interviewee Aaron Turner (of
IntegriCell, formerly Idaho National Laboratory, formerly Microsoft
security division) is vague about how code gets executed to do
undesirable things.
Smartphone 'soft-tokens' means virtual dongles used for (supposed)
two-factor authentication such as Symantec VIP or SecurEnvoy
SecurAccess. Pity Turner doesn't say _how_ iOS, Android, and
BlackberryOS yield 'total control over devices' to local carriers.
Turner goes on, in the bit about international travelers, to talk about
a cruise ship passenger who uses a cafe's WiFi in port, and 'the coffee
shop owner has realized he can make more money selling your address book
to spearfishers than he ever can make selling you even his
most-expensive latte'. I'm intrigued, Mr. Turner. How does connecting
a smartphone to a WAP give the WAP owner automatic access to the
smartphone's address book?
I'm used to assuming that networks are dangerous and untrustworthy and
layering things trustworthy over them. Why is that approach not
feasible with a smartphone -- or is Turner just another guy selling
unnecessary gear to the rubes?
28 Jul
28 Jul
11:19 a.m.
On Sat, 27 Jul 2013, Rick Moen <rick(a)linuxmafia.com> wrote:
A: The most-security-aware organizations are taking
these threats very
seriously. They're destroying phones after taking them to hostile areas
with known malicious carriers, they're limiting what information gets
copied to the default inbox/contact list on devices, they're limiting
what applications can be installed on devices which have access to
enterprise infrastructure.
[...]
Which would be more of a risk? A random drive-by attack against all users of
a rogue telco in some strange country or a random drive-by attack with a fake
cell tower in the center of the Melbourne CBD or other well trafficed area? I
presume the latter if compromising phones via mobile tower is so easy.
A: There are two major threat categories when it
comes to international
travel, the malicious foreign carrier and the enterprising private
mobile attacker. These threats result from the fact that citizens of a
foreign country generally have no rights to privacy and no official
recourse if their information gets stolen while they are in the foreign
country. I already spoke about how foreign carriers have total control
over devices which are associated with their networks. Probably the most
alarming thing we've seen happen in our tests is how foreign carriers
can steal the cryptographic seed values from soft-tokens installed on
smartphones. One take-away I'd love to get across to all of your readers
is to never let soft-tokens become a solution to be relied on for
organizations which have a large number of international travelers.
[...]
Given that telcos in countries like the US have deliberately sold phones with
malware pre-loaded, I expect that such things would be done in countries with
a supposed rule of law too if they were so easy. Of course the rule of law in
the US only applies to poor people.
Smartphone 'soft-tokens' means virtual dongles
used for (supposed)
two-factor authentication such as Symantec VIP or SecurEnvoy
SecurAccess. Pity Turner doesn't say _how_ iOS, Android, and
BlackberryOS yield 'total control over devices' to local carriers.
It seems that every time a new version of iOS is released someone jail-breaks
it quite quickly. So it's obviously not impossible to crack the OS. But
doing so reliably over a population without getting caught is going to be
difficult.
Turner goes on, in the bit about international
travelers, to talk about
a cruise ship passenger who uses a cafe's WiFi in port, and 'the coffee
shop owner has realized he can make more money selling your address book
to spearfishers than he ever can make selling you even his
most-expensive latte'. I'm intrigued, Mr. Turner. How does connecting
a smartphone to a WAP give the WAP owner automatic access to the
smartphone's address book?
There's also the economic issue. Why would someone who wants such data buy
from small cafes? If it was so easy to do then someone could setup wifi acces
points purporting to be McDonalds, Starbucks, and other common vendors in
central city areas. Phones usually connect to such Wifi access points by
default without even informing the user so if such a Wifi attack is possible
then it could be implemented against 10s of thousands of people a day in
Melbourne CBD instead of dozens a day in a backwater cafe.
I'm used to assuming that networks are dangerous
and untrustworthy and
layering things trustworthy over them. Why is that approach not
feasible with a smartphone -- or is Turner just another guy selling
unnecessary gear to the rubes?
Sounds like it.
It seems to me that one of the biggest problems with security is the use of
devices for multiple purposes. If a company issues a nice laptop and phone to
an employee then there's a good chance the laptop will be used to view porn
and the phone will be used for playing games (particularly if the employee has
children) and that's two major vectors for attack.
One of my suggestions has been to issue laptops with small screens to make
them less suitable for porn. For phone use when employees access sensitive
data it wouldn't be particularly expensive to give them a spare phone for
games.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
11:31 a.m.
On 28 July 2013 11:19, Russell Coker <russell(a)coker.com.au> wrote:
Just because it is possible to jail-break the phone, which usually requires
physical procession of the phone, does not mean your carrier can remotely
access your data. In fact, at least for some phones jail breaking can't be
done without erasing your data, so they still wouldn't be able to access it.
Maybe the article is talking about bugs/security exploits in the OS that
may or may not be fixed in recent code? A good reason not to use old
versions of Android.
I would hope everyone is using secure encryption these days for syncing
contacts, etc. However, if not, that is another way your carrier could get
access to your data.
--
Brian May <brian(a)microcomaustralia.com.au>
Smartphone
'soft-tokens' means virtual dongles used for (supposed)
two-factor authentication such as Symantec VIP or SecurEnvoy
SecurAccess. Pity Turner doesn't say _how_ iOS, Android, and
BlackberryOS yield 'total control over devices' to local carriers.
It seems that every time a new version of iOS is released someone
jail-breaks
it quite quickly. So it's obviously not impossible to crack the OS. But
doing so reliably over a population without getting caught is going to be
difficult.
29 Jul
29 Jul
10:30 a.m.
Rick Moen wrote:
A: The most-security-aware organizations are taking
these threats very
seriously. They're destroying phones after taking them to hostile areas
with known malicious carriers
IIRC for the beijing olympic games, BHP gave their people[0] shiny new
thinkpads to take to China, instead of taking their existing corporate
laptops. I heard ASIO (WTF? Not ASIS or DFAT?) told them to expect
Chinese intelligence to take laptops out of hotel safes, dd them, then
put them back. I don't think they do it for normal visits to
e.g. Surinam and South Africa, tho.
[0] though probably only management, not the plebes.
12:19 p.m.
On 29 July 2013 10:30, Trent W. Buck <trentbuck(a)gmail.com> wrote:
Rick Moen wrote:
Also think of: http://xkcd.com/538/
You might think you are protected by having all your files encrypted, then
the foreign country demands you give them your decryption key, with threats
of jail if you don't.
I wouldn't take any sensitive information on computer/phone/tablet
overseas, even encrypted, unless I absolutely had to.
Also consider that a hostile entity might be able to get cached browser
information, find out what Google, Twitter, Facebook, etc, accounts you
have, then coerce you to log into them.
--
Brian May <brian(a)microcomaustralia.com.au>
A: The most-security-aware organizations are
taking these threats very
seriously. They're destroying phones after taking them to hostile areas
with known malicious carriers
IIRC for the beijing olympic games, BHP gave their people[0] shiny new
thinkpads to take to China, instead of taking their existing corporate
laptops. I heard ASIO (WTF? Not ASIS or DFAT?) told them to expect
Chinese intelligence to take laptops out of hotel safes, dd them, then
put them back. I don't think they do it for normal visits to
e.g. Surinam and South Africa, tho.
12:20 p.m.
On 29 July 2013 12:19, Brian May <brian(a)microcomaustralia.com.au> wrote:
Also consider that a hostile entity might be able to
get cached browser
information, find out what Google, Twitter, Facebook, etc, accounts you
have, then coerce you to log into them.
... assuming of course you haven't saved your login or credentials
unencrypted in the browser, in which case it becomes even easier.
--
Brian May <brian(a)microcomaustralia.com.au>
4:06 p.m.
Quoting Brian May (brian(a)microcomaustralia.com.au):
You might think you are protected by having all your
files encrypted, then
the foreign country demands you give them your decryption key, with threats
of jail if you don't.
Schneier has had a number of articles about creative ideas to deal with
that scenario. There are some very creative people out there, and I
cannot remember most of the nuances. One was a filesystem that, if you
give it one key gives access to the real data but if given a different
key gives access to innocuous decoy data.
I've also considered storing on any traveling laptopc some large files
containing random data and publicising widely the fact that I do so.
I wouldn't take any sensitive information on
computer/phone/tablet
overseas, even encrypted, unless I absolutely had to.
Yes, it's an interesting problem. One possibility is to bring only a
generically loaded machine with the intent of later wiping it upon
reaching one's destination and downloading the intended substantive
contents off an Internet repository established in advance for that
purpose. The trick would be to keep the download size and transfer time
reasonable.
6:19 p.m.
Rick Moen wrote:
Schneier has had a number of articles about creative
ideas to deal
with that scenario. There are some very creative people out there,
and I cannot remember most of the nuances. One was a filesystem
that, if you give it one key gives access to the real data but if
given a different key gives access to innocuous decoy data.
Assange had a patch to ext ages ago (like, when ext2 was current) to
give you multiple filesytems inside ext, with deniability.
The game theory goes something like "unless ALL blocks are allocated
to filesystems you know about, you CAN'T know that I've given you all
the access keys, therefore you have no reason to ever stop hitting me
with that rubber hose". I'm not sure how that works in practice.
If you just mounted it as normal ext, it'd consider those secret
filesystems' blocks as not reserved, so they might be trashed by
writes.
Yes, it's an interesting problem. One possibility
is to bring only
a generically loaded machine with the intent of later wiping it upon
reaching one's destination and downloading the intended substantive
contents off an Internet repository established in advance for that
purpose. The trick would be to keep the download size and transfer
time reasonable.
And avoiding MITM if $bad_guy can lift the key material off your
person / out of your head beforehand.
7:55 p.m.
On 2013-07-29 18:19, Trent W. Buck wrote:
Rick Moen wrote:
For reference, the filesystem was called Marutukku or Rubberhose:
http://en.wikipedia.org/wiki/Rubberhose_%28file_system%29
https://github.com/sporkexec/rubberhose
--
Regards,
Matthew Cengia
Schneier has had a number of articles about
creative ideas to deal
with that scenario. There are some very creative people out there,
and I cannot remember most of the nuances. One was a filesystem
that, if you give it one key gives access to the real data but if
given a different key gives access to innocuous decoy data.
Assange had a patch to ext ages ago (like, when ext2 was current) to
give you multiple filesytems inside ext, with deniability.
The game theory goes something like "unless ALL blocks are allocated
to filesystems you know about, you CAN'T know that I've given you all
the access keys, therefore you have no reason to ever stop hitting me
with that rubber hose". I'm not sure how that works in practice.
If you just mounted it as normal ext, it'd consider those secret
filesystems' blocks as not reserved, so they might be trashed by
writes. 
30 Jul
30 Jul
1:50 a.m.
On 29/07/2013 7:55 PM, Matthew Cengia wrote:
For reference, the filesystem was called Marutukku or
Rubberhose:
http://en.wikipedia.org/wiki/Rubberhose_%28file_system%29
https://github.com/sporkexec/rubberhose
Truecrypt can do similar, you can have multiple containers and depending
on the key used, different containers will open up.
Cheers
A.
1:52 a.m.
On 29/07/2013 7:55 PM, Matthew Cengia wrote:
For reference, the filesystem was called Marutukku or
Rubberhose:
http://en.wikipedia.org/wiki/Rubberhose_%28file_system%29
https://github.com/sporkexec/rubberhose
Truecrypt can do similar, you can have multiple containers and depending
on the key used, different containers will open up.
http://www.truecrypt.org/docs/plausible-deniability
Cheers
A.
29 Jul
29 Jul
6:11 p.m.
Brian May wrote:
In case that's not obvious, that was (AIUI) BHP's point.
You're going there to have fun, not do deals, so your corporate
secrets stay at home on your "real" work laptop. This one is just for
skyping to your family or whatever normal people do.
IIRC for the
beijing olympic games, BHP gave their people[0] shiny new
thinkpads to take to China, instead of taking their existing corporate
laptops. I heard ASIO (WTF? Not ASIS or DFAT?) told them to expect
Chinese intelligence to take laptops out of hotel safes, dd them, then
put them back. I don't think they do it for normal visits to
e.g. Surinam and South Africa, tho.
[...]
I wouldn't take any sensitive information on computer/phone/tablet
overseas, even encrypted, unless I absolutely had to.
3:55 p.m.
Quoting Trent W. Buck (trentbuck(a)gmail.com):
IIRC for the beijing olympic games, BHP gave their
people[0] shiny new
thinkpads to take to China, instead of taking their existing corporate
laptops. I heard ASIO (WTF? Not ASIS or DFAT?) told them to expect
Chinese intelligence to take laptops out of hotel safes, dd them, then
put them back. I don't think they do it for normal visits to
e.g. Surinam and South Africa, tho.
Sounds about right.
Back in 1999, I worked as head of the system administration department
at a Linux-industry pre-IPO firm[1] where I had an excellent hunch,
eventually proved correct, that the new CTO was somehow tapping all
company electronic communications. (Later, it emerged that he was
monitoring via the ethernet switches.) I reasoned that, if I couldn't
trust the integrity of company infrastructure generally, I also couldn't
fully trust my Debian-based personal workstation, either, as he might be
able to either trojan it subtly enough to make detection difficult or
install a hardware keylogger.
Because the notion of this particular person having any form of
visibiltiy into my _personal_ activity between me and my server at home,
I bought for the first time a laptop, always used it rather than my
workstation for anything sensitive, and never, ever left it unattended.
[1] http://linuxmafia.com/~rick/essays/preipo.html
6:05 p.m.
Rick Moen wrote:
Because the notion of this particular person having
any form of
visibiltiy into my _personal_ activity between me and my server at home,
I bought for the first time a laptop, always used it rather than my
workstation for anything sensitive, and never, ever left it unattended.
And never used an external CRT (ref. TEMPEST), and... :-)
12:25 p.m.
On 07/27/2013 06:21 AM, Rick Moen wrote:
I'm used to assuming that networks are dangerous
and untrustworthy and
layering things trustworthy over them. Why is that approach not
feasible with a smartphone
Depends on the phone but mostly the proprietary baseband firmware (and
other blobz) and the modems direct memory access = your phone is pwned
by any serious adversary be them international or local. OTA updates can
be pushed silently by a telco by design even on a non smart phone.
they simply are not secure.
1:18 p.m.
On 29 July 2013 12:25, nic <nic(a)404ed.org> wrote:
OTA updates can
be pushed silently by a telco by design even on a non smart phone.
they simply are not secure.
Only if you get OTA updates from your telco. Even then I would assume it
will only get updates from the telco that provided you with the phone.
Which could be different from the telco that you are currently connected
to, especially if travelling overseas.
Doesn't apply if you didn't get your phone from a telco or installed a
custom version of Android on it.
--
Brian May <brian(a)microcomaustralia.com.au>
1:40 p.m.
On 29/07/2013 1:18 PM, Brian May wrote:
On 29 July 2013 12:25, nic <nic(a)404ed.org
<mailto:nic@404ed.org>> wrote:
OTA updates can
be pushed silently by a telco by design even on a non smart phone.
they simply are not secure.
Only if you get OTA updates from your telco. Even then I would assume
it will only get updates from the telco that provided you with the
phone. Which could be different from the telco that you are currently
connected to, especially if travelling overseas.
Doesn't apply if you didn't get your phone from a telco or installed a
custom version of Android on it.
My S3 gets OTA updates, I bought it outright and unbranded -- no carrier
owns my phone; however, I'm sure that they could if they wanted to given
how easy it is to push OTA updates.
Cheers
A.
1:55 p.m.
Andrew McGlashan <andrew.mcglashan(a)affinityvision.com.au> wrote:
My S3 gets OTA updates, I bought it outright and
unbranded -- no carrier
owns my phone; however, I'm sure that they could if they wanted to given
how easy it is to push OTA updates.
Isn't there a signature verification involved? For example, if I were getting
updates from a phone manufacturer rather than a carrier, I would expect the
phone to hold the manufacturer's public key and accept only updates signed by
the corresponding secret key.
1:44 p.m.
On 07/29/2013 01:18 PM, Brian May wrote:
Only if you get OTA updates from your telco. Even
then I would assume
it will only get updates from the telco that provided you with the
phone. Which could be different from the telco that you are currently
connected to, especially if travelling overseas.
Doesn't apply if you didn't get your phone from a telco or installed a
custom version of Android on it.
any carrier you connect to via GSM can send push OTA to your phone/sim
its not an android update but a FTOA update of one of the proprietary
blobs on your handset once they have that level access its game over.
hence the problematic nature of the closed source baseband drivers and
direct memory access given to the modem on most phones.
2:10 p.m.
On 2013-07-29 13:44, nic wrote:
[...]
any carrier you connect to via GSM can send push OTA
to your phone/sim
its not an android update but a FTOA update of one of the proprietary
blobs on your handset once they have that level access its game over.
hence the problematic nature of the closed source baseband drivers and
direct memory access given to the modem on most phones.
Nic,
Could you please make a more concerted effort to use full sentences with
proper grammar and punctuation? Your first sentence above is very
difficult to understand.
I've not investigated this sort of update before, but based on the
little I grasped from your email I'd be interested to learn more about
how, when, and why these updates are deployed.
--
Regards,
Matthew Cengia
3:31 p.m.
On 07/29/2013 02:10 PM, Matthew Cengia wrote:
On 2013-07-29 13:44, nic wrote:
[...]
I shall do my best.
any carrier you connect to via GSM can send push
OTA to your phone/sim
its not an android update but a FTOA update of one of the proprietary
blobs on your handset once they have that level access its game over.
hence the problematic nature of the closed source baseband drivers and
direct memory access given to the modem on most phones.
Nic,
Could you please make a more concerted effort to use full sentences with
proper grammar and punctuation? Your first sentence above is very
difficult to understand. I've not investigated this sort of update before,
but based on the
little I grasped from your email I'd be interested to learn more about
how, when, and why these updates are deployed.
http://en.wikipedia.org/wiki/FOTA_(technology)
http://en.wikipedia.org/wiki/FUMO
http://en.wikipedia.org/wiki/OMA_DM
The above is ok for a very basic overview of the updating process
allowing updating of the baseband via a number of ways.
Below is focussed on exploiting the baseband rather than a malicious
update its interesting given this was a non-nation state attacker, so
they did not have the advantage of a "relationship" with a carrier/operator
https://www.usenix.org/system/files/conference/woot12/woot12-final24.pdf
4:19 p.m.
On 29 July 2013 15:31, nic <nic(a)404ed.org> wrote:
Thanks for the links.
According to http://en.wikipedia.org/wiki/OMA_DM, it only applies to
certain phones. Only one really old Android phone appears in the list. Are
you sure this is an issue?
Yes, more companies are listed under
http://en.wikipedia.org/wiki/FOTA_(technology), however I think this is a
more generic thing, and probably applies to the Android updates.
--
Brian May <brian(a)microcomaustralia.com.au>
I've not
investigated this sort of update before, but based on the
little I grasped from your email I'd be interested to learn more about
how, when, and why these updates are deployed.
http://en.wikipedia.org/wiki/FOTA_(technology)
http://en.wikipedia.org/wiki/FUMO
http://en.wikipedia.org/wiki/OMA_DM
The above is ok for a very basic overview of the updating process
allowing updating of the baseband via a number of ways.
Below is focussed on exploiting the baseband rather than a malicious
update its interesting given this was a non-nation state attacker, so
they did not have the advantage of a "relationship" with a carrier/operator
https://www.usenix.org/system/files/conference/woot12/woot12-final24.pdf
4:29 p.m.
Brian May <brian(a)microcomaustralia.com.au> wrote:
Thanks for the links.
According to http://en.wikipedia.org/wiki/OMA_DM, it only applies to
certain phones. Only one really old Android phone appears in the list.
Note however that the attacks described in the paper cited above don't rely on
the delivery of firmware updates; they exploit security vulnerabilities in the
GSM implementation. Thus there is cause for concern (about the binary-only
drivers and what might be lurking therein) quite aside from the firmware
updating mechanism.
3532
days inactive
3535
days old
22 comments
8 participants
participants (8)
-
Andrew McGlashan -
Brian May -
Jason White -
Matthew Cengia -
nic -
Rick Moen -
Russell Coker -
Trent W. Buck