Page 4 of 9

Remote Desktop “No Valid Certificates Were Found on This Smart Card” when trying to authenticate with National ID-Card

When trying to use smart-cards/tokens to authenticate to Remote Desktop you can receive the “No Valid Certificates Were Found on This Smart Card” error for multiple reasons. It can be that you don’t have the necessary drivers installed properly. It also can be that the CA trust chain is not in place. In this post I’m not going into detail on those issues. Here it’s just going to be a quick fix for the Estonian National ID-Card not showing up in Remote Desktop. It can also apply for other ID-Cards.

Namely the issue is that national ID-Cards tend not to have the “Smart Card Logon” key usage in their certificate profiles and that’s why they aren’t showing up in Windows Remote Desktop. So if the certificate you have on your smart-card doesn’t have “Smart Card Logon” set it won’t show up either. There is a quick work around/fix for it. You just need to modify one registry setting so that Windows would accept also certificates with out the specific permissions set.

Just copy paste this into notepad and save it with the .reg extension and execute it:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SmartCardCredentialProvider]
“AllowCertificatesWithNoEKU”=dword:00000001
“EnumerateECCCerts”=dword:00000001

Windows will give you a warning, just accept it and then it should say that the keys were successfully added to the registry. Now your ID-card certificates should show up in Remote Desktop.

Installing VMware Workstation 15 Pro on Windows 10 1903 can have a small installer issue

After updating my Windows 10 to 1903 VMware Workstation 14 stopped working. It is a known issue since the release of 1903. VMware hasn’t released a patch for it and the Windows updater points to and seems to be promoting upgrading to version 15. Although there are many workaround hints available, I for one do not want to mess about with uninstalling and blocking some windows update packages. So I went ahead and got the upgrade license and went on to update it. That didn’t go as smooth as I would have expected.

As it turns out the installer for VMware Workstation 15 Pro(VMware-workstation-full-15.5.0-14665864.exe) in my case had a small issue where it wouldn’t install. When running the installer it always prompted me that “In order to finish installing VC redist”, I need to reboot my computer. Well did that the first time the installer asked me to press “Yes” and reboot, after that the message still came up, tried it one more time and then it still persisted. After that I just went ahead and downloaded vc_redist.x64.exe via Microsoft’s support site and installed it manually. After doing that Workstation installer worked like a charm and had no more issues.

Even Yahoo is not able to keep track of it’s SSL certificates expiration

I have always thought that the “Internet Giants” have proper monitoring and procedures in place to keep track of their SSL certificates expiration dates. But as it turns out Yahoo does not.

In some instances of Yahoo advertisements they are still using a certificate that expired over a month ago. Today (07.08.2019) I am still at random getting an error about Yahoos advertisements certificate being expired:

Some connections getting reset on CP R77.30

On one system I started hearing people complain that one server cannot connect to an outside service normally. The connection is opened and gets reset after a while.

When looking at tcpdump traffic from both the client and the server side we saw that the culprit had to be the Check Point firewall in between. As the internal server got a tcp-rst with the source address of the external server and the external one got a tcp-rst with the source address of the internal server. Smart Console logs show that connection is being allowed through and that is it.

So to find out what is going on I turned to zdebug. Zdebug output showed the following line:

[DATE TIME];[cpu_10];[fw4_5];fw_log_drop_ex: Packet proto=6 Internal_Address:47891 -> ExternalHost:443 dropped by fwpslglue_chain Reason: PSL Reject: ASPII_MT;

Googling the “dropped by fwpslglue_chain Reason: PSL Reject: ASPII_MT;” message lead me to sk119432 and that pointed me to towards application control blade which had been activated on that GW by someone previously. When looking at the Application Control policy I found that the particular internal host was not included in the app control policy. So I added the source host involved to the app control policy and the traffic started flowing normally and stopped getting tcp-rst sent to both hosts.

To me it is interesting that all Application Control rules had logging and accounting defined to them, even the final drop rule. And yet no application control blade intercepts were logged. Besides that, the connection was allowed to be opened and always was up for a few seconds before getting reset.

“According to the policy the packet should not have been decrypted” after managment upgrade to R80

It seems that Check Point has changed the way that policies are compiled/handled. At one installation I saw a VPN connection break right after the policy was installed the first time from the upgraded management server. Right after that “According to the policy the packet should not have been decrypted” started appearing in the logs and traffic started being dropped.

