Slashdot Mirror

Angry or not angry, the point is that disclosing security bugs directly to the vendor first minimizes harm to end users - assuming, that is, the vendor feels sufficiently motivated to fix the bug.

IN A TIMELY MANNER.

You forgot the bit that's at the core of the disclosure debate. Virtually everybody in the security industry agrees on the principles of disclosure. All the flames are over the timing.

In one corner, we have Microsoft. They appear to believe in full disclosure, once the disclosure will have no adverse effects on stock price or profitability.

In another corner, we have a tiny handful of scum sucking, mercenary security researchers who believe that disclosure will happen just as soon as they get paid. And the terms of that disclosure will be whatever the purchaser wants.

In the other corners, and carpeting the entire floor, are all the rest of the security community. They believe that full disclosure must happen in a time-frame that minimizes damage to the user community. They just can't agree on when that might be.

This lack of a concensus has made it easy for Microsoft to define the current terms of disclosure. The result has been suppression of disclosure for longer and longer periods. The inevitable consequence is more and more '0' day exploits.

In September 2009, SANS released an excellent State-of-the-Internet on the top cyber security threats: http://www.sans.org/top-cyber-security-risks/ One of their points was:

"World-wide there has been a significant increase over the past three years in the number of people discovering zero-day vulnerabilities, as measured by multiple independent teams discovering the same vulnerabilities at different times. Some vulnerabilities have remained unpatched for as long as two years."

To demonstrate this issue they enumerated the history of MS08-031:

For example, MS08-031 (Microsoft Internet Explorer DOM Object Heap Overflow Vulnerability) was discovered independently by three researchers. The first researcher submitted remote IE 6/7 critical vulnerability on Oct 22, 2007. A second independent researcher submitted the same vulnerability on April 23, 2008. A third independent researcher submitted the same vulnerability on May 19, 2008. All three submissions outlined different approaches of auditing and finding the same vulnerability.

What goes unstated is while 3 'responsible' researchers disclosed to Microsoft and waited and waited, unknown numbers of hackers also discovered the vulnerabilities and exploited them.

