Security within LAN

[Wognath]

Someone on the MXLinux forumasked if it's possible to set up a guest account with no password. One of the replies said:

If your PC is plugged into any network... and you have an open account, anyone with access to that network has free and open access to your machine.

Ok, I have no interest in an open account, which they said is impossible anyway, but that reply implies that a password is the only thing preventing easy access to another computer on a LAN.

How would that "free and open access" theoretically be obtained?

Suppose someone in a coffee shop has my username and password. They could log in remotely if I obligingly turn off firewall and start ftpd or telnetd. But suppose no server is running; is access still easily possible? How?

I make a new 32-character password and keep it secret this time. Is access still feasible?

someone sitting on the street with the requisite hardware & software & knowledge can easily access your device, especially if you leave a simple open account.

Easily??!!

Thanks for any information. I want to be just paranoid enough.

[s243a]

I would do it by giving them only access to a whitelisted set of websites, and I would set up a local vpn that has access to the wider internet.

Also, I would look for some kind of firewall (and/or intrusion detection system) that could detect malicious activity (both internal to the network and external). Finally, I would consider anonymizing their traffic via a VPN or proxy so that any bad things they might be up to wouldn't be associated with the primary external ip address used. I would also restrict the bandwidth for anyone not on the private VPN.

Also do not use any low budget router or network switch as they are prone to exploits and backdoors. For info on how to exploit such devices look up routersploit.

[Wognath]

s243a, thanks for the reply. To narrow my question, I'm thinking of public wifi, where I have no control over the router. But that routersploit site is very interesting.

[rufwoof]