After a bit of looking around on the Check Point support site about the message it pointed to multiple objects having similar VPN domains. After going through the object database, I managed to find a “copy” of the peer GW object. Basically 2 gateway objects had same external IP address and similar VPN domains defined. Fortunately that “duplicate” entry wasn’t in use so I deleted it. After deleting the duplicate entry and pushing the policy again, the traffic started flowing again.

I wonder why the upgrade verification process showed no errors or warnings. To me it seems they should have shown some sort of warnings about it, as it breaks things.

Nice feature/bug in Check Point NAT

It seems that I have stumbled upon a interesting Check Point firewall NAT behavior. Namely the firewall does something that it is not ordered to do, it translates the source IP to a different one than in the policy.

Had a static inbound NAT rule where the source address of the client was supposed to be faked to another static address. What happened was that yes the policy installed fine. Yes the client IP address was changed and hidden from the service. But it was changed to an incorrect address. The rule stated that the client IP address be changed to for example 172.16.2.10, but what it was translated to was 172.16.2.100. And the new address did not exist anywhere in the policy database.

And after upgrading that particular management server to R80.20 it refused to compile the policy with that NAT rule in place. Fortunately recreating the NAT rule removed the issue.

The error in the FWM debug logs was for that issue:
“Invalid Object in Source of Address Translation Rule 57. The range size of Original and Translated columns must be the same.”

The interesting thing is, that it was fixed simply by deleting the rule and just re-adding it. And yes it was a 1 address to 1 address translation, not a network to 1 address.

WhatsApp used to interact with ATMs in Brazil

Happened upon a interesting article today – https://www.zdnet.com/article/banco-do-brasil-launches-cash-withdrawals-via-whatsapp/. As URL already states they are enabling users to withdraw cash from ATM’s via WhatsApp.

Basically what they say is that, the user needs to add a chatbot to their contact list and ask it for money. Then the chatbot gives them a “key” that is valid for a day. Although the service has a 80$ transaction limit, it still feels like a bad idea to me. I can already feel the new “malware wave” coming that tries to exploit this thing on the phones.

When thinking about this service, I really would love to see the analysis they made to say this is a really secure thing to do. How is this channel secured? How are they protecting people against “theft via malware”? I feel like I need to do some research in to that.

Upgrading a secondary management server to R80.20 GA issue

The Check Point upgrade guide for R80.20 is quite clear in saying that on a secondary server you should perform a clean install. All is fine and dandy with that. I don’t know if I am the first one to actually run in to a problem with it.

When using the CPUSE clean install feature in the WebUI, it seemed to work. That is after I had resized the partitions to give it enough space to perform the upgrade. It was arguing that 30GB of free space is actually 29.83GB. So, after making the current active install partition smaller all seemed well. Until the reboot that is.

After the server rebooted, I could see the new WebUI and felt excited, that it actually kept the original IP address. As CPUSE had warned that all settings will be wiped that was a nice surprise.

Unfortunately, the nice things ended there. I was unable to log in. The default “admin/admin” combo didn’t work or the previous credentials that i had. Found no hint on the Check Point support site either.

After a bit of googling around ended up just downloading the clean install ISO file and re-installing the machine. If I had used the ISO before instead of the CPUSE, I would have saved a lot of time. I guess that CPUSE clean install feature is not that clean yet.

Malware campaigns are going even after the smaller “markets”

Yesterday I happened to read a warning by the Estonian police, that there is a new malware campaign. The fact that there is a malware campaign going on is not news to anyone. But what actually caught my attention was the translation quality on the phishing sites.

The warning had a screenshot of a site spreading malware was the classic your computer is infected with a virus scam, but for smart phones. Sites like that have been used for a long time. But the quality of translation has been really bad for those sites. This time the message had quite good quality and a lot of people might actually fall for it.

The message there basically stated that the user had visited a site containing malware or porn and might be infected with a virus. It also contained a threat that your ISP will block your internet access. They have scripted the ISP part, so that they try to get the ISP name from your IP address.

Besides the rise of quality of the phishing text and translation based on the localization info, a lot of the phishing sites have also moved on to using HTTPS. Malware sites have started using certificates that are accepted by web browsers making them a bit harder to detect by unsuspecting users.

It is the first time in years I felt like doing a refresher to my parents on recognizing malicious sites.