The crypto-policy that comes with Red Hat Enterprise Linux 9 and AlmaLinux 9 does not allow RSA key sizes below 2048 bit. Some legacy SSH servers are configured with 1024 bit key sizes though which will result in connection failures:
# ssh username@servername.example.com
Bad server host key: Invalid key length
Trying to find the issue using ssh -vvv, you would get:
OpenSSH_8.8p1, OpenSSL 3.0.5 5 Jul 2022
debug1: Reading configuration data /home/geeklab/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /home/geeklab/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Reading configuration data /etc/ssh/ssh_config.d/99-jxs.conf
debug1: Connecting to servername.example.com [1.2.3.4] port 22.
debug1: Connection established.
debug1: identity file /home/geeklab/.ssh/id_rsa type 0
debug1: identity file /home/geeklab/.ssh/id_rsa-cert type -1
debug1: identity file /home/geeklab/.ssh/id_dsa type -1
debug1: identity file /home/geeklab/.ssh/id_dsa-cert type -1
debug1: identity file /home/geeklab/.ssh/id_ecdsa type -1
debug1: identity file /home/geeklab/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/geeklab/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/geeklab/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/geeklab/.ssh/id_ed25519 type 3
debug1: identity file /home/geeklab/.ssh/id_ed25519-cert type -1
debug1: identity file /home/geeklab/.ssh/id_ed25519_sk type -1
debug1: identity file /home/geeklab/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/geeklab/.ssh/id_xmss type -1
debug1: identity file /home/geeklab/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: compat_banner: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000002
debug1: Authenticating to servername.example.com:22 as 'root'
debug1: load_hostkeys: fopen /home/geeklab/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_GROUP received
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: SSH2_MSG_KEX_DH_GEX_REPLY received
Bad server host key: Invalid key length
While the best solution would be to fix the key size of the target server, this is not always possible on embedded devices. For those devices, you could alternatively make a change to your ~/.ssh/config file:
One of my customers is still using a very old library for iDeal online payments.
It's old, but it's also really stable. Or rather, was stable. Until today. Today I tried to switch that customer from ideal.secure-ing.com to the new ideal-acquiring.ing.nl. That didn't go so well.
The switch itself was pretty simple. Change the merchant ID, do a little chair dance with the SSL certificates and change the hostname. Unfortunately, that turned out not to be the full fix.
ING Bank kept returning this very useful error message "System generating error: Acquirer":
<errorCode>SO1000</errorCode><errorMessage>Failure in system</errorMessage><errorDetail>System generating error: Acquirer</errorDetail>
According to the iDeal manual, the Acquirer is the bank of the Merchant (=webshop). So when the website I'm working on is connecting to their bank, the bank basically says in their message that they themselves are having a technical issue. For several hours, both on the live environment and on sandbox environment. Sounds a bit unbelievable to me.
As a external consultant I cannot call the bank for help, I'm condemned to use public resources and spend a lot of time to find the issue here.
Took me several hours of trying to change certificates, changing the Merchant ID and other parameters, but nothing helped. Until I noticed the library this customer is using opens it's own connection to the bank:
Could it be that the new environment requires different/more secure SSL/TLS? I did a tcpdump on the network and opened the dump in wireshark. The connection was using TLSv1.2, nothing to worry about.
Hey, that's weird. HTTP/1.0, did we not abandon that protocol 20 years ago? Could it be that using an old protocol blocks the whole transaction? Turns out I was right. I replaced the whole function to use curl, and the problem was instantly fixed:
That's it. For now. At some moment I'll probably advise this customer to change to a more modern iDeal lib.
I'm a bit annoyed though. The bank could give an answer that's more indicative of the problem. How hard is it for the ING Bank to always include a reason if the request gets past the webserver to begin with? The error message was digitally signed with a SSL-based XML signature, which I think means the backend application could have done better.
It has been annoying a lot of people for a long long time: Ubiquiti's unwillingness to fully support multi-VLAN networks on all of its products. And their constant push towards "the cloud", a nice marketing term for "another persons computer". Ubiquiti has a great set of products. But if you like to stay away from the cloud and don't want to create a ui.com account, some functions are hard to get to work or just don't work at all.
This is especially annoying with the CloudKey Plus, a device that runs the management software for your network AND a NVR (Network Video Recorder) named "UniFi Protect" at the same time. You should always isolate network management from normal users, but in the case of the CloudKey Plus that also limits access to Protect.
"With the UDM-Pro, can I assign the applications their own IP address? For example, can the UDM-Pro/network app be on a different subnet than the Unifi Protect app? I prefer to keep my network devices on a different subnets than my cameras."
"The new feature of Offline Access from the mobile apps is great, but in our case we have some separate networks for wireless, protect, computers and several remote sites. It doesn't make us sense that the direct connection works only on the direct subnet having routing enabled between the subnets. [..] From the security point of view, it could expose a 'risk' having a phone beaconing the IPs of the protect devices, but I think that can be acceptable or have switch to enable/disable the feature on the NVR Unifi OS."
When someone else mentions the topic is so silent, _Space responds:
"I dont think the lack of reply is due to people having flat networks, I think it is many people just giving up.
As they say at work, no horse is too dead to beat... but this topic has been beaten to death... People BEG for the ability to use protect from a mobile device, no cloud and point to an IP. maybe port forwarding, maybe vpn, maybe just on the local LAN... lots of scenarios.
UI is aware of what people are begging for.
BUT, UI has a plan. they wont tell anyone what it is and the are determined to keep their cloud in the mix."
Let's see what we can accomplish.
My network setup
For this article, my network will be set up as follows:
EdgeRouter 12
Multiple UniFi switches
CloudKey Plus (UCKP)
G4 Bullet camera
VLAN4 = 192.168.4.0/24 = management VLAN that contains the camera but also the CloudKey Plus (UCKP). This VLAN is on switch0.4 of my EdgeRouter.
VLAN5 = 192.168.5.0/24 = LAN, where my laptop and phone are connected. This VLAN is on switch0.5.
Failed attempts to get the Unifi Protect app to connect to the console
The Ubiquiti Protect app scans the local network by sending out a broadcast to 255.255.255.255 on udp port 10001. If there only was a way to relay that message to another VLAN, the app might be able to detect the Protect appliance.
First I looked to see it my EdgeRouter 12 supports forwarding of broadcast packets, but I haven't found a built-in way to do that. In Odi's astoundingly incomplete notes I found an interesting alternative, using iptables' TEE target. The command to run would be:
iptables -t mangle -A INPUT -i switch0.5 -d 255.255.255.255 -j TEE --gateway 192.168.4.255
Unfortunately, my EdgeRouter does have the libxt_TEE.so required for this, but lacks the corresponding kernel modules to make this target work.
I then found a post that claims to have a way to use iptables' PREROUTING redirect a packet for 255.255.255.255 to a specific address on another VLAN. According to that page, I should be able to route Ubiquiti's discovery packets to my CloudKey using the following command:
I don't see anything wrong with this, but still it does not work. I'm not sure, but I think the global broadcast address 255.255.255.255 may be explicitly excluded from forwarding by the Linux network stack.
Another suggestion I found, was to install ubnt-bcast-relay which is based on udp-broadcast-relay. By installing this software on your edgerouter, you can easily relay packets from one network to another. This may be a useful method for some people, but personally I don't feel like running third-party software on my router. Also, I'm not sure this will work as the EdgeRouter itself is listening on udp port 10001.
How I connected my app to the Unifi Protect server
I could not find a satisfying software-based solution for this issue. The best option would be for Ubiquiti to just add a text field in which you can type an IP, but they won't. Setting up a temporary Network Bridge between VLAN4 and VLAN5 could help the app to connect to the Protect NVR, and then remove the bridge again. This is a bit risky, because adding the interface you're connected to to a bridge will make you lose your connection.
Instead, I chose to set up a "hardware bridge": a simple network cable. On one of my switches, I picked two unused ports, set one to VLAN4, the other to VLAN5. Disabling Spanning Tree Protocol for the ports is a requirement, or the ports will quickly go into blocking mode. Then I connected a UTP cable between them, letting all traffic flow between VLAN4 and VLAN5. I set up the protect app and 30 seconds later I removed the cable and reversed the settings.
Yay! We got a working app! Or do we....?
We got the app set up, but I doubt we actually got a long lasting solution. At least not if you're trying to get your Unifi Protect to work over a VPN. Even now we can connect cross-VLAN or over a VPN, the app is flaky at best.
The very first time I tried to access my camera's via VPN over a 4G connection, the Protect App began to stutter. And complain about how "Some VPN networks may cause connectivity issues".
Yes, some VPN networks may do that. But I manage my own, and it's set up well. Why does Ubiquiti actively try to scare people away from VPNs?
Right after the message above, the connection is magically lost. And then the UCKP is grayed out and becomes unusable.
Unfortunately for Ubiquiti a few tools let us see right through their bullshit. Using any browser on the phone, we can still connect to the CloudKey just fine. Also, tcpdump shows traffic is just fine. The app sometimes works for a short while, then without any good reason loses connection to the UCKP. And there seems no acceptable method to get it back to work.
Once the UCKP is grayed out, the only way to get it back, is to log off the whole app and re-discover the CloudKey. Not even reconnecting to the original wifi gets it back online if VLAN4 and VLAN5 are not directly linked to each other.
It seems that the app constantly wants to keep re-discovering the UCKP, and if it can't, it will stop functioning.
My suggestion is to stay away from Ubiquiti camera's.
After hours of trying, I'm done with it. I have deleted the UniFi Protect app from my phone. And I'm returning the €190 camera to the webshop. For my office, I'll probably end up with another brand that does respects its customers' wishes.
I did not test this, but I figured it could be useful.
A dirty solution for discovery
A dirty solution that could help out, is to use socat to tunnel the connection. Then you'd have to change the source ip as well. I just came up with this solution, but have not tested it yet:
A Hexadecimal color code looks like #ff7f00. This means:
red: ff hexadecimal = 255 decimal
green: 7f hexadecimal = 127 decimal
blue: 00 hexadecimal = 0 decimal
And that will generate a orange color with hex value ff7f00.
One can think of several very difficult methods to generate 3 numbers between 0 and 255, then concatenating their hexadecimal values. But there's a much easier way.
Since the string is formatted as a 6 character string, the value of which is between 000000 and ffffff (hex), you could just pick any random value between 0 and 16777215 (=hex ffffff) and convert that to a hex string.
Both of these lines will generate a random Hex Color Code:
While installing Microsoft SQL Server on a VMWare, I had this error:
"This SQL Server setup media does not support the language of the OS, or does not have the SQL Server English language version installation files. Use the matching language-specific SQL Server media, or install both the language specific MUI and change the format and system locales through the regional settings in the control panel."
I found a lot of possible solutions, especially those on https://www.ryadel.com/en/sql-server-2017-setup-install-error-oops-language-not-supported-rules-fix/ looked promising. But they did not work in the end.
The solution turned out to be mounting the iso file locally on the target machine. SQL Server comes as a .iso file. If you mount that via VMWare CDROM emulation or via a network share, you'll run into problems installing. But copy the iso to the target machine and double click it, then you can run setup.exe without problems.
A lot of people are complaining about being unable to (re)install Logi Capture, the software that comes with modern Logi (formerly known as Logitech) webcams.
The complaints
For example, Sasha says: "Logi Capture Version 2.06.8 will not complete installing on my Windows 10 PC. The .exe file immediately jumps to a "Restart Required" screen, and upon reboot nothing happens. Have cleared regisistry and removed all other logitech files.", to which the customer support gives an answer that indicates they didn't even read the question.
Michael says: "can't install Logi Capture software for my Brio anymore. I get the restart required splash screen after clicking the exe. Restart doesn't solve the issue. Cleaning up the registry doesn't help either. using Win 10 (1909)"
And Jason says: "I just uninstalled Logitech Capture 2.00.226 from my Windows 10 64bit. Then I went to install it again as an Admin, but I now get a window telling me, Restart Required - "Restart is required to continue with LogitechCapture installation." I have followed this process 3 times, with no installation complete. FYI- I have Skype for Business and ZOOM installed on my machine. Skype and another Softphone client that has video conferencing login upon startup."
I think I figured out how to fix this issue. I first installed version 2.08.11, which has some bugs. After removing that version, I ran into the same message trying to install version 2.06.12. Restarting the computer didn't fix anything.
My analysis
It seems that when uninstalling LogiCapture, the old version leaves uninstall instructions in the registry, the LogiCaptureSetupNeedReboot key in the RunOnce section to be exact. The installer expects Windows to run a command based on that, and then remove the data from the registry. It is normal for uninstallers to do such a thing, but Logi has done it wrong: when you're running a 64-bit computer, it writes to the 64-bit registry. Apparently, Windows doesn't even look at the 64-bit version of the registry for RunOnce entries. Therefore, after uninstalling the software from a 64-bit computer, you can never reinstall Logi Capture anymore.
My fix
Fixing this issue is simple. Just remove the wrong entry from the registry
click start type "cmd" and then press ctrl+shift+enter to run cmd as administrator then in the command line screen, type:
After this, I could start Capture_2.06.12.exe or Capture_2.08.11.exe to reinstall Logi Capture.
Please use these tips at your own responsibility.
The real fix
Of course, Logi should fix this in their installer/uninstaller. But given that version 2.08 introduced an annoying message in big red letters to push you away from Logi Capture to another product, I don't think we'll get a real solution soon.
Apart from changing the rwxr-xr-x like permissions, some Linux filesystems have another way of protecting files. You cam make them IMMUTABLE, after which no program can change them. Not even if you have the right permissions. Python however does not support reading or writing the immutable attribute.
Inspired by yellowcrescent, I just wrote the following code snippet for my own use:
# Code from geeklab.info
import fcntl
from array import array
# FS constants - see /uapi/linux/fs.h in kernel source
# or <elixir.free-electrons.com/linux/latest/source/include/uapi/linux/fs.h>
FS_IOC_GETFLAGS = 0x80086601
FS_IOC_SETFLAGS = 0x40086602
FS_IMMUTABLE_FL = 0x010
def chattri(filename: str, value: bool):
with open(filename,'r') as f:
arg = array('L', [0])
fcntl.ioctl(f.fileno(), FS_IOC_GETFLAGS, arg, True)
if value:
arg[0]=arg[0] | FS_IMMUTABLE_FL
else:
arg[0]=arg[0] &~ FS_IMMUTABLE_FL
fcntl.ioctl(f.fileno(), FS_IOC_SETFLAGS, arg, True)
def lsattri(filename: str) -> bool:
with open(filename,'r') as f:
arg = array('L', [0])
fcntl.ioctl(f.fileno(), FS_IOC_GETFLAGS, arg, True)
return bool(arg[0] & FS_IMMUTABLE_FL)
f="/root/testfile"
print("Yes" if lsattri(f) else "No")
chattri(f,False)
print("Yes" if lsattri(f) else "No")
chattri(f,False)
print("Yes" if lsattri(f) else "No")
Use it as you like, at your own risk. If possible please link my website.
Keep in mind that only users with root-access can change file attributes.
Yesterday, one of my customers had their WordPress website hacked. An out-of-date plugin had allowed uploading an arbitrary PHP file, and someone had used this to drop a few files on serveral locations on the website. Luckily the IDS picked up on this quickly, and we could remove the infection and fix the hole.
What happened?
If we just restore the website, and do not plug the hole, the website will be hacked again in no time. So how did they gain access?
According to the webserver logs, a POST was performed to /wp-content/plugins/wp-time-capsule/wp-tcapsule-bridge/upload/php/index.php. That index.php file is just including /wp-content/plugins/wp-time-capsule/wp-tcapsule-bridge/upload/php/UploadHandler.php and instantiating the UploadHandler class. After sending the POST request to index.php, a webshell was created on the server, which was then used to drop the other files.
There was a .htaccess file in /wp-content/plugins/wp-time-capsule/wp-tcapsule-bridge that could have prevented this, but not every webserver even supports .htaccess files.
First thing I did was compare UploadHandler.php to the most recent version of the file. Apart from a few empty lines, the difference between UploadHandler.php in 1.16.3 and 1.17.0 is:
The version 1.16.3 used content-type (a untrusted field) to check for file type, the new version checks the actual file extension. If you can modify the headers of the HTTP-request to spoof a application/sql type of file, you can basically upload anything you like.
Lets just make a proof of concept here. First create a file test.php with some malicious code. Then upload it using:
Now your file is available through http://www.example.com/wp-content/plugins/wp-time-capsule/wp-tcapsule-bridge/upload/php/text.php
Version 1.17.0 of the wp-time-capsule plugin patches the vulnerability by implementing a file extension check, but the changelog does not mention this at all. I believe making a coding error could happen, but covering it up is unpermissible. I prefer to stay away from software developers that don't report on their security problems.
Had this vulnerability been reported transparently, then the WP management software this customer uses would probably have flagged this update as necessary.
Last night Microsoft released several updates. One of them sets the language of parts of Outlook 2007 installations to Swedish.
Turns out, this is KB4011086. Uninstalling KB4011086 reverts all of outlook to the correct language.
Last night Microsoft released several updates. One of them sets the language of parts of Dutch Outlook 2007 installations to Swedish.
Turns out, this is KB4011086. Uninstalling KB4011086 reverts all of outlook to the correct language.
Loading...
