Mailing List Archive

Brian Micek wrote:
> I don't mean to re-start an old topic, but would anyone happen to have
> access to the source code for the second phase of the popular SSH
> probes? The reason I'm interested in it is because I'd like to exploit
> some weaknesses in the code and at least cause it to drop a core.

IANAL. I am also not law enforcement. I'm also not a poser when it comes
to security.

I have spoken to law enforcement agencies from a number of countries about
this specific issue on several occasions, and I've also spoken with
attorneys about this specific idea in a couple of countries. You tread on
very dangerous ground, and it's an immature and unwise approach. The fact
is, defensive measures are generally not interpreted to include trying to
exploit vulnerabilities in code operating on boxes you don't own or have
authorization to attack. You'll exceed authorized access on someone else's
system, if you're successful. It may cause a great deal of collateral damage.

Your approach is ill-advised. It's also not all that wise as it could be
used to lauch DoS against other sites, and may be capable of doing DoS
against your site (MITM, forged syn, synack, ack sequences in two
directions, linking the stream from your /dev/urandom dump (ie: chargen) to
any port that will listen (echo). Chews up cycles, at a bare minimum...
forever.

> Currently, I have a service started by xinetd and close stdin on the
> command line arguments to avoid hackers hacking my program. I run a
> bash script as user "nobody" that basically looks like this (extra
> extraneous stuff is removed):
>
> #!/bin/bash
> function fakessh() {
> echo SSH-2.0-OpenSSH_3.9p1 # ID ourself as a valid SSH service
> /bin/cat /dev/urandom # and send random data
> }
> # Main follows - this is run as user "nobody"
> fakessh <&- # Call the payload and (again) close stdin to avoid hacks
> # EOF - fakessh
>
> The result for someone using a normal ssh client is:
> UNIX> ssh localhost
> Disconnecting: Bad packet length 3349376822.
>
> I am hoping to cause some kind of memory problem here and thats why I
> need the source code. Another exploit to examine is what happens with
> zero length packets if we cat /dev/zero. If there is nothing to exploit
> here, I'll remove the "echo" line so I send random data until the hacker
> client terminates his connection.
>
> Thank you,
> Brian Micek


--
William Yang
wyang@gcfn.net
--
gentoo-security@gentoo.org mailing list

I don't think you understand what I'm proposing. I am currently cat
(1)ing /dev/urandom on TCP port 22 in hopes to discourage hackers who
attempt to break into my system. Its beyond me how this is treading on
dangerous ground, what systems I'll endanger or what is morally wrong
with doing this. Brian Micek

On Sat, 2005-11-05 at 15:19 -0500, William Yang wrote:

> agenci

Brian Micek wrote:
> I don't think you understand what I'm proposing. I am currently cat
> (1)ing /dev/urandom on TCP port 22 in hopes to discourage hackers who
> attempt to break into my system. Its beyond me how this is treading on
> dangerous ground, what systems I'll endanger or what is morally wrong
> with doing this. Brian Micek
>
> On Sat, 2005-11-05 at 15:19 -0500, William Yang wrote:
>
>
>>agenci
>
>

How is what are you planning to do any different from me hosting a
website that attempts to exploit vulnerable web clients? Am I not
responsible for hosting what could be considered hostile content? Are
you responsible for damages to my machine if your /dev/urandom causes me
undo downtime?

You may think that this situation is different than the web example
above, but in reality they are quite similar. You can't know with 100%
certainty that the person requesting resources is a hacker and
attempting to crash their client is what most would consider a hostile
action.

We all realise that there are people who do dumb crap like ssh scanning.
However, I seriously doubt doing anything like this is going to help
your situation; or hinder theirs. In the end you will waste bandwidth
and cpu cycles and as the other poster mentioned, if they are smart
enough to realize what is going on they can probably DoS your machine
with it.

Just keep your ports closed, or keep them open and monitor the activity.
No need to go pissing the scanners off and give them a reason to spend
more time on your systems anyway.

-Alec Warner (Antarus)
--
gentoo-security@gentoo.org mailing list

Brian Micek wrote:
> I don't think you understand what I'm proposing. I am currently
> cat(1)ing /dev/urandom on TCP port 22 in hopes to discourage hackers
> who attempt to break into my system. Its beyond me how this is
> treading on dangerous ground, what systems I'll endanger or what is
> morally wrong with doing this. Brian Micek
>
> On Sat, 2005-11-05 at 15:19 -0500, William Yang wrote:
>> agenci
It's roughly analogous to pointing a loaded shotgun at the door and
tying a string to the trigger so that whoever opens the door gets shot.
There is a pretty good chance that you'll shoot the wrong person - most
likely yourself. And, assuming you do shoot someone, you'll have a
pretty nasty wrongful death suit on your hands regardless of whether the
person you shot had any business opening the door.

What you are proposing to do is to attack anyone who comes knocking. The
problem is that you don't know who is going to come knocking or how they
might be disguising themselves, using someone else's resources, etc.
Your counterattack may not affect the hacker who attacks your system at
all. It may affect an innocent bystander or even your own system.

--
gentoo-security@gentoo.org mailing list

I'm very sorry for not describing what I'm doing in more detail
resulting in all this wasted email.
1. cat(1)ing /dev/urandom does not exploit any problems in an ssh
client. Ssh is written well and the program will realize there is a
problem on the TCP stream, describe the error and exit
2. My goal is to discourage punk hackers from attempting to crack my
networks. In order to do this, I'm experimenting with variations of
invalid TCP streams on TCP port 22.
3. I have no idea how people think this can hurt any network other than
my own or any legitimate software product.

I have to admit I'm angry at your attempt to argue a null issue. Your
network shouldn't be connecting to my networks but, in case it does, the
worse that can happen is a stream of random data will pass to your
machine over one socket from a single host resulting in bandwidth usage
on the lines of downloading a file. I postulated the hacking tool is
not written well.

Please lets forget about this thread because its going nowhere and once
again, I apologize about all this spam.
Brian Micek

On Sat, 2005-11-05 at 16:41 -0500, Alec Warner wrote:

> Brian Micek wrote:
> > I don't think you understand what I'm proposing. I am currently cat
> > (1)ing /dev/urandom on TCP port 22 in hopes to discourage hackers who
> > attempt to break into my system. Its beyond me how this is treading on
> > dangerous ground, what systems I'll endanger or what is morally wrong
> > with doing this. Brian Micek
> >
> > On Sat, 2005-11-05 at 15:19 -0500, William Yang wrote:
> >
> >
> >>agenci
> >
> >
>
> How is what are you planning to do any different from me hosting a
> website that attempts to exploit vulnerable web clients? Am I not
> responsible for hosting what could be considered hostile content? Are
> you responsible for damages to my machine if your /dev/urandom causes me
> undo downtime?
>
> You may think that this situation is different than the web example
> above, but in reality they are quite similar. You can't know with 100%
> certainty that the person requesting resources is a hacker and
> attempting to crash their client is what most would consider a hostile
> action.
>
> We all realise that there are people who do dumb crap like ssh scanning.
> However, I seriously doubt doing anything like this is going to help
> your situation; or hinder theirs. In the end you will waste bandwidth
> and cpu cycles and as the other poster mentioned, if they are smart
> enough to realize what is going on they can probably DoS your machine
> with it.
>
> Just keep your ports closed, or keep them open and monitor the activity.
> No need to go pissing the scanners off and give them a reason to spend
> more time on your systems anyway.
>
> -Alec Warner (Antarus)

Brian Micek wrote:
> Please lets forget about this thread because its going nowhere and once
> again, I apologize about all this spam.

yeah, i love BOFH : ) but the argue about cpu and bandwith waste is real

