Onderwerp: secure client-side platform

how to have a secure client-side platform for secret communication?
... transferring and storing secret messages, online banking, etc

i got some fresh ideas in mind, and would like to share it here:
0. watch network with sniffer, so be sure no byte is sent to weird destinations
1. read-only operating system(knoppix, etc), so every boot is a fresh start
2. get every secret processed in memory and stored as encrypted in remote server

any suggesion or fresh idea on this topic is welcome

this document for ordinary people on the street:
http://umbrella.name/upid/trooseid

bugtraq guys can directly go to the conclusion part:
http://umbrella.name/computer/troose...ne/#conclusion

have a nice day,

Liu Die Yu

#1, we are talking about how to do critical secret communication in a secure
way, right? so forget about those putting win9x 24/7 on DSL ... let them
continue contributing to the spam and zombie business ;-)

imagine i'm going to access an e-gold acocunt of $1M ...
first i unplug the network cable and remove harddrive;
then boot with a clean livecd;
later start firewall and then plug the network cable;
run "mozilla-firefox about:blank";
directly go to HTTPS-secured website;
once done, reboot.
i cannot figure out what could go wrong in the above process ...

clean read-only OS is a solution against "once owned, stay owned" (trojan
stays in system until next format)

it does not solve the problem of the vulnerabilities in client software like
mozilla (as joxean and keith suggested)

if we only have encryption-secured connection to trusted server,
assuming enemy do not have control over the trusted server itself,
our computer can only be compromised if:
* enemy have total control over the communication channel
between us and the trusted server
* AND
- there is a vulnerability in the certificate/publickey
verification process of client software like mozilla
- OR the mathematic foundation of publickey-privatekey
sign/encrypt trick got a problem.
- OR we clicked YES in the
certificate-is-invalid-continue-or-not dialog
* AND
enemy got vulnerability to exploit after going thru the
certificate verification process taken in our side.

chances are rare, hum? the very last sentence of my trooseid article is:
Never touch any not-encryption-secured connection during a
secret-communication op.
you read it, right?

Q: can you really trust Google?
A: it's really up to you which server you choose to store and transfer
encrypted secrets. in my view, the Gmail service of google is just a good
example here ... you got service better than google's gmail, of course go
ahead ... )

honestly, i have not used the tools mentioned in the "why not ... " part
below. it gonna take some time to evaluate those solutions by myself.

####################

"you got a problem"
*** 1 ***
Joxean Koret <joxeankoret@yahoo.es>
[+] I think this is a bad idea. What about client software vulnerabilities?
You can have a system that were secure but

currently it's not.
[+] Various applications, such as web browsers, mail clients, etc... needs to
be constantly updated to fix the newest

vulnerabilities.
*** 2 ***
"Keith Oxenrider" <web10198@sol-biotech.com>
[+] I am sure you will be hearing this from many others, but basically it is
impossible to secure client side computing if

the client every goes outside of your control (one presumes that if it remains
inside your control you have effective

controls). Clearly, server side computing is entirely within the control of
whomsoever owns (or 0wns) the server, so there

is implicit trust when you connect (can you really trust Google to protect
your content?).
[+] While your recommendations, if used, will obviously increase the baseline
security of the average person, you can't

guarentee anything. Smart card developers run into many of these issues and
they don't have to deal with buggy commodity OSs

and browsers. Since the vast majority of users don't even bother to keep
their machines patched (people STILL use Win9x

connected 24/7 to DSL, btw), offering suggestions on how to make their
computer even more difficult to use is unlikely to win

any converts.
[+] Those of us who are already paranoid and have done their homework know
there is no way to ensure on-line security

besides never doing anything on-line.
[+] Something to keep in mind, a read-only OS is only as good as its patch
level when it was written and will decay with

time eventually (soon) reaching an insecure state that can easily be penatrated.


"why not ..."
*** 1 ***
Joxean Koret <joxeankoret@yahoo.es>
Why not use a system like LTSP (Linux Terminal Server Project) or any other
"Think Client" based system?
*** 2 ***
"Beauford, Jason" <jbeauford@EightInOnePet.com>
Tinfoil Hat linux ..silly. http://tinfoilhat.shmoo.com/
*** 3 ***
"Gustavo Paredes" <gustavo.paredes@internet-solutions.com.co>
Do you know secuware? www.secuware.com

####################

how to have a secure client-side platform for secret communication?
... transferring and storing secret messages, online banking, etc