Just this week, a dozen well managed, fully patched, WinXP (with .NET installed) computers at my institution were compromised by clicking on a major news site (http://www.ksl.com/index.php?nid=148&sid=9814436).

Microsoft would have us believe that this is acceptable. But really, would immediate, full disclosure be any worse?

Miles

There is an industry effort to define a "watch list" for common mistakes that lead to security flaws. Co-led by the folks behind the Common Weakness Enumeration at MITRE and the SANS Institute, the SANS Top 25 (full listing here) is being used as a requirements document for the security of purchased applications by the State of New York, among others.

It's not perfect--it omits backdoors and other intentional security flaws, among other categories--but it's better than nothing, by a long shot.

Disclaimer: I work at Veracode and was a co-author of the report that the original article was about.

Back when I was in charge of hiring new programmers for a web development shop, the very first thing I'd do when I got a resume would be to load up the applicant's personal website, if he had one.

No, I didn't look at the aesthetics of the site. I didn't care about the cleanliness of the HTML. The implementation language and web framework didn't matter. I had more important things on my mind: I would find a form, and type hello world' -- ; SHOW TABLES. If the site misbehaved, I'd toss the resume in the trash and adamantly refuse to reconsider it.

Management thought I was nuts --- these were guys with degrees! They came with great recommendations! And they're cheap! What does one bug matter? But with SQL injection being the now #2 security vulnerability, who's whining now?

Attention to correctness is the bedrock trait of a good developer. Everything else comes second; security is just one property of correct code.

.. Root the box, and you might be able to recover the cached passwords from it.

Almost. The iSec paper mentioned, but didn't explain 'Pass The Hash' attacks. See the excellent SANS paper at: http://www.sans.org/reading_room/last.php

Bottom line is, the attacker doesn't need to get back to the passwords by cracking the hashes. The attacker can just directly use the hashes.

Being targetted by these guys is like standing in the middle of a crowd of pick-pockets. No matter what you do, they are going to get stuff. You are lucky get get out with your teeth.

Miles

It's relatively easy to attempt to follow best secure coding practices. It's really hard to get things exactly right. And, right enough for lawyers, thats nearly impossible.

Just look at their sample contract. Even their lawyers can't write a sample contract they can stand behind. It is covered with disclaimers passing the buck. Here's what they propose at: http://www.sans.org/appseccontract/

"DISCLAIMER: THIS DOCUMENT SHOULD BE CONSIDERED GUIDANCE ONLY. IT IS STRONGLY RECOMMENDED THAT YOU CONSULT A QUALIFIED ATTORNEY TO HELP YOU NEGOTIATE A SOFTWARE CONTRACT.
Please be advised that there is no warranty, expressed or implied, and no assumption of any legal liability or responsibility for any third party's use, or the results of such use of this Document."

Writing code or writing contracts is hard to get legally right. Code should be written with proper disclaimers to require the customer's security experts to review and approve deliverables. Thats how they kick the can down the street in their example contract.

You get this problem if your atapi.sys was malware-infected.

Solution: Replace atapi.sys with a clean copy.

More info:

http://isc.sans.org/diary.html?storyid=8209

Microsoft Update KB977165 triggering widespread BSOD One of Microsoft's "Patch Tuesday" security fixes is triggering a widespread "Blue Screen of Death" problem. The cause is not the update itself, but an existing infection. So far, reports suggest that this problem affects Windows XP and Windows Vista. Once the update is applied and the system rebooted, Windows will bluescreen at boot. When booted to Safe Mode, the system will freeze. Removing the update from the Windows Recovery Console or using live media will get the system booting again, at least until the update is reapplied. I have found that the root cause is an infection of %System32\drivers\atapi.sys, and that replacing this file with a clean version will get the system booting normally. This is not the first time that an infection hitting atapi.sys has caused updates to trigger bluescreens. If you are running Windows and have not yet applied this update, make sure you scan your computer thoroughly for infections before applying this update. If you are experiencing this problem, get your computer to a professional that can replace the infected atapi.sys and clean any other malware from your computer. References: http://isc.sans.org/diary.html?storyid=8209 http://social.answers.microsoft.com/Forums/en-US/vistawu/thread/73cea559-ebbd-4274-96bc-e292b69f2fd1 Detailed Repair Instructions Using the Windows XP Recovery Console 1. Boot from your Windows installation CD Insert your Windows installation CD and boot your computer. If your computer is not set to boot from CD first, you may need to reconfigure your BIOS or press a boot menu key (often F12, F8 or Esc). If you are unsure of how to do this, consult your favorite geek. As soon as the boot starts, you should see a message like "Press any key to boot from CD..." - press a key. 2. Start the Recovery Console After the CD loads (it may take a minute), you will be presented with a few choices. One of these options is to start a recovery by pressing "R". Press "R" to launch the Recovery Console. * You may be asked to choose a Windows installation. If so, choose the damaged installation (probably "1). * You may be prompted for the Administrator password. If you do not have one, press "Enter". 3. Identify your CD drive letter You should now be at the command prompt. Enter the following command: map Look for the drive letter for your CD drive. It may look something like this: D: \Device\CdRom0 In this case, your CD drive is "D:". 4. Replace ATAPI.SYS Enter the following, replacing "D:" with your CD drive: cd system32\drivers ren atapi.sys atapi.old expand D:\i386\atapi.sy_ You should see the message "1 file(s) expanded." - this indicates you have succeeded. 5. Reboot and scan for malware Reboot your computer. With a little luck, your computer will now boot normally. Because this problem is caused by malware, you should immediately scan your computer with up-to-date antivirus software. Tags: Malware, Security, Windows This entry was posted on Thursday, February 11th, 2010 at 17:22 and is filed under Security. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

It seems like someone's figured out what was causing the bluescreens... from the MS forum thread:

I had an Eee PC with XP Home brought to me with this same problem. I rolled back KB977165, rebooted and the system worked fine. I reapplied KB977165 and the rest of the updates available at Microsoft Update, and the problem returned. I replaced %System32%\drivers\atapi.sys with a clean version from a XP SP3 distribution folder and rebooted... voila! Problem solved.

For reference, the SHA1SUMs of the atapi.sys files:

Non-working:
bb3e36ad0c8ed6daab38653ea4a942d74b9f4ff6

Working:
a719156e8ad67456556a02c34e762944234e7a44

If anyone wants to look at the non-working atapi.sys:
https://patrickwbarnes.com/pub/atapi.sys

I will be looking at this more in-depth. If I find anything more, it will be posted in a follow-up comment at the ISC:
http://isc.sans.org/diary.html?storyid=8209

UPDATE :
I uploaded the non-working atapi.sys file to VirusTotal, and this is the result:
http://www.virustotal.com/analisis/85aa49f587f69f30560f02151af2900f3dc71d39d1357727ab41b11ef828a7ff-1265925529

Apparently, this update problem is the result of an infection.

From the comments over a DShield on this topic http://isc.sans.org/diary.html?storyid=8209 it looks like this might be the case again

It may also look suspicious to sysadmins that you keep sessions alive for so long.

Is it possible for a Windows admin to poke around your desktop, remotely, without your knowledge?

Of course, the answer is yes.

Also, if you yourself use the Remote Desktop protocol, in some scenarios it is not as secure as SSH.

Remote Desktop connections are encrypted, of course, but there are two problems:

• In the default configuration, the RSA private key used to sign the terminal server public key used is hard coded into a DLL, and well-known.
• Most people don't know or don't bother to configure RDP properly for TLS security
• The windows password is trivially intercepted as it is being typed

In other words, if you use RDP, and have not gone to substantial lengths to secure against MiTM attack, then if you yourself use RDP, it will be much less secure than the typical SSH setup (where each server has its own host key, and the client has memorized or been populated with the correct ones).

Don't think it's that complex. From June 2009:
http://isc.sans.org/diary.html?storyid=6601

Yesterday an interesting HTTP DoS tool has been released. The tool performs a Denial of Service attack on Apache (and some other, see below) servers by exhausting available connections. While there are a lot of DoS tools available today, this one is particularly interesting because it holds the connection open while sending incomplete HTTP requests to the server.

In this case, the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated.
The initial part of the HTTP request is completely legitimate:

GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n

After sending this the client waits for certain time – notice that it is missing one CRLF to finish the header which is otherwise completely legitimate. The bogus header line the tools sends is currently:

X-a: b\r\n

Which obviously doesn't mean anything to the server so it keeps waiting for the rest of the header to arrive. Of course, this all can be changed so if you plan to create IDS signatures keep that in mind.

According to the web site where the tool was posted, Apache 1.x and 2.x are affected as well as Squid, so the potential impact of this tool could be quite high considering that it doesn't need to send a lot of traffic to exhaust available connections on a server (meaning, even a user on a slower line could possibly attack a fast server). Good news for Microsoft users is that IIS 6.0 or 7.0 are not affected.

At the moment I'm not sure what can be done in Apache's configuration to prevent this attack – increasing MaxClients will just increase requirements for the attacker as well but will not protect the server completely. One of our readers, Tomasz Miklas said that he was able to prevent the attack by using a reverse proxy called Perlbal in front of an Apache server.

We'll keep an eye on this, of course, and will post future diaries or update this one depending on what's happening. It will be interesting to see how/if other web servers as well as load balancers are resistant to this attack.

So why didn't it stop this 8 yr old exploit?

http://isc.sans.org/diary.html?storyid=682

SELinux is an additional layer of *ACLs* to system resources and it is located in kernel layer. I can't put it better than that.

Just because SELinux is based on a formally verified architecture, it won't stop you for specifying wrong ACL rules which it seems to be the case here.

--
Even Bing would have found the answer for you!

So why didn't it stop this 8 yr old exploit?

http://isc.sans.org/diary.html?storyid=6820

Vulnerability applies to 32-bit Microsoft Windows operating systems with Windows NT 3.5 heritage.

Vulnerability arises from ancient coding or design flaws in the MS-DOS execution subsystem. This subsystem is not present in 64-bit Windows OSs.

The workaround is to disable the MS-DOS subsystem.

Great article at the SANS Institute Internet Storm Center: http://isc.sans.org/diary.html?storyid=8023. This includes links to Youtube videos on how to use Windows Group Policy tools to disable this subsystem.

However, once you do this, you won't be able to run 16-bit DOS-based software, so if you really need that you may have to wait for a patch. Or build a dedicated DOS machine, where at least you'll have no illusions of security. (Cynics would say this is true of any MS operating system, but I leave that debate to others.)

Seems like deja vu, since this has issue cropped up before, what with everything from Adobe wanting to install (at least on Mac and Windows) with system level privileges and enable javascript by default. [Tell me again, how is javascript a desirable feature for this file type?]

Which makes it a good idea to use alternatives like Preview, and Skim (for OS X), as well as Foxit Reader for Windows.

It's not like there's a paucity of options to get away from Adobe's bloatware, no matter what OS you're running.

http://www.sans.org/newsletters/ouch/ You can subscribe them to the monthly newsletter. It is meant to help non technical users understand these issues. Being in the IT Department, I have been forwarding these emails every month to all employees for years.

I use a mental algorithm that will always it generates a "good" secure password. No two passwords are the same. Because I the input to the algorithm is site or situation specific, but personally obvious, I always get the same output. I have to keep track of more than 30 passwords and I have a terrible memory. I used to use the same four passwords over and over again until I read the Simple Formula for Strong Passwords (SFSP) Tutorial. It is a long read but most of it is examples. Basically it teaches you how to come up with a system that guarantees that you create memorable and secure passwords.

Yes I've since re-researched my information (never post before coffee) and realised the flaw in my logic(so yes I was utterly wrong), but in essence there are still problems prevalent in the way windows does privilege escalation, problems I'm yet to hit in the *nix world and probably never will. *nix is a ground up built for multiple users, Windows has been built in the opposite direction. PDF -> Sudowin

Gotta admit it is a bit of a marketing ploy. Too bad about picking a port that's likely to be blocked at the firewall or conflicting with p2p software.

http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
  1337/TCP PowerFolder P2P Encrypted File Synchronization Program Unofficial
  1337/TCP WASTE Encrypted File Sharing Program Unofficial

From http://isc.sans.org/services.html
  Shadyshell 1337/tcp #[trojan] Shadyshell

http://www.sans.org/top-cyber-security-risks/

Chart(jpg) shows 92% 'other'.

SANS ISC has already been doing this for years. http://isc.sans.org/top10.html Old news. The only thing different will be data from non-corporate home users who opt in.

Con-Fu:
http://isc.sans.org/diary.html?storyid=608

"Stay Alert! Trust No One! Keep Your Laser Handy!"

This is arguably more of an issue in the compiler than in the kernel,

Not completely... from the SANS Storm Center, the code was as follows:

struct sock *sk = tun->sk; // initialize sk with tun->sk

if (!tun) return POLLERR; // if tun is NULL return error

The error was that the compiler optimized away the if statement, assuming that tun had already been initialized. The check should have been placed before the sock variable referenced it. Not entirely obvious maybe, but then again, it should have been checked before the assignment.

The check should have been placed before the sock variable referenced it. Not entirely obvious maybe, but then again, it should have been checked before the assignment.

Well, had the check been done first that would be a more reasonable program. But whose to say there isnt a line directly above this that assigns, invariably, a known memory access. Then, say this is a multi-threaded application, and there is a possibility that memory area has been deleted, and if so, you want to take a certain action.

I don't see how this isn't absolutely a compiler issue. There is no way that an if statement that does an error check should be optimized out in this situation, if any.

As previously mentioned, the right behavior would be to warn about this. And to leave the if statement in.

This is arguably more of an issue in the compiler than in the kernel,

Not completely... from the SANS Storm Center, the code was as follows:

struct sock *sk = tun->sk; // initialize sk with tun->sk

if (!tun)
        return POLLERR; // if tun is NULL return error

The error was that the compiler optimized away the if statement, assuming that tun had already been initialized. The check should have been placed before the sock variable referenced it. Not entirely obvious maybe, but then again, it should have been checked before the assignment.

I tell everyone I know, along with everyone I work with, that surfing anything but internal corporate sites with Internet Exploder is the same thing as saying "take my machine, please!" to the world at large. Since I'm in charge of security infrastructure for a nationwide company with over 10K employees, I get listened to a bit more than your average geek. I'm single-handedly responsible for at least 30-40 people, if not more, switching to Firefox over the last 6 months, I'm quite sure.

The current ActiveX video 0-day, plus the constantly-updated list of sites that are actively exploiting it, is perfect proof that you're a fool to surf with IE.

You're also a fool to run Windows XP on a daily basis, but that's another topic.

If you're going to post links to isc.sans.org, can you please post links to the specific article, and not just the main page?

Here is the link to the specific article: http://isc.sans.org/diary.html?storyid=6601

Wait, you mean the summary on /. is finally correct!?

No. Here is the link to the article. Not sure what to tell ya about the pig, though. Maybe check the dosage on your meds? ;-)