No security to connect to a LAN via wifi, opens up that LAN to potential drive-by scanners (drive around trying to connect to Wifi's and some may have no security).

Access to a local LAN means potentially seeing, or changing the content of packets flowing around that LAN, which includes inbound/outbound flows. https goes some way to avoid tampering/monitoring of contents, however https requires a initial unencrypted 'hello' handshake process to set up the encrypted connection(s) which are open to potential establishment of a man-in-middle attack. Which could reveal the userid/passwords you use to access sites (despite seemingly being via a encrypted connection); Or for cracks to be inserted into what your browser sees/runs that may exploit flaws that open up the PC (if for browser X receiving Y opens up remote control a m-i-m could inject that Y action that enables a unwanted something else to be run on your PC. That something else may be a simple repeated sending of connection requests to a crackers server, and running the commands sent in the response, that being locally originated traffic isn't blocked). Doesn't take long to reveal what's installed/running etc. and for the responses from the crackers site to be refined according to what is installed/running. Typically with a view for the cracker to install something else that is hidden away and that persists across reboots (change MBR, bootloader ... whatever) and to propagate/install onto other systems on the same LAN. If for instance a cracker can modify the router to redirect flows via servers they control, then all systems using that same common router are subject to potential m-i-m. Your browser might look to connect to xyz.com for instance via a encrypted connection and send a hello packet, that instead of the desired real xyz.com initiates a connection to the crackers server, that then also connects to the real xzy.com web server and returns the response received back to your PC, perhaps with modifications that might exploit the browser being used, whilst also seeing any userid/passwords that you might be sending out.

For ssh where keys have already been set up, you can't m-i-m that and as such is more secure than https (at least in the more commonly used https manner). Similarly if you boot from usb and then that usb is removed once booted (run in ram), then that session cannot modify the bootloader/etc. Could however modify the save file/folder content, unless that also were being stored on the usb (and you only ever boot a clean session, make configuration changes and then saved those changes and removed the usb before going online).

Browsers are a common attack vector. They change over time and changes might fix one bug, but introduce other bugs, and security bugs are just normal bugs but that open up security weaknesses. Most versions of browsers have security flaws/bugs and as in how virus scanners keep records of known viruses, so crackers keep records of known security bugs/exploits for each browser/browser-version. In that context, given browser X having a exploit Y already known, and open access to a LAN, then a crackers task can be 'easy'. A case of having the right tools to hand making tasks easy - that otherwise might be relatively difficult.

[Wognath]

Thanks!

For https, when on public wifi I follow the protocol of http://www.grc.com/fingerprints (Trust if EV, otherwise verify the certificate fingerprint). So I believe m-i-m is precluded.

[s243a]

Most versions of browsers have security flaws/bugs and as in how virus scanners keep records of known viruses, so crackers keep records of known security bugs/exploits for each browser/browser-version. In that context, given browser X having a exploit Y already known, and open access to a LAN, then a crackers task can be 'easy'. A case of having the right tools to hand making tasks easy - that otherwise might be relatively difficult.

Just for anyone reading. This is called a CVE scanner:
https://resources.infosecinstitute.com/ ... rs-2/#gref
https://www.cvedetails.com/

[s243a]

Thanks!

For https, when on public wifi I follow the protocol of http://www.grc.com/fingerprints (Trust if EV, otherwise verify the certificate fingerprint). So I believe m-i-m is precluded.

What does "Trust if EV" mean?

[s243a]

Suppose someone in a coffee shop has my username and password. They could log in remotely if I obligingly turn off firewall and start ftpd or telnetd. But suppose no server is running; is access still easily possible? How?

I make a new 32-character password and keep it secret this time. Is access still feasible?

someone sitting on the street with the requisite hardware & software & knowledge can easily access your device, especially if you leave a simple open account.

Easily??!!

Thanks for any information. I want to be just paranoid enough.

and

s243a, thanks for the reply. To narrow my question, I'm thinking of public wifi, where I have no control over the router. But that routersploit site is very interesting.

You might not intentionally have any network services open but perhaps some application has a network service open that you don't know about.

You could try port scanning your machine (e.g. tool: nmap).

Anyway, I suspect not all your connections are ssh connections. For instance are you using an ssh connection to your dns servers? I recall an exploit that could work over a dns connection.
https://github.com/vincentcox/bypass-fi ... /README.md
https://blog.fbkcs.ru/en/a-loophole-in- ... XdwyPKxHCM

Thanks!

For https, when on public wifi I follow the protocol of http://www.grc.com/fingerprints (Trust if EV, otherwise verify the certificate fingerprint). So I believe m-i-m is precluded.

I'm not expert on ssh but what if some rouge application compromised your fingerprint verification system? rufwoof, suggests a browser exploit. I'm just guessing here.

[belham2]

Thanks!

For https, when on public wifi I follow the protocol of http://www.grc.com/fingerprints (Trust if EV, otherwise verify the certificate fingerprint). So I believe m-i-m is precluded.

Hi Wognath,

Just logged to say "thanks" for that to grc's fingerprint. Of all the stuff I've read over the years, that was/is the most straight-forward, clear explanation I've seen regarding certificates and the world wide web's function.

Wondering if a little script could be written where it picks up the fingerprint (using grc's site) and then compares it against the site your browser's on (which, I think, means you'd have to be accessing that browser's API, so it essentially it would be an add-on). Or something along thse lines......still, it provides another assurance that the sensitive site you want to make sure you've arrived to IS in fact that very site (and not a spoofed one).

This dovetails very nicely with a question I posted a few weeks back recently on here about DNS redirects (the absolute bane of the Internet, now and going forward).

Anyhow, thanks again!

[rufwoof]

A keys based ssh connection is safe from m-i-m ... provided the private key is secure. When a pre-arranged/installed public/private key pair has been set up then a m-i-m cannot pretend to be you without also knowing the private key. ssh connections that use a password entry are subject to m-i-m hence the common advice to use keys instead. To protect those keys typically there in a folder with the correct permissions set (most often questions about 'my ssh link isn't working' is a consequence of wrong permissions of the .ssh folder/files), and where a password is entered in order to access the keys (some opt to set no password for 'convenience' and as such risk having their keys more easily stolen/revealed).

Fundamentally its a case of pre-validation between two parties enables a secure communication between those two parties to subsequently occur in a manner where a m-i-m cannot spoof you without also knowing the private key element. If the private key however isn't private, but known to a m-i-m then its game over.

In Puppy for instance saves may be stored in a single file system file, that include your key. Those keys might be encrypted and require a password (or more casually not), such that grabbing a copy of that single file could potentially have private keys opened up. The save file content might also be loaded into ram, so that gaining access to ram again might enable private keys to be exposed. Running a browser as root simplifies that, but running as spot can also be as good as not having bothered in many Puppy's as spot to root elevation can be trivial.

Security is a nightmare, has to be secure 24/7 and just a single weak point instance at any time could have resulted in the entire security network having been compromised. A lot of hard work and inconvenience to in practice have achieved nothing. Travel through a typical London airport for instance and every passenger goes through numerous security checks, whilst potentially that might all be circumvented via pressuring a baggage handler to bypass all of those security measures.

Running a Puppy, the correct way is more a reversal of the more common security practices. Puppy can be booted 'clean' (as through pristine factory fresh) at each reboot, loaded into ram and the boot/save medium removed (disconnected), such that it cannot be remotely cracked (next boot will also be clean). That alone is vastly better than having a PC that's been used 24/7 for months and that at any one point in time might have been compromised. Yes individual Puppy sessions could be compromised, but if booted clean to then go directly to your bank web site, nowhere else before or after, and cleared out afterwards (not leaving any remnants) then that connection most likely was safe/secure. For other sessions, online userid/passwords might be 'stolen', but equally entire sets of userid/passwords might have been stolen from servers.

For me, the 'just paranoid enough' is to run Fatdog, booted via a usb, disconnecting the usb after booted, and using the multi-session save option (that facilitates the usb being unplugged between saves) with the saves also being stored on the same usb (so have to reattach the usb again to make a save). And where you strive to keep that 'clean' (generally boot and use a session without saving, but when you want to make changes then boot clean, make changes, save, and then remove the usb and continue to use the session as normal but not save at the end of that). That requires all data be stored outside of 'Puppy space', bookmarks, data etc. and maintaining disconnected backup copies of that data, along with storing it in encrypted form in case the laptop is stolen (I have a single DATA folder on HDD beneath which all data is stored, and where a fatdog rox right click menu option has the options to open/close that data folder). I store my calendar and .ssh (keys) in separate encrypted folders, that are only opended up when needed, closed again afterwards (for ssh links the ssh keys are only required for the duration of actually making the ssh connection, once connected the keys are no longer required). More ideally, sensitive files/folders would be better protected if stored on a separate usb stick to the one that is used for booting, that was only plugged in for the duration of being required, unplugged again afterwards, but in comparison to how vastly better the arrangement is already compared to others I personally don't bother with that additional inconvenience.

[rufwoof]

I'm not expert on ssh but what if some rouge application compromised your fingerprint verification system? rufwoof, suggests a browser exploit. I'm just guessing here.

Browsers are a weak point (common attack vector), but so also are software bundles - getting you to download/install something 'attractive'. Part of the Unix philosophy strength was being limited/restricted to using single trusted repositories. The core Debian MAIN repo for instance is considered clean, drift outside of that however, adding contributed/others repos ... and the trust is broken.

[rufwoof]

Puppy's tend to come with all inbound ports closed by default. If however you open up something like a ssh port (server), then quite quickly you'll see a barrage of attacks. Not so much they're looking to penetrate your system, but rather in gaining access to your perhaps poorly configured ssh server setup that can reveal your private keys ... that opens up other servers. A gateway to secure a command line access on more attractive servers, and where the blame for anything untoward as a consequence of such access points back to you (your userid/keys having been used to seemingly 'initially' connect).

[s243a]

Puppy's tend to come with all inbound ports closed by default. If however you open up something like a ssh port (server), then quite quickly you'll see a barrage of attacks. Not so much they're looking to penetrate your system, but rather in gaining access to your perhaps poorly configured ssh server setup that can reveal your private keys ... that opens up other servers. A gateway to secure a command line access on more attractive servers, and where the blame for anything untoward as a consequence of such access points back to you (your userid/keys having been used to seemingly 'initially' connect).

I'm thinking that we might have other services open such as ARP and dhcp. A lot of pubblic WIFI requires one to connect to a non secure http server to gain access to the public WIFI. One might be able to man in the middle this intial conneciton point using arp poisoning. This will do two thing. It will give the attacker an attack vector via the browser. It will also allow the attacker to passively monitor for open ports such as might be opened for a chat program (as an example).

[Wognath]

Thanks for the replies. They will take me a while to digest.

What does "Trust if EV" mean?

Gibson says "Extended Validation [EV] certificates are COMPLETELY SPOOF PROOF!"

... that was/is the most straight-forward, clear explanation I've seen regarding certificates...
Wondering if a little script could be written where it picks up the fingerprint

I've found grc.com to be very useful (though wordy). I've been using his fingerprint checker for some time and assume I'm safe from m-i-m. I hope
Regarding script, for me it's reassuring to check the certificate myself. I wish all browsers would allow viewing the SHA sum without going through a maze :/ (Firefox: 4 clicks, vivaldi: only 2 clicks)

[rufwoof]

Ok, I have no interest in an open account, which they said is impossible anyway, but that reply implies that a password is the only thing preventing easy access to another computer on a LAN.

How would that "free and open access" theoretically be obtained?

netcat in busybox would suffice

Code: Select all

while :; do
   nc -l -p 8899 -e /bin/sh
done

which just repeatedly loops around listening (-l) for connections on port 8899 (-p ... pick whichever port number you like), and when a connection occurs it executes (-e) ... in this case /bin/sh (command line).

Run that script and then connect to it with

Code: Select all

nc localhost 8899

They'll be no $ or # prompt, it will just sit there, but if you type in a command such as ls ... then it will return the results from that command.

That assumes your firewall isn't blocking that port. Or if you're "outside" of the local LAN you'll have to use the external IP to connect to it .. and the router will have to be set to permit that port traffic through (port forwarded).

You can also set telnet, or ssh to be passwordless. passwd -d <userid> removes the password from a userid. So if telnetd or sshd are running (listening) for a particular port/userid and the password for that userid isn't set, then they'll log straight in.

More usually you wouldn't be that daft if the command being run was /bin/sh, instead you'd write a shell script to restrict what anyone connecting could do.

If for example you created a executable script called /home/spot/BBS with the following content

Code: Select all

#!/bin/bash
_trycmd() 
{ 

  case "$ln" in
	ls) ls | more;;
	exit|quit|bye|q) exit ;;
	clear|cls) clear ;;
	*) nf=`echo "$ln" | cut -d' ' -f1`; echo "$nf :not found" ;;
  esac 
} 