don't care who say you can't send random data on request, we are free to
reply what we want on a request (also some ascii p*rn is a good idea)

if you are using tcpd consider to do something like catting some random
data to a file and then stream the file (no disk i/o since linux has
caching, low cpu usage)

remember also you are sending some of your precious *true* random data
to the bad guy (i'm not able to exploit or predict the next random bit
but i heard somebody on the globe is able to.. so be paranoid :P )

also the client will break the tcp stream on X null chars or something
like that so use a file and close the connection at some poit is good
to prevent bandwith waste (don't let the client decide)

an other thing to consider is ip spoofing, but who cares : )

just my 901 bytes opinion..
--
gentoo-security@gentoo.org mailing list

Who gives a shit if a script kiddie gets his box
rebooted for doing something he shouldnt be doing in
the first place. This looks like an active defense,
and I would definitely like to see the results if you
finish your project brian!


--- ascii <ascii@katamail.com> wrote:

> Brian Micek wrote:
> > Please lets forget about this thread because its
> going nowhere and once
> > again, I apologize about all this spam.
>
> yeah, i love BOFH : ) but the argue about cpu and
> bandwith waste is real
>
> don't care who say you can't send random data on
> request, we are free to
> reply what we want on a request (also some ascii
> p*rn is a good idea)
>
> if you are using tcpd consider to do something like
> catting some random
> data to a file and then stream the file (no disk i/o
> since linux has
> caching, low cpu usage)
>
> remember also you are sending some of your precious
> *true* random data
> to the bad guy (i'm not able to exploit or predict
> the next random bit
> but i heard somebody on the globe is able to.. so be
> paranoid :P )
>
> also the client will break the tcp stream on X null
> chars or something
> like that so use a file and close the connection at
> some poit is good
> to prevent bandwith waste (don't let the client
> decide)
>
> an other thing to consider is ip spoofing, but who
> cares : )
>
> just my 901 bytes opinion..
> --
> gentoo-security@gentoo.org mailing list
>
>





__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
--
gentoo-security@gentoo.org mailing list

Adam Sroka napisał(a):
> Brian Micek wrote:
>
>> I don't think you understand what I'm proposing. I am currently
>> cat(1)ing /dev/urandom on TCP port 22 in hopes to discourage hackers
> It's roughly analogous to pointing a loaded shotgun at the door and
> tying a string to the trigger so that whoever opens the door gets shot.

Adam, he's not pointing a gun :).

The better analogy would be that he's put a sick dog standing by his door, and
someone tries to OPEN them not just knock. Kiddie tries few keys and then dog
starts to barf at him. If that would be a normal ssh client, he'd come clean,
but since it's a script kiddie - well...

If someone tries to root access via ssh on every IP - that's not knocking,
that's like checking all my doors.


--
-=[ Lukasz C. Jokiel ]=- | Klonex VCS, Zbozowa 27, 45-837 Opole.
CCNA/CCDA/CCCS; DOCSIS,CMTS,cable modems,ISD; Linux Cable Services
sys&net adm@klonex.pl | phone: +48774572901*116 | Skype: lcjoker
-=[ http://lukasz.jokielowie.com/ ]=-
--
gentoo-security@gentoo.org mailing list

Brian Micek wrote:
> I don't think you understand what I'm proposing. I am currently
> cat(1)ing /dev/urandom on TCP port 22 in hopes to discourage hackers who
> attempt to break into my system. Its beyond me how this is treading on
> dangerous ground, what systems I'll endanger or what is morally wrong
> with doing this.

If it's beyond you, then perhaps you need to do further research into how
things work before deploying your solution. Your stated goal was to cause
a core dump through spewage. To restate that, you want *to crash software
on a remote system.* Which is to say, you want to *cause damage to a
remote system.*

So, to explain this in a more tangible way, assume three hosts, A, B, and
C. A is you. B is an attacker. C is an innocent bystander.

It's possible, using several features of IP for B to connect the output of
ports from A to ports on C. That is, B can create a connection from A to C
using legitimate TCP behaviors, that neither C nor A would otherwise have
initiated.

Your "solution" of cat-ing /dev/urandom is, in effect, creating a binary
character generator *which never stops generating characters* (though it
will periodically delay in doing so, and it does exhaust your true entropy
on your system, which is harmful if you have any reason for randomness
(cryptography, password generation, complex simulations, game theory
decision models, etc). For us oldtimers... those of us who've been around
the block a few (hundred thousand) times... we remember the earliest DoS
attacks, which created connections from the chargen to echo or discard
ports on various machines, simply to consume bandwidth and processor. It
sounds like a great avenue of attack against your "solution."

Think a little broader. The reason I can level this criticism at all is
because you're looking only at a tiny subset of the consequences of your
technology. When one looks at a much broader range of possible outcomes
and possible MIS-uses of the technology, when one looks at the boundaries
of a problem statement and looks for how things will cross those
boundaries, that's how you create actual security and assurance against
adverse events.

There's a reason why pretty much every major security organization comes
down against "active response" (aka "strikeback" or "offensive response" or
"retribution" or, my personal favorite, "vengence") strategies and
approaches. These strategies almost invariably lead to unintended
consequences which can damage uninvolved third parties, which are
predictable, preventable, and undesirable. That's what makes these
strategies a generally bad idea, and why security professionals argue
against them.

The line you don't want to cross has to do with sending responses to
someone else. If you want to stop them from talking to you, fine. If you
want to blacklist them from talking to your networks, fine. But when you
reach your hand back toward them, you cross the line and become part of the
problem, rather than part of the solution.

-Bill
--
William Yang
wyang@gcfn.net
--
gentoo-security@gentoo.org mailing list