Quoted from here:

Spinrite is not data recovery software. I get many questions about why I left off Spinrite on my recommendations of recovery software. I specifically leave off Spinrite because under the strictest terms it is not data recovery software. Almost every single data recovery package knows, and will warn you not to write the data back to the original source drive. Data Recovery/Forensics software almost always recover from a source to a destination. Spinrite does not do that, it refreshes the surface and controls reads to get the maximum amount of data from the sectors and then puts it back down on the same drive.

I think it does quite a few things very well and it does an excellent job at reporting and reading the SMART info and refreshing the surface of the hard drive. However, I would like to first try to get the data from the drive before scanning it and trying to rebuild sectors. There are many reasons for this, but the most important one being that the drive can die in the process of running Spinrite. It is possible to do more damage to the drive by doing excessive read and writes. There are times that you only get once [sic] good chance at data and if you use a tool that just goes in and surgically removes the data you want BEFORE doing the scan you will be a lot safer.

If I was going to use Spinrite, I would get everything I could off the drive to another destination first and then use Spinrite to try to get anything I could not repair (although I never have to with the tools I use). Another horrific story I have seen with drives sent to me, is that if Spinrite it runs successfully, people are under the impression that the drive is repaired and is usable again and continue to use it. Big mistake and it usually dies again shortly. On a Windows Hard Drive I would try NTFSExplorer/FatExplorer first in the hopes of doing a surgical recovery as oppose to spending days rewriting sectors in the hopes that my drive can live though it as Spinrite does. But for $80 it is well worth the attempt if you are going to do nothing else. Good Luck.

Oct 6, 2008 11:26 PM ~ Scott A. Moulton

Also, you can find some very interesting papers/presentations/videos here.

Quoted from here:

Spinrite is not data recovery software. I get many questions about why I left off Spinrite on my recommendations of recovery software. I specifically leave off Spinrite because under the strictest terms it is not data recovery software. Almost every single data recovery package knows, and will warn you not to write the data back to the original source drive. Data Recovery/Forensics software almost always recover from a source to a destination. Spinrite does not do that, it refreshes the surface and controls reads to get the maximum amount of data from the sectors and then puts it back down on the same drive.

I think it does quite a few things very well and it does an excellent job at reporting and reading the SMART info and refreshing the surface of the hard drive. However, I would like to first try to get the data from the drive before scanning it and trying to rebuild sectors. There are many reasons for this, but the most important one being that the drive can die in the process of running Spinrite. It is possible to do more damage to the drive by doing excessive read and writes. There are times that you only get once good chance at data and if you use a tool that just goes in and surgically removes the data you want BEFORE doing the scan you will be a lot safer.

If I was going to use Spinrite, I would get everything I could off the drive to another destination first and then use Spinrite to try to get anything I could not repair (although I never have to with the tools I use). Another horrific story I have seen with drives sent to me, is that if Spinrite it runs successfully, people are under the impression that the drive is repaired and is usable again and continue to use it. Big mistake and it usually dies again shortly. On a Windows Hard Drive I would try NTFSExplorer/FatExplorer first in the hopes of doing a surgical recovery as oppose to spending days rewriting sectors in the hopes that my drive can live though it as Spinrite does. But for $80 it is well worth the attempt if you are going to do nothing else. Good Luck.

