4Q wrote:

Wouldn't booting from a bart disk accomplish this as well? WHat rootkit
can hide itself from that?

--
Regards,
Dustin Cook
http://bughunter.atspace.org

4Q wrote:

So basically, hiding and marking sectors as bad? And this will
defeat a low level disk analsys tool how exactly?

Which is all old school, old as fuck. This shit was tried with one
particular video game on my coco3. It had a bad spot marked on the disc
where the games real data lied. Normally, you couldn't copy that
section.

So this hidden filesystem is feasable, but.. it's not exactly.. ground
breaking new technology doing it. It's simply taking a section of the
hard disk, marking it as unused whatever, and stashing your data
there... I wonder tho, how well this would get along with programs like
diskkeeper and various hd cloning applications and standalone hd
cloning units. Would they (a) copy the hidden data as well, or (b) wind
up not copying this hidden data resulting in either a dead rootkit, or
dead os .... hmm...

Dustin Cook wrote:

Well I didn't mention marking the sectors as bad, however
this technique could be used if the coder desired.

As per the simple description I gave I only had in mind
using sectors that were not currently used... (like the
old bootdisk virus that could hide the MBR at the end of the
disk or some other unused space). Okay above is very very old
school method, but new school would be to analyse the disk
and look for appropriate repository places. One very
effective system is to use stegonographic methods and hide the
alien entity body within other data files/objects/structures.

Re: the low level disk analysis.

How is any analysis going to be done if
* The state of files/slacks/structures isn't known before hand.
(i.e. entire disk sector by sector snapshot)

* The entity is encrypted and the analyser doesn't know
what he's looking at... Is that sector they are analysing
left over data detritus from previous disk writes or is it a
part of a hidden encrypted file without headers or obvious
links.

After all the whole philosophy behind serious rootkit development
is to leave no evidence for this kind of forensics. And this subject
is covered in the Hoglund & Butler ROOTKITS book and in the
http://rootkits.com forums.

* Harddisk are only one form of storage system. RAM and other memory
storage can be used... after all some systems never get switched off,
and the evidence (zero forensics) would evaporate when they reboot with
a Bart or Knoppix CD.

And before you mention low level memory analysis, we are back to the
previous problem of knowing how to analyse unknown encrypted/stego
data.

Yes this is old school but just like 'round hoops' are still in use
as wheels today. These old systems still work. If the target system
doesn't have any R&D low level analysis tools or a 0-day scanner
installed then this method will hide the data in plain sight right
under the nose of the victim, without requiring any stego or any form
of encryption.

Anyhow I'd love to expand on this subject some more with you Raidy
(as I know you get a buzz from this kind of hax0ring) but I am quite
busy on other matters atm. I'll keep you in mind for any draft copies
of future VX articles of iWORM-NET (2). Expect to see Sploit-Worm
engine,
Hijacker vector modules, r00tkit/stealthkit, Metamorphics and good
shit like that. ;]]

4Q

p.s. I think I already wrote about 'spores' and hiding in slackspace
in iWORM-NET (1). Lookup VDAT 2.002 or Metaphase 2 zine on
http://vx.netlux.org

p.p.s. Error in article about using slackspace sectors, when I meant
to say clusters.

On 31 May 2006 17:59:16 -0700, "4Q" <paul_zest@hushmail.com> wrote:

If it's in free space though, the analyser doesn't have to worry about
that. He can simply overwrite the whole of freespace with a standard
erase program just in case.


Jim.

Jimbo wrote:
And if he/they(analyser) overwrite freespace and slacks then this
would suit the r00tkit developers cause (they don't want anyone
to analyse the trojan entity). The hacker would prefer a computer
Luser PC as a target, instead of a security firm R&D guy PC or a
even a tech savy enduser that practices safehex.

Here is a guestimate:

99% of users are r00tkit illiterate
1% of users tech savy or higher

The hacker targets the 99% and tries to avoid honeypots.
A professional hacker would make bespoke tools and limit
their exposure to any form of analysis (by doing a reckie
on host system i.e. operate in paranoid mode) carry out
the mission objective then remove all traces of r00tkit
and activity.

You can bet that some trojans and r00tkits exist and have
existed without discovery for many years... We're not
talking about 101 level Trojan/VX developers, mass infection
spyware merchants, script kiddies, book selling malware writers
(Hoglund & Butler - ROOTKITS) or attention grabbing media-whores
like Gigabyte here ;]]


4Q

On 31 May 2006 19:58:33 -0700, "4Q" <paul_zest@hushmail.com> wrote:

Okay, I used the term analyser loosely following on from your post. I
was referring to the (probably above) average user who is smart enough
to make a bartpe cd and who suspects there might be a some hidden
malware on his machine. He can erase the freespace and cluster tips
without having to scan for anything. If the hacker wants to avoid that
he must put his kit in files in used space where it's open to
detection like all other malware.

The security R&D guy is a different issue which I don't know the first
thing about and so can't comment on.


Jim.

