Security Basics
Re: Port-Knocking vulnerabilities? Dec 28 2007 07:07PM
Jay (jay tomas infosecguru com) (1 replies)
Re: Port-Knocking vulnerabilities? Dec 29 2007 01:28PM
Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (1 replies)
Re: Port-Knocking vulnerabilities? Dec 31 2007 06:27PM
Robert Inder (robertinder googlemail com) (2 replies)
Re: Port-Knocking vulnerabilities? Dec 31 2007 08:50PM
Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (1 replies)
RE: Port-Knocking vulnerabilities? Dec 31 2007 09:46PM
Craig Wright (Craig Wright bdo com au) (1 replies)
RE: Port-Knocking vulnerabilities? Jan 01 2008 01:01PM
Bill Lavalette (blavalet homenet-security com)
Re: Port-Knocking vulnerabilities? Dec 31 2007 07:40PM
Goldstein101 (goldstein101 gmail com) (1 replies)
RE: Port-Knocking vulnerabilities? Dec 31 2007 09:32PM
Craig Wright (Craig Wright bdo com au) (1 replies)
Re: Port-Knocking vulnerabilities? Jan 06 2008 04:12AM
Michael Rash (mbr cipherdyne org) (1 replies)
RE: Port-Knocking vulnerabilities? Jan 06 2008 04:49AM
Craig Wright (Craig Wright bdo com au) (1 replies)
Re: Port-Knocking vulnerabilities? Jan 06 2008 05:17AM
Michael Rash (mbr cipherdyne org) (1 replies)
On Jan 06, 2008, Craig Wright wrote:

> Hi Michael,

Hi Craig -

> I admit I have not looked at fwknop, so I will withhold comment until I have. It is not port knocking, so the issues there do not apply.

(Just for completeness, fwknop does also offer a port knocking mode - it
was the first port knocking system to also combine p0f-style OS
fingerprinting as an additional authentication parameter - but SPA is
the default mode and the port knocking has been deprecated).

> The idea of these servers being undetectable is a falacy. SPA still leaves itself open to diagnostics for detection. Timing differences give away that there is something on the port. I know this means maths, but I am a statistician, so math is good. This does not mean that it will be broken, but it can be detected.

A server that is behind a default-drop packet filter is not
_practically_ detectable (say, with an nmap scan). Can you point to a
piece of software that can reliably perform the timing differences you
are referring to in order to infer that a server is really listening
behind such a packet filter? Do you have to invoke an additional server
(say, a webserver in addition to an SSH server) that is on the same
system that is accessible and then making a statistical argument around
latencies caused by such a server or something like that?

Either way, even if you can reliably detect an SSH server behind a
default-drop packet filter (and I think this is unlikely unless you are in
a position to just see a live SSH session in progress on the wire and
therefore it is obvious), that by itself is not a huge advantage even if
you know of a vulnerability in SSH. How would you exploit a vulnerabile
function in the SSH server?

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F