Oct 6, 2008 11:26 PM

Also, you can find some very interesting papers/presentations/videos here.

I am referring to a blog entry from Scott A. Moulton who is a forensic and data recovery expert and currently teaches the SANS 606: Drive and Data Recovery Forensics course.

Spinrite is not data recovery software. I get many questions about why I left off Spinrite on my recommendations of recovery software. I specifically leave off Spinrite because under the strictest terms it is not data recovery software. Almost every single data recovery package knows, and will warn you not to write the data back to the original source drive. Data Recovery/Forensics software almost always recover from a source to a destination. Spinrite does not do that, it refreshes the surface and controls reads to get the maximum amount of data from the sectors and then puts it back down on the same drive.

I think it does quite a few things very well and it does an excellent job at reporting and reading the SMART info and refreshing the surface of the hard drive. However, I would like to first try to get the data from the drive before scanning it and trying to rebuild sectors. There are many reasons for this, but the most important one being that the drive can die in the process of running Spinrite. It is possible to do more damage to the drive by doing excessive read and writes. There are times that you only get once good chance at data and if you use a tool that just goes in and surgically removes the data you want BEFORE doing the scan you will be a lot safer.

If I was going to use Spinrite, I would get everything I could off the drive to another destination first and then use Spinrite to try to get anything I could not repair (although I never have to with the tools I use). Another horrific story I have seen with drives sent to me, is that if Spinrite it runs successfully, people are under the impression that the drive is repaired and is usable again and continue to use it. Big mistake and it usually dies again shortly. On a Windows Hard Drive I would try NTFSExplorer/FatExplorer first in the hopes of doing a surgical recovery as oppose to spending days rewriting sectors in the hopes that my drive can live though it as Spinrite does. But for $80 it is well worth the attempt if you are going to do nothing else. Good Luck.

