Date: Fri, 20 Jul 2012 18:11:36 -0700
From: Gage Bystrom <themadichib0d@...il.com>
To: "Everhart, Glenn" <glenn.everhart@...se.com>,
	full-disclosure@...ts.grok.org.uk
Subject: Re: A modest proposal

If you are going to make a reference to something like the infamous A
Modest Proposal, your post should have SOMETHING analogous to it, but
that is besides the point :)

Ok someone should correct me if I make a mistake on my next few
points, because it has been a handful of months since I've mucked
around with some of this stuff and I'm running off the top of my head
here, but anyways:

1.) The ecosystem isn't going to get changed and become scrambled.
That is outright counter-productive. I may have never been on a
software development team, but anyone can look around and tell you
it's hard enough to get a large application working consistently on
even the majority of your target environments. Working with an
environment intentionally scrambled to shore up the weaknesses of an
idea that does not address the problem it's trying to would only make
things infeasible. Security isn't worth it if the machine is a mere
brick after words. Ergo hijacking DLLs will always work unless methods
of stopping dll hijacking crop up(and I believe thats what code
signing is useful for, but my memory is foggy right now).

2.) Yes my point is that blackbox(and grey box but you missed that,
which is ok) tactics will not be bothered by it. Thats an issue
because thats what people are already using anyways. Why implement a
defense for something no one bothers with anyways? It'd be like
safeguarding a room from Van Eck Phreaking when the only thing in the
room is a headless server.

3.) Less callouts the better for the attacker in a way. Means less
functions they need to monitor for, less things that need to be
replaced. Also statically linked does not work well with ASLR, and
supercharging it would only make things worse. ASLR works because code
location cannot be predicted in advance, while almost by definition
statically linked anything means everything HAS to be predictable. In
fact on linux you can't statically link an executable and still make
it a PIE'd executable. For the record PIE is essentially aslr actually
in practice when it comes to the .text portion of the code. In
hindsight it almost sounds like you are trying to argue for PIE but
are going about it backwards.

4.) You don't need to reverse engineer each executable. Like I said,
each program variant still has to have the same inputs and outputs and
thats all a piece of malware needs to look for. The reason why malware
uses these techniques is NOT to make reverse engineering harder or
anything remotely of the nature, it's merely to prevent automated
detection. A piece of malware doesn't necessarily have to have the
same inputs and outputs because it does not exist for the sake of the
end-user. Real applications have to, so they cannot employ those
methods to escape automated detection by malware /because it will be
defeated in ten seconds flat/.

On a unrelated note, what the hell is everyone else talking about? You
never mentioned anything about trying to stop bugs and exploits, only
about preventing malware from interfering with the executable itself
ala ZeuS. I imagine with the idea that doing so would force malware to
use more obtruse  methods that would make them be easier caught by
traditional means. And your reply to me seems to confirm that, so I
know I wasn't the one that misread you, but I'm weirded out that it
seems like nearly everyone else did.

On Fri, Jul 20, 2012 at 6:03 AM, Everhart, Glenn
<glenn.everhart@...se.com> wrote:
> Well, the idea was not only to change instructions but change layout,
> heavily (ASLR on steroids).
>
> Some malware does that. It is of course much harder than just changing
> opcodes.
>
>
>
> (As for waste of a reference, how much do you expect in a quick message? J )
>
>
>
> You are right that inputs and outputs of the program need to be the same. If
> however
>
> the ecosystem changes so that the OS and utilities all get massively
> scrambled, finding ways to
>
> replace those dlls can become harder to do. (Debugging does too, but you’d
> debug unscrambled,
>
> apply automated scrambling, and if that introduced errors you’d need to fix
> the scrambling
>
> process. There are tools I’ve seen references to for doing scrambling.) What
> you are pointing
>
> out is that black box techniques may continue to work. My point was that
> grey box and clear
>
> box techniques can be made hard. If the black box gets big enough (someday)
> the attacking
>
> business can get harder yet. (I was thinking of this in terms of a self
> contained program
>
> used for some fixed functions, and linking the whole mess statically the way
> portable
>
> executables get done, to minimize callouts.)
>
>
>
> Changing opcodes and so on makes it harder to find things though. Consider
> the case where
>
> you want to patch some entry point which is not global, so you haven’t got
> any nice pointer
>
> right into it. You find that normally by looking for code sequences. That’s
> not so easy
>
> when in effect there are no constant code sequences. Finding data is what
> you change layout
>
> for.
>
>
>
> There is no need to prevent reverse engineering. I thought that was clear
> enough: the point
>
> of the variation is that you make the attacker reverse engineer each copy
> separately.
>
> The attacker will get tired.
>
>
>
> It’s good to get responses like yours though; that is what I hoped might
> come out of the post.
>
> Glenn Everhart
>
>
>
>
>
> From: full-disclosure-bounces@...ts.grok.org.uk
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Gage Bystrom
> Sent: Thursday, July 19, 2012 9:44 PM
> To: Glenn and Mary Everhart; full-disclosure@...ts.grok.org.uk
> Subject: Re: [Full-disclosure] A modest proposal
>
>
>
> 1.) waste of a reference by no follow through :( shame shame
> 2.) The only real problem with that idea is that you'd be doing it wrong. As
> in what you are doing does not accomplish what you want it to do. Those
> polymorphic techniques are there to prevent identification, not necessarily
> to prevent hooking, code injection, and reverse engineering. You use
> completely different techniques for those.
> 3.) It wouldn't be hard to get around it. Just replace a dll or two with the
> functions you want to intercept and analyze the output. They couldn't care
> less how polymorphic your code is if it still needs to pass the juicy data
> to a library function. And in a lot of cases they are already doing this, so
> its highly possible that you could suddenly take an application a piece of
> malware was designed to harvest information from, make it all polymorphic,
> and the same old malware version could still mess with it. And yes, it would
> still he able to identify the application cause the end user needs to be
> able to identify it and the malware would just use whatever method the end
> user would to spot it for injection or what not.
> 3.) I will say, at least you're thinking, even if its flawed.
>
> On Jul 19, 2012 6:24 PM, "Glenn and Mary Everhart" <everhart@....com> wrote:
>
> Hello, FD...
> A thought occurred to me:
> Why not use the same kind of polymorphism and software metamorphism that
> is used by malware writers as a protective measure?
>
> If you have a piece of code that you don't want malware to be able to
> inspect, that might perhaps
> have some "secrets" in it or that you want not to be trivial to have
> some other code patch,
> why not arrange for that code to be different in form (but the same in
> function) with every copy?
>
> (For places that insist on code that must be signed, you might need to
> have only perhaps scores or
> hundreds of variants, and then make it clear that the "signed code"
> requirements were making
> the systems that have them LESS secure than those without. <bwahahaha>.
> <grin>.)
>
> There are many ways to achieve this kind of result. Many would result in
> somewhat larger
> executables or the like, or possibly larger data, but some of the
> methods don't even need access
> to source code. (I would suspect many systems like this will be clearest
> to those of us who have
> worked in assembly languages and the like over the years, but that is a
> bit beside the point.)
>
> If every copy of a program is laid out differently, and data gets moved
> around also from copy
> to copy, the job of the attacker would seem to get much harder.
>
> Glenn Everhart
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
> This transmission may contain information that is privileged, confidential,
> legally privileged, and/or exempt from disclosure under applicable law. If
> you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is STRICTLY PROHIBITED. Although
> this transmission and any attachments are believed to be free of any virus
> or other defect that might affect any computer system into which it is
> received and opened, it is the responsibility of the recipient to ensure
> that it is virus free and no responsibility is accepted by JPMorgan Chase &
> Co., its subsidiaries and affiliates, as applicable, for any loss or damage
> arising in any way from its use. If you received this transmission in error,
> please immediately contact the sender and destroy the material in its
> entirety, whether in electronic or hard copy format. Thank you.

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

Powered by blists - more mailing lists