i got some fresh ideas in mind, and would like to share it here:
0. watch network with sniffer, so be sure no byte is sent to weird destinations
1. read-only operating system(knoppix, etc), so every boot is a fresh start
2. get every secret processed in memory and stored as encrypted in remote server

any suggesion or fresh idea on this topic is welcome

this document for ordinary people on the street:
http://umbrella.name/upid/trooseid

bugtraq guys can directly go to the conclusion part:
http://umbrella.name/computer/troose...ne/#conclusion

[As usual, the From: is a black hole, as a broken-autoresponder
defense. Use the address in the signature if you want to reach me.]

> imagine i'm going to access an e-gold acocunt of $1M ...
> first [...]; then [...]; [...]
> i cannot figure out what could go wrong in the above process ...

How about a "reflash your BIOS" infection? I've heard of malware loose
in the wild that trashes flashable BIOSes; it would take only a little
more care to build one that flashes a carefully infected image instead.

I've never liked the flashable BIOS idea, though I'm OK with it if
there's a way to disable reflashing that can't be changed by software
(eg, a jumper must be on a certain pair of pins). I've seen boards
which "defend" against malware reflashing them by having two copies,
both flashable, which may help against getting randomly trashed but is
of no value against careful malicious reflashing; whatever the vendor
reflashing software can do, malware can do too.

> Q: can you really trust Google?

Trust Google with what? Trust Google to do, or not do, what?

No, I don't actually myself care about the answers to those. I'm just
trying to point out that trust is not a simple yes-or-no thing. For
example, I trust my upstream to deliver (almost) all of the data I send
through them unchanged, but I don't trust them with my passwords on
other than their machines.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Something I have discussed with a friend but not explored wrt technical
feasiblity is a micro kernel residing in the system bios that emulates the
hardware it is residing on. I believe under those circumstances it would
be impossible to prove you had a secure system without having an external
way of verifying the bios instructions. This idea came to me when I read
about some bios chip that had 8 MB of memory; plenty to fit a micro Linux
kernel with room to spare.

Keith Oxenrider, CISSP

At 03:24 AM 9/1/2005 +0000, liudieyu@umbrella.name wrote:


>#1, we are talking about how to do critical secret communication in a secure
>way, right? so forget about those putting win9x 24/7 on DSL ... let them
>continue contributing to the spam and zombie business ;-)
>
>imagine i'm going to access an e-gold acocunt of $1M ...
> first i unplug the network cable and remove harddrive;
> then boot with a clean livecd;
> later start firewall and then plug the network cable;
> run "mozilla-firefox about:blank";
> directly go to HTTPS-secured website;
> once done, reboot.
>i cannot figure out what could go wrong in the above process ...
>
>clean read-only OS is a solution against "once owned, stay owned" (trojan
>stays in system until next format)
>
>it does not solve the problem of the vulnerabilities in client software like
>mozilla (as joxean and keith suggested)
>
>if we only have encryption-secured connection to trusted server,
>assuming enemy do not have control over the trusted server itself,
>our computer can only be compromised if:
> * enemy have total control over the communication channel
> between us and the trusted server
> * AND
> - there is a vulnerability in the certificate/publickey
> verification process of client software like mozilla
> - OR the mathematic foundation of publickey-privatekey
> sign/encrypt trick got a problem.
> - OR we clicked YES in the
> certificate-is-invalid-continue-or-not dialog
> * AND
> enemy got vulnerability to exploit after going thru the
> certificate verification process taken in our side.
>
>chances are rare, hum? the very last sentence of my trooseid article is:
>Never touch any not-encryption-secured connection during a
>secret-communication op.
>you read it, right?
>
>Q: can you really trust Google?
>A: it's really up to you which server you choose to store and transfer
>encrypted secrets. in my view, the Gmail service of google is just a good
>example here ... you got service better than google's gmail, of course go
>ahead ... )
>
>honestly, i have not used the tools mentioned in the "why not ... " part
>below. it gonna take some time to evaluate those solutions by myself.
>
>####################
>
>"you got a problem"
>*** 1 ***
> Joxean Koret <joxeankoret@yahoo.es>
> [+] I think this is a bad idea. What about client software vulnerabilities?
>You can have a system that were secure but
>
>currently it's not.
> [+] Various applications, such as web browsers, mail clients, etc...
> needs to
>be constantly updated to fix the newest
>
>vulnerabilities.
>*** 2 ***
> "Keith Oxenrider" <web10198@sol-biotech.com>
> [+] I am sure you will be hearing this from many others, but basically it is
>impossible to secure client side computing if
>
>the client every goes outside of your control (one presumes that if it remains
>inside your control you have effective
>
>controls). Clearly, server side computing is entirely within the control of
>whomsoever owns (or 0wns) the server, so there
>
>is implicit trust when you connect (can you really trust Google to protect
>your content?).
> [+] While your recommendations, if used, will obviously increase the
> baseline
>security of the average person, you can't
>
>guarentee anything. Smart card developers run into many of these issues and
>they don't have to deal with buggy commodity OSs
>
>and browsers. Since the vast majority of users don't even bother to keep
>their machines patched (people STILL use Win9x
>
>connected 24/7 to DSL, btw), offering suggestions on how to make their
>computer even more difficult to use is unlikely to win
>
>any converts.
> [+] Those of us who are already paranoid and have done their homework know
>there is no way to ensure on-line security
>
>besides never doing anything on-line.
> [+] Something to keep in mind, a read-only OS is only as good as its patch
>level when it was written and will decay with
>
>time eventually (soon) reaching an insecure state that can easily be
>penatrated.
>
>
>"why not ..."
>*** 1 ***
> Joxean Koret <joxeankoret@yahoo.es>
>Why not use a system like LTSP (Linux Terminal Server Project) or any other
>"Think Client" based system?
>*** 2 ***
> "Beauford, Jason" <jbeauford@EightInOnePet.com>
>Tinfoil Hat linux ..silly. http://tinfoilhat.shmoo.com/
>*** 3 ***
> "Gustavo Paredes" <gustavo.paredes@internet-solutions.com.co>
>Do you know secuware? www.secuware.com
>
>####################
>
>how to have a secure client-side platform for secret communication?
> ... transferring and storing secret messages, online banking, etc
>
>i got some fresh ideas in mind, and would like to share it here:
>0. watch network with sniffer, so be sure no byte is sent to weird
>destinations
>1. read-only operating system(knoppix, etc), so every boot is a fresh start
>2. get every secret processed in memory and stored as encrypted in remote
>server
>
>any suggesion or fresh idea on this topic is welcome
>
>this document for ordinary people on the street:
>http://umbrella.name/upid/trooseid
>
>bugtraq guys can directly go to the conclusion part:
>http://umbrella.name/computer/troose...ne/#conclusion