Oct 6, 2008 11:26 PM

Also, you can find some very interesting papers here.

One thing that nobody seems to have mentioned yet is freezer trick. If the drive is just not spinning anymore (and you do not hear a click of death), just throw your drive in a ziplock bag into the freezer for a couple of hours. Often times it will then run long enough to make a bit-to-bit (dd) copy as others already mentioned.

One thing that nobody seems to have mentioned yet is freezer trick. If the drive is just not spinning anymore (and you do not hear a click of death), just throw your drive in a ziplock bag into the freezer for a couple of hours. Often times it will then run long enough to make a bit-to-bit (dd) copy as others already mentioned.

"Before a patch can bve installed on medical equipment, the hardware vendor has to validate the patch"

What are the technological and legal issues in relation to computerized medical equipment. How does one go about validating a patch. Who is responsible when something goes wrong. At least one hospitable has had equipment rebooting during surgery. How do you test the patch, apply patch, scrub up and attend operation, wait for BSOD and click on restore ?

http://isc.sans.org/diary.html?date=2009-04-08

They may not be. Also, the 2003 blackout was caused by maintenance failures, specifically not trimming trees, not worms.

• It exploits the MS08-067 vulnerability to infect via the network.

• It uses the Autostart mechanisms for spreading via network shares and removable devices (except for media that identify themselves as removable media such as USB sticks on WindowsXP and later)

• It tries to bruteforce shares as user Administrator and with a known precompiled list of quite trivial passwords.

Of course this could all get changed or enhanced with an update that could occur on April 1st.

Now, what I want to point out with this comment is that you can end up with a complete infected LAN by only having overlooked or spared out just one system that remained unpatched and here is why:

If you happen to end up with an infection of a system and you log in as domain admin to it the virus has got everything it needs to spread to every system, particularly to the central file server. And if you do not happen to run an AV client for real-time monitoring there or if an updated version is not detected by the systems AV client signatures, you can get infected pretty badly.

When Conficker has domain admin privileges, it creates scheduled processes to execute a copy of itself on remote systems. In order to prevent this, you can either disable the scheduling process or you can write-protect the Root folder on your central file server.

So you might want to CYA and make sure that:

• Every Windows box is patched

• Autostart from anything but CDs is disabled

• No system has admin accounts with trivial passwords

• The systems which host mapped SMB shares have local AV real-time scans and the Root folders of these shares are write protected.

• On Vista systems programs should not be started from removable drives: Confickers USB social engineering trick on Vista

When I first saw this here, the first place I looked for additional information was the Internet Storm Center, where they eat this kind of stuff up. And sure enough, they even had a call from someone at Symantec saying that yes, this one is theirs.

