[Full-Disclosure] [OpenPKG-SA-2005.004] OpenPKG Security Advisory (sasl)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenPKG Security AdvisoryThe OpenPKG Project http://www.openpkg.org/security.html http://www.openpkg.org [EMAIL PROTECTED] [EMAIL PROTECTED] OpenPKG-SA-2005.004 28-Jan-2005 Package: sasl Vulnerability: arbitrary code execution OpenPKG Specific:no Affected Releases: Affected Packages: Corrected Packages: OpenPKG CURRENT <= sasl-2.1.19-20040920 >= sasl-2.1.20-20041025 OpenPKG 2.2 <= sasl-2.1.19-2.2.0>= sasl-2.1.19-2.2.1 OpenPKG 2.1 <= sasl-2.1.18-2.1.0>= sasl-2.1.18-2.1.1 Affected Releases: Dependent Packages: OpenPKG CURRENT imapd kolab openldap::with_sasl postfix::with_sasl sendmail::with_sasl OpenPKG 2.2 imapd kolab openldap::with_sasl postfix::with_sasl sendmail::with_sasl OpenPKG 2.1 imapd kolab openldap::with_sasl postfix::with_sasl sendmail::with_sasl Description: A setuid and setgid application vulnerability was found in the Cyrus SASL library [0]. At application startup, libsasl2 attempts to build a list of all available SASL plugins which are available on the system. To do so, the library searches for and attempts to load every shared library found within the plugin directory. This location can be set with the SASL_PATH environment variable. In situations where an untrusted local user can affect the environment of a privileged process, this behavior could be exploited to run arbitrary code with the privileges of a setuid or setgid application. The Common Vulnerabilities and Exposures (CVE) project assigned the identifier CAN-2004-0884 [1] to the problem. Please check whether you are affected by running "/bin/openpkg rpm -q sasl". If you have the "sasl" package installed and its version is affected (see above), we recommend that you immediately upgrade it (see Solution) and any dependent packages as well [2][3]. Solution: Select the updated source RPM appropriate for your OpenPKG release [4][5], fetch it from the OpenPKG FTP service [6][7] or a mirror location, verify its integrity [8], build a corresponding binary RPM from it [2] and update your OpenPKG installation by applying the binary RPM [3]. For the most recent release OpenPKG 2.2, perform the following operations to permanently fix the security problem (for other releases adjust accordingly). $ ftp ftp.openpkg.org ftp> bin ftp> cd release/2.2/UPD ftp> get sasl-2.1.19-2.2.1.src.rpm ftp> bye $ /bin/openpkg rpm -v --checksig sasl-2.1.19-2.2.1.src.rpm $ /bin/openpkg rpm --rebuild sasl-2.1.19-2.2.1.src.rpm $ su - # /bin/openpkg rpm -Fvh /RPM/PKG/sasl-2.1.19-2.2.1.*.rpm Additionally, we recommend that you rebuild and reinstall any dependent packages (see above) as well [2][3]. References: [0] http://asg.web.cmu.edu/sasl/ [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0884 [2] http://www.openpkg.org/tutorial.html#regular-source [3] http://www.openpkg.org/tutorial.html#regular-binary [4] ftp://ftp.openpkg.org/release/2.2/UPD/sasl-2.1.19-2.2.1.src.rpm [5] ftp://ftp.openpkg.org/release/2.1/UPD/sasl-2.1.18-2.1.1.src.rpm [6] ftp://ftp.openpkg.org/release/2.2/UPD/ [7] ftp://ftp.openpkg.org/release/2.1/UPD/ [8] http://www.openpkg.org/security.html#signature For security reasons, this advisory was digitally signed with the OpenPGP public key "OpenPKG <[EMAIL PROTECTED]>" (ID 63C4CB9F) of the OpenPKG project which you can retrieve from http://pgp.openpkg.org and hkp://pgp.openpkg.org. Follow the instructions on http://pgp.openpkg.org/ for details on how to verify the integrity of this advisory. -BEGIN PGP SIGNATURE- Comment: OpenPKG <[EMAIL PROTECTED]> iD8DBQFB+ewigHWT4GPEy58RAjdyAJsFrQUG5q9DjmwiGvccEEIxU/mXbACg431X BjzkxqCH71N5ZEMlDoGBGwU= =kOee -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] NAT router inbound network traffic subversion
I have Googled around and asked a highly-respected Professor at my University whether it is possible to direct packets behind a NAT router without the internal 192.168.x.x clients first requesting a connection to the specific host outside. The answer I received is "not possible". I also asked if this can be thought of as a security feature, to which the reply was again "yes". Now, I wouldn't place all my bets on his answer and I am calling on someone out there to clear up my question. If NAT really does only allow inbound connections with a preliminary request as he suggests, it seems that the only way to get an "unauthorized" packet behind the router is by some flaw in the firmware of the device. How about if the client has requested a connection to Google.com from behind his Linksys home NAT router: would it be possible for an outside attacker to spoof packets from Google's IP to get packets into the network? Or do we need to know the sequence numbers as well? Or is there an even more devious way to get packets on the inside without a client's initiative? Has there been any research into this? Are there statistics on worm propagation and exploited network hosts in relation to those individuals that did not own routers (and instead connected directly to their modem)? If *all* home users on the Internet had NAT routers during the summer of 2003, would we have significantly slowed the spread of Blaster? I believe these all to be very important questions and the security aspects of the ability to route packets behind NAT really interests me...maybe some of you can elaborate :-) -- Kristian Hermansen <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Sify: ISP in India using hubs to provide connectivity
hi, This one is the most obvious problem, I am nevertheless reporting it since the ISP concerned has refused to take any action. Sify (www.sify.com/bbhome) is an ISP in India with second largest customer base and largest among broadband users. To provide broadband, they install a radio link near your place and than provide connectivity to many users via a HUB, not even a switch! The problem is obvious. I can listen to anyone's conversation and do anything at all, using stuff like dnsspoof and the likes. To top it all, they refuse to acknowledge that this is a problem warn that in case you run sniffers on our network, we will prosecute you! As if everyone who sniffs traffic is going to tell them. In a place like India where people are still on windows 98, scope of a major virus attack becomes many fold in such situations. Thanks Rohit ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy
On Thu, Jan 27, 2005 at 08:37:19PM +0100, Michal Zalewski wrote: > On Thu, 27 Jan 2005, Brad Spengler wrote: > > > I guess anyone who thinks that taking a hardcoded exploit and running it > > 256 times would always result in a successful exploit is stupid. > > It would not always result in a successful exploitation; just as flipping > the coin twice is not a guarantee of getting tails once. Of course, but you get the idea. Your chances of succeeding after 256 tries are such that it is highly probable you wouldn't fail (and in fact, if the process you're attacking is a forking daemon like apache, if you iterate through all the possibilities, you do indeed have a 100% chance of succeeding after 256 tries). > Other than that, the amount of randomization is indeed puny; but then, > even 32-bit randomization is a good defense only in certain situations, > and often, can be defeated with some time, aided by luck or a decent > NOP-equivalent sled. Indeed, and only PaX/grsecurity handles these things, which is why it is useful in our case. However, attempting to use weak randomization as RedHat is trying is nothing more than trivial obfuscation, which should have no place in the kernel. All it does is give people a false sense of security, and allow RedHat to make claims that they're preventing 75% of exploits with Exec-shield (of course ignoring that all such exploits that failed could be easily rewritten to succeed). Things have really taken a turn for the worse: Linus used to be against having only a non-executable stack because it's trivially evaded. Now he's all for something that is even more obfuscation than having only a non-executable stack: the exploits don't even have to be rewritten in this case. This all reeks of security ignorance and politics. -Brad signature.asc Description: Digital signature ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] NAT router inbound network traffic subversion
scenario... NAT client browses web... NAT client initates a HTTP request to do this... ROUTER returns the request to NAT client... ( normal activity ) attacker website exploits client browser... exploit drops and executes "badfile.exe" "badfile.exe" hooks iexplore.exe... "badfile.exe" is 'reverse connecting trojan'... "badfile.exe" initiates a HTTP request to do this... attacker's "badfile.exe"' 'client' is waiting with a HTTP server... the new hooked browser initiates a HTTP request to the attacker. NAT client is now connected to the attacker through the ROUTER ( kinda like browsing the web huh? ) attacker now has unrestricted packet via the NAT client, that is where ??? BEHIND YOUR ROUTER atacker now can do a he wishes to the rest of your network ( GAME OVER ) Cheers, m.w ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Winamp Exploit (POC) 5.08 Stack Overflow
Hello :) I´ve coded an exploit about this vulnerability, using the advisory "NSFOCUS SA2005-01 : Buffer Overflow in WinAMP in_cdda.dll CDA Device Name" as a guide. The advisory is very good, so it´s very easy to code the exploit. This code: cda://HHHnT _IJJJå3ÿWìÆEøcÆEùmÆEúdÆEû.ÆEüeÆEýxÆEþe¸D¿wP]øSÿÐ Should spawn a shell in a WinXP SP1 with Winamp 5.08, I have used as offset 0x5f20546e olepro32.dll, a "jmp esp" (nT _) å3ÿWìÆEøcÆEùmÆEúdÆEû.ÆEüeÆEýxÆEþe¸D¿wP]øSÿÐ is the scode in "printable" chars. I wrote the scode sometime ago, in http://foro.elhacker.net Its a very very simple scode, with hardcoded system() call (i´m a noob, sorry xD) I have used ... to see how big is the buffer, and to see where the ret is overflowed (in 5.08 exactly in HIII) In Winamp 5.05 works the same code, but the ret is "", so the exploit must have another "H": cda://nT _IJJJå3ÿWìÆEøcÆEùmÆEúdÆEû.ÆEüeÆEýxÆEþe¸D¿wP]øSÿÐ Then, the exploit works fine in Winamp 5.05 and spawns a shell :) I have only tested it in 5.08 and 5.05, but I think that its easy to "port" the exploit to another version. These codes can be saved in a archive type m3u (playlist archive Winamp) If you copy these codes in a text archive like this (Winamp 5.08): #EXTM3U #EXTINF:5,DJ Mike Llama - Llama Whippin' Intro cda://HHHnT _IJJJå3ÿWìÆEøcÆEùmÆEúdÆEû.ÆEüeÆEýxÆEþe¸D¿wP]øSÿÐ (for example, i have used the "demo" archive, DJ Mike Llama and edit the PLAY LIST ENTRY) And save as *.m3u file, if you open this (in this case, I repeat, with Winamp 5.08), a cmd shell will appear :) It´s trivial to change the shellcode to make a bindport, reverse shell, etc.. Sorry about my bad english, I´m spanish :)(Spain exists :D) Greets to http://www.elhacker.net and http://foro.elhacker.net and all the people I know, especially "her" (Isthar) :) THE REAL ELHACKER.NET! :D Best regards. Rojodos [EMAIL PROTECTED] 2005-01-28 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] NAT router inbound network traffic subversion
In message <[EMAIL PROTECTED]>, Kristian Hermansen <[EMAIL PROTECTED]> writes I have Googled around and asked a highly-respected Professor at my University whether it is possible to direct packets behind a NAT router without the internal 192.168.x.x clients first requesting a connection to the specific host outside. The answer I received is "not possible". I also asked if this can be thought of as a security feature, to which the reply was again "yes". Yes. But see later. Now, I wouldn't place all my bets on his answer and I am calling on someone out there to clear up my question. If NAT really does only allow inbound connections with a preliminary request as he suggests, it seems that the only way to get an "unauthorized" packet behind the router is by some flaw in the firmware of the device. If you are not offering any services to the Internet, yes. If you are, then you have ports open on the router, redirecting to real machines, which may be running software which can be exploited. This is how worms spread. the home user is unlikely to be hit by a worm, unless they are running a Windows NT-derived operating system, such as XP, without a firewall and/or NAT device. Commercial installations such as web servers are the main targets for worms. How about if the client has requested a connection to Google.com from behind his Linksys home NAT router: would it be possible for an outside attacker to spoof packets from Google's IP to get packets into the network? Or do we need to know the sequence numbers as well? Or is there an even more devious way to get packets on the inside without a client's initiative? Google for "man in the middle" attack. Has there been any research into this? Are there statistics on worm propagation and exploited network hosts in relation to those individuals that did not own routers (and instead connected directly to their modem)? If *all* home users on the Internet had NAT routers during the summer of 2003, would we have significantly slowed the spread of Blaster? I believe these all to be very important questions and the security aspects of the ability to route packets behind NAT really interests me...maybe some of you can elaborate :-) Worms are not usually an issue for home users, except when someone sells an operating system with ports open to the Internet by default. XP pre-service pack 2 is such an operating system. Its users were duly hammered by worms, and would not have been if they used the built-in firewall, which was not enabled by default. I'm not sure how much a NAT device would have helped on its own. Modern versions of Windows are extremely talkative, and it may well have invited the bad guys in of its own accord. But widespread use of the firewall would have stopped it. More troublesome for home users are viruses spread by email, which initiate connections through the firewall, router or other device from the inside. The security device cannot generally tell whether the user or a virus has made the request, though third-part 'personal' firewalls, running on the user's workstation, are becoming quite good at this. I don't think Internet Explorer currently runs any code in an incoming email automatically, as it once did, but it's not hard to persuade many users to click on a button and run the virus themselves. Most viruses are now also worms, they will attempt to spread both by email and by direct contact with unprotected machines. -- Joe ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] [ GLSA 200501-39 ] SquirrelMail: Multiple vulnerabilities
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200501-39 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: High Title: SquirrelMail: Multiple vulnerabilities Date: January 28, 2005 Bugs: #78116 ID: 200501-39 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis SquirrelMail fails to properly sanitize user input, which could lead to arbitrary code execution and compromise webmail accounts. Background == SquirrelMail is a webmail package written in PHP. It supports IMAP and SMTP and can optionally be installed with SQL support. Affected packages = --- Package / Vulnerable / Unaffected --- 1 mail-client/squirrelmail <= 1.4.3a-r2>= 1.4.4 Description === SquirrelMail fails to properly sanitize certain strings when decoding specially-crafted strings, which can lead to PHP file inclusion and XSS. * Insufficient checking of incoming URLs in prefs.php (CAN-2005-0075) and in webmail.php (CAN-2005-0103). * Insufficient escaping of integers in webmail.php (CAN-2005-0104). Impact == By sending a specially-crafted URL, an attacker can execute arbitrary code from the local system with the permissions of the web server. Furthermore by enticing a user to load a specially-crafted URL, it is possible to display arbitrary remote web pages in Squirrelmail's frameset and execute arbitrary scripts running in the context of the victim's browser. This could lead to a compromise of the user's webmail account, cookie theft, etc. Workaround == The arbitrary code execution is only possible with "register_globals" set to "On". Gentoo ships PHP with "register_globals" set to "Off" by default. There are no known workarounds for the other issues at this time. Resolution == All SquirrelMail users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=mail-client/squirrelmail-1.4.4" Note: Users with the vhosts USE flag set should manually use webapp-config to finalize the update. References == [ 1 ] SquirrelMail Advisory http://sourceforge.net/mailarchive/message.php?msg_id=10628451 [ 2 ] CAN-2005-0075 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0075 [ 3 ] CAN-2005-0103 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0103 [ 4 ] CAN-2005-0104 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0104 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200501-39.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 [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2005 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.0 pgphOcGB5Usfp.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] [ Positive Technologies ] Defeating Microsoft Windows XP SP2 Heap protection
It was discovered by MaxPatrol team that it is possible to defeat Microsoft® Windows® XP SP2 Heap protection and Data Execution Prevention mechanism. As a result it is possible to implement: - Arbitrary memory region write access (smaller or equal to 1016 bytes); - Arbitrary code execution; - DEP bypass. Details are described in the article: http://www.maxpatrol.com/ptmshorp.asp -- Best regards, aanisimov mailto:[EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Re: NAT router inbound network traffic subversion
I think the answers that I received in response to my query are somewhat obvious -- yes -- but neither answered my question! Morning Wood's analysis was brilliant as ever, like always ;-P "atacker now can do a he wishes to the rest of your network ( GAME OVER )" Ummm...okay. The problem with you was this statement: "NAT client browses web..." HOW IS THIS NOT USER INTERACTION?!?!? I asked if there is a computer on the internal network that doesn't do anything -- that means SENDING NO PACKETS to the router -- if an attacker can get EVEN ONE PACKET inside: then they will prove everyone wrong, right? If one packet can get through, it can be considered a rogue packet that should not have entered the internal network destined for a particular host -- or better yet -- an internal broadcast address going to all hosts. Some say getting these rogue packets into the network is "impossible". That is the reason for my question. I like to think that most problems are "intractable", but not "impossible". Can anyone prove me wrong? Can someone push a rogue packet behind a router with no client interaction??? This is my chautauqua... -- Kristian Hermansen <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] NAT router inbound network traffic subversion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Check it here -> http://www1.cs.columbia.edu/~smb/papers/fnat.pdf This should help clarify why NAT can not be considered a security feature. On Thu, 27 Jan 2005 22:12:19 -0800 Kristian Hermansen <[EMAIL PROTECTED]> wrote: >I have Googled around and asked a highly-respected Professor at my >University whether it is possible to direct packets behind a NAT >router >without the internal 192.168.x.x clients first requesting a >connection >to the specific host outside. The answer I received is "not >possible". >I also asked if this can be thought of as a security feature, to >which >the reply was again "yes". > >Now, I wouldn't place all my bets on his answer and I am calling >on >someone out there to clear up my question. If NAT really does >only >allow inbound connections with a preliminary request as he >suggests, it >seems that the only way to get an "unauthorized" packet behind the >router is by some flaw in the firmware of the device. > >How about if the client has requested a connection to Google.com >from >behind his Linksys home NAT router: would it be possible for an >outside >attacker to spoof packets from Google's IP to get packets into the >network? Or do we need to know the sequence numbers as well? Or >is >there an even more devious way to get packets on the inside >without a >client's initiative? > >Has there been any research into this? Are there statistics on >worm >propagation and exploited network hosts in relation to those >individuals >that did not own routers (and instead connected directly to their >modem)? If *all* home users on the Internet had NAT routers >during the >summer of 2003, would we have significantly slowed the spread of >Blaster? I believe these all to be very important questions and >the >security aspects of the ability to route packets behind NAT really >interests me...maybe some of you can elaborate :-) >-- >Kristian Hermansen <[EMAIL PROTECTED]> -BEGIN PGP SIGNATURE- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.4 wkYEARECAAYFAkH6Z/UACgkQ1kZ6e0Djf6zn3wCgiIb4yUWKP82hge9Oml7Qp75lOR0A oK4bjNPHtARambOFA4IallqA/b8C =Z8vB -END PGP SIGNATURE- Concerned about your privacy? Follow this link to get secure FREE email: http://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger http://www.hushmail.com/services-messenger?l=434 Promote security and make money with the Hushmail Affiliate Program: http://www.hushmail.com/about-affiliate?l=427 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Re: NAT router inbound network traffic subversionouter inbound network traffic subversion
You said: HOW IS THIS NOT USER INTERACTION?!?!? I asked if there is a computer on the internal network that doesn't do anything -- that means SENDING NO PACKETS to the router - If my english's not so bad,i think: "Somebody already answered:" Now, I wouldn't place all my bets on his answer and I am calling on someone out there to clear up my question. If NAT really does only allow inbound connections with a preliminary request as he suggests, it seems that the only way to get an "unauthorized" packet behind the router is by some flaw in the firmware of the device. If you are not offering any services to the Internet, yes. If you are, then you have ports open on the router, redirecting to real machines, which may be running software which can be exploited. Now, I wouldn't place all my bets on his answer and I am calling on someone out there to clear up my question. If NAT really does only allow inbound connections with a preliminary request as he suggests, it seems that the only way to get an "unauthorized" packet behind the router is by some flaw in the firmware of the device. *If you are not offering any services to the Internet, yes. If you are, then you have ports open on the router, redirecting to real machines, which may be running software which can be exploited.* However ... i'm reading on an italian e-zine an article sentencing that: NAT is not a security feature. Sorry, it's in italian and don't have time to translate it. It explain some way to pass a router's NAT... maybe you can translate it using some net translator or better finding an english version of that. Here you are, however: http://www.s0ftpj.org/bfi/dev/BFi13-dev-17 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] War-ftpd bug small addition
To fix the buggus advisory spreaded everywhere saying that you need to be authenticated, It's false Mc.Iglo ;) USER %s*115A PASS blahblah http://secunia.com/advisories/14054/ -class101Jr. ResearcherHat-Squad.com- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] NAT router inbound network traffic subversion
See http://www.phrack.org/show.php?p=62&a=3 "The Impact of RFC Guidelines on DNS Spoofing Attacks" by have2Banonymous The short version - Windows sends DNS queries from a consistent source port - 1026 in the author's tests, and with predictable request IDs - the first request after boot up is 1, then 2,3,4... (like an idiot's luggage combination) You can predict what DNS server an home ISP user will query; it's the ISP's DNS server. Using source port 53, and destination port 1026, you have everything you need to get phoney DNS replies past the NAT router. If you brute-force the lower hundred or so request IDs, you're reasonably likely to hit a request ID the DNS client just sent, assuming the computer was booted recently. And, here's the kicker - Windows doesn't check if the answer matches the question it asked - if you look up www.good.org, and an attacker manages to sneak in a phoney reply packet telling you that www.evil.com has address 6.6.6.6, that will be good enough. And your browser will be directed to the evil server, but show the good one's name in the address bar. Cheers Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristian Hermansen Sent: January 27, 2005 23:12 To: full-disclosure@lists.netsys.com Subject: [Full-Disclosure] NAT router inbound network traffic subversion I have Googled around and asked a highly-respected Professor at my University whether it is possible to direct packets behind a NAT router without the internal 192.168.x.x clients first requesting a connection to the specific host outside. The answer I received is "not possible". I also asked if this can be thought of as a security feature, to which the reply was again "yes". Now, I wouldn't place all my bets on his answer and I am calling on someone out there to clear up my question. If NAT really does only allow inbound connections with a preliminary request as he suggests, it seems that the only way to get an "unauthorized" packet behind the router is by some flaw in the firmware of the device. How about if the client has requested a connection to Google.com from behind his Linksys home NAT router: would it be possible for an outside attacker to spoof packets from Google's IP to get packets into the network? Or do we need to know the sequence numbers as well? Or is there an even more devious way to get packets on the inside without a client's initiative? Has there been any research into this? Are there statistics on worm propagation and exploited network hosts in relation to those individuals that did not own routers (and instead connected directly to their modem)? If *all* home users on the Internet had NAT routers during the summer of 2003, would we have significantly slowed the spread of Blaster? I believe these all to be very important questions and the security aspects of the ability to route packets behind NAT really interests me...maybe some of you can elaborate :-) -- Kristian Hermansen <[EMAIL PROTECTED]> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] NAT router inbound network traffic subversion
Actually...if you bothered to read the whole work, and did not just skim it, you would see that the team at Columbia very specificially states that their analytic techniques can be easily confused, and that there are basic steps for NAT use/configuration that render their techniques basically useless. Also, as intranet traffic fogs their results considerably, they state that this technique is not at all valid where such traffic occurs. There are more caveats, such as proximity to the source NAT device, etc...as well as the process missing multiple machines...in the paper, but enough...you get my point. No offense, but their work does not say what you said it says. Bart Lansing Manager, Desktop Services/Lotus Notes Kohl's IT [EMAIL PROTECTED] wrote on 01/28/2005 10:26:40 AM: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Check it here -> http://www1.cs.columbia.edu/~smb/papers/fnat.pdf > > This should help clarify why NAT can not be considered a security > feature. > > > On Thu, 27 Jan 2005 22:12:19 -0800 Kristian Hermansen > <[EMAIL PROTECTED]> wrote: > >I have Googled around and asked a highly-respected Professor at my > >University whether it is possible to direct packets behind a NAT > >router > >without the internal 192.168.x.x clients first requesting a > >connection > >to the specific host outside. The answer I received is "not > >possible". > >I also asked if this can be thought of as a security feature, to > >which > >the reply was again "yes". > > > >Now, I wouldn't place all my bets on his answer and I am calling > >on > >someone out there to clear up my question. If NAT really does > >only > >allow inbound connections with a preliminary request as he > >suggests, it > >seems that the only way to get an "unauthorized" packet behind the > >router is by some flaw in the firmware of the device. > > > >How about if the client has requested a connection to Google.com > >from > >behind his Linksys home NAT router: would it be possible for an > >outside > >attacker to spoof packets from Google's IP to get packets into the > >network? Or do we need to know the sequence numbers as well? Or > >is > >there an even more devious way to get packets on the inside > >without a > >client's initiative? > > > >Has there been any research into this? Are there statistics on > >worm > >propagation and exploited network hosts in relation to those > >individuals > >that did not own routers (and instead connected directly to their > >modem)? If *all* home users on the Internet had NAT routers > >during the > >summer of 2003, would we have significantly slowed the spread of > >Blaster? I believe these all to be very important questions and > >the > >security aspects of the ability to route packets behind NAT really > >interests me...maybe some of you can elaborate :-) > >-- > >Kristian Hermansen <[EMAIL PROTECTED]> > -BEGIN PGP SIGNATURE- > Note: This signature can be verified at https://www.hushtools.com/verify > Version: Hush 2.4 > > wkYEARECAAYFAkH6Z/UACgkQ1kZ6e0Djf6zn3wCgiIb4yUWKP82hge9Oml7Qp75lOR0A > oK4bjNPHtARambOFA4IallqA/b8C > =Z8vB > -END PGP SIGNATURE- > > > > > Concerned about your privacy? Follow this link to get > secure FREE email: http://www.hushmail.com/?l=2 > > Free, ultra-private instant messaging with Hush Messenger > http://www.hushmail.com/services-messenger?l=434 > > Promote security and make money with the Hushmail Affiliate Program: > http://www.hushmail.com/about-affiliate?l=427 > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html CONFIDENTIALITY NOTICE: This is a transmission from Kohl's Department Stores, Inc. and may contain information which is confidential and proprietary. If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited. If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000. CAUTION: Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages by authorized Kohl's Associates at any time without any further consent. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Fwd: [Full-Disclosure] FW: MS Antispyware makes deal to leave Weatherbug alone
On Tue, 11 Jan 2005 11:16:33 -0600, Todd Towles <[EMAIL PROTECTED]> wrote: > And the money payoff begins.. > > > -Original Message- > > From: jaynine [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 11, 2005 6:48 AM > > To: Patch Management Mailing List > > Subject: MS Antispyware makes deal to leave Weatherbug alone > > > > I read this rather disturbing article on another tech list. > > Pardon me if someone here has already made reference to it. > > > > --- j9 > > > > http://netrn.net/spywareblog/archives/2005/01/07/adware-vs-microsoft/ > > > > 1/7/2005 > > Adware vs. Microsoft > > > > It's started folks. WeatherBug Miffed at Microsoft's Spyware > > Classification . > > > > Microsoft Corp.'s newly released anti-spyware is flagging a > > component of AWS Convergence Technologies' WeatherBug > > application as a threat to Windows users, prompting an > > immediate complaint from the Gaithersburg, Md.-based company. > > > > It appears this dispute has been resolved already: A > > Microsoft spokeswoman said the beta product included a vendor > > dispute-resolution mechanism to deal with complaints from > > third-party companies. > > > > In the case of WeatherBug, the dispute-resolution process > > paid immediate dividends. On Friday, the company received a > > response from Microsoft with the good news that the current > > signatures for Minibug will be removed. > > > > Funny how MS/Giant are with a competing product Let's see what they say about Spybot Search & Destroy 1.3 ? I think it has been available for a while. I think a lot of admins have analysed it's effects as well ;-) An Unknown BrowserHelper Objet (BHO) Requires Approval [in BOLD] Microsoft AntiSpyware has detected a Browser Helper Object trying to be added. A BHO is an application that extends Internet Explorer and acts as a plug-in allowing the BHO full control of Internet Explorer. Name: Spybot - Search & Destroy Description: Bad download blocker Publisher: Safer Networking Limited Path: c:\program files\spybot - search & destroy\sdhelper.dll Advise: While this is not a known spyware threat, you might want to analyze this program followed by a Click here for more information about this alert What does this Application Agent do? The Browser Helper Object (BHO) Agent monitors additions to your Internet Explorer BHOs. If the BHO being installed is known to be safe, the agent allows it. If it is known to be spyware, the agent blocks it and notifies you. What is a browser helper object? A browser helper object (BHO) is an application that extends Internet Explorer and acts as a plug-in. Spyware and browser redirectors often use BHOs to display advertisements or monitor your activities across the Internet. BHOs are also used by a number of legitimate applications such as the toolbars offered by some common search sites. Applications that install BHOs are becoming more popular because they enable developers to control Internet Explorer through its native object model and provide useful functionality. For example, some legitimate applications use BHOs to monitor page navigation and show related page links. Others use them to monitor and control file downloading. It is very likely that you have BHOs installed on your computer that you don't know about. While there are good uses for BHOs, in some cases, you might not know that they are installed and they can be used for purposes like gathering information on your browsing habits. Spyware and BHOs can unintentionally cause problems ranging from incompatibility issues to corrupting important system functions. -- Thanks for using ByteBusters . Please email [EMAIL PROTECTED] or call (506) 657-BYTE for further assistance. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] [ GLSA 200501-40 ] ngIRCd: Buffer overflow
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200501-40 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: High Title: ngIRCd: Buffer overflow Date: January 28, 2005 Bugs: #79705 ID: 200501-40 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ngIRCd is vulnerable to a buffer overflow that can be used to crash the daemon and possibly execute arbitrary code. Background == ngIRCd is a free open source daemon for Internet Relay Chat (IRC). Affected packages = --- Package / Vulnerable / Unaffected --- 1 net-irc/ngircd < 0.8.2 >= 0.8.2 Description === Florian Westphal discovered a buffer overflow caused by an integer underflow in the Lists_MakeMask() function of lists.c. Impact == A remote attacker can exploit this buffer overflow to crash the ngIRCd daemon and possibly execute arbitrary code with the rights of the ngIRCd daemon process. Workaround == There is no known workaround at this time. Resolution == All ngIRCd users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=net-irc/ngIRCd-0.8.2" References == [ 1 ] ngIRCd Release Annoucement http://arthur.ath.cx/pipermail/ngircd-ml/2005-January/000228.html Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200501-40.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 [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2005 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.0 signature.asc Description: OpenPGP digital signature ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] ICMP Covert channels question
I've been doing some research on creating covert channels using icmp packets and a bounce server and so far everything worked fine. I can contact my web server through a bounce server outside of my network (like www.google.com or whatever). In my current setup both client and target are located in the same network and comunicate through the bounce server using icmp packets. Now, would it be possible to access a server behind a firewall, that normally isn't accessable, using this technique, if i'm outside of the target network? Assume there is a local machine (our target) with ip 192.168.0.2 that is connected to the internet using a router 192.168.0.1/88.88.88.88 (that is not blocking icmp packets) and my machine is say, 33.33.33.33. If i then send an icmp packet to the 88.88.88.88 router with source ip set to 192.168.0.2, would it forward that packet to the host in its local network, or will it discard it? Is there any way to deliver my packet to that local machine? ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] NAT router inbound network traffic subversion
You should probably clarify exactly what type of NAT implemenation you're speaking about. After all, it's perfectly common to leverage dedicated static NATs to support inbound connections for internal (and typically non-routed) hosts. Thank you, Darren Bounds Intrusense, LLC. On Jan 28, 2005, at 1:12 AM, Kristian Hermansen wrote: I have Googled around and asked a highly-respected Professor at my University whether it is possible to direct packets behind a NAT router without the internal 192.168.x.x clients first requesting a connection to the specific host outside. The answer I received is "not possible". I also asked if this can be thought of as a security feature, to which the reply was again "yes". Now, I wouldn't place all my bets on his answer and I am calling on someone out there to clear up my question. If NAT really does only allow inbound connections with a preliminary request as he suggests, it seems that the only way to get an "unauthorized" packet behind the router is by some flaw in the firmware of the device. How about if the client has requested a connection to Google.com from behind his Linksys home NAT router: would it be possible for an outside attacker to spoof packets from Google's IP to get packets into the network? Or do we need to know the sequence numbers as well? Or is there an even more devious way to get packets on the inside without a client's initiative? Has there been any research into this? Are there statistics on worm propagation and exploited network hosts in relation to those individuals that did not own routers (and instead connected directly to their modem)? If *all* home users on the Internet had NAT routers during the summer of 2003, would we have significantly slowed the spread of Blaster? I believe these all to be very important questions and the security aspects of the ability to route packets behind NAT really interests me...maybe some of you can elaborate :-) -- Kristian Hermansen <[EMAIL PROTECTED]> ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Re: NAT router inbound network traffic subversion
>Can anyone prove me wrong? Can someone push a rogue packet behind a router >with no client interaction??? I don't claim to be an expert on this, and I'm actually kind of surprised no one has mentioned this yet to you but yes, it is always possible. There is such a thing as "idlescanning" that does something kind of like this. It works very well on NAT routers to expand the inhabitants on the other side. The players are A, Z, and T; attacker, zombie, and target, respectively. There's a chart on the nmap page about it. http://www.insecure.org/nmap/idlescan.html hping is another tool that might work to accomplish what you are describing. The complication here is that you cannot simply craft packets to arbitrarily send to those on the other side of a NAT router. But you can determine how many clients are behind a NAT and spoof packets from them to the router and the router will craft packets in response. If you could get the router to respond a particular way, you could possibly use that to your advantage in a DoS or other malicious way. But the applications that would be succeptible to this must have been coded very poorly. Still, supposing a personal firewall automatically blocks an IP if it sends a flood of requests, you could use this to make the firewall block it's own router. This would result in a DoS for the user running the firewall, and it didn't involve any interaction on their part. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] ICMP Covert channels question
--On Friday, January 28, 2005 11:45:00 PM +0100 cyberpixl <[EMAIL PROTECTED]> wrote: Assume there is a local machine (our target) with ip 192.168.0.2 that is connected to the internet using a router 192.168.0.1/88.88.88.88 (that is not blocking icmp packets) and my machine is say, 33.33.33.33. If i then send an icmp packet to the 88.88.88.88 router with source ip set to 192.168.0.2, would it forward that packet to the host in its local network, or will it discard it? Is there any way to deliver my packet to that local machine? No, because non-routeable addresses are...wellnon-routeable. The only exception to this is *if* the target machine already had a session going with 33.33.33.33 (and it would obviously be nat'd/pat'd) there is a snort time frame within with your icmp packet would be delivered because the firewall is still translating the address/port for that session. Of course you have to know in advance all those variables, so, since you're sitting right there, just pound the dern thing with a hammer and be done with it. :-) Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] ICMP Covert channels question
On 28 Jan 2005, at 14:45, cyberpixl wrote: Assume there is a local machine (our target) with ip 192.168.0.2 that is connected to the internet using a router 192.168.0.1/88.88.88.88 (that is not blocking icmp packets) and my machine is say, 33.33.33.33. If i then send an icmp packet to the 88.88.88.88 router with source ip set to 192.168.0.2, would it forward that packet to the host in its local network, or will it discard it? Depends entirely on the router's configuration. Most will forward it; however, some will, whether out of misimplementation or paranoia, drop it. Is there any way to deliver my packet to that local machine? There are some other nifty tricks you ought to check out. For example, take a look at LimeWire's 'UDPConnect' protocol. PGP.sig Description: This is a digitally signed message part ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] ICMP Covert channels question
cyberpixl wrote: I've been doing some research on creating covert channels using icmp packets and a bounce server and so far everything worked fine. I can contact my web server through a bounce server outside of my network (like www.google.com or whatever). In my current setup both client and target are located in the same network and comunicate through the bounce server using icmp packets. Speaking of covert channels... http://www.cs.tau.ac.il/tausec/lectures/Network_Covert_Channels.pps Gadi. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