> I will get back when I have had a chance to trial it fully.
>
> Regards,
> Dr Craig Wright (GSE-Compliance)
>
> ________________________________________
> From: Michael Rash [mbr (at) cipherdyne (dot) org [email concealed]]
> Sent: Sunday, 6 January 2008 3:12 PM
> To: Craig Wright
> Cc: Goldstein101; Robert Inder; Ansgar -59cobalt- Wiechers; security-basics (at) securityfocus (dot) com [email concealed]; dave (at) davekleiman (dot) com [email concealed]
> Subject: Re: Port-Knocking vulnerabilities?
>
> On Jan 01, 2008, Craig Wright wrote:
>
> > First, you have mentioned SPA, and true this offers more then port knocking, you have also mixed port knocking and SPA up in a couple of your comments.
> >
> > Now you make the comment that SPA can "encrypt" and store in the IP ID. IP ID is a 16 bit flag. That is there are a max of 65535 values. Even with 4 IP packets it is functionally equivilant to a 3 character password. Given a standard ADSL line and 68 byte packets I can send all combinations in just under 7.5 seconds (and this is not doing any analysis on the IPID).
> >
> > That is SPA and not port knocking. That is the MORE secure of the two options.
>
> Agreed.
>
> > Yes this way will make a log entry, but are you sitting at the server 24x7 and monitoring ALL scans. Will you stop me in less then 8 seconds?
> >
> > When did people consider a 3 character password safe?
>
> That is why any implementation of SPA that just uses network or
> transport layer headers to communicate information instead of
> application layer data is inherently deficient and not worthy of the
> SPA designation IMHO (even though technically, yes, it is just a single
> packet).
>
> In addition to the small key space that just using the 16 bit IP ID field
> limits any such implementation to, there are additional limitations
> including*:
>
> - Such "SPA" packets are replayable against the target (unless some horrid
> S/KEY style iteration of a hash function is used or someone manually
> changes around the key for each SPA packet). If the application layer
> were used (such as in fwknop: http://www.cipherdyne.org/fwknop) the
> replay problem is trivially solved by prepending every SPA packet with
> 16 bytes of random data before it is encrypted. This is possible
> because of the relatively large amount of data that can be transfered
> within the application layer payload of a single UDP packet.
>
> - It is difficult to protect against MITM attacks because the source IP
> itself in the actual network layer header is allowed through the
> firewall policy on the server side. Fwknop allows the source IP to be
> placed within the encrypted SPA payload, and is therefore not subject to
> alteration by an attacker that possesses an inline device that can stop
> an SPA packet and retransmit it with a different source IP.
>
> - It is impossible to communicate client-side information that the
> server might find useful because the usage of packet headers is too
> restrictive. A true SPA implementation can use 2048-bit GnuPG keys
> and do things like communicate crypt() passwords so the server can
> interface with additional authentication mechanisms. Fwknop supports
> both Rijndael and GnuPG keys, crypt() passwords, and even the
> transmission of full shell commands.
>
> Here is a list of features supported by fwknop - all of these are
> possible because of the usage of payload data instead of just packet
> headers for SPA communications:
>
> http://www.cipherdyne.org/fwknop/docs/features.html
>
> *Disclaimer: I developed fwknop so obviously I'm biased. However, I
> welcome any critique that can point out a non-obvious limitation in the
> fwknop architecture or implementation.
>
> --
> Michael Rash
> http://www.cipherdyne.org/
> Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F
>
>
>
> > Rgards,
> > Dr Craig Wright (GSE-Compliance)
> >
> >
> >
> > Craig Wright
> > Manager of Information Systems
> >
> > Direct : +61 2 9286 5497
> > Craig.Wright (at) bdo.com (dot) au [email concealed]
> > +61 417 683 914
> >
> > BDO Kendalls (NSW)
> > Level 19, 2 Market Street Sydney NSW 2000
> > GPO BOX 2551 Sydney NSW 2001
> > Fax +61 2 9993 9497
> > www.bdo.com.au
> >
> > Liability limited by a scheme approved under Professional Standards Legislation in respect of matters arising within those States and Territories of Australia where such legislation exists.
> >
> > The information in this email and any attachments is confidential. If you are not the named addressee you must not read, print, copy, distribute, or use in any way this transmission or any information it contains. If you have received this message in error, please notify the sender by return email, destroy all copies and delete it from your system.
> >
> > Any views expressed in this message are those of the individual sender and not necessarily endorsed by BDO Kendalls. You may not rely on this message as advice unless subsequently confirmed by fax or letter signed by a Partner or Director of BDO Kendalls. It is your responsibility to scan this communication and any files attached for computer viruses and other defects. BDO Kendalls does not accept liability for any loss or damage however caused which may result from this communication or any files attached. A full version of the BDO Kendalls disclaimer, and our Privacy statement, can be found on the BDO Kendalls website at http://www.bdo.com.au or by emailing administrator (at) bdo.com (dot) au. [email concealed]
> >
> > BDO Kendalls is a national association of separate partnerships and entities.
> >
> > ________________________________________
> >
> > From: listbounce (at) securityfocus (dot) com [email concealed] [listbounce (at) securityfocus (dot) com [email concealed]] On Behalf Of Goldstein101 [goldstein101 (at) gmail (dot) com [email concealed]]
> > Sent: Tuesday, 1 January 2008 6:40 AM
> > To: Robert Inder
> > Cc: Ansgar -59cobalt- Wiechers; security-basics (at) securityfocus (dot) com [email concealed]
> > Subject: Re: Port-Knocking vulnerabilities?
> >
> > I guess most of you haven't bothered to check what port knocking
> > really is capable of 'cause I'm reading a lot of things that are not
> > true.
> >
> > First of all, Port Knocking is just another layer of security. Think
> > of it as the door of a room that contains a safe. You first have to
> > break the port knocking daemon and then the safe. Not that easy,
> > believe me.
> >
> > Second, Who said port knocking is like transmitting a password in
> > cleartext? Most modern PK systems are encryption based. An attacker
> > can sniff port numbers but packets usually contain other information
> > that is used for authentication.
> >
> > For example I use Aldaba Knocking Suite (aldabaknocking.com) which
> > provides Port Knocking and Single Packet Authorization.
> >
> > In Port knocking mode, basically the client sends this: [IP
> > Address][Port Number][Open/Close Flag][Checksum].
> >
> > That information is encrypted and sent encoded in the IP-Id field of 4
> > TCP-SYN packets. This way you have 2 forms of authentication: The
> > first is simple: you need to know the exact port numbers to use when
> > sending those TCP-Syn Packets. Second: you need to know a secret (the
> > encryption key) used to encrypt the information. If you don't have it,
> > you can send random data but when decrypted, it won't verify the
> > checksum.
> >
> > However, Port Knocking has some disadvantages and vulnerabilities. A
> > better and more elegant approach is SPA. Check it out. There are some
> > papers out there.
> >
> >
> > ..
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Dec 31, 2007 7:27 PM, Robert Inder <robertinder (at) googlemail (dot) com [email concealed]> wrote:
> > > On 29/12/2007, Ansgar -59cobalt- Wiechers <bugtraq (at) planetcobalt (dot) net [email concealed]> wrote:
> > > > On 2007-12-28 Jay wrote:
> > > > > Portknocking is a security mechanism as it is a type of
> > > > > authentication. "Something you know" in this case the sequence of
> > > > > ports to knock before a unstarted service or daemon begins listening
> > > > > for connections.
> > > >
> > > > Since everything is transmitted in the clear port-knocking is as much of
> > > > a security mechanism as cleartext passwords. Technically: maybe
> > > > (depending on your definition). Realistically: no.
> > >
> > > I think your dismissal of port knocking (and, indeed, plain text
> > > passwords) is unrealistic.
> > >
> > > If you can intercept my interaction with some remote server, you can
> > > steal the relevant secrets (the password or the sequence of ports).
> > >
> > > But isn't that quite a substantial "if"?
> > >
> > > How are you going to do it? Aren't you going to have to compromise
> > > some other machine, either where I am, or where the server is (or, I
> > > guess, where the relevant DNS records are), and then plant software to
> > > deliberately wait and watch until a relevant interaction takes place?
> > >
> > > I'm not saying that's impossible. But it would take considerable
> > > knowledge, planning and effort.
> > >
> > > Why doesn't that make it a substantial defence against most kinds of
> > > casual attack?
> > >
> > > Robert.
> > >
> > > --
> > > Robert Inder Interactive Information Ltd, Registered
> > > in Scotland
> > > 07808 492 213 3, Lauriston Gardens, Company no. SC 150689
> > > 0131 229 1052 Edinburgh EH3 9HH
> > > SCOTLAND UK Interactions speak
> > > louder than words
> > >
> >
> >
> >
> > --
> > Goldstein.
> > Room 101, Ministry of Truth.
> > W2, London. Oceania.

[ reply ]
RE: Port-Knocking vulnerabilities? Jan 21 2008 11:22AM
whip netspace net au (1 replies)
Re: Port-Knocking vulnerabilities? Jan 22 2008 12:26AM
Michael Rash (mbr cipherdyne org)


 

Privacy Statement
Copyright 2010, SecurityFocus