Final thoughts on Daemonic.c

["J. Oquendo" <intrusion () ENGINEER COM>]

FYI I thought you would like to see the following presumptions I gathered when thinking out daemonic.c This will be the 
last message on this subject for the time being until I can find further proof of whether or not this can kill a 
router's connection and not just a server running router based software.

Please refer to the following RFC for clarification on my method of thinking and note that I have fixed a flag which 
cause the original program to send data to a high port which someone pointed out earlier. The relevant data will be 
contained within brackets in an effort to clarify my message from the data contained within the RFC.

No special checks were looked into on eBGP as someone previously e-mailed me about since this was merely a way for me 
to open the door on different DoS based attacks with the presumption that if someone were to sit down and spec 
something in a much more detailed fashion that I had, massive problems would occur on a higher level. Or at least my 
thoughts lead me to believe so.

(Think of broken backbones between large internetworks.)

Again I'll restate for the record the thoughts were never malicious to any extent and for those who browse the list I 
respect just about every one who has commented with something positive or negative provided it was relevant and not 
some script kiddie type of response.


http://www.cis.ohio-state.edu/htbin/rfc/rfc1771.html

#################################################################
Page 4

The hosts executing the Border Gateway Protocol need not be routers. A non-routing host could exchange routing 
information with routers via EGP or even an interior routing protocol.


Page 6
This 16-octet field contains a value that the receiver of the
message can predict.  If the Type of the message is OPEN, or if
the OPEN message carries no Authentication Information (as an
Optional Parameter), then the Marker must be all ones.
#################################################################

I took this as a BGP network leaving room for someone who could craft a well enough packet to send bad data. Not 
everything is
authenticated and there is no notice of it being set by default.

#################################################################
Otherwise, the value of the marker can be predicted by some a
computation specified as part of the authentication mechanism
(which is specified as part of the Authentication Information)
used.  The Marker can be used to detect loss of synchronization
between a pair of BGP peers, and to authenticate incoming BGP
messages.
#################################################################

This is why I decided to make most of the attributes within the packets being sent random(), knowing I would not be 
able to capture a session therefore randomizing would server more of a chance of possibly corrupting a sequence 
exchange, whereas having someone guesstimate a sequence would be like a needle in a haystack. Although they're both 
(guessing and randomizing) highly unlikely of achieving.

#################################################################
ORIGIN is a well-known mandatory attribute that defines the
origin of the path information.   The data octet can assume
the following values:

Value      Meaning

0         IGP - Network Layer Reachability Information
          is interior to the originating AS

1         EGP - Network Layer Reachability Information
          learned via EGP

2         INCOMPLETE - Network Layer Reachability
          Information learned by some other means
#################################################################

Again if someone took the time to carefully craft a packet would setting the ORIGIN value to 2 possess an easier way to 
creep into a BGP based network? Well I could be reading things backwards but I believe it can be done.

#################################################################
Page 27
6.7 Cease.

In absence of any fatal errors (that are indicated in this section), a BGP peer may choose at any given time to close 
its BGP connection by sending the NOTIFICATION message with Error Code Cease.  However, the Cease NOTIFICATION message 
must not be used when a fatal error indicated by this section does exist.
#################################################################

I had thought about creating some sort of "packet injection" file
which would send these messages but since I'm still learning codes and modifying others' codes I would have to sit down 
with this for a while. But as part of the Theories in DoS paper I plan on trying to accomplish this whether or not it 
fails.

#################################################################
Page 52
Appendix 5.  TCP options that may be used with BGP

If a local system TCP user interface supports TCP PUSH function, then each BGP message should be transmitted with PUSH 
flag set.  Setting PUSH flag forces BGP messages to be transmitted promptly to the receiver.
#################################################################

Again if you read my "packet injection" message I intend on trying all sorts of settings till one of them either clicks 
or fails. I've got time since I doubt BGP is a dying protocol and since I'm studying more into the protocol while I 
have time.

If anyone cares to send me relevant information I sincerely appreciate it and if someone cares even more to send me 
RFC's or FAQ's on why this CANNOT be accomplished then all the better.

Already read:
rfc1774
rfc1965
rfc1966
rfc1997

Yours truly
J. Oquendo
sil () deficiency org
sil () antioffline com

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup