So, I am very curious how you are finding these? Have you automated this or is it manual hand work?
On Wed, Jul 23, 2014 at 2:50 PM, Stefan Kanthak <stefan.kant...@nexgo.de> wrote: > Hi @ll, > > the import function of Windows Mail executes a rogue program C:\Program.exe > with the credentials of another account, resulting in a privilege > escalation! > > 1. Fetch <http://home.arcor.de/skanthak/download/SENTINEL.EXE> and save > it as > C:\Program.exe > > 2. Start Windows Mail (part of Windows Vista and Windows Server 2008) > > 3. On the File menu, click Identities > > 4. On the entry page of the wizard click [ Continue > ] > > 5. Select "(*) Import identities of other Windows account" and click [ > Continue > ] > > 6. Enter account name and password of any Windows account > > 7. See the message from C:\Program.exe when Windows Mail runs the UNQUOTED > command line C:\Program Files\Windows Mail\WinMail.Exe /identcatalog > > > From <http://msdn.microsoft.com/library/cc144175.aspx> > or <http://msdn.microsoft.com/library/cc144101.aspx>: > > | Note: If any element of the command string contains or might contain > | spaces, it must be enclosed in quotation marks. Otherwise, if the > | element contains a space, it will not parse correctly. For instance, > | "My Program.exe" starts the application properly. If you use > | My Program.exe without quotation marks, then the system attempts to > | launch My with Program.exe as its first command line argument. > > > From <http://msdn.microsoft.com/en-us/ms682425.aspx>: > > | Security Remarks > | > | The lpApplicationName parameter can be NULL, and the executable name > | must be the first white space-delimited string in lpCommandLine. > | If the executable or path name has a space in it, there is a risk that > | a different executable could be run because of the way the function > | parses spaces. Avoid the following example, because the function > | attempts to run "Program.exe", if it exists, instead of "MyApp.exe". > ... > | If a malicious user were to create an application called "Program.exe" > | on a system, any program that incorrectly calls CreateProcess using > | the Program Files directory will run this application instead of the > | intended application. > | > | To avoid this problem, do not pass NULL for lpApplicationName. > | If you do pass NULL for lpApplicationName, use quotation marks around > | the executable path in lpCommandLine, as shown in the example below. > > > "Long" filenames were introduced 20 years ago, but M$FTs developers still > can't handle them properly, and their QA is unable to detect such silly > and trivial to spot bugs! > > > regards > Stefan Kanthak > > PS: yes, it needs administrative privileges to write C:\Program.exe. > BUT: all the user account(s) created during Windows setup have > administrative privileges. > > PPS: NO, the user account control is NO security boundary! > > <http://support.microsoft.com/kb/2526083> > > | Same-desktop Elevation in UAC is not a security boundary and can be > hijacked > | by unprivileged software that runs on the same desktop. Same-desktop > | Elevation should be considered a convenience feature, and from a security > | perspective, "Protected Administrator" should be considered the > equivalent > | of "Administrator." > > _______________________________________________ > Sent through the Full Disclosure mailing list > http://nmap.org/mailman/listinfo/fulldisclosure > Web Archives & RSS: http://seclists.org/fulldisclosure/ > -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website _______________________________________________ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/