Tanks and Foster's Lager.

[Dave Aitel <dave () immunitysec com>]

A number of people seem offended at the previous email, so I'll try to
clarify my comments. Obviously I don't think all outsourcing to foreign
nationals is bad. Immunity does a fair bit of that, since we have 4
people and we cover three continents (four, if you count California as
its own continent, which I'm pretty sure they do). 

But if the reason you're are running a penetration test is that you
believe there is a national intelligence threat against an information
system, then the tools you are using to assess that threat need to be
carefully analyzed. The trivial solution from a security perspective is
to use only in-house tools, which is fine if you are a massive
organization with colossal resources.

However, if you are (and you probably are) going to be using external
tools to perform an assessment, then the risk of getting owned by those
very tools does need to be taken into account. For what it's worth,
normal businesses usually do consider this, which is why they will buy
CANVAS instead of using Metasploit - because they have someone to sue.
In a sense, we provide a specialized insurance policy.

But for a more sensitive customer base, that's not enough. As they say,
people are in harm's way. These extra considerations extend not just to
the US military, of course, but to every government's sensitive
information systems. A lot of our customers in the EU and around the
globe are purchasing CANVAS from what is basically a potential foreign
intelligence service, as far as they are concerned.

It was therefor important to our business to look at this risk and find
a way to ameliorate it. As an exercise, Immunity spent time thinking
about ways to trojan our customers and we've come up with some
considerations. This is one of the reasons why CANVAS is the way it is,
as an all-source distribution, despite the huge pain this causes us in
every other area (piracy, licensing validation, etc).

Assume I can modify CANVAS. Even if I'm not working at Immunity, assume
I can walk down to the Immunity co-location where we host our servers,
and pay the nice Russian man there who manages the network for a few
hours of console time. It's likely this is a couple grand at most, less
if you communicate in Russian or play false-flag games, perhaps. It
would probably cost you more to hack someone at Immunity, but it's no
doubt possible.

I can then trojan CANVAS in several places:

1. The encoders or shellcode

This is the most obvious place. Most of CANVAS uses MOSDEF (and by 5.0,
all of it will), so all of the shellcode is in source form. This makes
it harder to trojan specifically in the shellcode (and it's not like it
changes every day either). One promising place to look would be the
MOSDEF assembler and compiler. For example, you could have a bogus
instruction that "assembled" into a mini-shellcode trojan.
Unfortunately, the compiler, while a pain to debug, is pretty hard to
trojan, since it just generates intermediate language, and you can print
that out to look for anomalies (which is easier than it sounds). So the
assembler is your best bet. The assembler is basically a table,
something easily verified with the Intel manuals. Also, a secondary
shellcode, even a small one, would look really out of place in the code.
(MOSDEF is available as public LGPL code, so not easy to trojan
un-noticeably).

And again, shellcode is small. It's not hard to disassemble it and
reverse it manually, even the massively overweight CANVAS shellcode.

Targeting would become a problem with shellcode as well. Although
machines that the shellcode runs on are unlikely to be watched closely
in some cases, in other cases they're likely to be very carefully
analyzed, as many people do a lot of CANVAS testing in the lab before
doing it in the wild. So you'd want to rate-limit your trojan to do a
1/10 chance of triggering. And because you're in shellcode, exfiltration
of data is a problem. You'd want to write a HTTP-proxy friendly trojan
in shellcode.

Writing compilers is a pain in the ass. Trojaning compilers is even more
so, since the compiler doesn't see a stream of data and search and
replace. It's a tree structured algorithm. The binary data is shooting
out very far away, and until then, each step is fairly structured. If
somewhere in the code was a "push blob, push blob, push blob, retesp",
it would be pretty easy to spot out.

Trojaning something is a delicate balance. I want to trojan something in
particular, but I don't want to trojan everything because I'll get
caught.

2. A misplaced .pyc

This is probably one of my favorites. We don't distribute .pyc files,
but if we slipped one in, it could be completely different from the
source, could manage its date (touch -r /tmp/ self.pyc), and is a
generally good way. It's a reasonably covert way to trojan a Python
program, but if it's found out, it's easy to decompile and analyze, and
an obfuscated de-compilation is pretty obviously hostile.

3. Python trickery

Some of Sinan Eren's code is trickery to me, since he uses map() and
other functional derivatives. This is still rare in the CANVAS codebase,
and use of exec is extremely rare. Someone could easily audit the
codebase itself, and then use that as a baseline and watch for malicious
patches with "diff". With a binary, it's a lot harder to do that. Binary
analysis tools are a lot harder to use than "diff" and there's valid
reasons for that. Also, reading 100K lines of Python is a lot easier on
the eyes than reading 100K lines of assembly (or 20Meg of assembly,
which is more likely).

4. Ogg files

We use OGG files as our sound delivery system. We play them with ogg123,
if you have it installed. Theoretically we could hunt down a bug in
ogg123 that we could exploit with a malicious .ogg file. This is my
second favorite next to the .pyc. Pretty unlikely though.

5. Callbacks from the Python code itself

CANVAS doesn't track use in any sense. It has no reason to be calling
back to a central server. It doesn't check for updates. It doesn't ask
if your license is valid. It doesn't grab OSVDB entries on the fly. This
is, in large part, a design decision to enable our customers to trust
us.


So to sum up, trojaning CANVAS is difficult, even for us, and
intentionally so. This is the consideration I was talking about in the
previous email. Even without the considerations we put into the design
of CANVAS, binaries are a lot easier (several orders of magnitude) to
trojan than source trees. 

For most businesses, this is a non-issue. They've purchased the
insurance. For people who have to normally consider an
intelligence-level threat, I believe this is an issue they should be
considering. CANVAS's very design (as full source, no callbacks, etc)
takes this into consideration. That's what I meant. 

-- 
Thanks,
Dave Aitel
Senior Security Architect 
Immunity, Inc.

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave