KeePass version 2.12 <= Insecure DLL Hijacking Vulnerability (dwmapi.dll)

Discussion:

(too old to reply)

YGN Ethical Hacker Group

2010-09-07 05:57:51 UTC

The fixed version KeePass 2.13 has been released.

http://keepass.info/news/n100906_2.13.html

But failure to describe "DLL Hijacking was fixed".

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Jacky Jack

2010-09-07 20:10:36 UTC

Permalink

Be patient.
It won't last for too long.
Even if you're tired of it, those who've been using it for creating
botnets love to see it.

I'm getting a bit tired of throwing away these "security advisories".
Really, someone should install a whole load of popular applications, ensure
any of them load their own files, and finally, thanks to a mass dependency
check, ensure DWM is being loaded at runtime.
At least, it would be just one email/thread to trash.

So, what's the security model around .ygwx files?

Post by YGN Ethical Hacker Group
The fixed version KeePass 2.13 has been released.
http://keepass.info/news/n100906_2.13.html
But failure to describe "DLL Hijacking was fixed".
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

YGN Ethical Hacker Group

2010-09-08 08:36:29 UTC

Permalink

A vulnerability is a vulnerability.
A SQL Injection is a type of Vulnerability.
For each type of Vulnerability, there will be thousands of web
applications that might be vulnerable to it.
DLL Hijacking is same.

We do each post rather than a list so that security vulnerability news
site can get required detailed information
as possible.

If you don't want it, set filter for each post subject with "DLL
Hijacking" or from our email.

We can't underestimate such an easy flaw that leads to system
compromise or command execution under user' privilege.

Disabling remote share/WebDav is not a solution to DLL Hijacking at all.

DLL Hijacking is highly effective in combination with the use of
Social Engineering Toolkit.

YGN Ethical Hacker Group

2010-09-13 17:03:55 UTC

Permalink

Isn't *any* mechanism for code execution going to be effective with the use
of social engineering? I mean, isn't that what we've known for years, that
the weakest component of any security system is the users?

Yes, we know. Don't get us wrong. We're not telling Social Engineering.
We're telling about Social Engineering Toolkit (SET) -
http://www.offensive-security.com/metasploit-unleashed/SET

What we mean is DLL Hijacking added a way to deliver payload to
entice users to execute it.
We've already drawn attention to SET authors and see how they will
leverage this issue.

DLL Hijacking is highly effective in combination with use of Social
Engineering Toolkit.

-- Rohit Patnaik

A vulnerability is a vulnerability.
A SQL Injection is a type of Vulnerability.
For each type of Vulnerability, there will be thousands of web
applications that might be vulnerable to it.
DLL Hijacking is same.
We do each post rather than a list so that security vulnerability news
site can get required detailed information
as possible.
If you don't want it, set filter for each post subject with "DLL
Hijacking" or from our email.
We can't underestimate such an easy flaw that leads to system
compromise or command execution under user' privilege.
Disabling remote share/WebDav is not a solution to DLL Hijacking at all.
DLL Hijacking is highly effective in combination with the use of
Social Engineering Toolkit.

Christian Sciberras

2010-09-08 23:44:33 UTC

Permalink

That is what others said, yet it installed automatically on mine.
The only interaction was that I allowed it to be downloaded and
installed....not really geeky at all...

I must say you'll have to take my word on it.

MS issued a patch quite some time ago.

http://support.microsoft.com/kb/2264107

That is not a "patch", not installed by default: is only for
uber-geeks who manually install it. Was issued a week ago, in
response to this kerfuffle, not "quite some time ago".
Which setting of CWDIllegalInDllSearch did you choose: was it
0xFFFFFFFF which may be "safe", but is known to break Outlook
(and others), as noted in
DLL hijacking vulnerabilities
http://isc.sans.edu/diary.html?storyid=9445
(geeks can add further tweaks to the registry to fix).
Cheers, Paul
School of Mathematics and Statistics University of Sydney Australia

Christian Sciberras

2010-09-09 10:52:32 UTC

Permalink

Bwt, you can simply turn our Internet-based test into an intranet or local test by
copying the files to your local share or a folder on your computer and double-click
the .wab file from there. The usual caution with runnning code from unknown sources
applies, of course.

I did better, I wrote my own test, which just like your test, it
failed proving the vulnerability.
The only difference was that I knew what was going wrong and tried to
get it to work in all ways possible;
it only seemed to work when the right possible wasn't anywhere near
the running executable (or system directories).

Unless the whole point of the vulnerability was to exploit non-existent dlls??

Can you please send the Process Monitor log for this case? We'll be happy to look
into your case.

Sure, fine by me.

Regards,
Chris.

On Thu, Sep 9, 2010 at 12:32 PM, Mitja Kolsek

Hi Chris,

Considering Acros highlighted how their POC was highly
unstable (they've frequently advised to try the program
several times to get it to work) I don't see such abnormal
behaviour out of this world.

Indeed, we're seeing problems with accessing (any) remote WebDAV shares from various
Windows computers, while it works just great on others. Based on network monitoring,
it doesn't seem to be the problem with the server though, but rather with occasionaly
unreliable support for WebDAV folders in Windows. We're looking for possible causes
and especially for workarounds that could improve the reliability.
We'll appreciate your feedback - tell us how it worked or didn't work for you. It's a
chance for us all to learn something new.
Bwt, you can simply turn our Internet-based test into an intranet or local test by
copying the files to your local share or a folder on your computer and double-click
the .wab file from there. The usual caution with runnning code from unknown sources
applies, of course.

One last thing, rather than just running a random POC I've
actually looked into what's going on, via Process Monitor,
and as far as it's concerned, it always loaded the correct
(ie, the original) dlls.

Can you please send the Process Monitor log for this case? We'll be happy to look
into your case.
Cheers,
Mitja Kolsek
CEO&CTO
ACROS, d.o.o.
Makedonska ulica 113
SI - 2000 Maribor, Slovenia
tel: +386 2 3000 280
fax: +386 2 3000 282
web: http://www.acrossecurity.com
ACROS Security: Finding Your Digital Vulnerabilities Before Others Do

Christian Sciberras

2010-09-09 10:53:49 UTC

Permalink

* replace my later "possible" with "dll" (to hell with distractions!)

Cheers,
Chris.

Post by Christian Sciberras

I did better, I wrote my own test, which just like your test, it
failed proving the vulnerability.
The only difference was that I knew what was going wrong and tried to
get it to work in all ways possible;
it only seemed to work when the right possible wasn't anywhere near
the running executable (or system directories).
Unless the whole point of the vulnerability was to exploit non-existent dlls??

Can you please send the Process Monitor log for this case? We'll be happy to look
into your case.

Sure, fine by me.
Regards,
Chris.
On Thu, Sep 9, 2010 at 12:32 PM, Mitja Kolsek

Hi Chris,

Considering Acros highlighted how their POC was highly
unstable (they've frequently advised to try the program
several times to get it to work) I don't see such abnormal
behaviour out of this world.

Stefan Kanthak

2010-09-11 16:49:27 UTC

Permalink

I can't take THAT seriously. At least not all of it.

4. Should I find such vulnerability in many applications as I can?
You should not. It's just a waste of time and your energy. Focus on most popular application types/classes.

If, say, DWM.dll is exploitable, why not point *that* out rather than
point out the many applications that are using it (wrongly)?

ANY DLL is/may be exploitable when referenced without its (often
well-known) complete pathname.
It IS necessary to name all the applications with unqualified
references and to have them fixed by their authors/vendors.

And there are MANY places where DLLs or EXEs are referenced, not just
in binaries: the registry, DESKTOP.INI files (especially in the start
menu and %ProgramFiles%), batch files (do you reference CMD.EXE always
as %SystemRoot%\System32\CMD.EXE? No? It really doesn't hurt!), scripts
(including AUTORUN.INF.-), ...

Stefan

Oh, and the "report". For obvious reasons, I cannot include the full
report. If I missed passing any detail, just ask and I'll fix right
away.
Loading Image...

Hi Christian
The reason I use "Clean" doesn't mean (or I'm not accusing) your
Windows is infected.
It's better to test DLL Hijacking in Clean Copy of Windows without any
prior applications messup.
Please take a look at
http://core.yehg.net/lab/pr0js/texts/when_testing_for_dll_hijacking.txt
We thank ACROS Security for bringing life to this issue.
We'll take social responsibility as a security community to stop this
issue as much as we could.