Conspiracy theory or no (and it's looking more like no), there are two things that rescue this from dullsville:

In the comments on that SANS article, it's mentioned that yes, Symantec is deleting comments left and right, and meanwhile the talk is slowly wending its way onto the ZoneAlarm forums, which just goes to show that one man's misstep is another man's opportunity. And...

While the story behind the PIFTS file itself isn't terribly interesting, some unsavory rapscallion had noticed its popularity as a search term, and planted malware where people looking for information on it could stumble upon it. Fun stuff, eh? Look for malware information, and find it the hard way.

Google has already removed that link, but it might still be out there, just in case you use a different search engine. And there's no reason he/they won't try again on another site.

and am probably not the only one who is.
First we have, "The NCSC is your only national body created to fulfill your responsibility to protect networks across the civilian, military, and intelligence communities."
Next, "In addition, the threats to our democractic processes are significant if all top level government network security and monitoring are handled by any one organization (either directly or indirectly)."
But, the point of having DHS focus primarily on civilian government networks and NSA and the intelligence community as whole focus on military network and their networks respectively, seems to make sense. This setup would probably require a very close working relationship between interested parties.
Also, there was a ton of news about the DHS getting $355 million in cyber security funding last week.

Mostly innuendo and facts of marginal relevance.

Except for these two zingers:
http://lists.sans.org/pipermail/unisog/2004-April/
http://lists.sans.org/pipermail/unisog/2005-January/

Look for the messages regarding "MediaSentry". Real network administrators posting their experiences receiving nonsensical requests from MediaSentry and related entities for information about bogus IP addresses. Doesn't reflect too well on MediaSentry's methodology.

Mostly innuendo and facts of marginal relevance.

Except for these two zingers:
http://lists.sans.org/pipermail/unisog/2004-April/
http://lists.sans.org/pipermail/unisog/2005-January/

Look for the messages regarding "MediaSentry". Real network administrators posting their experiences receiving nonsensical requests from MediaSentry and related entities for information about bogus IP addresses. Doesn't reflect too well on MediaSentry's methodology.

http://www.sans.org/top20/#z1

The critical flaws that were reported this year in Office products:

        * Microsoft Excel Remote Code Execution (MS07-002)
        * Microsoft Outlook Remote Code Execution (MS07-003)
        * Microsoft Word Remote Code Execution (MS07-014)
        * Microsoft Office Remote Code Execution (MS07-015)
        * Microsoft Excel Remote Code Execution (MS07-023)
        * Microsoft Word Remote Code Execution (MS07-024)
        * Microsoft Office Remote Code Execution (MS07-025)
        * Microsoft Outlook Express and Windows Mail (MS07-034)
        * Microsoft Excel Remote Code Execution (MS07-036)
        * Microsoft Excel Remote Code Execution (MS07-044)
        * Adobe Reader and Acrobat Remote Code Execution (APSB07-18)
        * Adobe Reader and Acrobat Cross Site Scripting (APSA07-01)

C2.2 Operating Systems Affected

Windows 9x, Windows 2000, Windows XP, Windows 2003, Windows Vista, MacOS X are all vulnerable depending on the version of Office software installed.

While all operating systems are affected...
Linux has two mentions on the entire page while other operating systems just go on and on and on.

With Open source, MANY eyes are looking at it finding problems and fixing them.

With Closed source, FEW eyes are looking at it-- are probably only focused on bugs and enhancements that will return new revenue, and may remain unaware of exploits for long periods of time. For example, some zero day flaws get extensive script libraries written to take advantage of them before they are discovered.

Hackers, the real ones (who are very few) can see the windows assembler and C code via disassemblers and debuggers anyway.

At least some of them probably have access to Windows code. (It's not really that secret- several companies have copies of the code including China which is known to launch cyber attacks against windows computers)

---

However, from dale carnegie, remember people decide with their emotions and then fit the facts to that.

You need to argue emotionally "Linux is safe because people really care about it and work hard to make it secure-- it's not just 'a job' that some jaded corporate programmer is phoning in".

I wonder if this is related to this http://isc.sans.org/diary.html?storyid=5713

It's autorun.inf not autoexec.bat, and it does require a bit of user interaction. Double clicking on it in explorer in XP will execute it but on systems running vista/7 it must rely on social engineering.

Let's see... you know someone has this device, they think they are "secure." you place _PASSIVE_ device consisting of collector and memory enough to save say a day's worth of data in something like a clock if you have daily access to persons room (think janitor) or something they will throw out in a few days (think flowers) and you have all the blinks and flashes. Then you can take the collected data back to your bunker and run probably a simple XOR or something equally as trivial on it and there you have it... all the communications of the day, week, month. I think this need to be filed under the other /. article on "technologies that will fail in 2009" I used to work for one of these guys years ago... it doesn't surprise me to see him behind another insecure and worthless "filler" technology. Hey Mike... read this: http://isc.sans.org/diary.html?storyid=5644 The real rear end chapper is that there is TONS of really cool technologies and lots of smart people in Minnesota. Sorry /. that you get the "country bumpkin tech" p.s. My Apple Newton had this same technology.

It's called dshield: http://isc.sans.org/howto.html

That was my first thought, although that may not be entirely accurate. As for dshield, noticed the other day there's what appears to be a new link on the Spamhaus page that reads

Consumer Alerts
Is your PC infected or part of a "botnet"?
Check it Here

Humorous aspects aside, it links to some sort of dshield copy-cat setup run by mynetwachman.com. Never heard of them personally, but the more the merrier. A community-based effort to solve a community-wide problem is sound in principle, and doubtless better than clamoring for new laws or regulations which typically brings unanticipated consequences to the mix.

It's called dshield: http://isc.sans.org/howto.html

I would agree with the post in for Jeremiah Grossman at WhiteHat Security. Jeremiah and his team do great work in this space, and their research is top notch.

I also wanted to offer our company's services as well. InGuardians is also well known in the industry. Our team frequently presents at major security conferences, both commercial (BlackHat, SANS, ...) and community (Defcon, Toorcon, Shmoocon, ...). In fact, I'm sure if you spoke with Jeremiah, he would give us a shining recommendation as well. And honestly, I'd say that you'd be hard pressed at finding anyone else in the industry that does better work than InGuardians and WhiteHat Security. You really can't go wrong with either choice.

Full Disclosure. I am a Senior Security Analyst for InGuardians that specializes in network and web app pentests. Another one of our Senior Analysts is Kevin Johnson, who is the author and lead instructor for the SANS 542 "Web App Penetration Testing and Ethical Hacking" course.

    http://www.sans.org/security08/description.php?tid=1722

Here is something else to help you out, regardless of who you go with. Kevin and I have a few OSS community projects, one that you'd probably be interested in is our live pentest CD called "Samurai-WTF". It is a live Linux environment that has been pre-configured with the best open source and free tools for testing and attacking websites. Feel free to go download a copy from our website. It works great running from any of the virtual machine products out there, and also works great if you burn it to a DVD. Once you get it running, the login is "samurai" with the password "samurai".

    http://samurai.inguardians.com/

I'd love to draft up a proposal for Kevin and I to pentest your website and the network it is sitting on. Please feel free to email me at justin (at) inguardians.com to set up a time to talk about your needs in more detail.

Check out our website if you would like to learn more about our company, the other services we offer, and the other members of our team.

    http://inguardians.com/

http://isc.sans.org/diary.html?storyid=5602

"A leap second will be added to the clock at 12/31/2008 23:59:59 UTC tonight.
Hopefully most IT folks will be otherwise occupied at that time and not focusing on their system clocks."

"Windows was wiiiide open for years, which is why there are so many exploits for it"

How do you explain the current phishing infestation ?

'We've all read the "Surviving the First Day of Windows XP" guide; we know how open that OS was'

It's news to me that it was considered so open. I can't find a link to the original but this says that to secure XP you enabled the XP firewall. Not much of an improvement then.

"Thinking for even one second that you're fully secure because you're using Linux makes you part of the problem"

It's not my Linux getting hacked that's a worry, but the server getting hacked and my identity stolen.

0-day for Internet Explorer v.7 is in the wild and was not patched yesterday

http://isc.sans.org/diary.html?storyid=5458
http://www.vupen.com/english/advisories/2008/3391
http://www.theregister.co.uk/2008/12/09/zero_day_ie_flaw_exploited/

Internet users located in China report infections that result when using IE 7 to browse booby-trapped websites. Researchers from McAfee investigated the matter and found the exploits successfully target the Microsoft browser on both Windows XP Service Pack 3 and Vista SP 1.