Category: Security
TightVNC Security Hole
Virtual Network Computing (VNC) is a graphical desktop-sharing system that uses the Remote Frame Buffer protocol (RFB) to remotely control another computer. It transmits the keyboard and mouse input from one computer to another, relaying the graphical-screen updates, over a network.[1]
VNC servers work on a variety of platforms, allowing you to share screens and keyboards between Windows, Mac, Linux, and Raspberry Pi devices. RDP server is proprietary and only works with one operating system. VNC vs RDP performance. RDP provides a better and faster remote connection.
There are a number of reasons why people use it.
There are a few VNC tools out there.
RealVNC
UltraVNC – Best one to use.
Tight-VNC – Security Hole
Tight-VNC has their encryption algorithm hardcoded into its software and appears they have NOT updated its encryption standards in years.
DES Encryption used
# This is hardcoded in VNC applications like TightVNC.
$magicKey = [byte[]]@(0xE8, 0x4A, 0xD6, 0x60, 0xC4, 0x72, 0x1A, 0xE0)
$ansi = [System.Text.Encoding]::GetEncoding(
[System.Globalization.CultureInfo]::CurrentCulture.TextInfo.ANSICodePage)
$pass = [System.Net.NetworkCredential]::new(”, $Password).Password
$byteCount = $ansi.GetByteCount($pass)
if ($byteCount –gt 8) {
$err = [System.Management.Automation.ErrorRecord]::new(
[ArgumentException]‘Password must not exceed 8 characters’,
‘PasswordTooLong‘,
[System.Management.Automation.ErrorCategory]::InvalidArgument,
$null)
$PSCmdlet.WriteError($err)
return
}
$toEncrypt = [byte[]]::new(8)
$null = $ansi.GetBytes($pass, 0, $pass.Length, $toEncrypt, 0)
$des = $encryptor = $null
try {
$des = [System.Security.Cryptography.DES]::Create()
$des.Padding = ‘None’
$encryptor = $des.CreateEncryptor($magicKey, [byte[]]::new(8))
$data = [byte[]]::new(8)
$null = $encryptor.TransformBlock($toEncrypt, 0, $toEncrypt.Length, $data, 0)
, $data
}
finally {
if ($encryptor) { $encryptor.Dispose() }
if ($des) { $des.Dispose() }
}
}
What this means is…IF you are using admin credentials on your machine while using Tight-VNC a hacker that is way better than I… Could gain access to your infrastructure by simply glimpsing the windows registry. Im sure there ways to exploit it.
I will demonstrate:
Now you can install Tight-vnc manually or via chocolatey. I used chocolatey and this from a public available repo.
Now lets set the password by right clicking tightvnc icon in the bottom corner and setting the password to an 8 character password, by clicking on change primary password and typing in whatever you like
‘Suck3r00’
Now lets open powershell without administrator privileges. Lets say I got in remotely and chocolatey is there and I want to check to see if tight-vnc is there.
As you can see I find this without administrator privilege.
Now lets say I was able to view the registry and get the encrypted value for tight-vnc; all I need to do is see for a few seconds.
Now there are tools online where you can convert that hexadecimal to binary decimal values long before AI was around. But since I love GPT im going to ask it to convert that for me
I have script that didn’t take long to put together from digging around for about an hour online. Which im obviously not going to share, BUT if I can do it……someone with skills could do pretty easy. A professional hacker NO SWEAT.
As you can see if you have rolled this out how dangerous it is.
Having said that I have also written an Ansible Role which will purge tightvnc from your infrastructure and deploy ultravnc which will use encryption and AD authentication. Which the other two currently do NOT do.
Hope you enjoyed getting P0WNed.
How to deploy Open-AKC(Authorized Key Chain)
Acting as a centralised trust management platform:
By allowing the “authorized_keys” mechanism on the hosts to be completely disabled, OpenAKC
permits SSH trust across an entire estate to be managed (with rich control and monitoring features)
centrally by “systems administration” or “information security” staff. This means that users, or
application developers etc. cannot add or remove trust relationships, effectively enforcing any
whitelist or approval process you might want to establish for the creation of trust relationships
within an estate.
A practical ‘Jump Host’:
Having worked in many Linux environments, the author of the software has seen a number of ‘jump
host’ solutions using dubious mechanisms such as “sudo” and others used to map users from AD or
LDAP directories to SSH trust relationships using shared private keys etc. and these solutions are
almost universally highly insecure.
OpenAKC implements a new approach and acts as an “drop in” upgrade for a legacy solution by simply migrating users to personal rather than sharedkeys with a “self service” key management mechanism. Requiring personal keys have pass phrases ensures increased security, and avoids ad-hoc automation from user accounts. The system provides rich control and monitoring features, while users can use familiar tools with little to no disruption to their workflow.
The problems everyone thinks about, but never finds a good solution.
The problem with joining every server to the domain:
◦ As soon as someone sudo’s to root. There is zero control on limiting what this root user can do. Which is a huge problem when getting compromised. Every key stroke is not logged and if you have multiple people sudo as root at the same time the logs can get blurry.
Well guess what….this is exactly what im talking about today. This architecture does take a few steps and time to understand its inner workings but security wise trumps anything out there currently being used by most folks.
This is a overview of a simplified architecture. This can be scaled out to new or legacy environment using many distros without interruption.
Combined jump host/security server architecture: This approach is generally used when it’s a small group managing things:
Benefits: The advantage here is your security server and your jumphost are on the same server. If you’re admin team is also managing the security then this approach is ideal because when diagnosing and editing role rules everything is in one place. Another key benefit… There are only couple client packages that are deployed on client machines upon deployment the client is already brought into the trust, so no additional work is required to bring it in.
Cons: If your jumphost goes down, so does your security server. Now this can be scaled out so there are two servers if one is unavailable it tries the second. But if you have one this could be a single point of failure. Keep in mind this is a VM and would takes seconds to bring back up, so durability is very good from a infrastructure stand point.
Or the alternative:
A Segregated jumphost/security server architecture: This approach is generally used when you have large groups and large infrastructure managing things.
Benefits: Now the advantage here is if you have a multiple groups and need to tighten the security. You can have a your security server and your jump hosts segregated. These two machines are the only two machines that talk you AD. You have roles setup on the security server. If your user is listed in the role on the security server and your apart the AD group that is allowed to login via ssh.
The security server will allow you to login as root via registered ssh keys. You can also strip away “roots” abilities, and every keystroke is logged per user on the security server. A key benefit here is that because the client machines are not joined to the domain. A hacker would never be able to determine information that leads to the heart of your network such as AD, the groups setup, and any of its users. The other benefit is the jump hosts are easily deployed as needed and ready to go if needed. Since the security stuff is not local, the jump host is also secured.
Cons: If your security servers are not functioning and you have disabled user/pass. You will be locked out unless you single user. However this is easily fixed by setting up a strong root/pass that can bypass all security and only give this to one person, such as your manager or someone in secureops. Which would be only used ever used in an extreme dire situation. I have yet to see this ever required once this is implemented correctly.
Special Features:
How to deploy Segregated jumphost/security server architecture:
Okay so the first thing we want to do is setup our security server host to Active Directory. The reason for this is we want to be able to setup centralised user management coupled with using authorised keys to jump to client machines.
Centos 7
Note: make sure you disable firewalld and selinux on your machine. Just a extra layer that not needed and only serves to tie your own hands behind your own back.
Install the following packages will be be using sssd/kerebros
[root@securityack1 ~]# realm discover AD.NICKTAILOR.COM
ad.nicktailor.com
type: kerberos
realm-name: AD.NICKTAILOR.COM
domain-name: ad.nicktailor.com
configured: kerberos–member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
login-formats: %U
login-policy: allow-realm-logins
it will ask you for the AD admin password, enter it and it should go to the next prompt. This step will create the all the necessary files /etc/sssd/sssd.conf /etc/krb5.conf /etc/smb.conf file you need.
yum install openakc-server
Example:
[nicktailor@security1 ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nicktailor/.ssh/id_rsa):
/home/tailorn/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nictailor/.ssh/id_rsa.
Your public key has been saved in /home/nicktailor/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:udhNKEp0txzfup7IxhUwNA+VSviWP1mu/aKPA5vZb3w tailorn@jumphost1.nicktailor.com
The key’s randomart image is:
+—[RSA 2048]—-+
| o+… |
| . ++. |
| . .oo=. |
| . . o=*… |
| . ..S.o=. |
| . . +.+=.. |
| . ..oBo= |
| .*.++= E |
| .o.**o+. |
+—-[SHA256]—–+
[nicktailor@jumphost1 ~]$ openakc register
OpenAKC Copyright (C) 2019-2020 A. James Lewis. Version is 1.0.0~alpha18-1.el7.
This program comes with ABSOLUTELY NO WARRANTY; see “license” option.
This is free software, and you are welcome to redistribute it
under certain conditions; See LICENSE file for further details.
Passphrase is requested to ensure you own this key.
Enter passphrase:
Escalating to perform API call
Connected to OpenAKC server. Sending key registration request
OK: Request processed
Here you will create a role block that will allow said user to jump to any client so long as your key is registered the openakc security server.
RULE=2020/01/13 19:17,2030/01/13 20:17,user,nicktailor
DAY=any
TIM=any
SHELL=/bin/bash
CMD=any
SCP=s,^/,/data/,g
CAP=cap_linux_immutable
REC=yes
FROM=any
RULE=2020/01/13 19:17,2030/01/13 20:17,group,linuxusers
DAY=any
TIM=any
SHELL=/bin/bash
CMD=any
SCP=s,^/,/data/,g
CAP=cap_linux_immutable
REC=yes
FROM=any
Note: The CAP section allows you to disable root abilities there is a long list of things. This particular one. Disables root from being able to edit any file with an immutable flag. So all your root users can not change these types of file eve as root.
You starting to see why this is how you do shit? Think for yourselves not because someone else said that best practice. Jeez…
Note: this is just a development setup I am doing for you. It can be scaled with two security servers using gluster of nfs to share the files system. This server will be what all the clients check with before allowing anyone to enter. They will need to first exist in AD and then their root key will need to be registered here, and then they will need to be allowed in the appropriate role and sssd and ssh groups before they can get in. This also eliminate the need to join any clients to the domain and protects against any hacker from being able to query the domain controller for user groups and if users exist. The would of also needed to get on to the jump host, have your key and also know your root passphrase. Unlikely going to happen
Okay now were going to setup the jumphost jump1.nickatilor.com
Note: You can have as many jumphosts as you like. This should be the only entry point to your servers. The jump host also talks to the security server. So even if you tried to go directly the server. You couldn’t since its only allowed from here. This is how you set shit up so you don’t end up like solarwinds and so many other idiots who follow rules old and out of date rule blindly.
Note: You also add this server to the domain. So please follow the joining of the domain setups from above and then carry on from here.
APIS=”nickack1.nicktailor.com“
PORT=”889″
ssh-copy-id –i ~/.ssh/id_rsa.pub root@192.168.1.200
[nicktailor@jumphost1 keys]$ openakc ping
OpenAKC Copyright (C) 2019-2020 A. James Lewis. Version is 1.0.0~alpha18-1.el7.
This program comes with ABSOLUTELY NO WARRANTY; see “license” option.
This is free software, and you are welcome to redistribute it
under certain conditions; See LICENSE file for further details.
Connected to OpenAKC server. Sending Test Run Ping Message
Test Run Response – OK: Pong! – from server – securityakc1.nicktailor.com
If you see that above that is a good sign
Now were going to add a client machine so you jump to it. This is the easiest part. So say you have a bunch of legacy systems and you want to centralise login without joining to the domain, you want everyone who using root to be tracked by logging every keystroke and logging what incident they logged in for to use root.
curl https://netlore.github.io/OpenAKC/repos/openakc-el7.repo | sudo tee
/etc/yum.repos.d/openakc.repo
vi /etc/openakc/openakc.conf
APIS=”192.168.1.200“
ENABLED=”yes”
PORT=”889″
CACHETIME=”60″
DEBUG=”no”
PERMITROOT=”yes”
AUDIT=”yes”
QUIZ=”no”
HIDE=”restrict”
FAKESUDO=”yes”
Note: Quiz if you set it to yes. When you log into root it will ask for a service now ticket number and description which will get logged on the security server.
That’s it!….
Now if you go back the jump host and try to log in
[@jumphost1 ~]$ ssh root@192.168.1.38
Enter passphrase for key ‘/home/nicktailor/.ssh/id_rsa‘:
OpenAKC (v1.0.0~alpha18-1.el7) – Interactive Session Initialized
[root@nickclient1 ~]#
This is session is now being logged and and you can not see if the user belongs to the domain
[root@nickclient1 ~]# id nickatilor
id: nicktailor: no such user
This is how you setup security like pro. Hope you enjoyed this.
Hope you enjoyed this.
Special thank you the author of the project “James Lewis” I enjoyed learning this and am a big fan of the innovation behind the open-akc project.
How to add new users:
That’s it your done. Now the new user is able to login into the estate via ssh from the jump host.
How to check if ports are open on an array of servers
Okay now there is a whole bunch of ways you can do this. This is just the way I played around with to save myself a bunch of time, using NCAT. Also previously known as NETCAT.
1.Ensure your Jumphost can ssh to all your newely deployed machines. Either you will use a root password or ssh key of some sort.
Note (ensure you have this install on all the new servers)
portcheckscriptnick.sh – this will check to see if your new server can talk to all the hosts below and check to see if those ports are up or down on each
============================
#!/bin/bash
host=”nick1 nick2 nick3 nick4″
for host in $host; do
for port in 22 53 67 68
do
if ncat -z $host $port
then
echo port $port $host is up
else
echo port $port $host is down
fi
done
done
========================================
Example:
Server1
Server2
Server3
Server4
6.Run the following below check the servers and see if each server can communicate with the hosts and ports necessary. If you see the are down. Then you will need to check the firewalls to see why the host is unable to communicate.
• for HOST in $(cat server.txt) ; do ssh root@$HOST “bash -s” < portcheckscriptnick.sh ; echo $HOST ; done 2>&1 | tee -a port.status
Note: the file port.status will be created on the jump host and you can simply look through to see if any ports were down on whichever hosts.
This is what the script looks like on one host if its working properly
[root@nick ~]# ./portcheckscriptnick.sh
port 22 192.168.1.11 is up
port 53 192.168.1.11 is down
port 67 192.168.1.11 is down
port 68 192.168.1.11 is down
This is what it will look like when you run against your array of new hosts from your jumpbox
[root@nick ~]# for HOST in $(cat servers.txt) ; do ssh root@$HOST “bash -s” < portcheckscriptnick.sh ; echo $HOST ; done
root@192.168.1.11’s password:
port 22 nick1 is up
port 53 nick1 is down
port 67 nick1 is down
port 68 nick1 is down
port 22 nick2 is up
port 53 nick2 is down
port 67 nick2 is down
port 68 nick2 is down
How to setup SMTP port redirect with IPTABLES and NAT
RedHat/Centos
Okay its really easy to do. You will need to add the following in /etc/sysctl.conf
Note: these are kernel parameter changes
kernel.sysrq = 1
net.ipv4.tcp_syncookies=1
net/ipv4/ip_forward=1 (important)
net.ipv4.conf.all.route_localnet=1 (important)
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.send_redirects = 0
It will probably look something like the rules below.
EXAMPLE
# Generated by iptables-save v1.2.8 on Thu July 6 18:50:55 2020
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2211:2804881]
:RH-Firewall-1-INPUT – [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp –icmp-type 255 -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 1025-m state –state NEW -j ACCEPT (make sure to have open)
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 443 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 8443 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 25 -m state –state NEW -j ACCEPT (make sure to have open)
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 80 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 21 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 22 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 106 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 143 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 465 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 993 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 995 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 8222 -m state –state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT –reject-with icmp-host-prohibited
COMMIT
#ADD this section with another Commit like below
# Completed on Thu July 6 18:50:55 2020
# Generated by iptables-save v1.2.8 on Thu July 6 18:50:55 2020
*nat
:PREROUTING ACCEPT [388:45962]
:POSTROUTING ACCEPT [25:11595]
:OUTPUT ACCEPT [25:11595]
-A PREROUTING -p tcp -m tcp –dport 1025 -j REDIRECT –to-ports 25
COMMIT
# Completed on Thu July 6 18:50:55 2020
[root@nick ~]# iptables -L -n | grep 1025
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:1025 state NEW
[root@nick ~]# iptables -L -n -t nat| grep 1025
REDIRECT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:1025 redir ports 25
Note:
You will need to run telnet from outside the host as you cant NAT to localhost locally. 🙂
[root@nick1 ~]# telnet 192.168.86.111 1025
Trying 192.168.86.111…
Connected to localhost.
Escape character is ‘^]’.
220 nick.ansible.com ESMTP Postfix