clear
echo "Hello"
while echo -n "$ " && read ln 
do 
	_trycmd "$ln" 
done

and for user spot you changed its shell to /home/spot/BBS in /etc/passwd, i.e. changed it from something like
spot502:502:Spot the Happy Dog,,,:/home/spot:/bin/sh
to
spot502:502:Spot the Happy Dog,,,:/home/spot:/home/spot/BBS
then any time spot was logged into it would run the above script, which contains it to running just a few commands/actions.

Using nc as the server is the easiest, closely followed by using telnetd (and telnet to connect). sshd is more awkward (but still relatively easy) to set up. A cracker once into a system/LAN might set up reverse versions of nc/telnet/ssh, so that the traffic originates from inside the LAN, and once connected to their external box they can control the compromised box directly from their box without having to generate any 'in-bound' originated traffic that firewalls/routers strive to block. A form of crack where the cracked box is in effect asking 'what command do you want me to run' and the cracker can reply 'cat /etc/passwd' ... or whatever, and then see the results from having run that command.

[Packetteer]

Hi All
If you find grc.com interesting and helpful might I suggest you go the
following URL

https://www.twit.tv/shows/security-now

Steve Gibson does a weekly Pod cast on Leo Laporte's TWIT network Titled
Security Now.

Best Regards
John

[Burn_IT]

I did a quick scan of the thread and I didn't see any mention of a PRIVATE FIREWALL.

Now I don't use Linux all that often and never when I am away from home, but in Windows I use a private firewall on my PC even at home since I often allow guest access via my router, and pretty much ANY modern smartphone could be used for hacking.