ip spoofing?
Dave RoaE Mescher
Arthur Lammoglia (al...@shadow.net) wrote:
: What does the term ip spoofing refer to exactly?
IP spoofing is broadcasting messages that appear to be coming from a different
address than that of a sender. For example, it is possible to send
a talk request from any machine I own to another machine and make it
appear like it came from another machine entirely.
: Art
--
Dave Mescher, co-owner Nex-Tech Industries.
"The difficult is in assembly, the impossible in R&D."
Offices on Tharkad, Luthien, New Avalon, Sian, Atreus, Strana Mechty,
Wolverine-Prime, and Blacksburg, Virginia, Terra.
Arthur Lammoglia
What does the term ip spoofing refer to exactly?
Art
Joshua Daymont
Sending a packet with a source address that is not your own.
- JD
Arthur Lammoglia (al...@shadow.net) wrote:
: What does the term ip spoofing refer to exactly?
: Art
Fulko van Westrenen
>Arthur Lammoglia (al...@shadow.net) wrote:
>: What does the term ip spoofing refer to exactly?
>IP spoofing is broadcasting messages that appear to be coming from a different
>address than that of a sender. For example, it is possible to send
>a talk request from any machine I own to another machine and make it
>appear like it came from another machine entirely.
What I would like to know is how do you manage to do that? I don't understand
how the answer comes back to you if you change the IP-address.
Fulko
Gary Howland
Fulko van Westrenen wrote:
>
> >IP spoofing is broadcasting messages that appear to be coming from a different
> >address than that of a sender. For example, it is possible to send
> >a talk request from any machine I own to another machine and make it
> >appear like it came from another machine entirely.
>
> What I would like to know is how do you manage to do that? I don't understand
> how the answer comes back to you if you change the IP-address.
It doesn't!
Gary
--
pub 1024/C001D00D 1996/01/22 Gary Howland <ga...@systemics.com>
Key fingerprint = 0C FB 60 61 4D 3B 24 7D 1C 89 1D BE 1F EE 09 06
Dave RoaE Mescher
Fulko van Westrenen (fu...@wtm.tudelft.nl) wrote:
: In article <4qc7qb$l...@csugrad.cs.vt.edu> dmes...@csugrad.cs.vt.edu (Dave "RoaE" Mescher) writes:
: >Arthur Lammoglia (al...@shadow.net) wrote:
: >: What does the term ip spoofing refer to exactly?
: >IP spoofing is broadcasting messages that appear to be coming from a different
: >address than that of a sender. For example, it is possible to send
: >a talk request from any machine I own to another machine and make it
: >appear like it came from another machine entirely.
: What I would like to know is how do you manage to do that? I don't understand
: how the answer comes back to you if you change the IP-address.
It doesn't (usually.) but w/ UDP packets you don't need any response.
You can do all sorts of wonderful things w/ just talk...
Larry J. Hughes Jr.
In article <fulko.313...@wtm.tudelft.nl>,
Fulko van Westrenen <fu...@wtm.tudelft.nl> wrote:
>What I would like to know is how do you manage to do that? I don't understand
>how the answer comes back to you if you change the IP-address.
In one case you (the attacker) use source routing so the answer does
come back to you. However many routers between you and the remote site
being attacked may (hopefully) be configured to disregard packets
flagged for source routing.
In another case (TCP sequence number guessing) you don't get the answer,
but it doesn't matter, because after you spoof the 3-way TCP handshake
you only need to deposit something evil into say a user's .rhosts file.
Quick, dirty, and possible without ever getting a byte in return.
---
Larry J. Hughes, Jr. hug...@indiana.edu
Indiana University http://copper.ucs.indiana.edu/~hughes/
* Author, "Actually Useful Internet Security Techniques," ISBN 1-56205-508-9 *
Brian Mitchell
On Fri, 21 Jun 1996 09:43:30 LOCAL, Fulko van Westrenen <fu...@wtm.tudelft.nl> wrote:
>In article <4qc7qb$l...@csugrad.cs.vt.edu> dmes...@csugrad.cs.vt.edu (Dave "RoaE
> " Mescher) writes:
>
>>Arthur Lammoglia (al...@shadow.net) wrote:
>
>>: What does the term ip spoofing refer to exactly?
>>IP spoofing is broadcasting messages that appear to be coming from a different
>>address than that of a sender. For example, it is possible to send
>>a talk request from any machine I own to another machine and make it
>>appear like it came from another machine entirely.
>
>how the answer comes back to you if you change the IP-address.
>
It doesnt.
However, you dont always need it to. Lets take rsh for example, if you
can send commands, you could send something like mv .rhosts RHOSTS;echo ++ >
.rhosts or something of that nature. You never really need to see the
response.
--
Brian Mitchell br...@saturn.net
Unix Security / Perl / WWW / CGI http://www.saturn.net/~brian
"I never give them hell. I just tell the truth and they think it's hell"
- H. Truman
Bruce Barnett
br...@tcpip.geek.net (Brian Mitchell) writes:
> However, you dont always need it to. Lets take rsh for example, if you
> can send commands, you could send something like mv .rhosts RHOSTS;echo ++ >
> .rhosts or something of that nature. You never really need to see the
> response.
I don't think that is a realistic example. Unless T/TCP is being used,
several packets have to be exchanged before the data is sent. You have
to send a SYN packet, and ACK the SYN packet you get back, before you
send data.
Besides people typically use source routing when they forge IP
addresses, or else use a virtual address, so target responds to a
second system, which relays the packets to a third system.
If the second system is trusted, or you can make the machine look like
a trusted system, the hacker can break into a system.
Lastly, people can disrupt a system by making the source address be
the loopback address.
--
Bruce Barnett <bar...@crd.ge.com>
Stefan Schmidt
Bruce Barnett (bar...@crd.ge.com) wrote:
: br...@tcpip.geek.net (Brian Mitchell) writes:
:
: > However, you dont always need it to. Lets take rsh for example, if you
: > can send commands, you could send something like mv .rhosts RHOSTS;echo ++ >
: > .rhosts or something of that nature. You never really need to see the
: > response.
:
: I don't think that is a realistic example. Unless T/TCP is being used,
: several packets have to be exchanged before the data is sent. You have
: to send a SYN packet, and ACK the SYN packet you get back, before you
: send data.
this IS realistic and 3..7 packets aren't so many.
: Besides people typically use source routing when they forge IP
: addresses, or else use a virtual address, so target responds to a
: second system, which relays the packets to a third system.
: If the second system is trusted, or you can make the machine look like
: a trusted system, the hacker can break into a system.
no need to use source routing.
stefan
Rolf Weber
Larry J. Hughes Jr. wrote:
> In one case you (the attacker) use source routing so the answer does
> come back to you. However many routers between you and the remote site
> being attacked may (hopefully) be configured to disregard packets
^^^^^^^^^
> flagged for source routing.
>
no, i disagree with this.
it's ridiculous to see how many routers disregard packets with IP options
while they cheerfully let IP spoofing thru.
source routing as *itself* is *not* bad.
it belongs to the IP stack (and there will be a smilar source routing in
IPng) and should only be stopped at end-point routers, if this site
doesn't want source routing.
what was bad with source routing?
yes, the conjunction with IP spoofing. but if IP spoofing is feasible,
you already lost the game.
yes, the bug in some routers, which didn't filter source routed packets
right. but this was a bug!
yes, the bug in some kernels, which forwarded source routed packets even
when forwarding was disabled. but this was a bug!
yes, there are a few nasty possiblities if a site has several routers,
but only if they (sure, one is enough) are poorly configured.
you could do a lot of useful stuff with source routing (BTW, maybe i'll
get flamed for this: what's with the idea to connect RFC1597 nets with
it?), and in conjuction with encryption there are little risks.
rolf
--
-----------------------------------------
Rolf Weber <we...@iez.com> | All I ask is a chance
IEZ AG D-64625 Bensheim | to prove that money
++49-6251-1309-109 | can't make me happy.
Martin Hargreaves
Bruce Barnett <bar...@crd.ge.com> wrote:
>br...@tcpip.geek.net (Brian Mitchell) writes:
>> However, you dont always need it to. Lets take rsh for example, if you
>> can send commands, you could send something like mv .rhosts RHOSTS;echo ++ >
>> .rhosts or something of that nature. You never really need to see the
>> response.
>I don't think that is a realistic example.
Strange, I believe spoofing with no data returned to create a .rhosts
file was _exactly_ the attack the Mitnick used to get into Shimomura's
machines at SDSC....
M.
##################################################################
# Martin Hargreaves (mar...@datamodl.demon.co.uk) Computational #
# Director, Datamodel Ltd Chemist #
# Contract Unix system admin/Unix security Sysadmin #
##################################################################
Vitus
On Jun 20, 1996 19:54:52 in article <Re: ip spoofing?>, 'jo...@cs.umd.edu
(Joshua Daymont)' wrote:
>Sending a packet with a source address that is not your own.
>
>- JD
>
>
AKA IP-masquerading. term "spoofing" usually refers to e-mail, where bad
guys do the same with
From: field
Greg Miller
On Fri, 21 Jun 1996 09:43:30 LOCAL, fu...@wtm.tudelft.nl (Fulko van Westrenen)
wrote:
>What I would like to know is how do you manage to do that? I don't understand
>how the answer comes back to you if you change the IP-address.
The answer doesn't come back to you. You can 'sniff' it off the network
if your system is in between the host being attacked and the host which address
your spoofing.
You can use source routing to force the packet to cross your network
before being routed to the intended receiver, but most systems should trigger an
alarm on that immediatley.
Greg Miller: Programmer/Analyst
DOS -- A user friendly version of UNIX.
gre...@mis.net
http://grendel.ius.indiana.edu/~gmiller/
Gus
Arthur Lammoglia (al...@shadow.net) wrote:
: What does the term ip spoofing refer to exactly?
: Art
It means forging the IP address fields in outgoing packets.
This can be used to set up a one-way connection to a machine
where the machine thinks you are, perhaps, a trusted host.
(one way beause the return traffic goes to the forged address)
A simple example can be found at
http://www.unix.geek.org.uk/~arny
as
arnudp001.c
which will send a single faked packet.
--
Gus <an...@bmsysltd.demon.co.uk> |-|PGP Fingerprint = 82 AA 4D 7F D8 45 58 05
http://www.thepulse.co.uk/angus |=|(Key on request) 6D 1B 1A 72 1E DB 31 B5
CIS 100545.720 |+| "Linux - You know you want to." | "fuck"
|Advertising/Promotional email will result in a campaign of hatred and abuse|
Gus
Martin Hargreaves (mar...@datamodl.demon.co.uk) wrote:
: Bruce Barnett <bar...@crd.ge.com> wrote:
: >br...@tcpip.geek.net (Brian Mitchell) writes:
: >> However, you dont always need it to. Lets take rsh for example, if you
: >> can send commands, you could send something like mv .rhosts RHOSTS;echo ++ >
: >> .rhosts or something of that nature. You never really need to see the
: >> response.
: >I don't think that is a realistic example.
: Strange, I believe spoofing with no data returned to create a .rhosts
: file was _exactly_ the attack the Mitnick used to get into Shimomura's
: machines at SDSC....
: M.
Inddedy, the Mitnick/Simomura attack used IP spoofing, and then
something similar to amodload.c (a SUNOS kernel module loader)
to complete the attack.
One thing that has so far not been mentioned, is that you must
have previously gained root on the machine you are coming from,
to be able to use the raw sockets.
(AFAICR, Mitnick had gained root on c2.org, from where he launched
the final part of the attack)
Bruce Barnett
mar...@datamodl.demon.co.uk (Martin Hargreaves) writes:
> Strange, I believe spoofing with no data returned to create a .rhosts
> file was _exactly_ the attack the Mitnick used to get into Shimomura's
> machines at SDSC....
I thought the discussion was on source routing only, and not source
routing combined with IP highjacking. Assuming what you say is
correct, why was source routing necessary at all?
--
Bruce Barnett <bar...@crd.ge.com>
Olaf Titz
Gus <an...@bmsysltd.demon.co.uk> wrote:
> One thing that has so far not been mentioned, is that you must
> have previously gained root on the machine you are coming from,
> to be able to use the raw sockets.
To gain "root" on a PC, turning it on is enough.
olaf
--
___ Olaf...@inka.de or @{stud,informatik}.uni-karlsruhe.de ____
__ o <URL:http://www.inka.de/~bigred/> <IRC:praetorius>
__/<_ >> Just as long as the wheels keep on turning round
_)>(_)______________ I will live for the groove 'til the sun goes down << ____
dru...@cybersydney.com.au
Bruce Barnett wrote:
>
> br...@tcpip.geek.net (Brian Mitchell) writes:
>
> > However, you dont always need it to. Lets take rsh for example, if you
> > can send commands, you could send something like mv .rhosts RHOSTS;echo ++ >
> > .rhosts or something of that nature. You never really need to see the
> > response.
>
> several packets have to be exchanged before the data is sent. You have
> to send a SYN packet, and ACK the SYN packet you get back, before you
> send data.
>
> addresses, or else use a virtual address, so target responds to a
> second system, which relays the packets to a third system.
> If the second system is trusted, or you can make the machine look like
> a trusted system, the hacker can break into a system.
>
> the loopback address.
>
> --
> Bruce Barnett <bar...@crd.ge.com>
Australia (yes we do have computers, electricity too!!) can you hlp me??
I'm trying to track down a wily hacker from wollongong (about 150 kms
south of here) he/she/it/they first started about a month ago in UNSW
syd. but we traced them and they ran to another city. unfortunately they
are running on a uni server so I think I'll have to, well, break-in to
nab them, or at least make it look like it is not me that is monitoring
their activity. IP spoofing would be very use ful for this, also n e
hints suggestions or death threats please mail me
worried
anxious
dying
smudge
Fidelio
fu...@wtm.tudelft.nl (Fulko van Westrenen) writes:
>In article <4qc7qb$l...@csugrad.cs.vt.edu> dmes...@csugrad.cs.vt.edu (Dave "RoaE" Mescher) writes:
>>Arthur Lammoglia (al...@shadow.net) wrote:
>>: What does the term ip spoofing refer to exactly?
>>IP spoofing is broadcasting messages that appear to be coming from a different
>>address than that of a sender. For example, it is possible to send
>>a talk request from any machine I own to another machine and make it
>>appear like it came from another machine entirely.
>What I would like to know is how do you manage to do that? I don't understand
>how the answer comes back to you if you change the IP-address.
100% correct, the answers go to the original site.
That's why spoofers
1) have to predict the ack that the other side will send, since they
won't be receiving it.
2) flood the to-be-spoofed side first to avoid that host to reset the
connection. A decent TCP/IP implementation will send a TCP RST packet
when it receives an ACK for something it didn't send.
Rob
--
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Rob J. Nauta Linux: putting power in the wrong hands
r...@pobox.com
Fidelio
mar...@datamodl.demon.co.uk (Martin Hargreaves) writes:
>Bruce Barnett <bar...@crd.ge.com> wrote:
>>br...@tcpip.geek.net (Brian Mitchell) writes:
>-> However, you dont always need it to. Lets take rsh for example, if you
>-> can send commands, you could send something like mv .rhosts RHOSTS;echo ++ >
>-> .rhosts or something of that nature. You never really need to see the
>-> response.
->I don't think that is a realistic example.
>Strange, I believe spoofing with no data returned to create a .rhosts
>file was _exactly_ the attack the Mitnick used to get into Shimomura's
>machines at SDSC....
You mean, the attacker who broke into Shimomura's home machines used this
technique. Then a few months later Mitnick was discovered to have a 180 MB
tar.gz file with all the files on the Well. The attacker broke in from
several universities, where he could easily hide such a big file, Mitnick
however was noticed immediately as the Well runs a diskspace wasters top
10 program, and the system is used heavily by thousands of users, so
excessive disk use like that is bound to be noticed. My guess is that he
managed to persuade the original attacker to share the loot with him,
but that he didn't do the actual break-in.
IP spoofing is a common technique nowadays. Various spoofers exist, although
all seem more or less broken. They are also highly machine-specific, most
spoofers work on Linux exclusively.
Stan Friesen
In article <DtGFE...@bmsysltd.demon.co.uk>, an...@bmsysltd.demon.co.uk (Gus) writes:
|>
|> One thing that has so far not been mentioned, is that you must
|> have previously gained root on the machine you are coming from,
|> to be able to use the raw sockets.
So? I effectively HAVE root on my home machine without any action
at all.
--
s...@elsegundoca.ncr.com sar...@ix.netcom.com
The peace of God be with you.
Mark Hickey
>
> br...@tcpip.geek.net (Brian Mitchell) writes:
>
> > However, you dont always need it to. Lets take rsh for example, if you
>
> I don't think that is a realistic example. Unless T/TCP is being used,
> several packets have to be exchanged before the data is sent. You have
> to send a SYN packet, and ACK the SYN packet you get back, before you
> send data.
>
Brian's example *is* a realistic example; he just doesn't spell out the mechanism by
which
the TCP connection is hi-jacked (the TCP 3-way handshake is vulnerable to
attack because it relies on a random number/ip address pair for authentication. It
has been shown that the random number the server expects from the client when
responding to the client's SYN packet can be easily predicted. This being the case,
if you can spoof IP, you can convince the server you should be trusted). The next
question after the TCP connection is subverted, is "what did the attacker get?" If
the connection in question is to a server like REXEC, RSH, etc. that allow commands
to be executed on the remote machine, or even a service like FTP that allow
potentially sensitive files to be overwritten with the attackers versions, then you
are in trouble, and as long as you have no typos in your commands, you need not see
any response from the server to complete the attack.
> Bruce Barnett <bar...@crd.ge.com>
Mark Hickey
>
>
> >What I would like to know is how do you manage to do that? I don't understand
> >how the answer comes back to you if you change the IP-address.
>
> 100% correct, the answers go to the original site.
> That's why spoofers
> 1) have to predict the ack that the other side will send, since they
> won't be receiving it.
> 2) flood the to-be-spoofed side first to avoid that host to reset the
> connection. A decent TCP/IP implementation will send a TCP RST packet
> when it receives an ACK for something it didn't send.
>
> Rob
> --
>
I read an interesting variation on
the SEQ number guessing/IP-spoofing attack described by Morris. If the
attacker has access to the wire between the target server and the targer
client, then when the client initiates the connection to the server, the
attacker can insert itself into the circuit between the two hosts
by doing the following:
- return a SYN to the client, IP-spoofed to look like the server,
with a manufactured SEQ number.
- send a RST to the server, IP-spoofed to look like the client
- Send a new SYN to the server with a manufactured client SEQ.
At this point, server packets to the real client are ignored by the
real client because the client does not recognize the connection (since
it was initiated by the attacker. Likewise, the server ignores the
client's packets containing the attackers manufactured SEQ number. The
two hosts CAN communicate through the attacker; the attacker sniffs the
packets going in one direction or the other with the out-of-sync SEQ
numbers, and generates new packets with the expected SEQ number for the
destination, IP-spoofed to appear to originate from the expected source.
The paper is available at http://www.mono.org/~arny/iphijack.ps
Brian Mitchell
On Sun, 23 Jun 1996 13:03:21 GMT, Gus <an...@bmsysltd.demon.co.uk> wrote:
>Arthur Lammoglia (al...@shadow.net) wrote:
>
>: What does the term ip spoofing refer to exactly?
>
[many blank lines compressed for shorter quoting]
> It means forging the IP address fields in outgoing packets.
> This can be used to set up a one-way connection to a machine
> where the machine thinks you are, perhaps, a trusted host.
> (one way beause the return traffic goes to the forged address)
> A simple example can be found at
> http://www.unix.geek.org.uk/~arny
> as
> arnudp001.c
> which will send a single faked packet.
>
If you are on the same subnet of either end of the connection, you should be
able to get 2 way by a sniffing based approach too. So it doesn't have to be
strictly send-only :-).
Brian Mitchell
On Sun, 23 Jun 1996 13:13:20 GMT, Gus <an...@bmsysltd.demon.co.uk> wrote:
>Martin Hargreaves (mar...@datamodl.demon.co.uk) wrote:
>
>: >br...@tcpip.geek.net (Brian Mitchell) writes:
>
>: >> However, you dont always need it to. Lets take rsh for example, if you
>: >> can send commands, you could send something like mv .rhosts RHOSTS;echo ++ >
>: >> .rhosts or something of that nature. You never really need to see the
>: >> response.
>
>: >I don't think that is a realistic example.
>
>: file was _exactly_ the attack the Mitnick used to get into Shimomura's
>: machines at SDSC....
>
>
> Inddedy, the Mitnick/Simomura attack used IP spoofing, and then
> something similar to amodload.c (a SUNOS kernel module loader)
> to complete the attack.
well, tap was used after the initial attack was completed and root was
gained. Tap is a loadable module that monitors both input and output streams
of a tty.
>
>
> One thing that has so far not been mentioned, is that you must
> have previously gained root on the machine you are coming from,
> to be able to use the raw sockets.
Or be on a system with no concept of superuser privledge, like a dos based
system.
With linux and freebsd as common as it is, not to mention dialup ppp/slip
access - root really is not an issue any more.
>
> (AFAICR, Mitnick had gained root on c2.org, from where he launched
> the final part of the attack)
I thought it came from toad.com.
Brian Mitchell
On Mon, 24 Jun 1996 07:26:17 GMT, dru...@cybersydney.com.au <dru...@cybersydney.com.au> wrote:
>hey there!!! I work as a sysadmin for a web publishing company in syd.
>Australia (yes we do have computers, electricity too!!) can you hlp me??
>I'm trying to track down a wily hacker from wollongong (about 150 kms
>south of here) he/she/it/they first started about a month ago in UNSW
>syd. but we traced them and they ran to another city. unfortunately they
>are running on a uni server so I think I'll have to, well, break-in to
>nab them, or at least make it look like it is not me that is monitoring
>their activity. IP spoofing would be very use ful for this, also n e
>hints suggestions or death threats please mail me
>worried
>anxious
>dying
>smudge
That would not be very smart. Your best recourse is to let the admins at the
university handle it from their end. And if you were to do this foolish
thing, you really should not advertise that fact on usenet. I'm not sure
about australian law, but your post could very well be held against you in
your trial.
My advice would be to voice contact the admin at the edu if possible (never
know who is listening on those ethernets, who is reading what mail, etc) and
explain the situation, perhaps aid him in tracking the person down.
In the states, at least, illegally obtained evidence would be inadmissable
in court anyways, so even if you did break in undetected and did get
evidence, you could not do anything with it.
Joe
br...@tcpip.geek.net (Brian Mitchell) wrote:
>On Mon, 24 Jun 1996 07:26:17 GMT, dru...@cybersydney.com.au <dru...@cybersydney.com.au> wrote:
>>hey there!!! I work as a sysadmin for a web publishing company in syd.
>>Australia (yes we do have computers, electricity too!!) can you hlp me??
>>I'm trying to track down a wily hacker from wollongong (about 150 kms
>>south of here) he/she/it/they first started about a month ago in UNSW
>>syd. but we traced them and they ran to another city. unfortunately they
>>are running on a uni server so I think I'll have to, well, break-in to
>>nab them, or at least make it look like it is not me that is monitoring
>>their activity. IP spoofing would be very use ful for this, also n e
>>hints suggestions or death threats please mail me
>>worried
>>anxious
>>dying
>>smudge
>
>That would not be very smart. Your best recourse is to let the admins at the
>university handle it from their end. And if you were to do this foolish
>thing, you really should not advertise that fact on usenet. I'm not sure
>about australian law, but your post could very well be held against you in
>your trial.
I'm sure the .edu.au admins are the same as the .edu admins.. (Except
more of them have accents ;)
Oh come on... This is an .edu?!? Most admins there, are... well...
odd. Admins at .edu's either A) don't care. or B) are so overbearing
about their network and system that they'll take it as an offence (and
quickly delete any record of that user on the system), that one of
their users could get by their rigerous methods of deturing their
users from acting maliciously. In short: It's not worth the trouble.
>My advice would be to voice contact the admin at the edu if possible (never
>know who is listening on those ethernets, who is reading what mail, etc) and
>explain the situation, perhaps aid him in tracking the person down.
If they'll talk to you. This is also assuming that they a) put you
through to the correct person and B) the information that InterNIC has
on file for them is accurate (and upto date).
>In the states, at least, illegally obtained evidence would be inadmissable
>in court anyways, so even if you did break in undetected and did get
>evidence, you could not do anything with it.
He could sleep better at night knowing he sent the hitman to the
correct address :) After getting fustrated with the Univ's admin not
wanting to talk to him... So he could sleep with a smile on his face
knowing there's one less of them around too :)
On the serious side. He's just verifying who's doing it. I'm sure
there's a user on the ISP he runs that has an account on the
university. And if he fingers @host to get a list, he could notice
that one specific user is logged on all the time that the system is
being hacked or whatever (without any idle time, that is). Which is
perfectly legal, from off the system... and on the system, he can view
the accounting information to view the user's activities.
Magnus Bergman
In article <yekbuic...@crd.ge.com>,
Bruce Barnett <bar...@crd.ge.com> writes:
>br...@tcpip.geek.net (Brian Mitchell) writes:
>
>> However, you dont always need it to. Lets take rsh for example, if you
>> can send commands, you could send something like mv .rhosts RHOSTS;echo ++ >
>> .rhosts or something of that nature. You never really need to see the
>> response.
>
>several packets have to be exchanged before the data is sent. You have
>to send a SYN packet, and ACK the SYN packet you get back, before you
>send data.
Yup ... That's correct. And that Three-way-handshake can be spoofed.
If we have three machines:
A - machine that trusts B
B - machine that is trusted by A
X - The attackers machine
First you send alot (8-10) of SYN:s to B with a spoofed source address
that does not exist to fill up the connection queue.
This means that it wont answer to any connection-requests.
Second you spoof a packet from X to allegedly be from B to A with the
flag SYN.
Machine A will try to respond to machine B (that will not be able to
answer it because of the filled up connection-queue) with a SYN-ACK. This
SYN-ACK must be ACK:ed by machine B to establish a connection, the ACK must
also contain the correct sequence-number, based on the SYN-ACK to establish
the connection.
This sequencenumber is "guessed" (predicted) (this is possible due to the
fact that it's generation is not random) and the ACK is sent from X and
spoofed to look like it is from B to A. Now we have spoofed the
Three-way-handshake and we have a valid established connection.
Third is to send a rsh A "echo + + >>/.rhosts" and spoof the
source-address so it looks like it is from B.
It's not that hard ...
//Tri
Timothy Kordas
> mar...@datamodl.demon.co.uk (Martin Hargreaves) writes:
>
> > Strange, I believe spoofing with no data returned to create a .rhosts
> > file was _exactly_ the attack the Mitnick used to get into Shimomura's
> > machines at SDSC....
>
> routing combined with IP highjacking. Assuming what you say is
> correct, why was source routing necessary at all?
Now *you* have introduced IP-hijacking (taking control of an already
established TCP connection). Source routing packets as part of an
IP-spoof attack would allow the attacker to listen to returned data
(by causing those packets to be routed past a machine they control).
However, as several people have already mentioned in this thread, source
routing is not required in an IP-spoof attack. The term "IP-spoof" is
used to describe the transmission of an IP packet by one host with a
source address which is legitimately assigned to another host.
-Tim
--
Timothy J. Kordas
t...@hypercon.com
Bruce Barnett
> Now *you* have introduced IP-hijacking (taking control of an already
> established TCP connection). Source routing packets as part of an
> IP-spoof attack would allow the attacker to listen to returned data
> (by causing those packets to be routed past a machine they control).
> However, as several people have already mentioned in this thread, source
> routing is not required in an IP-spoof attack. The term "IP-spoof" is
> used to describe the transmission of an IP packet by one host with a
> source address which is legitimately assigned to another host.
I understand now. For some reason, I thought Shimomura's account was
broken into using IP-Hijacking, and not pure IP spoofing. For
spoofing to work, doesn't there typically need to be a simple form of
authentication, like a .rhosts file? I didn't think Shimomura would
use rlogin as authentication on a enternal machine. I thought to
myself, nah. he wouldn't do THAT..... Unless the sequence number
predictor skipped several packets, and got the timing just perfect.
--
Bruce Barnett <bar...@crd.ge.com>
TWYG
>hey there!!! I work as a sysadmin for a web publishing company in syd.
>Australia (yes we do have computers, electricity too!!) can you hlp me??
>I'm trying to track down a wily hacker from wollongong (about 150 kms
>south of here) he/she/it/they first started about a month ago in UNSW
>syd. but we traced them and they ran to another city. unfortunately they
>are running on a uni server so I think I'll have to, well, break-in to
>nab them, or at least make it look like it is not me that is monitoring
in trying to crack their site, are you
really that much different than them?
and how do you plan to explain where you
got your information from if you take
any action against these folks? geez...
break in to "nab" them and you might be
the one getting nabbed, you realize.
t.