Jump to content


Most Valued Members
  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by rugk

  1. Windows phone is a closed platform. This means you cannot install apps from third-parties and all apps in the Windows store are scanned by Microsoft. So you should be quite secure.

    iOS uses the same approach and there are only few known malware samples for iOS. This is also one reason for ESET not to develop a security product for these platforms - it would not make much sense.

  2. The Fraunhofer Institute for Secure Information Technology (SIT) published a research paper where they explain many different vulnerabilities they found in mobile security/antivirus software.

    They found vulnerabilities in products from Kaspersky, ESET, Avira, McAfee and Clean Master Security. Most vulnerabilities are already fixed in the latest version of the products.


    So of course we focus on ESET here...



    The ESET Mobile Security & Antivirus application contains implementation flaws which can be abused by an attacker. The application contains an incorrect SSL certificate validation, which  can be abused by an attacker for eavesdropping or manipulating the communication. Furthermore, an attacker can steal the ESET license information or the user and password for the license. The Mobile Security scanner also implements an encryption scheme, which is violating Kerkhoffs’s  principle (hide the key, not the algorithm). The implemented crypto scheme is vulnerable to chosen cipher  text attacks and could be easily broken. Encrypted information can be decrypted to plaintext. We wrote a  short proof of concept script attached at the end of this document.  The crypto scheme is implemented within the native code layer. It should be verified if the scheme is  utilized in other ESET products.  If this is the case, please fix it also there.


    So they found two vulnerabilities: failed SSL/TLS verification and a broken encryption.

    Looking at the details in the PDF is interesting. They overwrote the Androids default SSL verification, which many anyone can easily intercept SSL secured traffic:


    In the current implementation this method [for verifying SSL/TLS] is empty, which means it does not validate the correctness of the server certificate nor the whole certificate chain.


    This is a widespread issue on Android app developers, but I thought at least ESET would get it right...


    And then we have the license username/passwords. Basically this is more or less and old issue and we had (and AFAIK still have) it in desktop products of ESET too.

    To summarize the linked topic: The username/password were send in plain-text only BASE64 encoded (Base64 is easily reversible and provides no security).


    So in EMS they changed this a bit:

    • At first they seem to use SSL/TLS now. But as said before, it was implemented incorrectly and therefore did not provide any protection.
    • But they implemented an "encryption" for the username/passwords.

    So what does the Fraunhofer Institute SIT say about this encryption?


    In our analysis we did not completely reverse engineer the applied encryption scheme for the license information, but we used chosen cipher text attacks in order to break it. The encryption is done by XOR the input value with a key generated by a random stream. In order to retrieve the key we utilized, for instance a username consisting of 25 times “a”. After that the application encrypted the username and the application with BASE64. We decoded the BASE64 String and XORed
    the byte array (50 byte) with 25 times of “a” (each 2ndbyte) and we got a key with the length of 25 bytes. We attached a proof of concept script,which will decrypt the LicenseUsername and LicensePassword up to the length of 25 characters. In the same way it would also be possible to generate longer keys but it depends of the length of username and password. Most people choose shorter ones.


    So about the last sentence one fact has to be added: ESETs licenses passwords and usernames are generated automatically and users cannot use a longer password even if they would like to do so.

    But generally this "encryption" is useless anyway, because


    The given encryption/obfuscation, behind the BASE64 encoding, of the credential information does not provide enhanced protection in this attack scenario, because the attacker does not need to decrypt it to authenticate. He retransmits the sniffed (partial) XML information in his own context and gets authenticated.

    So IMHO the SSL/TLS flaw is much more serious than the second encryption flaw as username/passwords of ESET licenses can "only" be used to hijack this license and e.g. register additional devices using the license of the victim. However the TLS issue is really a basic flaw and I strongly suppose it also affects the username/passwords of ESET Anti-Theft e.g. when you connected your Android device with it.

    Also when anti-theft is triggered users photos, location and more things are uploaded - using an SSL/TLS connection. If that's not secured it can easily be intercepted.

    So there are still some open questions:

    1. Are these vulnerabilities already fixed in EMS? If so what is the latest (VSD or product) version affected by this issues?
    2. When the SSL/TLS verification is properly done, I highly suggest another thing: You should really implement key pinning to protect the SSL/TLS connection.
    3. Is this "encryption"-approach of ESET license username/passwords also done in other ESET products? If so is it already fixed/replaced by a proper SSL/TLS connection there?


    BTW: It is also interesting to read through the whole PDF and look at the flaws of other security products. There are SSL/TLS flaws, XSS scripting and remote code execution vulnerabilities.

  3. If you already have installed ESS you don't need to do anything. This vulnerability only affects the installer.


    However as for your question about how to uninstall an ESET product completely you can use the manual uninstaller. But again: As I said this is not necessary here.


    BTW: If you want to be secure when installing an ESET program a much more important recommendation would be to look at the UAC prompt (= the message which pops up to asks you for administrative rights) and verify that the downloaded file is signed by ESET. You can see this at the "Verified publisher" name:

    In contrast to this faked (and potentially malicious) installer:


    If you see such a faked thing when trying to install a software by ESET stop the process (click on "No") and report this issue e.g. in the ESET forum with a description of what file you've downloaded and if you can attach the file.

  4. I downloaded the offline installer to the desktop and runned it as administrator. No other files were at the desktop at that moment. Am I safe?

    Well, ESET said all installers are already fixed and I also don't know whether the offline installers were affected at all.

    But in a more general way (which also applies for other installers) this answer is a bit longer: If there are really no files theoretically yes.


    However there may be hidden files or something like this, so the only way to be certain is creating an empty new folder, moving the file inside of it and running it from there.

  5. Yes, it may be not that easy to exploit, but it is certainly possible. And according to his "Proof of concept" you do not need a specially crafted DLL in this case. It is a generic DLL. Tricking the user into downloading a DLL is another thing, but it is certainly possible too. Just imagine how much files may resize in some users download folder. Here are more information about this.


    But do not take this too easy. Oracle, which had this issues in their installers too, seem to have taken it quite seriously:

    Due to the severity of this vulnerability, Oracle strongly recommends that customers apply the updates provided by this Security Alert as soon as possible.

    And the thing to note is that it can be fixed. So I would at least expect a fix with the next installer release. And I also would have expected that ESET at least replies to the researcher in some way...
    So what is ESET going to do about this?

  6. A security researcher recently discovered vulnerabilities in many software installers including Java, WinRAR, Python, Panda Security, TrueCrypt/VeraCrypt, Emsisoft, Trend Micro, Avast, McAfee and more.

    ESET is also a part of the list.


    Basically the vulnerability is an issue with DLL files, which are automatically loaded by the installer (which is usually executed from the downloads folder). If wrongly implemented these files are loaded from the current folder, which is the download folder. As most installers request admin rights this is a privilege escalation, because some untrusted DLL files are loaded and executed with admin rights.
    If an attacker can convince a user to download some badly crafted DLL files and later an installer with such a vulnerability is executed by the user, the DLL is loaded and malicious code may be executed.


    A way to prevent such attacks is to copy all installers into an empty directory before executing or to make sure there are no rogue DLL files in the Download folder.


    So why I am posting this is not only because of the general suggestion, which is a good thing to know, but also because of the Timeline included in the error report for ESET:

    Timeline:~~~~~~~~~2015-11-30    report sent to vendor              NO answer, not even an acknowledgement of receipt2015-12-12    report resent to vendor              NO answer, not even an acknowledgement of receipt2015-12-21    report published

    So according to this ESET has not yet replied or releases a fix in the installer. Can someone of the mods comment on this and possibly say whether the installers are still vulnerable and when this will be fixed?

  7. I assume you mean virusradar.

    There Iran is displayed in grey, which means that there is "no data" as the tooltip shows.


    And it is easy to find out why: ESET does not and is not allowed to sell their software to Iran. So as there are no (official) users ESET cannot receive any data.


    I don't want to ask how you got your ESET version, but at least you did not get it from an official ESET reseller unless you bought it from a foreign country.

  8. This only happens when going to forum.eset.com and no other HTTPS site? And it only happens with SSL scanning enabled?

    In the ESET SSL scanning dialog can you please click on the certificate and post a screenshot here?
    Please also click in the Firefox message on "Add Exception..." and click on "Show..." (or similar) to display the certificate. Please make a screenshot of this too.

    In both cases you can also find an "export" button somewhere (e.g. in the details tab), so you can save the cert and attach it here too (or link to it as I think the file extension is not allowed).

  9. Will I have to uninstall the Windows version of ESET before I blow away WIN7


    Technically it does of course not matter, because you set up the whole OS, but I think I know what you're asking: Whether this is a license issue. And AFAIK it is not. Even a dual-boot version would be okay - the only thing you must not do is running too much (= more than included in your license) versions of ESS simultaneously.

    That said it obviously does not hurt to uninstall the Windows versions before.


    will the latest Linux expect the Version 9 licence details or the details that applied to the earlier versions?   

    It does only accept the old license details (username/password), because the Linux version is quite old.

    Also note that there is no ESS for Linux, but only NOD32.

  10. BTW I have to praise you for reconfiguring HTTPS at forum.eset.com. Now it got scored much better than the last time: https://www.ssllabs.com/ssltest/analyze.html?d=forum.eset.com
    You finally get A-. :)
    (Previously it was C if I remember correctly and this was a really out-of-date config)

    But you can still improve your config...
    As far as I see the cipher suite (especially the order) might be optimized and if you also apply the HSTS header you can also get an A+ from SSLLabs.

  11. There is no direct access (have to open smart security panel and go to tools) instead of a quick access by the tray menu or right click menu.


    Actually you can access it through a desktop shortcut created when installing v9 or - in case you deleted it or it was no0t created - you can add it back by adding this shortcut:

    "%programfiles%\ESET\ESET Smart Security\ecmd.exe" /startprotectedbrowser

    Depending on your installation path you may have to adjust this value.

  • Create New...