Your attack tree below is of the form:
A and ( B or C or D) and E

I submit a simpler one of the form:
A or (B and C)

A - there is an exploitable vulnerability (in the remote-code-execution
sense) in the DNS response handling code on your livecd. You send out a
query, a malicious response reaches you before the real one & gets
through the firewall, and you're done.

OR
B - There is an exploitable vulnerability in the public key
verification process in the browser on your livecd. This vulnerability
could be a remote-code-execution vulnerability, or it could be limited
to causing the browser to present a certificate as legitimate when it
isn't. AND

C - The attacker is able to redirect you to a malicous https
server by e.g. DNS, ARP, or routing protocol attacks somewhere upstream.

C should be pretty much taken as a given, otherwise why bother with SSL
at all?

Regards
Mark


> -----Original Message-----
> From: liudieyu umbrella.name [mailto:liudieyu umbrella.name]=20
> Sent: August 31, 2005 21:25
> To: bugtraq@securityfocus.com
> Subject: Re: secure client-side platform
>=20
>=20
>=20
> #1, we are talking about how to do critical secret=20
> communication in a secure way, right? so forget about those=20
> putting win9x 24/7 on DSL ... let them continue contributing=20
> to the spam and zombie business ;-)
>=20
> imagine i'm going to access an e-gold acocunt of $1M ...=20
> first i unplug the network cable and remove harddrive;
> then boot with a clean livecd;
> later start firewall and then plug the network cable;
> run "mozilla-firefox about:blank";
> directly go to HTTPS-secured website;
> once done, reboot.
> i cannot figure out what could go wrong in the above process ...
>=20
> clean read-only OS is a solution against "once owned, stay=20
> owned" (trojan stays in system until next format)
>=20
> it does not solve the problem of the vulnerabilities in=20
> client software like mozilla (as joxean and keith suggested)
>=20
> if we only have encryption-secured connection to trusted=20
> server, assuming enemy do not have control over the trusted=20
> server itself, our computer can only be compromised if:
> * enemy have total control over the communication channel
> between us and the trusted server
> * AND=20
> - there is a vulnerability in the certificate/publickey=20
> verification process of client software like mozilla
> - OR the mathematic foundation of publickey-privatekey=20
> sign/encrypt trick got a problem.
> - OR we clicked YES in the=20
> certificate-is-invalid-continue-or-not dialog
> * AND=20
> enemy got vulnerability to exploit after going thru the=20
> certificate verification process taken in our side.
>=20
> chances are rare, hum? the very last sentence of my trooseid=20
> article is:
> Never touch any not-encryption-secured connection during a=20
> secret-communication op.
> you read it, right?
>=20
> Q: can you really trust Google?
> A: it's really up to you which server you choose to store and=20
> transfer encrypted secrets. in my view, the Gmail service of=20
> google is just a good example here ... you got service better=20
> than google's gmail, of course go ahead ... )
>=20
> honestly, i have not used the tools mentioned in the "why not=20
> ... " part below. it gonna take some time to evaluate those=20
> solutions by myself.
>=20
> ####################
>=20
> "you got a problem"
> *** 1 ***
> Joxean Koret <joxeankoret@yahoo.es> [+] I think=20
> this is a bad idea. What about client software vulnerabilities?
> You can have a system that were secure but=20
>=20
> currently it's not.=20
> [+] Various applications, such as web browsers, mail=20
> clients, etc... needs to be constantly updated to fix the newest=20
>=20
> vulnerabilities.
> *** 2 ***
> "Keith Oxenrider" <web10198@sol-biotech.com> [+] I=20
> am sure you will be hearing this from many others, but=20
> basically it is impossible to secure client side computing if=20
>=20
> the client every goes outside of your control (one presumes=20
> that if it remains inside your control you have effective=20
>=20
> controls). Clearly, server side computing is entirely within=20
> the control of whomsoever owns (or 0wns) the server, so there=20
>=20
> is implicit trust when you connect (can you really trust=20
> Google to protect your content?).
> [+] While your recommendations, if used, will obviously=20
> increase the baseline security of the average person, you can't=20
>=20
> guarentee anything. Smart card developers run into many of=20
> these issues and they don't have to deal with buggy commodity OSs=20
>=20
> and browsers. Since the vast majority of users don't even=20
> bother to keep their machines patched (people STILL use Win9x=20
>=20
> connected 24/7 to DSL, btw), offering suggestions on how to=20
> make their computer even more difficult to use is unlikely to win=20
>=20
> any converts.
> [+] Those of us who are already paranoid and have done their=20
> homework know there is no way to ensure on-line security=20
>=20
> besides never doing anything on-line.
> [+] Something to keep in mind, a read-only OS is only as=20
> good as its patch level when it was written and will decay with=20
>=20
> time eventually (soon) reaching an insecure state that can=20
> easily be penatrated.
>=20
>=20
> "why not ..."
> *** 1 ***
> Joxean Koret <joxeankoret yahoo.es> Why not use a=20
> system like LTSP (Linux Terminal Server Project) or any other=20
> "Think Client" based system?
> *** 2 ***
> "Beauford, Jason" <jbeauford EightInOnePet.com>=20
> Tinfoil Hat linux ..silly. http://tinfoilhat.shmoo.com/
> *** 3 ***
> "Gustavo Paredes" <gustavo.paredes internet-solutions.com.co>
> Do you know secuware? www.secuware.com
>=20
> ####################
>=20
> how to have a secure client-side platform for secret communication?
> ... transferring and storing secret messages, online banking, etc
>=20
> i got some fresh ideas in mind, and would like to share it here:
> 0. watch network with sniffer, so be sure no byte is sent to=20
> weird destinations 1. read-only operating system(knoppix,=20
> etc), so every boot is a fresh start 2. get every secret=20
> processed in memory and stored as encrypted in remote server
>=20
> any suggesion or fresh idea on this topic is welcome
>=20
> this document for ordinary people on the street:
> http://umbrella.name/upid/trooseid
>=20
> bugtraq guys can directly go to the conclusion part:
> http://umbrella.name/computer/troose...ne/#conclusion
>=20
>=20

This email and any files transmitted with it are confidential and intende=
d solely for the use of the individual or entity to whom they are address=
ed. If you have received this email in error please notify the system man=
ager. This message contains confidential information and is intended only=
for the individual named. If you are not the named addressee you should =
not disseminate, distribute or copy this e-mail.


This email and any files transmitted with it are confidential and intende=
d solely for the use of the individual or entity to whom they are address=
ed. If you have received this email in error please notify the system man=
ager. This message contains confidential information and is intended only=
for the individual named. If you are not the named addressee you should =
not disseminate, distribute or copy this e-mail.