rugk
-
Posts
1,716 -
Joined
-
Last visited
-
Days Won
54
Posts posted by rugk
-
-
Very nice idea, but unfortunately this requires root. And currently EMS does not support rooted devices.
-
You could block URLs in the web protection. Or you can find out the IP address of the domains (e.g. by pinging it, using nslookup or an online service) and block these. However IPs may change, so it could possibly circumvented.
On the other side you have to know that the web protection does not filter HTTPS connections and only if you enable SSL scanning you can possibly filter some connections. (some connections use key pinning, which could also prevent this)So personally I would do both methods, so at least one would catch. If you want to import a large number of IP addresses in ESS you can use my firewall rules generator. -
I think it does not harm to disable HIPS and real-time-protection before upgrading (as long as you do not forget to re-enable it afterwards).
However based on the instructions from ESET I linked earlier the upgrade should also be possible without disabling anything. (Otherwise they would have told so on the website or KB article)
-
But anyway - I think - you can of course use the old WinPE-based version too. As long as your license there is valid it gets VSD updates as any other ESET product.
-
Now there are more information from ESET regarding the Windows 10 upgrade: Compatibility of ESET products with Windows 10
It basically says that you can upgrade with ESS/NOD32 v7 or v8 without any problems.
But also note that there was just published an update (for ESS and NOD32) which adds compatibility with the (AFAIK) latest Windows 10 build, so personally I would upgrade to it before upgrading to Windows 10.
-
Okay, why didn't you said this earlier?
I mean that's great to hear.
-
What is the level of ESET involvement in this forum? Do ESET technical staff monitor these forums in order to assist customers having difficulty with the product?
Yes they monitor the forum. You can see all ESET moderators listed here. Their posts are marked with a green background.
-
It seems like this should be fixed with this update if it was not fixed earlier.
-
Regarding the persons behind, have a look at the About or Contact section. Does it look trustworthy to you?
Yes that's what I thought too. I already mentioned in the first post that their only contact detail is a Twitter account.
But about the vulnerability: I've passed your reply to them (in the comments below their article) so let's see what they say.
However as I see it it seems to be quite serious as it allows privilege escalation and sandbox escaping.
We are aware of this but this vulnerability is no way as serious as some others that could have been exploited without user's knowledge.
So the user will see it if it's being exploited?
Or does it need some steps from the users side to make the exploit work?
-
So thanks for fixing tree vulnerabilities in (nearly) all ESET AVs. Starting with this one all of them were discovered and reported by Google Zero team and fixed quickly with regular VSD updates.
So far this is very good (the fixes, not the vulnerabilities of course), but there is another one, which was published publicly, but does not seem to be fixed.
Here is an (a bit) obfuscated link - if you rather want to remove this link feel free to do so: hxxp://www.qwertlab.com/<enter current year here>/06/security-avisory-eset-lpc-component-multiple-issues/
Basically is about the communication between egui.exe and ekrn.exe which has a big vulnerability, which allows attackers to send many commands to ekrn.exe (which runs with system privileges) from a program which runs with user privileges:After successful connection to the LPC Port, it is possible to send untrusted data to the LPC server in ekrn.exe.
The handler has a very huge attack surface.
The researcher concludes:[...] the mentioned leaked image base address can be used to to bypass DEP/ASLR.
(interestingly - or sadly - that's the technology, where ESET just won a kind of test)
The final result is that the attacker is able to engineer the malicious requests [...] which exploits highest privileged ekrn.exe process, hence the attacker running the client elevate her privilege to the highest level in Windows as system. She is not only is able to disable the antivirus service, but also can bypass different level of windows access control and sandboxes.
A word about the test lab
The researcher has published sample exploit code and explained in detail how to reproduce it so I assume it is a real vulnerability.
However it is notable to say that this is the first vulnerability which was blogged on their blog and the research lab seems to be quite new. Their "blog anounce" (notice the spelling mistake) consists of 4 sentences and their only contact data is a Twitter account.
So if it - probably - is a not-working description and some parts or the whole thing are fake, please let us know. (I didn't tried to reproduce it.)
However I don't think so, but there is missing another thing in the blogpost: Was ESET already notified of this? Usually this should be done before publishing instructions how to exploit it - for obvious reasons, but here the research lab does not even mention anything like this with a single word.So do you know of this? Are you working on a fix?
-
Sorry for dumping this but could you please answer my questions?
-
More information about the cooperation of Facebook and ESET can be find here: ESET and Facebook - not a good idea
Basically it's notable to say that Facebook blocks your account and they are the only ones can unblock it.
About WinZip this is surely only a PUA detection:
So in this case the user was asked before, because the detection of PUA is completely optional in every ESET software.
-
BTW another note about your HTTPS connection: Besides disabling the weak Diffi-Hellmann cipher suites you may also want to activate ECDHE cipher suites, because they are much faster and more secure than RSA cipher, use less processing speed and are supported by all recent versions of major browsers.
-
@TomFace
Don't forget to include your time zone...
No, I think it would be indeed quite useful to make this feature available for regular users.
But i can also live without it.
-
This has a common point with post 149 (15062 not found).
Yes, it is. Here is a direct link: https://forum.eset.com/topic/51-future-changes-to-eset-smart-security/page-8#entry15062
-
In any case it would need much work, so don't expect it happen very quickly.Maybe now ESET will stop using Flash?
However of course I would also very much appreciate it.
-
Oughh...
Not that pretty.
Is the URL at least hashed before it's checked online? (If so what hashing algorithm is used?)
And maybe much more important: Is this check done via HTTPS?
And the thing with offline scan is confusing: So if you scan the disk offline you can only can find some URLs in browser histories or as (very rarely used) .url or .lnk files. What else with URLs could you find?
So if you find a malicious URL in the browser history - what do you do with it? Delete it?
And what is much more interesting: If you already have the offline database why don't just use it for all checks?
BTW this only affects the detection of malicious URLs, doesn't it? Because the phishing database is updated every 15 minutes and is used offline?
And another strange thing: If the check would be done instantly online why do you even need VSD updates before you e.g. unblock a false positive website?
-
@itman
Nice idea. But if I'm remembering correctly in v8 you can include and exclude applications for SSL scanning, so this may solve your problem.
-
I've just released v 1.2. Basically the program has not changed much, but I've changed some other things around it.
At first I switched from a CC-BY license to the MIT license as this is more suitable for software than a CC license.
And secondly this tool and all it's source code is now on GitHub.
So if you want to contribute something there you can do it easily.
-
A) Well... not exactly. All ESET version of course can detected cryptolockers (with virus signatures, heuristics or similar technologies), but they don't have a specific feature to block Cryptolockers.
They have an Exploit Blocker (which was enhanced in v8) which can block many attacks, so Marcos only mentioned cryptolockers and ransomware as an example in his post.
B) Simple answer: V8 won't weaken HIPS. The smart mode is (or can be) in fact protect you better, but you have to know how to react to the messages from ESET. So basically you can just stay with the automatic mode which is the same in v7 and v8.
As for ESET LiveRescue you can use it if you want, but don't have to. You can download it here without need to upgrade to v8.
ESET Cybersecurity Education: This is a kind of "training" for you and it's really easy to use and to understand so you don't need to be a techy. You can already try it out without upgrading to v8.
You can finds more information about this training in this thread: "Training" at the left side in ESET programs?
-
No it won't be better if you use a wrong-written version of enhanced instead of AI. And no, you don't need to try it with advanced next time...
But if it amuses you...
-
In this case please provide us with instructions how to reproduce the issue.
Maybe also look into the settings of the on-demand scans - there you can also change the default value for what should be scanned.
-
Does the browser show SSL/TLS error messages? If so you maybe have to manually import the root certificate from ESS into these browsers.
-
Another way to block OpenCandy can be done with ESET firewalls rules or web protection rules.
Here are all instructions: Block PUA inside installers from Nero Burning ROM, Orbit Downloader, ImgBurn, DVDVideoSoft... - Install them without OpenCandy!
@Kev35
However your message seems to be from a kind of "OpenCandy blocker" which changes the hosts file to block OpenCandy, similar like has done it. Afterwards it seems to display this message, so please be aware that this message is not shown from any ESET-related software.
I don't know any "OpenCandy blocker" which does it like this, but there is a chance that someone developed such a software which readds the hosts file lines (if they should be deleted somehow - which is/would be very strange as the hosts file is normally quite good protected) and because of this this message is displayed.
So basically if you have an ESET software installed you have other possibilities to get rid of OpenCandy, like e.g. explained in the thread I linked above. So if you know how to do you can uninstall/delete the OpenCandy blocker and use a method we suggested here or one which is described in my thread.
Please also note that the hosts file should not be easily writeable as it can be misused by malware too, like I explained here. So if it is too easily writeable (maybe because the OpenCandy blocker modified the permissions) you may want to adjust the permissions of this file and protect it from unauthorised changes.
Android/Locker.EJ - Duet?
in ESET Products for Mobile Devices
Posted · Edited by rugk
Today EMS detected Duet as Android/Locker.EJ during an on-charger-scan. It's the official app from Google Play and hasn't received an update in the last days, so it's very strange that it's now detected.
From a description of the same thread (group) I've read the malware should block access to the device. However nothing like this occurred.
So is this a false-positive?
Edit: Link to this thread sent to ESET labs.