"Dustin Cook" <bughunter.dustin@gmail.com> wrote in
news:1149036160.292286.234150@c74g2000cwc.googlegr oups.com:

I'm very interested in others opinions... Especially yours 4Q

Jimbo wrote:
No way. R00tkit technology from many years gone bye maybe analysable.
Nowadays pro hackers with the coding and technical skills comparable
to 29A VXers like Z0mbie, Vecna, Benny, MDriller and the criminal
motivation are going to be wise to amateur sleuths with liveCD's
(Bart/Knoppix etc).

Firstly the hidden data (on the disk) will be in a form that average
amateur sleuth will not be able to tackle unless prehaps he's an MIT
crypto science major or budding code breaker... i.e. AES256 level of
ciphers will stop them dead in their tracks even if they can see the
bytes with a hex tool.

Secondly the new breed of wannabe r00tkitist hacker is thinking
outside the box (literally). The files / structures can be distributed
over networks, paged out RAM, graphics card memory, EEPROMs.

Thirdly the r00tkit can be held in a state of encrypted suspended
animation. e.g. 95% of r00tkit trojan resides on hardisk and the
remaining 5% is inserted via an exploit breakin, the same remote
access that was probably gained initial entry from a 0-day sploit.
The 5% system is a bootstrap to reactive the 95% encrypted body.
Once the alien system is up and running (active), the usual kernel
subversion modules take hold of the OS, place the on-demand parts
into a propriety RAMDISK and only unencrypt HARDDISK units
on-the-fly...

So reboot and you are left with hardisk of un-analysable junk.
Until the missing 5% is bootstraped in from the remote hacker
again.

Don't forget Jimbo these aren't flag waving web defacing fame
hackers ;]]


4Q

4Q wrote:
of course there still needs to be regular code that will locate and
reconstruct/reassemble/de-obfuscate the main malware body... and that
will give it away... passive obfuscation techniques (which is not
comparable to stealth, it's camouflage/disguise) always require a
'loader' in some sense of the word... if you put the main malware body
outside the scope of the normal filesystem you'll need something
*inside* the filesystem to load it...

look for the loader...

again, look for the loader... the key has to be available to the loader
in order to decrypt the malware so it will be available to the analyzer
too...

you can't compromise a system without changing it (which actually sounds
a bit like the uncertainty principle) and changes are always
detectable... the best you can hope for is to disguise those changes,
but no disguise is perfect...

[snip]
tracking down stealth malware in memory is a fools errand... if it
changes something on the disk, that change will be detectable after
clean-booting... if it sends out it's own network traffic that will be
detectable by devices on the network but outside the scope of the
affected machine... if it changes the way the compromised machine
interacts with the outside world those changes are theoretically
detectable...

if it does none of those things then it's a tree falling in a forest
with no one around to hear it...

btw, nice to see more reasonable descriptions... i wonder what dustin's
secret is for teasing them out of you...

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

4Q wrote:
i guess i shouldn't mention the fact that *keys* stick out like sore
thumbs... no need to break the cipher when you can just locate the key...

but in order to run on machine X something on machine X would have to
reassemble all those parts at some point...

essentially a volatile network-borne loader... interesting idea... so
you can't find it on the local disk - so how does one find exploits on
the network? honeypots, among other techniques... still, a worthy
complication...

on second thought, the presence of the unknown encrypted data (encrypted
data, remember, is indistinguishable from random noise but looks very
different from normal code or data which typically has discernible
structure) could be enough on it's own to trigger suspicion... one
needn't simply delete/overwrite it but rather save it for later use *in*
a honeypot meant for trapping the loader/exploit...

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

4Q wrote:
You know Q, me ol' 4, your's is the kind of scenario I was implying for
years people should assume is the case. That the best hackers are the one's
who no-one knows about, the best malware is the stuff that evades all
current known detection and we should assume that it exists, assume that,
where some of us may be academically advanced, the 'enemy' is genius.

I think someone actually agreed with me once! :-)

But no, like everywhere else in this world this (usenet AV) field is largely
populated by those whose real (unconscious) purpose is to propagate the myth
of their own infallibility, for their own consumption, and like all such
insecure persons what they want are certainties.

When failing to convince someone of our mutual acquaintance that there is no
point actually targetting System Restore, I did think there *hypothetically*
might be simply because nobody would look there for malware that hadn't
already been detected and removed elsewhere. Although it's still the case
afaik by the time you can do that you already control the machine anyway, so
why bother?

But I did wonder about the possibility of storing part of a trojan in SR,
that won't be detected, for later extraction as in the 5% - 95% scenario
above. Although I *still* say the only point is that doing so has been ruled
out as point-less! So you're only really preparing yourself for doing battle
with a madman...but it'd be an interesting challenge...

What, I feel, one needs to envisage is the chemist in The French Connection,
except now he's a coder. And possibly a she. Or to judge by what I kept
seeing in London the other day, both.

But me, on a day like this is shaping up to be, I want a real tan!

Shane

kunt wismer wrote:

