Re: [Full-Disclosure] Windows Registry Analzyer
On Thu, 2005-03-03 at 10:35 -0500, Danny wrote: Anyone know of any free tools to analyze what changes have been made to a Windows 2000/XP registry? There used to be a company/product called Intact, which provided change monitoring of Registry settings as part of its HIDS offerings. I'm not sure if they are still around or got bought. Unfortunately it's not a free tool though. Regards, Frank 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] IDS Signatures
On Thu, 2005-02-24 at 22:33 +0530, John Galt wrote: I am also in the process of implementing a NIDS in Linux, only I am attempting to make it proactive, more like an IPS. As far as your work is concerned, do take a look at snort. [...] With regard to my task of making the system proactive, can some one give some pointers to me? Right now i have configured ssh as rsh, so remote execution is a breeze. I am controlling all traffic through a firewall, so that when snort sees as attack (say critical attack), i can have a script constantly parse the logs and block the offending IP at the firewall. John, take a look at Snortsam (http://www.snortsam.net). Several years ago, I had script, like you have now, running on Snort and a Checkpoint firewall so that Snort could block there. That script was rewritten into a C app so that it allowed extended functionality like white lists and a sort of attack mitigation system. Also, running as a daemon has the advantage that multiple Snort sensors can request a block on multiple firewalls. I like to call it an Intrusion Response Network :) Snortsam supports a variety of firewalls, making it attractive as a single-shot comprehensive solution. You can configure it to block out attackers or port scanner, but you can also configure it to automatically isolate compromised hosts (stuff you would do by yourself, except that Snortsam does it within a second, even at 4am Sunday morning). For example, it can isolate a compromised DMZ server by causing the DMZ firewall to block all outbound (and inbound) access from/to that compromised box. Or it can block attackers from coming in. There are a few solution that do that, but I think the distributed nature of Snortsam makes it pretty attractive. You can detect an attacker (say Nessus scan or so) in your London office and block him in London, but also Tokyo, Frankfurt, New York, etc. Check it out, it might suit your needs well. Feel free to email me if you have questions. Regards, Frank 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] How T-Mobil's network was compromised
On Sun, 2005-02-20 at 01:09 +0200, Willem Koenings wrote: I've seen cases where user input is correctly sanitized, but there was a flaw. Can you please bring an example? I'll give you three: 1) User input is passed to a function which sanitizes the input by converting dangerous characters to HTML representations. Function works perfectly, changes into lt;, into gt; Function is flawless from a programming perspective and performs as written. The only flaw was on a logic perspective since the function forgot to change into quote; (That's an obvious example. What I have observed all too often is a change of all known hostile characters. Yet chars =255 and 32 are not examined/converted). 2) User input is passed to a function which munges the input and converts in the input strings to output strings. Works perfectly, changes all characters except harmless ones. Function is flawless from a logic perspective and performs as expected. The only flaw is a missing call to free() which results in a memory leak. 3) (and based on a recent example, I just can't find the reference... it was some PHP app): Input URLs are examined for ../ and converted into ./. The function worked correctly, no flaw from a programming perspective. However, input of .../ was converted to ../ as planned, but leaving the application still vulnerable. (Note: I don't think the fix to that problem was all that great. What should have occurred is a check for ../ in a loop. Change and replace as often as ../ is found. There was no such loop in the suggested fix afair) The point is that often code works correctly, stable and secure, and does what the programmer intended to do. However, sometimes the programmer overlooked a condition to check for. The lack of that check is not a flaw in the code. A reviewer may not find it because he may not conceive a requirement for such a check either. So the code is correct, no flaws in it. Yet it will fail under certain conditions. We can only check for the existence of those flaws that we are aware of. We can not say that tested code does not have flaws that we didn't conceive. Regards, Frank 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] How T-Mobil's network was compromised
On Sun, 2005-02-20 at 21:26 +0200, Willem Koenings wrote: Yes, and thats why i said, that original quote is not always true because it is differently understandable. If i know one specific flaw or vulnerability, then i specifically can test against presence or absence of that specific flaw or vulnerability. hehe... no, no. The quote said flaws. Not a specific one. Flaws are errors as we know them. You can test for the presence of the ones we know, the specific ones. And you can test for the absence of these specific ones. But you can't test for the absence of any flaw. That would be akin to testing the presence of anti-flaws. What is a non-error? A non-flaw? It's a non-existing flaw, it doesn't exist. If could define and measure that to the extent that you can test for it, then Dijkstra can be proved wrong :) Until then the invert of presence of flaws is absence of flaws. And we can only test for the former. Cheers, Frank 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] How T-Mobil's network was compromised
On Sat, 2005-02-19 at 16:12 +0200, Willem Koenings wrote: - user input is correctly sanitized and there is no flaw - use input is not correctly sanitized and there is a flaw I've seen cases where user input is correctly sanitized, but there was a flaw. If you tested your whole parameter set and don't find a flaw, it doesn't mean that none exists. There could be a flaw that you haven't found with your set of tests. That's what the quote is eluding to. You can say for sure that there is a flaw, but you can not say for sure that there is not one. You can't test for the absence. So above saying is not always completly true. But you can't use testing to find something you don't know at this exact moment - unknown flaws. Well, that's exactly the point of the quote :) Cheers, Frank 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] Administrivia: List Compromised due to Mailman Vulnerability
On Wed, 2005-02-09 at 18:15 +, John Cartwright wrote: Subscriber addresses and passwords have been compromised. All list members are advised to change their password immediately. There do not appear to be further signs of intrusion although investigations continue. To prevent getting lulled into a phishing scam, could you please confirm the fingerprints of the self-signed SSL certificate that mailman is running on? :) Thanks, Frank 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] Administrivia: List Compromised due to Mailman Vulnerability
On Wed, 2005-02-09 at 15:01 -0500, [EMAIL PROTECTED] wrote: To prevent getting lulled into a phishing scam, could you please confirm the fingerprints of the self-signed SSL certificate that mailman is running on? :) Bonus points if the fingerprint is in a mail that's digitally signed, so we know the phisher isn't faking the mail Hand me some more tinfoil, will ya? :) heh... nah, having John look at the cert and say Yup, that's mine is enough of a trust-level for me. (On the other hand, if he says Oh shit! then the verification step has served its purpose :) Cheers, Frank (who knows he's being watched ;) 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] RANT Cart00ney-Sigs (was: Re: Freenet clone)
On Fri, 2005-02-04 at 07:58 -0600, J.A. Terranson wrote: I'm not gonna ask the more common question, since I can plainly see the answer of No, I didn't have the money to pay a lawyer to write shit for me... heh... or just a very cheap one ;) Cheers, Frank Agreement: You are not allowed to read this email. If you are reading this, you already have read to this point and are in violation of this agreement. Please contact the sender to make arrangement for the deposit of your out-of-court settlement. You may not use this email or email address. By contacting the sender for the settlement, you are violating yet another section. Since you are already planning on settlement payments, please double your payment. Disclaimer: The sender of this email disclaims any type of brain activity related to sense or reason pertaining to the contents of this email. 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] RE: Scan for IRC
On Sat, 2005-01-22 at 03:25 +, Nikolay Baramov wrote: Other ports commonly used are 7000 and 9000. And another, perhaps even more commonly used port, is 443 since that is allowed unproxied/uninspected through most firewalls. (clear-text IRC on port 443, although IRC can also be run over SSL) Regards, Frank 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] harddisk encryption
On Thu, 2005-01-20 at 10:27 +0100, Lentila de Vultur wrote: i'm evaluating a software that performs harddisk encryption for deploying in my company. the software in question is utimaco safeguard easy v4.10 (www.utimaco.com) running on w2k. i am interested in communitty's oppinion about this product. Since others are still throwing in their recommendations, let me add mine as well. Back in the days when I used Windows, I really liked HardDisk Encryption Plus from PCGuardian (www.pcguardian.com). It is a full-disk encryption program (or just a partition if you like). My old NT4 laptop was encrypted with it. No problems. Nice admin and recovery features. But what I really liked was the transparent encryption of the whole disk which you unlocked with a password on boot-up. I believe they still offer eval versions. Feel free to give them a try. Regards, Frank 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] OpenSSHd - Publickey-Authentication - Has 3.9 problems with 16384Bit DSA-keys?
On Thu, 2005-01-13 at 19:54 +0100, vh wrote: I created a 16384-Bit DSA-Key and stored the public part of this key in ./ssh/authorized-keys. I'm able to login with a 4096Bit DSA-Key but the SSHd wont accapt the 16384Bit-Key and falls back to passwort authentication. heh... I'm just curious: Why do you think a 4096 bit key is not sufficient? And, don't you think the session setup of a 16K+ key would be computationally expensive? Frank 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] Multi-vendor AV gateway image inspection bypass vulnerability
On Wed, 2005-01-12 at 12:37 -0800, Steven Rakick wrote: This would mean that if an image exploiting the recently announced Microsoft LoadImage API overflow were imbedded into HTML email there would be zero defense from the network layer as it would be completely invisible. Why am I not seeing more about this in the press? It seems pretty threatening to me... Because it's old news from a network layer perspective. Images, emails, etc can also be transferred zipped or encoded in base64 and what not. Lots of IPS/IDS/AV and other gateway devices miss these encoded files. The only novel approach I can see here is the embedding of the data together with type and encoding in the URL. Nice idea. $20 says spyware/spam/porn/phishing sites will adopt this fairly soon. Regards, Frank 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] /bin/rm file access vulnerability
On Thu, 2004-12-30 at 20:56 -0700, Jeffrey Denton wrote: Nothing new here. That is one of the problems with DAC systems, the admin has total control over the system. [...] To prevent the above from happening, use a MAC or a RBAC system such as Trusted Solaris. You should also be able to use file flags such as undeletable and immutable together with higher security levels (at least under BSD) to prevent root to remove/change the file under normal run-levels. (Normal run-levels excludes single-user mode and stunts like mounting the drive in non-native environments.) Regards, Frank 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: [in] Re: [Full-Disclosure] IE is just as safe as FireFox
On Sat, 2004-11-20 at 08:20, joe wrote: I agree with your initial comment, they can both be changed. I also agree they both do little. I don't agree that the hardcoding in the source does anything for you. Well, it *allows* you to change the ID of the superuser account to something else. But of course that is obfuscation, and is quickly discovered (just check what ID owns /bin/* and so on). Nevertheless, you have the *ability* to change the ID. You can't do that with Windows. (Yeah, cheap shot I know... ;) Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [in] Re: [Full-Disclosure] IE is just as safe as FireFox
On Fri, 2004-11-19 at 20:40, Jeremy Davis wrote: Are you able to change root's name in nix? Why not if the answer is no? (Things would break right? UID 0?) Knowing the account name is two-thirds of the battle. In windows it's fairly easy to change the admin name. Not a professional here just curious... You can change the name of the root account in Unix, just like the Administrator account in Windows. But you can not change the UID of the root account (0) just like you can not change the SID of the Administrator account (500). I argue that changing the account name in Unix does as little or much as changing the account name in Windows. If you have access to the system you can easily find the account name of the UID 0 account, just as easily as you can figure out the name of the SID x-500 account. The difference is that you can change and hard code that change in the source of Unix (at least with those that you have the source for, Linux, *BSD, whatever). Can you do that with Windows? Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Administrivia: Fool Disclosure
On Mon, 2004-11-15 at 11:46, Andrew Farmer wrote: It's clean. Here's a PNG version, if you're still feeling paranoid. Is *that* clean of the last PNG overflow exploit? (Aug 10, 2004) Which leads to the question, which is a safe graphics file format? BMP perhaps? Cheers, Frank signature.asc Description: This is a digitally signed message part
RE: [Ring-of-Fire] [Full-Disclosure] IE is just as safe as FireFox
On Fri, 2004-11-12 at 09:41, Eric McCarty wrote: [...] IE is just as secure as Firefox. Why?, because we don't click on fake citibank adds, It is my understanding that some flaws, for example the recent IFRAME overflow issue, do not require a user to click on anything. Am I mistaken? [...] Don't sleep with hookers if you don't want AIDS, it's as simple as that. I agree. But I'd say that IE *is* the hooker. :) In all fairness, though, pretty much all the other browsers are whor^H^H^H^H faulty too. (As Michal Zalewski has shown recently) The difference between them and IE is that they require a patch for the browser application, whereas IE often requires fixes that reach far deeper into the system (thanks to tight integration into the OS). And that means that sometimes IE fixes and OS fixes step on each others toes (erm, DLLs?) and creating conflicts or even invalidate each other. Wasn't there a recent IE flaw that was fixed long ago and then surfaced again? How did that happen? The browser-wars are over, and they all lost. The question is how much impact a faulty browser has on the remainder of the system. The question that we should be asking ourselves is not Is IE as safe as Firefox but Does a faulty IE have a larger impact on the system than a faulty Firefox. Regards, Frank -- * It is easier to fix simple systems than it is to fix complex systems. * Fixes should modify core components. They should not be bolted onto core components. signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Senior M$ member says stop using passwords completely!
On Tue, 2004-10-19 at 15:15, Banta, Will wrote: Wow! Three-year-olds are supposed to have a vocab of 500+ words So, how long would it take a 3 year old to brute-force through that key space? ;) -Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Senior M$ member says stop using passwords completely!
On Sat, 2004-10-16 at 11:46, Frank Knobbe wrote: It's a nice recommendation of MS to make (to use long passphrases instead of passwords). But I don't consider 14 chars a passphrase. Perhaps they should enable more/all password components to handle much longer passwords/phrases. heh... I suck. Scratch that msg (where's my coffee?). My gaming laptop is even configured to log in automatically with AutoLogon=1 and a password that is longer than 14. Perhaps a faint memory of pain from the old Winders days wallowed up inside me. Oh well, I'll shut up now... signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Any update on SSH brute force attempts?
On Fri, 2004-10-15 at 23:23, Kevin wrote: Use one time passwords (OTP, e.g. S/Key). How about: Require (long) DSA keys? I'd like to see someone brute-force trough a 4096 bit key :) Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Senior M$ member says stop using passwords completely!
On Sat, 2004-10-16 at 09:46, Tim wrote: Even if this was a new attack, a full rainbow table shouldn't be possible against a secure hash. True if the hashes are salted. (with more than one byte please, otherwise they just use 256 DVDs :) Pass-phrase LENGTH, not complexity defeats these attacks. Not if your hashes are chunked like some (all?) of M$'s. Precomputed chunks with a good lookup table defeats longer passwords. It's a nice recommendation of MS to make (to use long passphrases instead of passwords). But I don't consider 14 chars a passphrase. Perhaps they should enable more/all password components to handle much longer passwords/phrases. Let me guess, that will all be fixed in Longshot. Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
On Fri, 2004-09-24 at 06:21, ASB wrote: That has nothing to do with Windows, and everything to do with a stupid application. ...as if stupid app developers are solely the products of Windows environments. No. But according to that logic it seems that Windows is a product of stupid developers. http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q216/6/41.aspNoWebContent=1 signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
On Fri, 2004-09-24 at 09:15, Barry Fitzgerald wrote: The article doesn't make the situation entirely clear. Did the app intentionally restart the system and foul it? Did the restart occur because the app crashed? No, no, the problem was human error because a tech didn't reboot the system. It's clearly operator error, not a problem with any systems at all. Unfortunately, there is some truth in this. We (and not just the media) are starting to put blame on humans far too quickly. Is this justified? On one hand, they are only tools for us to do our job. On the other hand, they are products that we should be able to rely on. Who do we blame? Operators or products? Cheers. Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
On Fri, 2004-09-24 at 15:55, Ron DuFresne wrote: Who do we blame? Operators or products? or vendors. you forgot vendors Frank! gryn. vendors drive how other apps are produced for the environment, which drives how technical folks deal with them... Heya Ron, yeah, you're right. But we have to better specify vendor. For one there are the manufacturer of products. Then there are the resellers and consultants that introduce products into organizations. It sounds like you are referring to the later part. I think operators/employees and reseller/consultants do feel heat when products fails (employees being shafted/fired and resellers/consultants being not called back and losing contracts). I think we need to put more emphasis/heat/blame on the manufacturer. Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] AV companies better hire good lawyers soon.
* Jason Coombs PivX Solutions: I work as an expert witness in addition to being an infosec researcher, etc. and you would not believe how terrible the quality of computer forensics is in the real world today. To begin with, are you aware that people are going to prison in the U.S. for nothing more than having a compromised Windows box in their possession? Could you please cite a case and precedent where this has happened? As far as I remember, someone got acquitted in the UK _because_ he was in possession of a compromised Windows box. I would assume the same could be argued here in the States. Which side were you on? Did you testify for the prosecution and put the guy away for his compromised box? Or did you fail to defend him? BTW: If you are in IT forensics, why are you complaining about the quality of it? Are you trying to improve it but struggle with it, or hit road-blocks? Or is this just frustration in dealing with these issues on a daily basis? Cheers, Frank (having testified on forensics in a court of law myself) signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] AV companies better hire good lawyers soon.
On Tue, 2004-09-14 at 08:14, Micheal Espinola Jr wrote: [...] If your software is so important that you and your user base cannot deal with possibly up-to a few days of inconvenience due to a false-positive - then yes, you had better coordinate with with that software vendor to make certain your precious software is not one of them. [...] Alternatively, software manufacturers can add their applications into AV exclusion lists upon installation of their products. Applications already have to register with the operating systems. Why not make it register with the AV software if the software is prone to false positives? Or at least advice the end-user of such recommended manual step during installation. If the user trusts the application, and does not trust the AV software, he can override the AV checks for this software. If AV vendors present a lot of false positives, my guess is that the trust of the end user in those AV products will wane. So, it is in the best interest for the AV vendor to ensure low/no false positives. There is no need for software manufacturers to register their products with AV vendors. Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Where is security industry gng??
On Tue, 2004-09-14 at 08:38, Barry Fitzgerald wrote: The problem with IDS was always that people perceived IDS as being a magic box that automatically and exclusively detects intrusions. Anyone who's ever worked with an IDS knows that that couldn't be further from the truth. However, that does not invalidate the data from the IDS. A properly tuned IDS can be very useful. I agree, but like to stress that Intrusion Detection Systems by themselves are worthless (as Gartner says). It's the Intrusion Detection Analyst/Operator that is useful, and the IDS is only a tool for the IDA to use and do his job. So in a sense, a properly tuned Intrusion Detection Analyst can be very useful. I liken it to this physical analogy (don't you love them? :) ): I'm not even gonna go there... ;) So, where is the security industry going? Well, who wants to buy a fire suppression system? :) Nope. The next hot thing is security insurance. Then thereafter will be The Great Collapse after which information technology will experience some sort of Renaissance, mainly based on concepts of free software (as in free thought) and free of failed market manipulation. Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] AV companies better hire good lawyers soon.
On Tue, 2004-09-14 at 15:57, [EMAIL PROTECTED] wrote: Works great until the viruses start registering themselves when they install themselves (you know, the same stuff that already turns off firewalls and so on...) Nah. Viruses, just turn AV off altogether :) Putting up a dialog box that has to be user-clicked would help, but I don't think that Joe Sixpack would put up with it If it's between that of an application not working because it disappears every time after install, a simple dialog box doesn't look like a bad idea... Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Security Obscurity: physical-world analogies
On Thu, 2004-09-02 at 11:24, Peter Swire wrote: I think there is a strong analytic similarity between a firewall and physical settings where guards are deciding whether to let people/trucks/etc. through a gate. [...] In both cases, there is filtering by the defenders. Some entrants are excluded. Some get more intensive screening. The level of filtering varies with the perceived level of the threat. I was trying to stay out of this discussion, but I do have to throw in some comments. I do not believe that we can make accurate and meaningful analogies between the physical realm and the information technology realm or cyber space or whatever you want to call it. The analogies we to make appear to serve our purpose for making it easier to understand the difficult issues surrounding IT based scenarios, but in fact are presented solely for one situation. Any modification of the situation, and reaction scenarios, break down quickly because they can not be performed in both worlds with the same results and same action-reaction behavior. Case in point: You say firewalls are like entrances. People (on lieu of packets) are inspected and gain entrance or not. For a single person/packet, this works. While in the physical the person can not circumvent the entrance, in the information world this is quite easily achieved. In cyber space, the person-packet would just clone or copy itself a million times, overwhelming the inspectors and slip passed the checkpoint. To really illustrate the point, let me make a more colorful example. People-packets in the real world can be stopped by a moat around the castle. The people-packet runs towards the castle and falls into the moat. People-packet has ceased to exist. In cyber space, the people-packet will again clone itself and run purposefully into the moat, piling up the dead people-packets until the moat is full. The remaining people-packets can then enter the castle. Feel free to play through the same scenario with a wall where dead people-packets get purposefully deployed in front of the wall until the last people-packet can climb the packet mountain and pass over the wall. There are some that say certain aspects don't work in the real world... these people think in terms of the real world. There are other people that say other aspects don't work that way in cyber space. That's because they think through the scenario with information technology as the background. There will be people in each camp that see certain aspects as useful, but each will again view it from their own perspective. Analogies between the worlds work when we want them to work. The same analogies can be shot down if we don't like them. These analogies do no allow us to represent one world when trying to make a point in another. The copy conundrum: You have a chair. Dave wants to steal your chair. If he does, you know your chair has been stolen. In cyber space, Dave can steal your chair by making a copy. You still have your chair and you do not know if it was stolen or not. Dave does have your chair now, but you don't know. Leftovers: Let's say you burned said chair. Let's say Dave told you that he came to your house, made a copy of your chair, drove home and put the copy into his living room. In the real world you might go to Dave's house and remove/destroy your chair. In the IT world you will find that said chair is not only present in Dave's living room, but there is an inadvertent copy left in his car. Oh, and also on his hands, or any other place that the chair passed through. Physical objects can not be compared to information. Try to imaging a computer programs in the real world. It doesn't work. Information and ideas, communication and packets, security vulnerabilities, attacks and security countermeasures can not be quickly substituted with real world physical objects. Henceforth any attempt to place analogies of scenarios from one world into the other is flawed. Regards, Frank PS: When I flew over your paper, I read a lot about security and secrecy of information. What I did miss was the distribution of misinformation. And no, it does not easily compare to obscurity. While obscurity does not improve security, it does add value along with security. in the physical as well as information technology world. signature.asc Description: This is a digitally signed message part
Re: Re: [Full-Disclosure] Security Obscurity: physical-world analogies
On Thu, 2004-09-02 at 19:49, James Tucker wrote: A very well stated argument.The only remaining point I would like to hear your opinion on is whether said analogies may be useful (although clearly never complete) in the education of people, in order to provide an abstraction which they may understand more immediately rather than to require further knowledge in the field? In my opinion, no, it does not appear to be useful. If you make an abstraction about IT related issues with a real world analogy, you may be able to bring across the action/issue you want to present, but it will be understood in relation to the real world, not cyber space. Any thoughts that are provoked in the people you are trying to educate will appear in reference to the real world, and play out according to real world physics. In effect, you are doing yourself a disservice by -- not so much confusing the subjects you want to educate -- but by leading their thinking down the wrong path, namely that of the physical world (or cyber space, depending on what surrounding the analogies plays out in). When you try to bring your point across, your subject will analyze it based on their experience and knowledge of the given situation. If you take an IT subject matter, and place it in a real world analogy, your subjects will analyze it based on their experience and knowledge of the real world surrounding you placed the analogy in. That means you not just completely side-step any issues that your idea may have in cyber space, but you also do not allow your subject to understand the idea in the frame of cyber space, and deny them further scrutiny and massaging the problem in the setting of cyber space. Further, your subjects may react with counter ideas and scrutiny based on the real world which of course don't work in cyber space where you transferred the idea from. While your subject may understand the point you are trying to make, you deny them to evaluate the problem the native surrounding (i.e. cyber space), which means your subject will not fully understand your idea in the native surrounding. You basically get that familiar Uh hu, I think I understand with the eyes glazed over. I hope that made it a bit clearer. Thinking about these issues, how we appear to recognize ideas and thought and process them, kinda makes my brain twist into funny 3-dimensional shapes. :) Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Empirical data surrounding guards and firewalls.
On Thu, 2004-09-02 at 19:42, [EMAIL PROTECTED] wrote: In some cases, Marines with live ammo *are* used to achieve exactly that disconnection :) But that leaves dead bodies as evidence. A disconnect will not. The evidence is that someone was there, but it's much harder to find out where. These analogies just don't work. Why do we keep trying to make them? Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Automated ssh scanning
On Wed, 2004-08-25 at 17:32, Richard Verwayen wrote: The attackers installed some software and irc-bots and tried to use this host for testing other computers, thats not the point. I would like to know where's the weak point in the system? As the system was updates on a daily base! The only known weakness were these two accounts! How do you know what they brought in? Do you have shell history files available? Care to share them with us? Shell history should (if left over) should give a clue to not just what they brought in, but also how they used it. That will answer your question as to what local root exploit they used. If you don't have shell history files left over, try repeating the experiment with .history hard-linked to something like .opera/adprefs.ini (create other .opera/ files as cover). Once they clean up and delete the .history file, you should be left with a copy in .opera/adprefs.ini. (Depending on the clue level of the script kiddie he may not find the linked copy). If you do have .history content, or other log info, pleas share it here with us. Regards, Frank signature.asc Description: This is a digitally signed message part
[Full-Disclosure] RE: [Full-Disclosure]MS should re-write code with security in mind. lame bitching about xpsp2
On Wed, 2004-08-18 at 11:38, joe wrote: I think you meant your first line to be All OS vendors should bite the bullet and re-write their code with security in mind. Not sure why you singled MS out for that statement. Especially considering the rest of the post. Probably to bait you, and you've bitten :) Earlier versions of NT (3.51-4.0) had security in mind (perhaps a heritage from the VMS days...dunno). The web server (up to and including IIS 3.0) ran under a user account (configured in the services list). So did the FTP account. It was even possible to run the Scheduler Service under a dedicated user account. Being able to run processes under dedicated user accounts allowed the administrators to keep these services confined in terms of access to Registry keys and the file system. Unfortunately, during the course of moving to 2000, all these features disappeared. The greed for speed lumped all services into the System context. Pretty sad. I loved NT 4.0. I thought it was great. I had services locked down so tight, even file system-wise these boxes were pruned (no explorer, just cmd as the shell). Oh well, now I'm using a different OS and am much happier with it. The biggest boon to security would be to start simplifying Windows. Not from a end-user perspective (as in how easy it is to use it), but from an architectural perspective. That's where systems like *BSD shine, a simpler (and thus more secure and faster) architecture. Another thing that would improve Windows security greatly (besides a *real* host-based firewall) would be something like the Execute bit in the *nix file permissions. Seems like Microsoft is trying this through use of a list of approved/signed applications. That may or may not work (not counting downsides of administrative overhead). We should keep a close eye on the success of that. Perhaps a simple Execute-Bit, that can only be set after entering a password (to foil attempts by hostile code to set it on behalf of the user), might have been a better solution. Again, a simple solution with far-reaching effects. But since Joe No-pun-intended Shmoe at home doesn't want security, it will never happen. Oh well... Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] (no subject)
Howdy Harlan, On Fri, 2004-08-13 at 09:40, Harlan Carvey wrote: The attitude that the entire A/V industry should have a common naming convention seems to be coming from the open source camp...while A/V companies aren't necessarily open source. Companies in general are about making money, and you do that through establishing and maintaining competitive advantages. What gave you the idea that this discussion started from a open source camp? But you are right in regards to the goals of the A/V companies. I think a lot of folks in this thread made is blatantly clear that A/V companies do not care about their clients or client satisfaction, they just care about their bottom line. Let's leave it at that and move on. How are A/V companies competitive? They identify and analyze malware, and update their products. Doing it faster and better than the next guy is the key. Slowing that process down to coordinate with other companies dissolves the advantage. Let's say I discover a piece of malware, and call a round table meeting...only to find out that none of the other members have discovered the malware yet. My advantage goes bye-bye. Nope, doesn't have to be. There doesn't need to be information sharing. I wouldn't even make it a round table meeting. On the risk of being ridiculed again by Nick or others, let's entertain this idea. Remove the round table and replace it with a public (or industry) bell. If an A/V company (commercial or not) finds a new virus, it rings the bell. First to ring the bell sets a name. Other companies publish with their own name *candidates* and if it turns out to be the same virus, adopt the name of the company ringing the bell. Renaming a virus on a web site and in a database and signature set a few hours later shouldn't be hard to to. But what do I know about the A/V industry anyway... I'm just making silly suggestions. No information sharing needs to take place, and competitive advantage remains. All it takes is an industry agreement to work this way. I think it will benefit their clients greatly. In closing, the A/V industry has done a good job with naming viruses in the past. However, in recent year the surge of worms has quickened the reaction of the industry. They know respond in hours, dare I say minutes, because the worm/virus/malware is spreading faster then it did before. This haste or rush to market is what caused the names to differ between vendors. And I think that through a sensible agreement, heck make it a handshake agreement, the industry can return to better more coherent naming of viruses. Regards, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] SP2 and NMAP
On Fri, 2004-08-13 at 11:21, Castigliola, Angelo wrote: Microsoft told Fyodor the reason they disabled raw sockets in SP2 was: We have removed support for TCP sends over RAW sockets in SP2. We surveyed applications and found the only apps using this on XP were people writing attack tools. Silly thing to say anyway. Even if raw sockets are no longer available, attack tools can (and some do) still use their own IP stacks (libpcap/libdnet/etc). Unless MS starts to filter calls on the network driver layer, attack tools will still work. Nicely shows Microsoft's lack of understanding in this area though. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] (no subject)
On Tue, 2004-08-10 at 09:47, [EMAIL PROTECTED] wrote: Software gets named over days/weeks. They crank out a new name for an element every few years. These things need names in *MINUTES* - often while the various A/V companies are looking at different copies of a polymorphic, multi-attack piece of malware. Hey, I didn't say it would be easy, did I? 5 blind men and an elephant time... and you want them to agree on a name before they even agree they're looking at the same thing??? Obviously not at time of research. But these days everyone is keeping an ear on the ground... I mean Internet... while they are doing research. Once one company, which is working on a new strain they term BigNasty, finds out 3 others are discussion this (on the Internet or private AV channels) as the SuckThis virus, then they could adopt that name to avoid confusion. I didn't say it was easy, but they could at least make an effort. Here we are a year later and still call it Bagle or Beagle, either one. I'm still confused if MyDoom-O and MyDoom-M are the same thing or not. BTW: Perhaps the analogy to medicine was misplaced. I just thought in term of diseases. How many different names do we have for ...say... chicken pox or colitis or diabetes? Imagine you had 5 different names for the flu. I could come up with a dozen Monty Python sketches taking place in the doctors office I didn't say it was easy, but we should encourage the AV industry to work towards such a standardization. It may even be beneficial for them. Sing with me Valdis I say tomato, you say tomato, I say potato, you say potato, I say Beagle, you say Bagle, and others are calling it something else. Regards, Frank (throwing rocks at the glass palace) signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] (no subject)
On Tue, 2004-08-10 at 10:25, [EMAIL PROTECTED] wrote: Diabetes comes in Type 1 and Type 2, which are quite different (in one, your pancreas quits producing insulin, in the other, the insulin is produced, but not utilized well by your body). I know, my wife has type 2. They still call it diabetes. As you were saying? If you missed the point, let me repeat it: I believe different names for the same virus confuses consumers and industry alike. I'd like to urge the industry to start adopting a common naming convention. signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] AV Naming Convention
On Tue, 2004-08-10 at 10:34, [EMAIL PROTECTED] wrote: Give the AV companies a bit of mercy though: they are called upon to analyze virii with ever less lead time, and need to pick names sometimes before full behavior is even known (as it seems to me from watching them). Given the time allowed to do this work, it seems a cross reference after the fact is probably the best one can hope for. Perhaps they could elect one person (of each AV shop) to be a naming mediator between the organizations. Competition is still ensured... after all, everyone wants to get it out first. Here's another incentive. First one out to propose a new virus/strain can give it a name. All prominent AV shops could, to help industry and consumers (marketing opportunity here), come to an agreement that governs how names are standardized. First representative of an AV shop that raises the hand says We got a new one! Can't give details of course since you are a competitor. But if you find the same thing in your research, let's call it Humptydumpty-2. Whoever finds the virus first has first choice on the name. No sharing of information required, just agreement on a name. Is that so hard? Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] (no subject)
On Mon, 2004-08-09 at 14:43, Bernardo Quintero wrote: BitDefender 7.0/20040809 found [JS.Dword.dropper] ClamWin devel-20040727/20040809 found [Trojan.JS.RunMe] eTrustAV-Inoc 4641/20040728 found [JScript/IE.VM.Exploit] F-Prot 3.15/20040809 found [HTML/[EMAIL PROTECTED] Kaspersky 4.0.2.23/20040809 found nothing McAfee 4383/20040804 found [JS/IllWill] NOD32v2 1.836/20040809 found [Win32/Bagle.AI] Norman 5.70.10/20040806 found [W32/Malware] Panda 7.02.00/20040809 found [Fichero Sospechoso] Sybari 7.5.1314/20040809 found [JS/IllWill] Symantec 8.0/20040809 found nothing TrendMicro 7.000/20040809 found [HTML_BAGLE.AC] Isn't the complete lack of naming standardization in the AV industry simply amazing? Imagine that were the case in science, particular medicine... Makes for a nice game of AV bingo though... -Frank signature.asc Description: This is a digitally signed message part
Re: FW: [Full-Disclosure] Question for DNS pros
Paul, I'm seeing the same thing now. It caught my eye because of another oddity that occurs from those IP's and I wanted to check with you if you see that as well. These addresses (about a dozen IP's from China in my case) also send a TCP SYN packet with 24 '0x00' bytes payload to port 53. Seq # and Ack # are set, windows size is 2048 (although I haven't confirmed that with all past scans). Below is a tcpdump. See if that looks familiar :) So it doesn't appear to be targeted just at UT Dallas. I start to wonder if other sites get hit too, but if that flies under the radar. Also, there is no name server at that address, never has been. The IP being targeted is the global NAT IP of a firewall. All outbound connections come from that IP. No other IP (in a two class C range) is being hit. This has started on a regular basis last week and seems steady: 2004-05-15 |10 2004-05-21 | 9 2004-06-15 | 6 2004-07-07 | 6 2004-07-25 |94 2004-07-26 |22 2004-07-28 | 211 2004-07-29 | 281 2004-07-30 | 211 2004-07-31 | 312 2004-08-01 | 307 2004-08-02 | 274 2004-08-03 | 111 (so far) There are about 18 sources involved, but the majority of the packets are coming from 218.75.110.194 (601), 61.135.158.28 (589), and 61.135.158.29 (451), all three from China. All unsolicited incoming packets. Nothing is part of any kind of communication (i.e. response to web browsing, triggering web bugs, p2p, IM, etc). Paul, were you able to find anything out about this? Do those IP's correlate with your captured IP's? Do you see the TCP SYN too? Is anyone else seeing this pattern? Regards, Frank tcpdump: 21:16:15.434753 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 51621 NS? . (17) (ttl 44, id 51622, len 45) 21:16:16.194129 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 51622 NS? . (17) (ttl 44, id 51623, len 45) 21:16:16.932505 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 51623 NS? . (17) (ttl 44, id 51624, len 45) 21:16:18.431546 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 9949 PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9950, len 73) 21:16:19.186279 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 9950 PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9951, len 73) 21:16:19.939409 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 9951 PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9952, len 73) 21:16:21.433511 218.75.110.194.53 x.x.x.x.33434: [udp sum ok] 10344 FormErr [0q] 0/0/0 (36) (ttl 44, id 10344, len 64) 21:16:22.196164 218.75.110.194.53 x.x.x.x.33434: [udp sum ok] 10345 FormErr [0q] 0/0/0 (36) (ttl 44, id 10345, len 64) 21:16:22.995559 218.75.110.194.53 x.x.x.x.33434: [udp sum ok] 10346 FormErr [0q] 0/0/0 (36) (ttl 44, id 10346, len 64) 21:16:24.448425 218.75.110.194.1758 x.x.x.x.53: S [tcp sum ok] 3939495989:3939496013(24) win 2048 0 [0q] (22) (ttl 44, id 1, len 64) 21:16:25.208289 218.75.110.194.1794 x.x.x.x.53: S [tcp sum ok] 3774103031:3774103055(24) win 2048 0 [0q] (22) (ttl 44, id 2, len 64) 21:16:26.005612 218.75.110.194.1821 x.x.x.x.53: S [tcp sum ok] 992083552:992083576(24) win 2048 0 [0q] (22) (ttl 44, id 3, len 64) 21:16:27.441872 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 32512, len 64) 21:16:28.191483 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 32747, len 64) 21:16:28.949630 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 32997, len 64) 21:16:41.758970 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 36248, len 64) 21:16:42.166118 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 36448, len 64) 21:16:42.898505 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 36627, len 64) On Sun, 2004-07-25 at 13:57, Paul Schmehl wrote: 22:06:10.294071 x.x.x.x.2566 targethost.utdallas.edu.domain: 29462 NS? . (17) 22:06:11.043050 x.x.x.x.2566 targethost.utdallas.edu.domain: 29463 NS? . (17) 22:06:11.791218 x.x.x.x.2566 targethost.utdallas.edu.domain: 29464 NS? . (17) 22:06:13.298805 x.x.x.x.2566 targethost.utdallas.edu.domain: 30290 PTR? 63.37.110.129.in-addr.arpa. (44) 22:06:14.052600 x.x.x.x.2566 targethost.utdallas.edu.domain: 30291 PTR? 63.37.110.129.in-addr.arpa. (44) 22:06:14.799270 x.x.x.x.2566 targethost.utdallas.edu.domain: 30292 PTR? 63.37.110.129.in-addr.arpa. (44) signature.asc Description: This is a digitally signed message part
Re: FW: [Full-Disclosure] Question for DNS pros
On Tue, 2004-08-03 at 11:29, Ron DuFresne wrote: I think Frank mentioned the packets being like 2048 in size, and this makes me wonder if it's a tad more then mere recon. No, no, the WINDOW size (of the TCP packets) appears to be fixed to 2048. Total packet size is 64 bytes (40 header, 24 null payload). Sorry if that wasn't clear. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: FW: [Full-Disclosure] Question for DNS pros
On Tue, 2004-08-03 at 10:21, Paul Schmehl wrote: That's interesting. The address being targeted here was *also* a firewall PAT address. I'm starting to wonder if this is some sort of a recon tool to get past firewalls. That would explain why they're using port 53 (normally open) and udp (stateless). If they get any kind of response at all, they've identified a live host. I'm not sure it qualifies as a recon as it only hits the firewall address, no other address. It seems to know the exact address. It appears to be triggered by something that originates from our networks, but I wasn't able to capture anything. It may be as old as a bounce email a month ago, or access to a web site a month ago. The dump supplied was filtered on that one address over most of the night. As you can see there are no packets going to that address and provoking this traffic as a response. Considering the thing on my end started last week, it seems plausible that the trigger occurred around that time, or even earlier (as there were one or two probes over a month ago). Also worth noting is that this is on a single address within the main two class C's. This client also has other networks connected to the Internet which carry local traffic, and these do not receive these probes. The vast majority (of this large shop) goes through the redundant class C's. So the trigger appears to be rather rare and not wide spread. Also noteworthy is the fact that this client is pretty clean when it comes to viruses, so I'm ruling that out as a trigger as well. But something had to have happened as it is so targeted hopefully through correlation we can shed some light on this. Later, Frank signature.asc Description: This is a digitally signed message part
Re: FW: [Full-Disclosure] Question for DNS pros
On Tue, 2004-08-03 at 15:34, Paul Schmehl wrote: Frank, I've only checked two of the attacking IPs, but they are both BigIP load balancers. I'd bet that they all are, and these packets are some sort of probe to see if a host that contacted them before is still alive. hmm... I think it's a bit early to say that. After all, why doesn't it contact other systems? Why would it have to recheck in the first place? And why would it use a) a valid DNS query, b) and obscure, non-standard SYN packet, and c) a DNS query *specifically* including the pinged hosts' IP address in reverse notation? I strongly doubt that the F5 engineers through *that* would be a good way to see if a host is still alive. Even if, what would the BigIP gain from it? Nuttin' (as we say here in TN :) The mystery continues... Later, Frank signature.asc Description: This is a digitally signed message part
Re: FW: [Full-Disclosure] Question for DNS pros
On Tue, 2004-08-03 at 17:52, Frank Knobbe wrote: 216.154.239.240 - SBC in Irvine -- couldn't confirm that one 66.150.165.7 - Logical US-AWS NAP through Internap -- seadns01.shopattwireless.com (match) 64.170.177.10 - SBC Interactive through PacBell -- 64-170-177-10.ptim.com (match) 63.240.26.10 - CERFnet -- ny-ns.marketwatch.com (match) 63.210.252.135 - Level 3 -- cindns01.shopattwireless.com (match) (match means it is the exact same traffic, just a low volume, between 3 and 10 packets total). It appears all these are DNS servers. They also all respond to queries for . with the list of root servers. That means that they are recursive. Perhaps there is a 0-day exploit for certain DNS servers? Maybe those DNS servers have a worm that is trying to spread? Maybe seeded from China? Otherwise, why would ATT's name server be sending out probes? The mystery deepens... Regards, Frank signature.asc Description: This is a digitally signed message part
Re: FW: [Full-Disclosure] Question for DNS pros
On Tue, 2004-08-03 at 15:28, Mark wrote: I'd say I'm pretty much seeing the same thing from the following 14 addresses. 202.103.67.196 - appears in dshield -- check 218.25.41.136 - does not appear in dshield -- check 218.30.23.100 - appears in dshield -- check 218.30.23.161 - does not appear in dshield -- nope 218.30.23.162 - appears in dshield -- nope 218.75.110.194 - appears in dshield -- check 61.135.158.170 - does not appear in dshield -- check 61.135.158.171 - appears in dshield -- check 61.135.158.28 - appears in dshield -- check 61.135.158.29 - appears in dshield -- check 61.135.158.30 - does not appear in dshield --check 61.135.158.31 - does not appear in dshield -- check 61.135.158.34 - does not appear in dshield -- check 61.135.158.35 - does not appear in dshield -- check I see those, and I raise you the following :) 61.145.121.16 63.210.252.135 63.240.26.10 64.170.177.10 66.150.165.7 216.154.239.240 218.75.110.194 I was guessing it was targeting suspected DNS servers based on it seeing queries at some point. The target is the dynamic NAT address of one of our internal DNS servers, DNS is the only service running on that box and the only thing that server is allowed to do to the outside world is DNS queries. Good, so it appears that the trigger are DNS queries then (I confirmed that internal DNS queries appear from my targeted address as well). This falls further in line with Paul's findings. So, I'm speculating that a DNS lookup to something somewhere results in these IP's performing the observed theatrics (two UDP DNS queries, one TCP SYN scan with payload, and one ICMP ping). Let's see: 61.135.158.28-35, 61.135.158.170-171, 61.145.121.16, 202.103.67.196, 218.25.41.136, 218.30.23.161-162, 218.30.23.100, 218.75.110.194 are all China. 216.154.239.240 - SBC in Irvine 66.150.165.7 - Logical US-AWS NAP through Internap 64.170.177.10 - SBC Interactive through PacBell 63.240.26.10 - CERFnet 63.210.252.135 - Level 3 I'm not sure about my additional IP's as they don't have the same volume as the initially reported three (218.75.110.194, 61.135.158.28, and 61.135.158.29). I'll take a look at the payload shortly. If it turns out that all mystery come from China, what do you make out of that? Later, Frank signature.asc Description: This is a digitally signed message part
Re: FW: [Full-Disclosure] Question for DNS pros
On Tue, 2004-08-03 at 19:46, John Hall wrote: It is possible some of the traffic you are seeing is the result of a site using our 3-DNS global load balancing product. A clear indicator that 3-DNS is responsible would be that the probes ID fields start at 1 and increase by one for each packet in a set of probes. 3-DNS sends its probes only in response to DNS queries and uses them to measure round trip time and reachability from each data-center under 3-DNS's control to the client's local DNS server. The data collected is used to direct other requests using that local DNS server to the best data-center. You should generally see no more than 9 packets per hour per site using 3-DNS, although one of our customers may have configured more aggressive probing (which we discourage). 3-DNS does maintain a do-not-probe list to which you can be added, if the 3-DNS's probe traffic is too obnoxious for you. Hello John, glad to see you guys are keeping up with all the current stuff going on in lists ;) I had sent a dump earlier. It is attached again below. The TCP SYN packets do indeed start with IPID 1 and move up to 3. However, these all come from the same IP address. Also, there doesn't appear to be anything in regards to round-trip. I mean, your devices send the SYN's but nothing is coming back. Are you expecting DNS querying device to have an open DNS port on TCP and are expecting a SYN-ACK? That I can understand. But what the heck is the purpose of performing two DNS queries against the host that is querying a 3DNS balanced server? Seems a bit invasive to me for measuring trip time... :) In any case. I'm glad to see that there is a normal explanation for this, and this does not appear to be an attack mounted by China. Thanks for the info. Now we just need to find a decent IDS signature that allows your 3DNS probes to be ignored, but not render the IDS silent for related traffic (although I really would like to know when someone is probing my server for the . zone Perhaps you guys could move to fixed IPID for those UDP queries or something?) Thanks again, Frank tcpdump: 21:16:15.434753 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 51621 NS? . (17) (ttl 44, id 51622, len 45) 21:16:16.194129 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 51622 NS? . (17) (ttl 44, id 51623, len 45) 21:16:16.932505 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 51623 NS? . (17) (ttl 44, id 51624, len 45) 21:16:18.431546 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 9949 PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9950, len 73) 21:16:19.186279 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 9950 PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9951, len 73) 21:16:19.939409 218.75.110.194.3847 x.x.x.x.53: [udp sum ok] 9951 PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9952, len 73) 21:16:21.433511 218.75.110.194.53 x.x.x.x.33434: [udp sum ok] 10344 FormErr [0q] 0/0/0 (36) (ttl 44, id 10344, len 64) 21:16:22.196164 218.75.110.194.53 x.x.x.x.33434: [udp sum ok] 10345 FormErr [0q] 0/0/0 (36) (ttl 44, id 10345, len 64) 21:16:22.995559 218.75.110.194.53 x.x.x.x.33434: [udp sum ok] 10346 FormErr [0q] 0/0/0 (36) (ttl 44, id 10346, len 64) 21:16:24.448425 218.75.110.194.1758 x.x.x.x.53: S [tcp sum ok] 3939495989:3939496013(24) win 2048 0 [0q] (22) (ttl 44, id 1, len 64) 21:16:25.208289 218.75.110.194.1794 x.x.x.x.53: S [tcp sum ok] 3774103031:3774103055(24) win 2048 0 [0q] (22) (ttl 44, id 2, len 64) 21:16:26.005612 218.75.110.194.1821 x.x.x.x.53: S [tcp sum ok] 992083552:992083576(24) win 2048 0 [0q] (22) (ttl 44, id 3, len 64) 21:16:27.441872 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 32512, len 64) 21:16:28.191483 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 32747, len 64) 21:16:28.949630 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 32997, len 64) 21:16:41.758970 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 36248, len 64) 21:16:42.166118 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 36448, len 64) 21:16:42.898505 218.75.110.194 x.x.x.x: icmp: echo request (ttl 44, id 36627, len 64) signature.asc Description: This is a digitally signed message part
Re: FW: [Full-Disclosure] Question for DNS pros
On Tue, 2004-08-03 at 20:38, John Hall wrote: In general, most sites use local forwarding DNS servers that do the recursive lookups for all the clients at that site, so our probes measure the RTT from each datacenter to that forwarding DNS server and maintain that data so we can make intelligent decisions the next time a client from that site (via that local forwarder) makes a request. Okay. I'm not sure how that would help since the server could just send the reply. Actually, it could have sent several during the time it takes to measure the round trip time. But this is not the place to discuss 3DNS merits. What is strange, though, is the fact that the load-balancer sent those packets without actually receiving a request. The dump I provided span most of the night, filtered on that host, and there are no DNS queries being sent to the load-balanced DNS server. Instead, it appears like the load-balancer is just unsolicited probes. It is, however, possible that these are responses to spoofed packets that the load-balanced server received from someplace else. But wouldn't that make 3DNS an amplifier in a DoS attack? I guess it depends on how it is configured. Seems so that, when configured wrong with an overly aggressive configuration, it will respond with a multiple of probes packets to a single spoofed reply. The problem goes like this. An attacker sends a single spoofed UDP packet, spoofing the IP of his target, to a handful of 3DNS load-balanced DNS servers. Each load-balancer will send a series of probes to the target. If not usable for a denial-of-service attack (due to low volume), then at least it can be misused to generate a cover of suspicious traffic that the attack can use to hide his own little reconnaissance packets in. Don't get me wrong, I'm not complaining about 3DNS. I'm just questioning whether it really is useful to produce a series of probes in response to a potentially spoofed packet. That does look like a full set of 3-DNS probes. We generally recommend that our customers only configure two probe methods. Looks like this guy has all of the probe methods configured. Since your firewall doesn't respond at all, it's trying each method in turn. The traffic does look like it's pretty low volume, so I guess your major concern is being woken up at 4am with IDS alerts Not really. It is generating about 300 annoying packets a day. The issue is that it appears to be hard to distinguish this from a real attack (in case of the UDP queries). I'm planning on writing signatures for the TCP SYN scan to ignore these 3DNS probes. But the UDP queries for . and the reverse IP address are things that need to cause an alert since they could be part of a human-driven recon/attack. I'm hesitant to turn a blind eye on those... Currently, I don't know of any specific signature other than the ID field that would help identify our . probes. I'll ask around. Please do. As mentioned earlier, a fixed IPID might work. But then again, an intruder could use those values to do his dirty work, and (by making the packets look identical to 3DNS probes) slip under a radar screen. Perhaps the only solution is to build a list of 3DNS IP addresses and ignore these type alerts from those addresses. Thought anyone? (If anyone is still following ... :) Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Re: OpenServer 5.0.6 OpenServer 5.0.7 : Multiple Vulnerabilities in Sendmail
On Thu, 2004-07-29 at 17:07, George Capehart wrote: Subject:OpenServer 5.0.6 OpenServer 5.0.7 : Multiple Vulnerabilities in Sendmail Advisory number:SCOSA-2004.11 Issue date: 2004 July 28 This advisory was issued on March 29, 2003. That was /*sixteen*/ MONTHS ago . . . C'mon, guys! Heya George, perhaps the engineers are too busy fixing broken legal strategies and are putting silly software issues on the back=burner. (After all, why fix it if they file Chapter 11 by end of the year anyway?) Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: FW: [Full-Disclosure] Question for DNS pros
On Sun, 2004-07-25 at 13:57, Paul Schmehl wrote: For the last time, I have *already* done this. With both a snaplen of 1024 and a snaplen of 4096. It *hasn't* produced anything useful unless someone thinks *this* is useful (I'm using tcpdump on FreeBSD 4.9 RELEASE.): tcpdump -c 100 -xX -s 4069 -i xl0 -p -w x.x.dump 'udp host x.x.x.x port 53' (Our IP has been changed to x.x.x.x) Paul, could you please post some *payload* of these packets instead of just the tcpdump one-liner? Perhaps that's why we confused about your tcpdump output/usage. Thanks, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Microsoft Faces Angry IE Users' Questions
On Sat, 2004-07-10 at 23:58, Eric Paynter wrote: I'm a little confused by what you mean here. The user:pwd@ prefix is a part of the URI standard documented in the RFC. As far as I can tell, the patently incorrect part is that they removed it and thus made the browser (even more) lacking in standards support. It's a simple example of how MS solves problems: I believe the issue was that there is no such thing as user:pwd@ for http: or any other URI's with the exception of FTP: Just because it is described in an RFC for FTP doesn't mean that you can go ahead and add this capability to everything else that trails a colon. If you feel otherwise, please show us an RFC that describes user:pwd@ for http:. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] IE Web Browser: Sitting Duck
On Tue, 2004-07-06 at 11:38, Barry Fitzgerald wrote: Does it work now? Haven't tried as I (unfortunately) need IE on that box. It's always been there to my knowledge, but in the past it's never actually removed it - just reverted to the prior version. Which version of Windows are you looking at? Windows 2000 SP4. I had not noticed the addition of that option (and Outlook Express) to the Windows Components Add/Remove list. I don't use Windows anymore except this one box for occasions where Windows (or IE) is required. Perhaps I should take some time to check out all those new *features* and *services* that simple *patches* add to the system. :) Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] IE Web Browser: Sitting Duck
On Tue, 2004-07-06 at 09:27, Barry Fitzgerald wrote: Is it impossible to remove easily and difficult to remove cleanly? Yes... Heh... I just noticed (by chance) that there is an option in |Control Panel - Add/Remove Programs - Windows Components| to remove Internet Explorer (which supposedly Adds or removes access to Internet Explorer from the Start menu and Desktop). I never thought I see the say where MS makes the removal (or at least hiding) of IE an option :) Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Web sites compromised by IIS attack
On Thu, 2004-07-01 at 10:03, Denis Dimick wrote: LMAO.. I see it now, your makeing a joke out of it.. Heh... you are quickly distracted from the main issue. List me 5 other products where is it assumed and accepted that the purchased products has flaws. Quality of software has gone downhill over the last 10 years or so, but only slightly each year. The change is so small that it becomes unnoticed and accepted as new norm. You have to look back several year to see the difference. Yes, complexity of software is increasing and with it the amount of flaws. But complexity of hardware is increasing as well, and hardware is designed by humans too. Why does the industry manage to turn out relative good quality hardware? Because it's a pain in the ass to fix a broken hardware product. With software you don't have this pain factor, so it has become accepted to sell flawed software products and then fix it later. That burden of fixing the flawed product is now on the consumer, not the producer. That's what's wrong. The producer should fix the problem, not you. Is that clearer now? Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Presidential Candidates' Websites Vulnerable
On Thu, 2004-07-01 at 10:48, Jordan Klein wrote: Oh yes, and there should be a checksum of the unique number assigned to each vote to ensure that someone couldn't just reverse engineer the barcode and make up a bunch of bogus votes. I'm not sure exactly how that part would work, but I'm sure there's a way. There needs to be mechanism to block a bunch of made-up votes. Someone could also make up fake punch-cards. Same issue, same solution. More important is the issue of *disappearing* votes. Voter gets a receipt, yes, but how can you guarantee that her vote (bar code or otherwise) has actually been counted? Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Web sites compromised by IIS attack
On Wed, 2004-06-30 at 15:58, TIERNAN RAY, BLOOMBERG/ NEWSROOM: wrote: [...] Sites running Microsoft server software, such as the Kelley Blue Book, were infected with malicious code. [...] ``Our site was infected,'' said Robyn Eckard, a spokeswoman for Kelley Blue Book, an automotive pricing site at http://www.kbb.com. Users tipped off the site Wednesday that one of 15 Web servers running Microsoft's IIS was infected, she said. [...] If this email is real (and the headers do look legit), I have to applaud Kelley Blue Book for coming forward with this information. It takes a bit of guts to make an announcement like this. But I don't think Kelley's Admins are to blame. Administrators should spend their time on keeping systems operating, setting up jobs, and satisfying business requirements. They should not have to spend their time fixing broken products. No. The blame squarely falls on the manufacturers of broken products. They should produce software that works. That includes QA, product testing, due diligence etc. (Insert your favorite car analogy here) I think we all have tolerated broken software products for too long. It is high time to demand better products, or to select alternative products. We need to stop accepting software riddled with flaws and instead demand better quality software. No other products besides software is purchased with flaws -- knowingly at least, and consumer oriented organizations are making sure that consumers know about defects. Why should software be different? Because it is more convenient for the manufacturer and not the consumer to fix it after the sale? We should start treating software like any other products. If it's broken, the producer is required to fix it, not the consumer. No, I do not blame the companies of compromised servers, nor their admins. I blame the manufacturer of the product. So, with sympathy to Kelley Blue Book, and all other companies that had been affected, I say Shame on you, Microsoft. Instead of requiring the consumer to install patches, Microsoft should be required to fix their own, broken products. That means that they should send their army of engineers (a lot of which are now carrying the CISSP certification) to the consumers and have their engineers correct the flaws in their products. They sold flawed products, they should fix it. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Web sites compromised by IIS attack
On Wed, 2004-06-30 at 22:05, Denis Dimick wrote: They pretty much do. That is if the application is one that users have found worth supporting. Exactly. The responsible parties are doing their job. Now contrast that with commercial software. So can I assume that you would allow a vendor to remotely patch your system? Not remotely, but... Like I said, Do you REALLY want a vendor to install patches for you? Absolutely. Have them send a technician ON SITE. Have them STAY and fix the product until it is working. (Free of charge mind you... just like the free repair of a recalled water pump for your car). If applied patches crash the system further, it is the responsibility of that technician (representing the vendor) to get it back in working order. If he can't do that well.. since he is there, you can hold him accountable in any way you see fit. :) If we were able to mandate such a response, how long do you think it would take before out-of-the-box software quality improves suddenly? I think Frank that your starting to point out a problem for M$ and other vendors. They don't have the money to support there products any longer. M$ has somewhere like 20,000 payed programers, How many programers are working on open source products? 100,000 plus, maybe more. How do you expect a company like M$ to compete? I don't think they can. There are a lot of healthy, smaller commercial software shops out there that produce usable (and often surprisingly good quality) code. They typically also have good support and decent business ethics. Some larger vendors these days are more concerned with increasing their own wealth rather than producing good quality software. That's unfortunate. In case of Microsoft, I think that this company has grown to such proportions that it is starting to collapse on itself, much like the operating system they produce. If that is going to happen as quietly as a cheese soufle or as loud as a supernova remains to be seen (although it will be spectacular either way). The next 5-10 years will be interesting. Anyhow. my main gripe is the sale of broken products. I don't remember if that was NT4.0 or some other product, but the box came with the CD for the software, and a CD with patches. Here, your purchase. It's broken. Fix it yourself while you install it. Regards, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] RE: M$ - so what should they do?
On Tue, 2004-06-22 at 14:42, joe wrote: There are some very intelligent people on this list who have good understanding of things that are really wrong with Windows and the *nixs. Yeah, and most of them have migrated from Windows to a Unix-like OS because of that. :) (Unless they already started out with it) Now back to the topic of security. I still haven't seen a post that actually points out why from a security standpoint, Windows needs a base level redesign. Yeah, it was there. Someone already mentioned it: Complexity. Microsoft would be well advised to start slimming down the system, trimming fat, consolidating APIs, cleaning DDL-hell, making it less complex. But instead they make it more complex! Look at the requirements of Longhorn. That's just ridiculous. Frankly (no pun intended), the reason I abandoned Windows a few years ago was that a) I got fed up with all those security issues, mainly patches breaking things instead of fixing things (IE was not quite as bad at that time as it is today), and b) because of the blatant privacy violations one has to endure when wanting to run the OS (2000 SP3 and the new version of Media Player come to mind). But the security issue is mainly due to complexity. Heck, I can have a BSD install running in the same disk space that the DLLCACHE folder alone takes away. The fact that Microsoft is bolting on instead of reducing complexity is a sure indicator that they don't get it. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1694 - 33 msgs
On Wed, 2004-06-09 at 01:54, Todd Burroughs wrote: Also, read the whole thing, Expert sysadmin since 2003 should clue you in that it's either a joke or the guys an idiot. (I suspect that he's laughing at the responses...) While that signature line and the overall tone of the email sounded suspiciously (although funny), the clue should have come after a whois lookup on the bilano.biz domain which was registered just a week ago. Listed as the contact is a certain Reverend Deuce. And if that doesn't sound suspicious enough yet, do a lookup on spudland.com and visit that web site, and all will be clear. Yet we have handful of gullible folks replying. It seems to show that this list has a high number of ... subscribers that don't even do basic research on issues and/or posters, but take everything at face value and start replying immediately. However sad that may be, I can't deny the humor in the initial post and some of the replies... Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Imaging Operating Systems
On Fri, 2004-05-28 at 10:14, Curt Purdy wrote: You are right about vmWare. It is THE most usefull tool for lab work I've found. When you are through trashing a virtual OS, just delete it and copy over the original folder that you initially backed up and you're good to go again. Why so complicated? Just configure the vmWare virtual disk as undoable and discard the changes when you're done trashing the OS. Instant reset to where you started. :) Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Port 5000
On Tue, 2004-05-18 at 08:16, Geo. wrote: Does anyone know what's causing the port 5000 scans yet? http://isc.incidents.org/port_details.php?isc=b4827221b7f45feeb0c12bc5040cab c9port=5000repax=1tarax=2srcax=2percent=Ndays=10Redraw=Submit+Query Why yes. http://isc.sans.org/index.php?on=diary :) Regards, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Agobot author is a pacifist?
On Tue, 2004-05-18 at 06:58, Jos Osborne wrote: Hmmm...compulsory national service...what a cheap way of getting a labour force. I'm mixed on my views on this - on the one hand having this labour force is a good thing, and a younger me could have definately done with having some discipline and structure, but then again reports of what used to happen here when national service was compulsory make me nervous of the concept. What do other people think? Not really a topic for Full-Disclosure. But since you asked... I think more countries should have that. Not so much for the military service, but for the civil service. I grew up in Germany and spent 18 months doing civil service, caring for a 14 year old quadriplegic boy. (After those 18 month, that boy was like a son to me. One of the most rewarding things I ever did). Point is everyone should be called to this to gain stature and experience while at the same time doing good things for folks living in the society that otherwise could not get the help they need. Kurt mentioned Meals-On-Wheels type service. There are also other services, but mostly helping the elderly or handicapped. The need will always be there. Why not send some juveniles to help out, have them perform a good service while learning something on the way? (And getting paid of course). Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Slowly down the drain
On Tue, 2004-05-18 at 09:41, Paul Schmehl wrote: Am I the only one who thinks that this list is slowly descending into complete worthlessness? [...] (And *this* will devolve into another 250 post thread about nothing.) Yeah, yeah, yeah. Sorry, I shouldn't have cc'ed FD on it, and pollute the list with useless blabber ah crap, I did it again... ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Worm of the worm?
On Fri, 2004-05-14 at 07:26, Roberto Navarro - TusProfesionales.es wrote: I have detected some scans lookin' for the 5554 port (sasser's ftpd). Does somebody know anything about a new worm, exploiting its vulnerabilty? Perhaps the Dabber worm? http://www.lurhq.com/dabber.html Regards, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Calcuating Loss
On Wed, 2004-05-12 at 10:56, Schmidt, Michael R. wrote: Well one of the biggest issues that allows people to remain anonymous is DHCP. If everyone on the internet was required to get a static IP address, or to log which IP they were using - using a secure technology then everyone could be tracked, Wrong again. As you said, dial-in users can be traced by phone number (unless they hop through hacked PBXes). Cable users can be traced by MAC address, DSL providers probably by switch port and/or MAC. Your ISP can track you from IP to MAC or dial-in port to your credentials. But if you jump through 20 open proxies, the person/site that you are attacking will have a hard time finding you (and your IP address). So in essence, the biggest issue that allows people to remain anonymous are open proxies and zombie PCs. And I don't think we'll ever get rid of those. Regards, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Calcuating Loss
On Wed, 2004-05-12 at 11:57, Gary E. Miller wrote: Too much work. Just do a bit of wardriving until you find a WiFi net you can jump on. Just be sure to forge your MAC just in case someone is in turn sniffing you locally. Heya Gary, too much work? You mean I have to get out, buy an antenna (or Pringles can), get gas, drive around the city, find an open WAP, find me a parking lot, hook up my gear and hack away? I find it so much more convenient to just download YAPH and proxychains and cover by tracks that way, all from the comfort of my own bed... I mean... home. ;) Of course if you are doing something really nasty you should still probably bounce your packets off several foreign countries first just to make it fun. Yeah, it's always some damn Korean senior citizen homes that do all the nasty stuff on the 'net. :) Cheers, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Avoiding traceability (was: Calculating Loss)
On Wed, 2004-05-12 at 12:42, Gary E. Miller wrote: If you convert your pringles can properly it should work from your bedroom window as well. :-) lol yeah, I saw that one coming Go ahead and use your home internet conenction if you must. Just be carefull who you annoy enough to track you down. If the Feds supect you they can get a warrant and tap your line. Agreed. The mobility of (mis)using wireless networks helps evading profiling and taps. Do not expect any encryption to be a protection, the Feds say they have never been stumped by encryption. Right, but (not including weak and breakable encryption) isn't that because they can get the keys through other means? (as in physical access, including planting hardware or software keyloggers [Scarfo]) Anyhow, probably drifting off topic now. I concede that there are definitely advantages that unsecured wireless connections offer in term of becoming untraceable (and complete decoupling of all things physical). But I still believe that open proxies are easier and more convenient to use. Regards, Frank PS: Not that I do these things of course perhaps a real blackhat or two that do hack anonymously can speak up and tell us what they use to anonymize themselves. signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Calcuating Loss
On Tue, 2004-05-11 at 12:52, [EMAIL PROTECTED] wrote: We're fast approaching the point where a site can't do anything resembling a reasonable testing process and complete it before the worm arrives. I think we're getting close to the point where we realize that patches and virus signatures and such are not sufficient to protect networks from worms and viruses. I meant to bring this up a month or so ago. After the NetSky.A-Z and Bagle.A-Z and NextOne.A-Z, people should start realizing that they need to escape the vicious circle of updating sigs and patching. Different, deeper reaching measures need to be taken to reduce susceptibility to these issues. Architectural changes are necessary to remove the capabilities for these things to run, spread and thrive, not more patches and virus signatures. Sooner or later, individuals will find the answer. It's evolution in the digital world. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Wireless ISPs
On Tue, 2004-05-11 at 13:33, D B wrote: All transactions done via secure websites are secure, No, they are not. It's just harder to intercept the data. A wired internet connection limits the number of people who have access to this data simply by the nature of the internet putting it within acceptable risk. Same can be said for wireless. (Except that the perimeter of the attack arena is defined by the wireless emissions instead of cable runs.) It is legal according to US law to eavesdrop on wireless connections. Maybe, INAL. But it is illegal to commit fraud with the data gathered by eavesdropping. 2. Encrypt all wireless transmissions at least making someone who gains access to this data prosecutable. Uhm... someone that accesses and uses the data is already prosecutable. Please direct all flames to /dev/null Neat. Never heard that before... :) -Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Wireless ISPs
On Tue, 2004-05-11 at 16:15, D B wrote: The level of knowledge it takes to penetrate a SSL style transaction puts it beyond most peoples scope of abilities Agreed. But the blanket statement secure [ssl implied] websites are secure is just not correct. [...] and on a switched network odds are if you spoof to that MAC / IP you will confuse the network enough to be noticeable Depending on where on the inside, that may not be true. But I agree that it is more noticeable. This is a good point to highlight as intrusion detection capabilities in WiFi clouds are lower (dare I say much lower) than in wired networks. a high gain antenna attached to a laptop / PDA and a wireless AP such as an internet provider would mount would give access in some cases up to 17 miles away with no trace Point taken. It's probably easier to get away too :) Maybe, INAL. But it is illegal to commit fraud with the data gathered by eavesdropping. and someone after credit card #'s is worried about legal ? Sorry, you brought it up. point being it is preventable and not being done so ... or at least preventable to a level beyond the scope of running a program and watching the data flow Oh, yeah, I agree whole heartedly. And I know what you are trying to do (having read your response to Mr. Coffee), and I agree and support your cause. But your statements that wired networks are secure is just not correct. There is no absolute security. SSL web sites are not secure. And the people you are trying to convince (wireless ISPs) may respond with that as well. It's all a matter of what level of risk is accepted. The difference here is that on wired networks, SSL and such are step to improve security, not fool proof mind you. Wireless ISPs that do not encrypt just don't do that, and should be held legally responsible for negligence. Wireless ISP should encrypt the data just like wired ISPs put locks and chains on their switching facilities. I'm with you. I just don't agree to some of the reasons you gave (or how you worded them) to justify it. Call me a nit-pick :) Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Wireless ISPs
On Tue, 2004-05-11 at 14:20, D B wrote:
[...] Guess what ? the Credit card #
and address are in that email.
The ones I get have several in them. It's again a blanket statement
you make.
Besides, I think you're confusing web sites operators/developers with
{wired|wireless} ISPs.
Cheers,
Frank
signature.asc
Description: This is a digitally signed message part
RE: [Full-Disclosure] Psexec on *NIX
On Thu, 2004-05-06 at 15:19, Chris Carlson wrote: [...] MAC address of a desktop in Ohio. In windows, it only takes a 'psexec \\ohio ipconfig /all'. [...] I need this for unix. ssh ohio ifconfig rsh ohio ifconfig You still need permission of course just like in Windows, for example root [administrator] access and /etc/hosts.* [RPC/DCOM] configurations. But all you need to do is install ssh on YOUR machine. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Sasser skips 10.x.x.x Why?
On Mon, 2004-05-03 at 14:44, Eric Chien wrote: Actually, it is all variants (.A - .D). And more specifically, it iterates through all the host IP addresses looking for an address that does not match: 127.0.0.1 10. 172.16 - 172.31 (inclusive) 192.168. 169.254 Then, using this address it creates a random address (sometimes changing all octets, sometimes just the last three, and sometimes just the last two). Word has it that this is not true. While the code for the address check is there, it doesn't appear to work on some Sasser variants. There are reports of infected 10/8 and 192.168/16 networks. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] morning_wood is really a blackhat
On Fri, 2004-04-30 at 19:04, Kurt Seifried wrote: Same great taste, but less filling. But we come here for the taste, not the food. ;) Cheers, Frank -- Warning at the Gates of Bill: Abandon hope, all ye who press ENTER here... signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Top 15 Reasons Why Admins Use Security Scan ners
On Wed, 2004-04-28 at 17:04, Harlan Carvey wrote: Someone should be. Admins should be to confirm that their environment is in the state that they believe it to be. I guess we'll have to agree to disagree. In my experience, the guy who set a system up shouldn't be the one to inspect it, or verify it. and With regards to the rest of your comments, I think you're missing the point. I'm not saying that a security scanner shouldn't be run...I just don't think that admins should be the ones to run the scanner. Heya Harlan, long time. I think you are missing the point. I don't think Stuart is saying that the admins should also be the auditors. But they should run scanners and other security tools to verify that they did their job correctly. But only to the extend to make corrections and such. They should not perform an audit per se. You still need independent (either outside the company or an audit department) that runs those tools (and more) themselves during the audit that will generate a report to management. This is probably what you are thinking of. I don't think we're saying admins should audit themselves. But admins should run tools to ensure that they did their job ok. Cheers, Frank -- Warning at the Gates of Bill: Abandon hope, all ye who press ENTER here... signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Core Internet Vulnerable - News at 11:00
On Tue, 2004-04-20 at 14:41, Dave D. Cawley wrote: This is what they're talking about...a TCP vulnerabilty with BGP most likey to get hit. ... in network of providers that still have not learned to properly secure their routers and perimeters with ACL's and proper egress/ingress filtering. Looks like someone didn't read http://vesuvio.ipv6.cselt.it/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt -- Warning at the Gates of Bill: Abandon hope, all ye who press ENTER here... signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Cisco LEAP exploit tool...
On Wed, 2004-04-14 at 22:38, Jeff Schreiner wrote: This is true but from my experience with amateur radio an HF rig running at [...] Even directional tracking devices used by zoologists will only pick up the [...] Sorry about the extended discussion on RF broadcasts, the main point wanted to point out was detecting a 802.11 2.4 GHz transmission from 7 miles away would be almost impossible. Could it be that you are confusing transmission/receipt of analog signals and digital signals? In the digital world you can distinguish between 0 and 1 even in signals which could be considered absolute crap from an analog perspective. BTW: The FCC authorizes higher power levels for point-to-point connections. A quick Google search found this: http://www.dailywireless.org/modules.php?name=Newsfile=articlesid=1926 Regards, Frank (absolutely not a WiFi or ham or otherwise RF guy) -- Warning at the Gates of Bill: Abandon hope, all ye who press ENTER here... signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Microsoft Coding / National Security Risk
On Wed, 2004-03-24 at 07:06, joe wrote: [...] They weren't correcting a single self-contained program like W3SVC or Apache or netdom, they were correcting functionality in a core component used widely across the OS. ^^ But it's just that -- A core component. Not hundreds of core components. It was ONE DLL that needed fixin', not a multitude of them. I think the Windows source code has grown to a size that is hard even for Microsoft to manage. I'm not surprised if the very developers are starting to lose trust in their own code because it has grown to galactic proportions... hence the need to extra long test cycles. Regards, Frank If the next slammer virus came through and started formatting hard drives, I would say the same thing I did when the last one came through and that would be How come you weren't patched with a patch that had been out that long?. It doesn't matter how fast MS produces patches if admins and users aren't getting them applied. The issue isn't simply one of technology, it is also one of process. A vast number of people don't want automatic updates of their systems either because they don't trust the source or simply don't' want their machines updating automatically but DON'T go back to do it in a conrolled fashion. They wait until someone says they need to go do it. I don't let MS update my PC automatically but I do make it a point to go back and check every couple of days to see if something has been released and I watch several notification streams as well. Most people will not do this so they either need to go with some form of automatic updates or unplug. MS sent many many people through the code. People outside are going through the code. Again this isn't one program that one person could go through and have a strong handle of. I don't think 10 more people could add much if any value. Not sure 100 outside people could. If this were the case we wouldn't be finding old holes in other open source now, we would only be finding stuff in the newly released code. I would however like to think that MS is working on better automated scans of the code to find holes, that would be more value than trying to find 10 excellent security programmers. I am someone who has access to the current source and have walked through large sections of it, it isn't like the holes jump out and say HI, here I am. Also the code I have had a chance to walk through in the last 8 months is pretty decent, I definitely am not going, oh my god oh my god. It seems more rigorous than the code I have walked through say for Samba however that is an objective opinion and am not going to enumerate items I think one does better than the other. BTW, how many zero day exploit based worms/viruses have been beating up on MS in the last year or two... Not being flip here. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Hatch Sent: Wednesday, March 24, 2004 5:10 AM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Microsoft Coding / National Security Risk Hi all, Microsoft have stated that to make the source code for Windows publically available would be a risk to National Security. Microsoft also took 9 months to produce a fix for the ASN.1 problem. As much as some people may regret it, Western civilisation runs on Microsoft software. Imagine the panic that would ensue if the next slammer worm infected 10 machines then formatted hard drives, or scrambled random parts of random files. This is not news, some old DOS viruses set file lengths to zero, rather than deleting files that could be recovered. So my idea is this: Take a team of really really good C/C++ coders with excellent security vulnerability knowledge and have them go through the source code for windows (starting with the core functionality and internet facing functionality maybe). Find these bugs (including methodical black-box testing against the binaries) and fix them. These people would be fully supported by Microsoft (including full access to all technical documentation, Microsoft technical advisors, etc), and backed by the NSA or other Government agency. Microsoft could impose whatever NDA's they want, but they should fund the bug hunt. Not only can they afford it, they created the problem code. Fresh insight into how Windows functions is required to identify the less obvious vulnerabilities. Microsoft Windows is not just another piece of software, it has become a fundamental part of businesses and governments. Oh, can anyone suggest a reason why disclosing the source to Windows would be a National Security risk, yet Microsoft is happy to provide the same source code to ceratin third-parties (I assume this means any company that has enough cash and signs the right paperwork). Folks, simply reacting to 0days just doesn't work. R. Hatch --- 'The
Re: [Full-Disclosure] RE: Sarca rainbow tables on-line cracking service
On Tue, 2004-03-23 at 12:00, [EMAIL PROTECTED] wrote: Ok everybody let's send our LM Hashes and email addresses to this group of complete strangers. Sounds like a great idea. 1) It wouldn't be MY hashes: email address != LM hashes 2) They still don't have the user account name: email address != user ID 3) Which system are they from? They don't know: ID + password = host(x) |where x is undefined 4) Hashes don't need to be valid anymore: insert witty function about password over time here But I agree, it's probably not a good idea to send these to an untrusted party. Would make for an interesting project though: What information (except favorite color and shoe size) could you derive from a password hash... Cheers, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] viruses being sent to this list
On Tue, 2004-03-23 at 11:34, Alerta Redsegura wrote: Stupid people are often (always?) more dangerous than malicious people Question then: Do stupid malicious people cancel themselves out? signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Re: pgp passphrase
On Sat, 2004-03-20 at 19:41, Max Valdez wrote: Keylogger ? Intelligent enoght to know wish keystrokes are passphrase ?? Nah, keyloggers don't have to be intelligent, they just have to log data. It is *you* that needs to be intelligent when reviewing the captured key strokes. Examples: 1) command line: [...] cd .. gpg -sae text.txt my hovercraft is full of eels cat text.txt.asc | mail [EMAIL PROTECTED] rm test.txt [...] 2) GUI: [...] I'll see you then. Best regards, Justme always look on the bright side of life Hello Pat, I sent Tony an invitation [...] Can you spot both passphrases? Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] PGP attachments (was: NEVER open attachments)
On Fri, 2004-03-19 at 22:16, petard wrote: If anyone knows of a clean hack to trick Evolution to sign an email inline, please let me know. Apply the patch from bug 127521: http://bugzilla.gnome.org/show_bug.cgi?id=127521 Alternatively, you could use an external program to do the deed. Just paste your mail into something like seahorse (search sourceforge) and sign it there. YES! Thank you, this is exactly what I was looking for. I'll try this out shortly. I had looked at this issue earlier, and was able to call gpg to clear sign the email Evolution passed to it, but I wasn't able to get it back into Evolution. I tried to filter on outbound messages and I wrote a wrapper around gpg, but didn't get anywhere. It would have been necessary to hack the source a bit, just like the URL you provided does. Thanks again! Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] NEVER open attachments
On Fri, 2004-03-19 at 14:43, Staves, Steve wrote: I would like to second that motion. I never open attachments, especially on newsgroups etc as they are a prime target. No problem, that's yours (and VB's) choice. Just don't open anything we post. I don't have a problem with that. I'm not quite sure how that evolved into a thread though... Cheers, Frank (realizing that it's probably futile to respond to your post...hehe) signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] PGP attachments (was: NEVER open attachments)
On Fri, 2004-03-19 at 14:09, Jeremiah Cornelius wrote: They SIGN their messages, and some clients insist on representing inline S/MIME and OpenPGP messages as attachments. BTW: I prefer to have Evolution (my email program of choice) sign messages inline like PGP in Outlook used to do, but I can't convince neither Evolution nor GPG to do so. If anyone knows of a clean hack to trick Evolution to sign an email inline, please let me know. Thanks, Frank PS: You will notice that I did not cc Jeremiah on this email since I wasn't responding to him directly, but opening this question to the list. ;) signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Re: Administrivia
On Thu, 2004-03-18 at 19:08, Jason wrote: but *I* prefer to be in the recipient list if I have joined in on the discussion, it is clearly a discussion I am interested in or felt like chiming in on. I have filters... they filter... they filter differently if I am a named to or cc... discussions I am participating in by default float to my attention. In addition, a discussion between 2 or 3 parties can take place faster if they email themselves directly as opposed to wait for a sluggish mail list to deliver the posting 6 hours later. Personally, I prefer to be cc'ed as well. If I want to unlink from a discussion, I'll the participants know. There is no absolute answer to this problem, like in much of security. It's a decision where each and everyone of us has to apply something special common sense. Regards, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Comcast using IPS to protect the Internet f rom their home user clients?
On Wed, 2004-03-10 at 07:46, Chmielarski TOM-ATC090 wrote: Yes, they say they are now doing this. http://www.infoworld.com/article/04/03/09/HNcomcastspam_1.html But this article says they are shutting systems down once identified as a spam/hack/dos zombie. This can be done easily by reconfiguring the Cable modem or removing MAC addresses from filter/pass tables (don't know what types of access controls are in place over there). It doesn't say they are using an inline IDS/IPS. Where would those IPS's be? At the major NAPs or peering points? Or distributed in regional hubs? I'm curious how they are dealing with the performance impact. Perhaps they are using ASIC based IPS's, or very limited signature sets (which would explain why a whisker scan completes unimpeded, but a nikto scans hangs at the same spot). So far, a couple others reported that they noticed the same behavior. I haven't heard anyone say my scans are not affected. To reproduce the test, fire off a nikto scan against a remote web server (remember, get permission first). See if nikto completes without getting stuck. (I used a recent nikto from the FBSD ports tree). Anyhow, finding spam sources and bandwidth hogs and turning them off manually is one thing. Having an network-based intrusion prevention system sitting in their wires is another. Perhaps they are beta testing that as an additional method to weed out bad traffic? Regards, Frank PS: I'm completely okay with them filtering as long as they allow me to tunnel my traffic to corporate servers. Whatever it takes to get rid of spam is fine with me... signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?
On Tue, 2004-03-09 at 23:17, Aditya, ALD [Aditya Lalit Deshmukh] wrote: if you are routing all your scans from a vpn and the vpn connections are encrypted as they always are then is impossible that the scan are triggering some kind of signatures. i think while they *might* have a ids installed and working, they also might be filtering based on the traffic thresholds ... Dear Aditya, I am NOW routing the scans through a VPN so that they are not blocked by Comcast. When I noticed that something was going on, I was scanning from my Cable IP. Once I realized that something seems fishy, I started to tunnel all attack traffic, with the reported results. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?
On Wed, 2004-03-10 at 14:44, Exibar wrote: I know the feeling behind what you typed, but you really don't mean what you typed. Filtering should not be done by the ISPs, they should provide a pipe, and that's it. [...] If the ISP's start filtering traffic, scanning E-mail for viruses, etc, they are getting close to censorship in my eyes. They're also removing themselves from common carrier status in the eyes of the law too I would think. Heya Exibar, I tend to think of a common carrier as a T-1 provider, and perhaps most DSL providers. By end-user ISP like MSN, AOL, or cable services seem to be better described as consumer carriers. The main differentiators being the ease of use (just plug it in and get an IP via DHCP) and of course the level of clue of the technical staff. That said, I would support certain filtering (like blocking inbound or outbound SMTP connections) as long as it is done indiscriminately. By that I mean it is okay to filter port 25 across the board, but it should not be okay to filter on some content that the carrier deems is inappropriate (as that definition most likely varies between carrier and consumer). If certain criteria is applied, I would agree, I would be similar to censorship. After all, I should have the right to receive my Viagra ads and Nigerian investment opportunities. :) Spam filtering and virus checking should occur on the carriers email gateways/hosts, and not on the wire itself. I should have the right to receive all the viruses I want in my email (perhaps for legitimate research). As far as filtering inline, if it occurs on fixed critera (i.e. port 25), I'm okay with it (even though I may not like it. As I said, as long as I can tunnel around it, I'm fine :) But if filtering occurs inline on undefined critera, then it may be of concern. That is the reason that I posted the question if anyone else had noticed that some filtering on some content is occurring. Cheers, Frank PS: The Infoworld article Tom mentioned seems to deal more with detect and manual punishment. I'm okay with that as well. As long as they don't use automated tools to turn peoples modems off when the IDS triggers on a possible false alert. signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Comcast using IPS to protect the Internetfrom their home user clients?
On Wed, 2004-03-10 at 22:50, Aditya, ALD [Aditya Lalit Deshmukh] wrote: i think you and i just said the same things, by traffic thresholds i ment total traffic, so it includes all your tunneled ones also, but as this is pure speculation and speculation is something that is not good so i will let this thread die here Oh, okay, I see what you meant. I don't think that's the case since I had higher traffic volumes (for example, scp'ing a tar backup of a remote server). Also, whisker scans ran fine. Pretty much same volume, same hosts. Regards, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Comcast using IPS to protect the Internet f rom their home user clients?
On Wed, 2004-03-10 at 17:30, Richard Compton wrote: They are beta testing the TippingPoint IPS. Now we're talking. That's a pretty confident statement you made there. Care to explain how you can be so sure? Are you, or someone you know, involved in the setup/execution of that beta? Cheers, Frank signature.asc Description: This is a digitally signed message part
[Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?
This post should probably have gone to SF-PenTests, but since it is more of a discussion item, I thought about Full Disclosure, the list for vuln info and everything else :) Anyhow, I noticed that certain vulnerability scans, for example scans using Nikto and similar tools, when run from a Comcast address show a different behavior than when they are run from a clear, uncontrolled Internet connection (i.e. corporate T-3). In fact, it appears like Comcast has an Inline-IDS (some call it an IPS ;) sitting on its wires, filtering out certain signatures and blocking subsequent access for a short period of time. For example, scan progresses, then hangs inexplicably, then resumes, trips a sig, and hangs again. At the same time, the same scan from a non-Comcast address continues without any hick-ups. Targets have been ruled out (up and running, verified at the same time from different addresses), and connectivity to the rest of the net remains. It's looks like just the src-dst address pair is used so that all connections from a Comcast src to that particular dst are blocked for a short moment (1-5 minutes). Has anyone else noticed that? Is Comcast actually attempting to keep all those worms'n'viruses of their clients away from the Internet? How many other ISP's are known to use IPS's inline to protect themselves from the 'Net, or protect the 'Net from themselves? Regards, Frank (routing all scans via VPN through corporate hosts ;) signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] mydoom.c information
On Sun, 2004-03-07 at 19:47, Chris Eagle wrote: As I recall the -L option (persistent listener) only works on the windows port. If you want it for Unix: How about? while true;do nc -l -p 1234;done Forrest? Trees? -Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] mydoom.c information
On Mon, 2004-03-08 at 01:01, [EMAIL PROTECTED] wrote: The problem with that is that there is no incrementing counter. The output never gets written to file, since nc sends data directly to stdout. Which is why I had an 'x' variable in my loop - it conveniently increments by one each iteration, thus generating a new filename. Of course. My point was just that calling nc in a loop has the same effect as the -L option. No need for patching and recompiling. I didn't even see your line until just now. Looks like I just stated the obvious... sorry. Your code is right on. Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Re: DoomJuice.A, Mydoom.A source code
On Mon, 2004-02-09 at 22:29, Riad S. Wahby wrote: I asked people to email me personally; in doing so, I was attempting to contact those who might be of assistance. Moreover, by attempting to do so in a personal context (off-list) I've implied that I'm willing to confirm my identity and describe in greater detail my intentions. As far as I can tell, I have ignored no ethical issues in attempting to establish a dialogue with those who might help me. I don't want to start a discussion about your validity, and it is not my intention to discredit you in any way. According to your resume you are doing some cool stuff (although more focused on hardware apparently). I think what raises concern is that your buddy Ian Martin describes you as a H4x0r gra|\|d3. There is no need for you to confirm your identity when MIT's servers give plenty of information about you. I hope all goes well for your graduation this summer. As for the code, have you tried catching the bug with a honeypot? I heard of people using netcat listening on port 3127 to catch the bug... Regards, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] MyDoom.b samples taken down
On Sun, 2004-02-01 at 06:08, Mike wrote: I have copied the files to the following locations: http://homepages.ihug.co.nz/~mjcarter/virus/MyDoomA.exe http://homepages.ihug.co.nz/~mjcarter/virus/MyDoomB.exe And so the virus spreads again. and by means not anticipated by its author... Spreading via search engines, and infecting people wanting to download the Doom sequel... When posting viruses, may I suggest a mechanism that forces someone to manually click on a button or enter a number or something? Anything that prevents automatic download from a URL. Otherwise your web space might be misused by MyDoomC as a download point. Regards, Frank signature.asc Description: This is a digitally signed message part
RE: [Full-Disclosure] Culprit Bio: Perfect Storm Averted or Just Ahead?
On Thu, 2004-01-29 at 09:06, Clairmont, Jan wrote: There is the CVS tag that mentions Andy. So there is an association with Andy and Forth. Unless of course Ivan added that intentionally to throw you off course. You just swallowed hook, line, and CVS tag. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] MyDoom bios infection
On Thu, 2004-01-29 at 03:14, Ferris, Robin wrote: It was also unknown that the virus infects the BIOS of the computer it infects by injecting a 624bytes backdoor written in FORTH which will open port tcp when Mydoom will be executed AFTER febuary 12. Although code in BIOS could interact with your network card, it would require the correct driver routines for your particular card. Does the virus come with network card drivers for a variety of cards? No? Then BIOS code won't open a TCP port. Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] MyDoom bios infection
On Thu, 2004-01-29 at 12:09, Ben Nelson wrote: Although code in BIOS could interact with your network card, it would require the correct driver routines for your particular card. Does the virus come with network card drivers for a variety of cards? No? Then BIOS code won't open a TCP port. It would need a TCP stack too, would it not? That would be supplied with the code injected into the BIOS. The BIOS code of PXE systems contains what is needed to get DHCP addresses, etc. Likewise, viral code that written itself into BIOS has enough potential to get an IP address and listen on a port. Just very rudimentary stuff, nothing pretty in form library functions other apps can use. Remember the old BOOT ROMs on NICs? That type of stuff. The gotcha is that different cards have different IO port ranges, registers, interrupts, etc, and require different code (read driver) for the particular card. The virus would have to carry all that driver code with it. The more cards it were to support, the more code it has to schlepp along. It's doubtful that all of that would fit into 600-some bytes. :) I don't want to drag this into a is a BIOS network worm possible thread. Theoretically yes, but there are a lot of practical limits. Even if a NIC-code carrying worm made itself a home in the BIOS, you would have issues with concurrent access to the NIC once the OS gets loaded. (But it might be able to spread before Windows is up...). Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] MyDoom bios infection
On Thu, 2004-01-29 at 14:45, Juari Bosnikovich wrote: It appears that what I called sooner a BIOS BackDoor is more of a Microsoft Windows exploit. When the infected machine boots for the SECOND time AFTER febuary 12 it is injecting a malicious program in the Windows installation that downloads a new version of Mydoom which will probably be called Mydoom.c after it's discovery. In other words, it has nothing to do with the systems BIOS? If that was a mishap in naming it then that's ok. Apology accepted. I understand the point of vue of unbeleivers but unfortunately it is very CLEAR to me that they did not conduct their own research concerning this VERY destructive virus. Personally, I don't believe or disbelieve anyone since I haven't looked at that virus. But I have two things to say: 1) Anyone doing disassembly/analysis of any sort of thing has to be more precise in the analysis and not jump to conclusions. 2) (and in reply to) As a reminder to the various persons which contacted me privately via email and to whom I shared more information PLEASE keep it private. Full Disclosure is a about... uhm... Full Disclosure. Please don't tease us with the things you may have found without publicly disclosing and sharing information. I understand that in certain cases you don't want the public to know (for example, when you analyze code and share information with folks, including LEOs, where that information might lead to an arrest, or for other reasons that require confidentiality). Full Disclosure was and is about disclosing bugs in vendor provided software. I don't think it was intended as an analyze-fraud type forum. If you like to contribute to that, contact your local Infragard chapter or law enforcement agency or the like, and operate outside of public view. If you want to dissect viruses to help the community and public at large, and you want to do this here (instead of quietly with AV vendors), then please share and disclose the information. Can we stop all that chest-pounding and return to normal FD business? I'll go first: Anyone find the IE exploit of the day yet? ;) Cheers, Frank PS: This rant is not directed against Juari Bosnikovich. I applaud his motivation and effort to dissect the virus. My rant is against those that proclaim they found information without sharing it. FD is not the right place for those folks. signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] DOS all platforms
On Fri, 2004-01-23 at 21:00, Matt Burnett wrote: Actually I just remembered the viruses can break current hardware. There are many CPU's out there that can be overclocked in software. The PowerPC 750 (aka G3) cpu using in Apple computers is one of them. And I doubt anyone will try to argue that OCing can kill the cpu. Isn't it possible to erase/overwrite the microcode ROM of Intel CPU's? What would make for a nasty virus and may just be what the experts expect as the digital perl harbor. (The downside [upside?] is that testing microcode viruses is ...uhm... somewhat limited :) Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Symantec Manhunt ?
On Tue, 2003-12-16 at 17:11, Clint Bodungen wrote: ManHunt has been tested at up to 2 gigabits per second. lol well, that's great, but how did it *perform* at 2 Gbps? How many packets did it drop, how many alerts did it miss, munge or misinterpret? Would you mind sharing the real results? Regards, Frank signature.asc Description: This is a digitally signed message part
