[syslinux] PXE and Security Issues

[Ryan McLean]

>I know this isn't the "philosophy of security" mailing list, but here's 
my 2 
>cents. ALL security is through obscurity. On average, it would take a 
fast 
>computer longer than the age of the universe to guess a 2048-bit key. 
>However, it is not impossible that you could guess the right key on the 
first 
>try. Same goes for all passwords, keys, filenames, etc....anything that 
>someone might need to get into a system...it's secure because it's 
obscure, 
>and ONLY because it's obscure!
>
>Larry

As HPA said.. 

Security through obscurity applies to things like, instead of ssh on port 
22 you put it on port 2222.
Anouther reason i am against security through obscurity is that for every 
port you remap you have to remember it / note it down or when you try to 
trouble shoot you are in for a very difficult time.

>Nothing short of an absolute firewall with no security flaws set to
>block ALL incoming and ALL outgoing ports is absolutely secure.
>Sometimes all you can do is combine the best things that work for you.

Why pay for a Firewall just pull out the LAN cable.. :)

>However, I must point out that just because MAC addresses can be
>changed does not make MAC filtering insecure.  They must know WHAT to
>change to.  Perhaps you can get this through sniffing if the traffic
>is unencrypted, but it can't be THAT easy to get it (meaning that your
>average employee isn't going to be doing this probably at the very
>least.)  If one does not know what MAC addresses are valid, then it's
>a 12 digit long hexadecimal code, which means it's not exactly
>something you can just guess at.

Actually any decent packet sniffer can pull the MAC address from the 
packets, as far as i am aware even encrypted packets leave the IP & MAC 
unencrypted, Esp in the case of wireless (try kismet).

>I'm not sure why you feel that way, but "security through obscurity"
>isn't some theological concept or theoretical but untested idea.  It's
>simple logic.  It works under this basic premise:  if a potential
>hacker does not know that there is something to hack, then chances are
>they aren't going to do it.  Take for example one of the most
>extremist ways of handling this, port knocking.  The firewall simply
>drops all traffic until certain ports are "knocked at" in a certain
>order.  All other traffic is simply dropped as if there is no computer
>there at all.  To a potential hacker, this may be crackable, but if
>they don't know a computer is there, they don't expend the time and
>effort needed to crack it.  Since there may not even be a computer
>there at all, they usually just move on to a system that does respond
>to what they are looking to crack. 

The main reason they drop the unsolicited packets is to prevent a DoS 
attack. If they inspected every packet it would be simple to overload them 
and render the users connection useless. Which can be just as rewarding 
(if used for extortion) as successfully gaining root on an internal 
machine.

>The fact is, if they set their 
>mind to it, a good hacker is probably going to get in if you set them
>a challenge

Couldn't agree with you more.

>Really it's just simple logic that there is security in obscurity.
>Just as gravity exists whether you believe in it or not (even if we
>may not yet fully understand its nature) no amount of denying it will
>make it go away.  Now I'm not saying that "security through obscurity"
>is the answer to everything, just that it is a potential concept to
>explore a question of security comes up.  In this particular case,
>there are some holes in the idea I had, which is why I only barely
>mentioned it and mentioned it last.  Actually, I must point out that
>all good firewalls follow the security through obscurity concept to
>some extent already by dropping unsolicited traffic and detecting port
>scans such that a potential hacker may think there is no system there
>at all.  Mind you, they still allow solicited or seemingly solicited
>traffict through, so it's obviously not perfect, but my point is that
>they already rely on such a concept to increase security somewhat.
>Who today still wants one of those old cheap firewalls that would
>simply refuse unsolicited traffic, waving a big red flag to any
>scanners?

Again a decent portscanner will still tell you which ports are available, 
(try nmap with different setting combinations).
You can assertain if a computer is present by watching the network traffic 
(wireshark).

>The biggest problem with my idea here, if it's just a simple matter of
>a kernel and initial ramdrive, then anyone can look on the simple-FTP
>server (which doesn't have much by way of access controls) and see the
>filenames of each.  Only if something more complex must be entered on
>the command line will it work -- something they can't just see by a
>simple file list.  In perhaps the best example, one might modify the
>inital ramdrive's startup scripts to look for a password on that
>command line, then produce a misleading error if it is not correct
>(say a complaint about some hardware problem for example -- something
>that might just look like a standard problem with an old outdated
>kernel or something.)  You could even set it up to store and compare
>that password with a more complex hash than SHA1 because you are in
>control of what is done once control has been passed from PXELinux to
>the kernel.  While it's possible to disect even that, a person would
>have to think that there is a reason to examine it up closely before
>they will do so and even then there is at least some small possibility
>that they could just accidentally pass right by the modified section
>if it looked harmless enough at first glance.
>
>It's not perfect, but like with trying to open a hole on a dam, the
>moment you open one, however small, you stand the risk of it widening.

As to the original disscussion, the problem here is that were are 
discussing a tftp server so the following sequence of events happens 
(generally).

Computer joins network and broadcasts for address
DHCP server responds with IP lease & address of tftp server (so now we 
know that they both exist)
Comptuer "talks" to tftp server
tftp responds..

So basically though packet sniffing for certain packets we get the 
addresses of the client and the tftp server. 
>From there we filter all our traffic for these 2 only. 
And the packets will contain all the info such as passwords etc 

Obv thats a very much simplified attack but it show how easy it is to 
initate. I would point out while I haven't looked at the SHA-1 crack i am 
assuming that t works on the same principle as the WEP crack (gathering 
enough packets to preform a bruteforce based on the packets encryption 
pattern) To gather enough packets from a tftp transaction would be alot 
more time consuming to the point of being almost a waste of time.

>Unfortunately, in the case of security, a small hole must be opened,
>so no solution will ever be 100% perfect probably.

Agreeed.
Unfortunatly there is no such thing as totally secure, just a combination 
of "secure enough" and damage limitation.
Even an off network pc in a locked room can be hacked.. you just need to 
break into the room first.. :) and it wouldn't be useful. So we trade 
security off against usefulness.


Regards,


Ryan McLean
Systems Administrator
Email: ryanm at accelrys.com
Tel: +44 1223 228632
Ext: 8632