Asshole, no one is falling for your pseudo expertise. Rootkit
technology and the philosophy that drives it means hackers will
always be finding ingenious ways to stay hidden inside your
system. And laughing at you trying to convince everyone you can
stop them with your silver bullets act. *snigger*



Erm, maybe the nib on his censor pen isn't as wide as yours
http://rootkit.com <-- get a clue about rootkits, before some
fucker plants a botfarm on your PC just for fun. ;]]


4Q

Shane wrote:

It maybe point-less but who knows what drives the curious minded
hacker to want to try it anyway. Btw I wrote a little encryption
splitter system many years ago that uses a OTP, leaving part of
the files on the target machine and the remainder part offline...
Kinda fucks Wisearse's key detection theory to pieces... But hey
he probably expects hackers to play by "his rules". There are a
zillion hacker ways to skin the target cat, even if this particular
one is a bit naff.

paraphrasing "necessity is the mother of all invention"


4Q (hackers eat free! ;]] )

4Q wrote:
[snip]
you aren't seriously waving around an OTP implementation like it's
something to be proud of, are you?

not really *my* theory, it's something i saw in a presentation by paul
kocher (i believe) at rsa2002... i can see how it might not apply to an
OTP but there are so many *other* reasons not to use an OTP that that
doesn't really matter...

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

4Q wrote:
[snip]
well, considering i keep telling people i'm not an expert... i'm not the
one bringing up the expert bullshit either, that appears to be you...

actually, i think that has more to do with the ability to support
stealth being inherent to the platform...

active stealth does not and can not work when the code isn't running...
i see no reason why this should be such a controversial statement...
even your hero greg hoglund understands this (in his words "Rootkits
require subversive code to execute.")...

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

kunt wismer wrote:
Re-read what I wrote shithead. I said it was "naff"
However the OTP fucked your little key analysis theory up ;]]

*NOTE*
for anyone that doesn't know what a OTP is (One Time Pad),
just think of it as a way to stop any security agency (NSA/FBI)
doing some key analysis and cracking into your encrypted information.
*DOUBLE NOTE WARNING* This system has some severe operating
limitations (that a well known issues in the crypto crowd).

*BUT* Still works under the right conditions.


OTP threw a spanner in your works, aye. *noted* ;]]


4Q

kurt wismer wrote:
You're the Kunt that seems to be giving people the idea
r00tkits are obsolete under your expert analysis. I say
people should read the Hoglund & Bulter book and visit the
website http://rootkit.com to get some perspective on how
these systems can slip under the radar and remain hidden
despite the false impression you are giving that they would
never get passed a Kunt Wismer anti-rootkit.

Asshole, "a spore" is inactive... i.e. not running. Once the entity is
in it's dormant state it's there and it's still hidden.


You just can't accept that the alien system can exist on the
target system 'dormant' after the initial invasion.

stages
*Initial invasion of host
*It's been active
*It's done some kind of hacker mission
*It's buried itself
*It's hidden
*It survives a reboot as a spore
*It waits for re-activation

Stop trying to pretend this isn't possible.


4Q

4Q wrote:
you might as well have said it was goobledezork for all either word
means to me... further, your statement was ambiguous in it's reference...

no, it just changed a few things... an OTP key might not stick out like
a sore thumb, but only by random chance, and the larger the key the less
the chance of that happening, and since the key has to be as big as that
which is being encrypted they key is going to be pretty big - a couple
of kilobytes at least... of course you could 'select' a key that had
better properties, but then you'd no longer have an OTP and the security
proofs for it would no longer apply (specifically it would become easier
to guess what the key was if it had such constraints placed on it)...

of course, that's just about finding the key *fast*... if necessary an
exhaustive search of the disk will turn it up regardless, and an OTP
would rule out including it in your exploit-borne loader (in order to
get it off the disk) as the key + loader combined would be larger than
the malware itself...

conditions that are exceptionally difficult to meet in the real world...
like getting enough entropy to use for keying material and never reusing
it....

only rarely, and only by chance (assuming it really is an OTP)...

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

4Q wrote:
find me a message where i said they were obsolete...

[snip]
if i can *see* it then it's not hidden, and if it's not running it can't
prevent me from seeing it... it may prevent me from recognizing it, but
that's a matter of being disguised, not being hidden...

stop trying to pretend it's really hidden...

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

kunt wismer wrote:

scrutiny! I started to think maybe YOU alone had thwarted
all the ITW kits, then I started to look through the
bugtraq archives for your name -- shit, it came up zero, just
like your peer reviewed work in the comp sci journals!!!

*shrug* I'm starting to think you haven't got anything remotely
resembling credentials in the security/crypto field. At least
Hoglund & Butler are recognised in the security field and have
authored material... that's probably why I would always offer
a link the their site http://rootkit.com so that people could
learn more about security, hackers and r00tkits over some
Canadian runt with a webblog glossary. Pages like
"what is a virus", "what is a worm", "what is a rootkit"
Was this your school homework project or something? *grin*


Stop hiding the URL to http://rootkit.com when you
quote me... then maybe people can checkout a proper
source of information on the in and outs of r00tkits ;]]


4Q