[FD] IPSwitch IMail Server WEB client 12.4 persistent XSS
# Exploit Title: IPSwitch IMail Server WEB client 12.4 persistent XSS # Date: 3 june 2014 # Exploit Author: Peru (GoSecure!) # Vendor Homepage: www.ipswitch.com # Software Link: http://www.imailserver.com/try/ # Version: Tested on 12.3 and 12.4 before 12.4.1.15 # Tested on: WindowsServer2008R2 STD SP1 # CVE : 2014-3878 (Calendar section) Four injection points were useful to create a persistent Cross Site Scripting. All the injections are reached using default Web Client interface, but the Web Client Lite seems to be not vulnerable to these tests. 1. Contacts section: A persistent XSS can be reached adding a new contact with a specific string in the Name field and whatever image: PoC string: GS! When the contact is saved and on mouse over the picture the Name is been displayed in a bubble activating the JS. 2. Contacts section: A vulnerability can also be reached in the Adding Group task. PoC string: http://www.google.it"; height=500 width=500 frameborder=1 align=center> 3. Calendar section: A persistent XSS can be reached adding a new event in the Calendar; this event can be spread adding the Meeting Request option. Since, using this injection point, the XSS can be spread to other users, this is the most dangerous of the four and can be used to spoofing sessions and therefore compromising the attacked users account. The JavaScript is executed simply viewing the calendar or when the Reminder pops up. PoC string: GS! 4.Task section: In a similar way also the tasks are vulnerable to persistent XXS. PoC string: http://www.mysite.com/remote/xss_h.html> Bye Peru ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] [oss-security] Bug in bash <= 4.3 [security feature bypassed]
In my opinion the drop of privs in bash was mostly a "help" measure for poorly written setuid programs executing system() calls. I don't think is the role of bash to do this as the problem that could be exploited by that would really be in the original program that does not drop privs before invoking the shell. This has been known for some time in some circles at least, but as I said the problem would really be in the non-priv-dropping privileged program, that's why most people did not really care that much. Last year there was a vuln that is very much related to this subject: http://blog.cmpxchg8b.com/2013/08/security-debianisms.html Correct me if I'm wrong, but even in that case there is another "help" measure that has been implemented at least in linux kernels > 3.1: http://lxr.free-electrons.com/source/kernel/sys.c?v=3.1#L628 Therefore setuid calls do not fail anymore even in the case of existing resource limits for processes (in linux). But in any case, for the sake of correctness I agree that the drop_priv code should be fixed (or just completely removed...). 2014-06-03 16:16 GMT+02:00 Hector Marco : > Hi everyone, > > Recently we discovered a bug in bash. After some time after reporting > it to bash developers, it has not been fixed. > > We think that this is a security issue because in some circumstances > the bash security feature could be bypassed allowing the bash to be a > valid target shell in an attack. > > We strongly recommend to patch your bash code. > > Why don't fix this bug by simple adding mandatory "if" clause ? > Any comments about this issue are welcomed. > > > Details at: > http://hmarco.org/bugs/bash_4.3-setuid-bug.html > > > > Thanks you, > > Hector Marco > http://hmarco.org -- Jose Carlos Luna Duran Network Software Engineering. jose.carlos.l...@gmail.com ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] More /tmp fun (PHP, Lynis)
After reading about today's "Check, rootkit" vulnerability (CVE-2014-0476),
I thought I'd share these stupid bugs:
BUG #1 - PHP's ./configure script writes a predictable filename to /tmp
allowing for a symlink attack against the user running the script
>From PHP 5.5.13:
18045 #include
18046 int main(int argc, char *argv[])
18047 {
18048 FILE *fp;
18049 long position;
18050 char *filename = "/tmp/phpglibccheck";
18051
18052 fp = fopen(filename, "w");
18053 if (fp == NULL) {
18054 perror("fopen");
18055 exit(2);
18056 }
18057 fputs("foobar", fp);
18058 fclose(fp);
18059
18060 fp = fopen(filename, "a+");
18061 position = ftell(fp);
18062 fclose(fp);
18063 unlink(filename);
18064 if (position == 0)
18065 return 1;
18066 return 0;
18067 }
Reported to secur...@php.net twice, no response ever received:
September 22, 2012
January 8, 2013
This issue goes back at least 10+ years, but no one configures/compiles PHP
as root and your files aren't important anyway.
BUG #2 - Lynis 1.5.4 (and presumably earlier) writes a predictable filename
to /tmp allowing for a symlink attack against the user running the script
Website: rootkit.nl
This utility, which is similar in nature to "chkrootkit" and "rkhunter" and
must be run as root, also writes a predictable filename to /tmp (you'll
have to win a race for this one). Unreported, because this is security
software. Therefore it is secure. (The logic is intentional. What's to
report?)
___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] Linksys E4200 Authentication Bypass
https://phra.gs/blob/2014-06-04-linksys-e4200-auth-bypass.html - - Jordan Bradley ph...@phra.gs https://keybase.io/phrag ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] TrueCrypt?
On 2014-06-03 04:09, Dave Howe wrote: The issue we have with the current TC builds is that they are not reproducible. The source code is available online, and is in the process of being audited, but there is no guarantee the installer almost all the users have installed TC with contained code actually built from that source. https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/ claims to have managed to build a reasonably identical build (such that the remaining differences can be identified and explained as build date/time stamps). The site includes instructions to reproduce the work. I haven't tried it personally, but it might be an interesting exercise to see if anyone else can independently reproduce the binaries. ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
