Category Archives: Vulnerabilities

Microsoft Office 365 blocking access to sites with digital certificate issues – is not working

Hacking, Hardening and Mitigations, Vulnerabilities, What have I discovered?Eitan Caspi

Dig this – a bonus for you, my loyal readers… 🙂

Do not click on this link – https://2.21.143.74. It is the IP address of microsoft.com (the IP itself is of Akamai). Copy it to a clean Word document or clean Excel worksheet (make sure the apps are using the latest version of 365). Make sure the text becomes a link. Click on the link. A warning message will appear as in the attached image, stating that there is no match between the site you requested (because you requested an IP address) and the name of the site for which the certificate is intended (microsoft.com).

If you click “No” or the “X” button for closing the warning message window or even typing the keyboard combination of Alt+F4 to close the Word/Excel app – the link will open anyway … only killing the Winword.exe process for Word or Excel.exe for Excel – will cause the link not to open…

Also notice that the default focus in the warning window is on the “No” button, so a user’s automatic action (hitting “Enter” or “Space” on the keyboard or clicking the mouse main button, if the cursor feature of “Snap to default” is enabled) will cause the site to be opened instead of avoiding the site. That means that this protection does not work.

I contacted the MSRC with the above information, and they responded as follows:
“
Hello Eitan,
Thank you for submitting this issue to MSRC. We determined that while the issue you reported is valid, it does not meet our the bar for immediate servicing. That being said, this submission has been flagged for future review by the product team as an opportunity to improve the security of the affected product. We do not have a timeline for when this review will occur, and will not be able to provide status for this issue moving forward.
“

How I found an open SSH access on an Israeli government’s gov.il DNS server

Government and Regulation, Hacking, Information Security in Israel, SSL in Israel, Vulnerabilities, What have I discovered?Eitan Caspi

I have much criticism about the Israeli government information security status and activity. Lots of PR and marketing for being a “Cyber Nation” but it is true mostly for the selling of knowledge, services and products. Not so much doing the “dirty work” of protecting the Israeli Internet facing IT, including the one of the Israel government itself.

So, I started this weekend to operate a mini-project of checking the quality of HTTPS sites of the gov.il sub-domains. I publish the results in a public spreadsheet, accessible as read-only (viewing, downloading and printing is allowed anonymously) from Google – https://docs.google.com/spreadsheets/d/1Fez2A1FwqesWRuc2DowpdG20okh-KDbYfO5qnl8nZ-U/edit?usp=sharing

While running these checks I found something alarming:

One of gov.il’s DNS servers, a server called dns3.gov.il, at 62.219.20.20 – replied at port 22 TCP, i.e. SSH, a service used to manage mostly Unix/Linux servers. Yes, open, allowing me try to login…

Telnet access to port 22 TCP to the server
Access to the server using PuTTY, the digital certificate prompt
The SSH login

As I found it, in the afternoon of Friday, 31-Jan-20, I sent this finding at 16:28 to the Israeli national CERT and after ten minutes I also managed to correspond with someone I am in contact with, who was senior in government’s information security department, and he forwarded this issue to another security senior in the government’s IT, and he passed the details on to those who can fix this issue.

It took a few hours, but at the last check I did, around 21:30 that evening – access was blocked as this port has been closed, so it seemed to me that the issue had been addressed. Quite fast for almost Friday evening (the beginning of Shabbat in Israel).

Another point was that the SSH server identification was SSH-2.0-OpenSSH_7.4p1 Debian-10 + deb9u6, which means that the OpenSSH version is 7.4p1 that was released in December 2016, and since then several versions and a few security fixes for various security issues were released for OpenSSH, which are probably missing now from server. I hope they will update what is needed as soon as possible.

OpenSSH release notes
https://www.openssh.com/releasenotes.html

OpenSSH vulnerabilities
https://www.cvedetails.com/version-list/97/585/1/Openbsd-Openssh.html

The network capture of the PuTTY access to the server

iDrive backup use SSL 2.0

Encryption - Decryption, Vulnerabilities, What have I discovered?Eitan Caspi

Recently I begun using iDrive cloud backup service, using their Windows client.

Being who I am I sniffed around and found that during the backup the Windows app is backing up files to the service server using SSL 2.0, which is considered as not secure.
See a Wireshark screenshot below.

Log of events trying to get iDrive response for this issue:

2-Dec-2019 – I sent an email to their support asking about this problem. I received immediately an auto-reply email with support case ID number

7-Dec-2019 – Since I didn’t get any human reply, I sent another email asking for reply, using the relevant case ID.

9-Dec-2019 – I got a reply that my case was filed under a case ID for all the past enhancements requests I sent before
Right after accepting this email I replied that this is not an enhancement request but a vulner to take care of and that I wish a security employee will contact me

That’s it. Nothing since then. It’s time to go public.

To their credit I must note that they claim their app encrypts the data before it is sent over the network (I didn’t check this part. Yet…).
Still, I believe every layer should be secured correctly.

iDrive backup user SSL 2.0 during backup
TCPView session showing process connections to the same IP address
TCPView process properties for the relevant process, showing it is related to iDrive