DLL Hack in Notepad++
-
I think there is no sens in checking certificates or staff like that because project is open source and everybody could create their own version of npp.
P.S. If someone is paranoid then could simply check md5 hash of original files(dlls and so on) :D
-
Yes, well, in this case you’d have to check the MD5 on the SciLexer.dll that will be loaded, which is perhaps a different one than the one that you think will get loaded. :)
-
I think there is no sens in checking certificates or staff like that because project is open source and everybody could create their own version of npp.
Not if the private key is kept private ;-) (so it is open source with parts being not open)
NO ;-) I don’t want to start a new discussion whether this makes sense. :-)If someone is paranoid then could simply check md5 hash of original files(dlls and so on)
Nope, md5 is considered insecure.
But all in all you are correct and Don, dail etc… do also agree once users’ PC are compromised …
Cheers
Claudia -
@Claudia-Frank ,
SHA-2 (SHA-256) or SHA-3 could be checked as well, just to be certain everything is ok and sleep calmly at night ahhaha :D -
Exploit Notepad++ (SciTE) ;-)
-
I still don’t understand what makes this unique to Notepad++/SciTE/Scintilla. You could do the same thing to any dll file.
-
There is nothing unique here. I could do the same thing with any dll file. Just you were unlucky to turn up in Wikileaks. :)
-
Signatures are a problem for people who want to build NPP by themselves and modify it.
They can’t sign DLL by themselves so they will need to go into NPP code and also disable the signature check.
Given that the added security is very very minimal I don’t think that NPP should test the signature of SciLexer.DLL.
Once an attacker has access to the file system to replace DLLs, specifically to ‘Program Files’ which usually requires administrator privileges the system is doomed anyway. -
Collisions on linking with a static build of scilexer.lib:
1>SciLexer.lib(PlatWin.obj) : error LNK2005: “public: virtual __cdecl Window::~Window(void)” (??1Window@@UEAA@XZ) ist bereits in fileBrowser.obj definiert.
1>SciLexer.lib(UniConversion.obj) : error LNK2005: “unsigned int __cdecl UTF8Length(wchar_t const *,unsigned int)” (?UTF8Length@@YAIPEB_WI@Z) ist bereits in UniConversion.obj definiert.
1>SciLexer.lib(Style.obj) : error LNK2005: “public: __cdecl Style::Style(void)” (??0Style@@QEAA@XZ) ist bereits in Notepad_plus.obj definiert.
1>SciLexer.lib(Style.obj) : error LNK2005: “public: __cdecl Style::~Style(void)” (??1Style@@QEAA@XZ) ist bereits in FindReplaceDlg.obj definiert.See http://www.scintilla.org/ScintillaDoc.html#BuildingScintilla for builds with STATIC_BUILD.
-
From what I’ve read in the Vault7 release, DLL injection is a great way to insert malicious code into the memory space where a legit DLL resides.
I’m not terribly sure if this directly applies, but I found this post on StackOverflow on how to avoid DLL injection in Windows processes/applications:
http://stackoverflow.com/questions/869320/how-do-i-prevent-dll-injection
Honestly, I hadn’t heard of DLL injection prior to the Vault7 release, so the my comprehension of the matter is limited. I have to say that if I understand it correctly though, the concept is fascinating.
-
Is it possible to know if my scilexer.dll has been hijacked?
-
@Gilberto-SC said:
Is it possible to know if my scilexer.dll has been hijacked?
It depends on the hijack. The CIA, related organizations, and black-hat hackers, is adding spyware to computers and devices used by their targets. Among the things they do conceal that spyware is running is that are making changes to DLLs and/or intercepting calls to DLLs. Someone inspecting their process list will see nothing unusual. If they use Notepad++ they would see notepad++.exe running. If they close Notepad++ that process goes away.
If the only change they made to the target’s computer is to replace DLLs with versions that include spyware then, yes, it’s possible to know if scilexer.dll has been hijacked. However, in order to replace scilexer.dll the attacker needed full administrative mode rights. If that’s the case they likely also installed a root kit and much more. If the target inspects scilexer.dll the bits and bytes they see will be exactly the same as the copy of scilexer.dll that comes with Notepad++ or similar products. The only way for a target to see if they have been hacked is to take the machine or device to a forensic lab and to have them tear it apart down to nearly the molecule level. Even with that they may miss the clues. See Stuxnet for an example of how attackers such as the CIA operate. The good news for the CIA is if the target hears about v7.3.3, installs it, that it’s going to pass the test. The target thinks they are safe (until they read this post) and the CIA continues to monitor the target. Once the CIA spots this post they may make arrangements so that the target sees something that leads them to believe they are safe. :-)
-
you can use procmon in order to find out which dll gets loaded, from where and when.
Run procmon, define a filter for npp and then start npp.
It needs a bit of training but if you are really interested in finding out what does what
check out the sysinternals tools as well as everything Mark Russinovich has posted/blogged.Once you are at the level to understand how process, threads, libraries, drivers … work together
download hxd and start investigating memory.Other useful tools can be found at nirsoft .
Cheers
Claudia