Slashdot Mirror

Check out CERT, a good site for this stuff. Here's their warning (more info than DHS). A list of what they have to block:
135/TCP
135/UDP
139/TCP
139/UDP
445/TC P
445/UDP

Also, it appears 4444 is being used,

Security Focus's incidentmailing list is also enlightening. And for good measure, a posting on the ineffectiveness one of MS's patch (as of 29 Jul).

Half-life hasn't got the best
security track record

Half-life hasn't got the best
security track record

Half-life hasn't got the best
security track record

Half-life hasn't got the best
security track record

Half-life hasn't got the best
security track record

Half-life hasn't got the best
security track record

Half-life hasn't got the best
security track record

Half-life hasn't got the best
security track record

There are multiple vulnerabilities in the Linux 2.4 kernel.

Get your patch here, here, or here.

BTW, there are no security patches required for OpenBSD 3.3 yet.

...can be found at SecurityFocus.

Indeed, I was just looking at this yesterday after taking over responsibility of a client's NT4 -> 2000 Active Directory migrated network, as the client machines are a mix of 98, 2000 Pro, and XP Pro.

This URL may be of some use?:
Active Directory Client Extensions for Windows 95/98 and Windows NT 4.0

I've yet to have time to check whether it's actually on the 2000 Server CD, but I hope so... (I still want to get rid of the 9x clients though)

Speaking of hardening Windows networks, I'd recommend checking out a few of the following:
Berkeley Labs Computer Protection Program: Windows Security (including guides on how to harden 2000 & XP)
Some interesting Windows password quirks
Ten Windows Password Myths
Securing Windows 2000: First Steps

That should be enough to get started :) Cheers,

Stef

...and rebuked the company's lawyers for wasting her time by promising proof that never materialized--legal vaporware, in essence.

As far as I can tell, the patents that InterTrust owns cover the technology; They don't go into details on accomplishing what they describe.

Q1. What if Microsoft developed a way to carry out their authentication (using these trusts) either
1. On their own or
2. Without even hearing about InterTrust's patent?

Q2.In the case of #2, everyone is probably saying "It doesn't matter..." but if this was the case, how would/did InterTrust find out about it? Microsoft doesn't leave their source code lying around the internet; Now they do give SDK's, but (at least prior to .NET framework), the SDK is vague on how things like authentication happen. If you want to learn about NTLM, you need to go to a site like Security Focus. The helpfile in any SDK that Microsoft releases will not talk about the underlying technology (or lack thereof...heh)

Of course, I'm not against suing Microsoft, but I'm just curious as to how this whole suit came up... Maybe someone else out there can enlighten me?

http://www.securityfocus.com/archive/1/83156/2002- 12-01/2002-12-07/0

To disable NTLM authentication, perform the following steps:

- Type 'telnet' at the command prompt.
- Type 'unset ntlm' and hit Enter.
- Type 'quit' to exit telnet and save your preferences.

To determine what form of authentication you are currently using,
perform the following steps:
- Type 'telnet' at a command prompt.
- Type 'display' at the telnet prompt.
- A value of 'Will Auth (NTLM Authentication)' means telnet will
use NTLM authentication by default.
- A value of 'Not Auth (NTLM Authentication)' means telnet will
not use NTLM authentication.

Note: Additional security patches are available at the Microsoft
Download Center

From the article here

But four Polish researchers, known as the "Last Stage of Delirium Research Group," said they discovered how to bypass the additional protections Microsoft added, just three months after the software went on sale.

Even the Poles are able to exploit Windows now! What is the world coming to?

DISCLAIMER: I love Poles, I married one! I love the Polish jokes too!

That's from here btw.

And the fourth item points to two programs (one in C, one in Perl) that supposedly would cause my server to run out of memory by sending very long SMTP commands to my qmail-smtpd server.

I ran both programs. In both cases, my qmail-smtpd server quickly aborted the connection with status 256, according to tcpserver, and the respective programs exited at about the same time.

Even if qmail-smtpd could be exploited to the point where it consumes all available memory, I suppose that'd apply to only that one instance of qmail-smtpd (i.e. that one connection), since a new instance is spawned for each incoming SMTP connection by tcpserver (if I have my facts right). So one could limit the amount of memory consumed by qmail-smtpd processes, using native OS facilities, so that any one process can't bring down the entire machine, which is what the exploit claims happens. (Absent adequate OS control over maximum run-time allocation of heap and stack memory, one could simply rewrite programs such as qmail-smtpd in ANSI FORTRAN 77, a language which allows an implementation to guarantee no run-time allocation of memory beyond the initial program image.)

But maybe the reason qmail-smtpd works for me is that I'm using the latest, greatest version of qmail -- version 1.03 -- which came out only recently. But I don't know when "recently" is, nor do I know whether or when qmail-smtpd might have been fixed to avoid the exploit described above.

However, since the email describing the exploit you identify was written in 1997, it's not what I would call "breaking news" in terms of qmail security concerns.

If you really do know of any security flaws in qmail, by all means identify them -- I'd like to look into closing them, since I run qmail on my server, which serves three domains of mine, two of which I actually use (haven't deployed the third yet).

Goto: http://www.securityfocus.com/search
Type qmail into the box, and push search. Be amazed!

• qmail-masq - A Perl program that works with qmail.
  
• Qmail passing sendmail vulnerability downstream - I understand that Qmail is not vulnerable to the recent Sendmail issue, but I want to know if Qmail will still forward the sendmail vulnerability...
  
• Is QMail also affected by the Send Mail Bug - (the answer is no.)
  

Goto: http://www.securityfocus.com/search
Type qmail into the box, and push search. Be amazed!

• qmail-masq - A Perl program that works with qmail.
  
• Qmail passing sendmail vulnerability downstream - I understand that Qmail is not vulnerable to the recent Sendmail issue, but I want to know if Qmail will still forward the sendmail vulnerability...
  
• Is QMail also affected by the Send Mail Bug - (the answer is no.)
  

Goto: http://www.securityfocus.com/search
Type qmail into the box, and push search. Be amazed!

• qmail-masq - A Perl program that works with qmail.
  
• Qmail passing sendmail vulnerability downstream - I understand that Qmail is not vulnerable to the recent Sendmail issue, but I want to know if Qmail will still forward the sendmail vulnerability...
  
• Is QMail also affected by the Send Mail Bug - (the answer is no.)
  

RFID Chips Are Here

RFID chips are being embedded in everything from jeans to paper money, and your privacy is at stake.

By Scott Granneman Jun 26 2003 09:15AM PT

Bar codes are something most of us never think about. We go to the grocery store to buy dog food, the checkout person runs our selection over the scanner, there's an audible beep or boop, and then we're told how much money we owe. Bar codes in that sense are an invisible technology that we see all the time, but without thinking about what's in front of our eyes.

Bar codes have been with us so long, and they're so ubiquitous, that its hard to remember that they're a relatively new technology that took a while to catch on. The patent for bar codes was issued in 1952. It took twenty years before a standard for bar codes was approved, but they still didn't catch on. Ten years later, only 15,000 suppliers were using bar codes. That changed in 1984. By 1987 - only three years later! - 75,000 suppliers were using bar codes. That's one heck of a growth curve.

So what changed in 1984? Who, or what, caused the change?

Wal-Mart.

When Wal-Mart talks, suppliers listen. So when Wal-Mart said that it wanted to use bar codes as a better way to manage inventory, bar codes became de rigeur. If you didn't use bar codes, you lost Wal-Mart's business. That's a death knell for most of their suppliers.

The same thing is happening today. I'm here to tell you that the bar code's days are numbered. There's a new technology in town, one that at first blush might seem insignificant to security professionals, but it's a technology that is going to be a big part of our future. And how do I know this? Pin it on Wal-Mart again; they're the big push behind this new technology.
Right now, you can buy a hammer, a pair of jeans, or a razor blade with anonymity. With RFID tags, that may be a thing of the past.
So what is it? RFID tags.

RFID 101

Invented in 1969 and patented in 1973, but only now becoming commercially and technologically viable, RFID tags are essentially microchips, the tinier the better. Some are only 1/3 of a millimeter across. These chips act as transponders (transmitters/responders), always listening for a radio signal sent by transceivers, or RFID readers. When a transponder receives a certain radio query, it responds by transmitting its unique ID code, perhaps a 128-bit number, back to the transceiver. Most RFID tags don't have batteries (How could they? They're 1/3 of a millimeter!). Instead, they are powered by the radio signal that wakes them up and requests an answer.

Most of these "broadcasts" are designed to be read between a few inches and several feet away, depending on the size of the antenna and the power driving the RFID tags (some are in fact powered by batteries, but due to the increased size and cost, they are not as common as the passive, non-battery-powered models). However, it is possible to increase that distance if you build a more sensitive RFID receiver.

RFID chips cost up to 50 cents, but prices are dropping. Once they get to 5 cents each, it will be cost-efficient to put RFID tags in almost anything that costs more than a dollar.

Who's using RFID?

RFID is already in use all around us. Ever chipped your pet dog or cat with an ID tag? Or used an EZPass through a toll booth? Or paid for gas using ExxonMobils' SpeedPass? Then you've used RFID.

Some uses, especially those related to security, seem like a great idea. For instance, Delta is testing RFID on some flights, tagging 40,000 customer bags in order to reduce baggage loss and make it easier to route bags if customers change their flight plans.

Three seaport operators - who account for 70% of the world's port operations - agreed to deploy RFID tags to track the 17,000 containers that arrive each day at US ports. Currently, less than 2% are inspected. RFID tags will be used to track the cont

Today meaning July 4th at 3:00 pm, this bug made its rounds on every major vulnerabilty database before slashdot even posted it... Why doesn't slashdot get its own vuln db? Or maybe a link to bugtraq: http://www.securityfocus.com/archive/1

then we wouldn't have to get our vulnerabilty news a day late and a dollar short.

Everyone is vulnerable to evil attachments -- just look at this from earlier in the week. As you suggest having to open the attachment to execute any evil payload is of course much better than having it execute on previewing, since most bad things are sent by unknowns or by a spoofed contact with obviously fake covering notes.

Kmail has a good balance between previewing content and safety IMHO, but then I am happy to see raw HTML by default.

I really don't consider this flame bait at all. In fact, I think that there are some good points here. It was actually just this afternoon that I submitted this smaller version of the story, which can be found here and here. The story was rejected, and I figured the reason it was rejected was because it wasn't really news. It was just something of an advisory. And nothing may materialize on the 6th, so there may be absolutely no point covering this.

And that's the reason I'm not so sure if this should be covered here. So I don't think this will cause those dastardly script kiddies to make a bigger mess. But I'm sure it'll make sysadmins take the usual precautions (ie. apply software patches, disable unnecessary services, etc.) So maybe something good can come from this.

Better watch out then...

It's really wonderful to know that the system mostly works.

The problem is it doesn't always work that way. Don't forget Cointelpro, and more recently the Ramparts case in LA and the Riders case in Oakland. As if to disprove that wide-spread, systematic abuse was part of the past, the DOJ brought us their post 9/11 roundup policy.

Getting a warrant is trivial. It is not an impediment to law enforcement and represents only the most inconsequential of protections (no wiretap request was turned down last year). What it does provide is a paper trail a tiny bit of oversight, and that means some recourse for the Abner Louima's of the world, and possibly a moment of reflection for the cops to question their own actions, even if the judge really isn't likely to.

It's right to help law enforcement in their legitimate business, but it's not up to a private company to determine legitimacy, it's up to the courts. That everyone has the right (I think still) to refuse to cooperate without a warrant is our only fig leaf; dropping it voluntarily just encourages abuse. We all owe it to our police forces to make it harder for the bad apples to ruin things for the good cops.

Hopefully some bad cop somewhere will misuse this policy of eBay's and the injured party will file a massive lawsuit against eBay for aiding and abetting the crime and collect a meaningful punitive reward. Probably not, but we can hope. In the mean time, eBay makes it easy for anyone who wants a few credit card numbers to pay their bills.

At the rate they move (as fast as Red Hat, but slower) I would expect it to be in the STABLE around the same time the four horsemen ride by

Which is not very far away after reading Revelation 13:16-17 and this article on RFIDs.

Also, who's to say that there will be any connection between the id stored in the tag and your name?
there may not be a connection immediately. It may be made later (the same way HTML cookie information is collated). Like when you hand over your ticket and step on an airplane, or when your EZpass equipped car goes through a tollbooth. The data can be collected now, and the individual identified later. Like when the police come to your door to pick you up as a material witness.

Companies would have no reason to keep track, and they're the only ones who could get that information.
That's showing a distinct lack of imagination. Companies have a ton of incentive to keep track. For example, think of all the great marketing information you can gather. For example, maybe Gap sweatshirt buyers hang out at the mall food court. Good place to advertise specials. What brands of clothing show up at a baseball game, or a chick flick, or the tool dept. at Sears? This information is valuable, and as it becomes cheaper to collect, companies will want to.

Instead of spreading FUD, try promoting proper use and regulation of a new technology that could be very beneficial in a lot of areas.
I'd love to see your suggestions for regulations controlling the use of RFID information. And I'd love to see a bill about it introduced in Congress before it becomes a problem. But as we know from the spam situation, Congress usually waits for something to become a big problem before it's willing to limit the freedom of marketers.

I also think you should withdraw that comment about FUD. Everything I wrote follows from intentions or potential intentions announced by companies or other institutions and described in the original article.

Be sure to read this interesting reply to this story by a security director at Unisys UK.

And here you can read about the newest security leak which is not patched by this servicepack ;)
That guy who analysed the buffer overflow also found a funny easteregg in the buggy dll file. :)

WEP (Wired Equivalency Protection) uses RC4 encryption which is not very strong. Due to the design of RC4 (it was intended to be used over a synchronous stream), WEP designers had to make the key change with each packet. This means that the keys are quickly reused, and thus a sinffer can eventually - and usually rather quickly in large networks - determine the key loop. The SSID (Service Set ID) is sent over the wire either unencrypted or encrypted using weak algorithims.

WTLS (Wireless Transport Layer Security) was designed poorly as well. It's design limits the effectiveness that a certificate authority like Verisign can have when using WTLS.

Attacks against the WAP WTLS protocol (PDF): Source one, Source two

Security+ primer (lots of basic WEP, WAP, WTLS): Alpha Geek

Intrusec posted an analysis of a single trojan they had dissected. It was posted both on BugTraq and Incidents, but the former had better formatting. Read the lengthy description here.

It seems ISS pulled their information from Intrusec's report. As to the copycat nature of this trojan, Intrusec researchers believe this piece of code is not the real trojan but simply a good imitation, built on the information already discovered of the '55808' trojan and designed to match the known behaviour.

Disclaimer: I just read the mailing-lists. This particular analysis was remarkably well-written, informative and therefore an enlightening read. Compared to the less informative reports seen about weekly, it was a real delight.

You know... All of these fancy 'spam-fighting' methods are just a waste of time, when all you really need is a properly configured smtp server and some good free realtime blackhole lists. After making simple changes, I went from receiving 5-6 spams a day down to 1 in a year and a half. With no complaints of 'false-positives'. There have been instances where the senders mail server was misconfigured, but after contacting them and explaining the situation they were invariably helpful. All I did was make sure that only mail sent from fqdn to valid local accounts, and such were allowed there is an ok tutorial on basic psotfix configurattion herehere.... and a great one Here.

When you can't get anyone to care, perhaps it's time to try out Tim Mullen's strikeback proposal. He wrote about defending yourself from worms actively attacking you, but I think shutting down a passive attack is worth contemplating.

Securityfocus mailing lists is definitely one place to go. You'd probably want to post on the Incidents list. They also have a Focus on Incident Handling list which is more about discussing incident handling procedures.

In any case, once it's posted in a big enough public forum, it becomes a problem for their Public Affairs/Public Relations dept and not just tech support. Don't know if Slashdot qualifies as big enough, but you might as well try Cnet/Wired since they've reported these kinds of large scale hacks before.

With all of the new wireless-enabled cars that are due to come out (like Daimler-Chrysler's UConnect) and emerging hacking tools like Redfang it's getting scary to drive a car.

As you said, they have the ability to log it on a client level. Imagine a company with 500 000 machines. Are you going to collect logs from each and every one every single day?? Even if you saved the logs on a network drive, do you want 500 000 different files per day?

The difficulty is logging the traffic on a server level. The reasons are many. I think this article describes them fairly well.

Basically, IM traffic tries to hide itself, generally as HTTP traffic. Yahoo for example prepends a HTTP header to all packets, thereby being disguised as a HTTP GET request. AOL/ICQ/MSN has the ability to use HTTP Proxy servers, and AOL provides www.proxy.aol.com for free (port 80, no pass). MSN will auto-configure itself to use a proxy server if direct access is blocked.

Here's the result of logging IM traffic on a client level.

Any admin who isn't completely shirking his duties has exactly no use for this book. Who, then, will find it valuable? That's right: hackers. Script kiddies have an easy enough time of it as it is. The computer book industry needs to take some responsibility and stop publishing this sort of hacker how-to.

A truly secure system must be able to withstand open review at all levels (e.g. protocol, source code, etc).

The details of security vulnerabilities should be available to everyone. (source: Bugtraq)

And I've just hijacked my own /16!

Also, I find that Security Focus has a huge backlog of very useful and interesting information for those concerned with computer security. In that same vein, dbaseiv.net [Google cache, the site seems to be down right now] is shaping up to be a huge repository of computer security knowledge.

The Linux Documentation Project is full of HOWTOs relating to Linux, if you've got a Linux problem that you need to work out (though HOWTOs make for really boring recreational reading).

This is just what I can come up with off the top of my head, I'll probably post a reply to this when I remember more.

because if you'd actually learned anything in the same 20 years that I've been working in IT it is that there is no "magic platform" that's invulnerable to sloppy coding be it windows, linux, AIX, plan9, OpenBSD or whatever.

Go read Security Focus and count the number of "Design Errors"

Here's one from today's front page :

Linux Kernel Privileged Process Hijacking Vulnerability **

> I have 7 PC's here at home, all of them are Linux.

Your cock waving has no effect I'm afraid.

> It's not FUD, it's FACT.. I know it from experiance.

If I can restate your premise :

-----
"Every fscking worm/backdoor is allowed to call home"
Simple. Don't use Windows.. That's a Windows problem.
-----

It's not even factual let alone borne of experiance [sic].

It's about a firewall rule. And it sounds like a simple NAT. It doesn't even have anything to do with Operating Systems

>I quit using Windows in August of 2002 and have not had a single worm, virus, trojan, backdoor, hack, sneeze, fart, or burp since..

I've been using Windows since 1987 and have never suffered from any of those things.

> I didn't just fall off of the turnip truck...

Nope, sounds like you stayed right on the top of the pile

** A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges.

The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes.

This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

It's as safe as windows 2000 sp3 with updated IIS 5.0 listening on port 80 and 21.
ISS related exploits

Ugh. Another flame-war sparked by those who favor "disclosure". In the minds of some, "disclosure" and "exploit code" are synonymous; anyone who feels differently must be in the "anti-disclosure" camp. As expected, the "disclosure" mujahedin trot out their usual line of reasoning, which is roughly: "if sploits are outlawed, only outlaws will have sploits." And of course, they make the same shrill, baseless ad hominum accusations of sell-outs and cover-ups. Please.

I have some bad news for those who believe that the value of vulnerability information will somehow be irretrievably reduced simply because exploit details are not included.

Let's go to the videotape, shall we? In 2000, Arbaugh, Fithen, and McHugh at the University of Maryland published an IEEE article on the lifecycle of vulnerabilites, based on CERT/CC reporting data. The article contains quite a bit of empirical data and several useful charts. Here is the money quote:

The argument for releasing vulnerability information to the public stems from the belief that crackers already know the information -- but system administators don't... In our research, we found that automating a vulnerability, not just disclosing it, serves as the catalyst for widespread intrusions.

The notion that somehow it doesn't matter if the exploit code is published is just hogwash. It does matter. It makes a decisive difference in the rate of incident occurrences, as the data shows. The number of zero-day exploits is a tiny trickle compared to those that come later, after scripts are widely circulated.

Vulnerability disclosure is critical to making systems more secure. Vulnerability information needs to be freely available to the public. But posting detailed "proof of concept" code that can be easily converted into an automated attack script is another thing entirely. Posting exploit scripts in public forums is, as P.J. O'Rourke once put it, "like giving whiskey and car keys to teenage boys." It is reckless, and irresponsible. Self-important glory-seekers who wail that their livelihoods are at risk, it seems to me, need to develop some more marketable skills.

Admittedly, I have only perused the draft, but it does appear to be another attempt to prevent large companies from being "outed" when they choose to release software that is not ready or is poorly designed. Bugtraq, the Internet Storm Center and the Insecure.org Mailing List Archive do a fine job of lighting a fire under the responsible buttocks when necessary.

I have yet to hear of a posting to one of these lists that could be considered responsible for actual "trouble".

I would assume that if someone were planning on taking advantage of a vulnerability, they would look for one that hasn't yet made it to these lists.

It can be interesting and it improves ones ability to read, write, and understand code.

Doing so in a public forum can create reputation capital for ones consulting services or products. In some cases may lead to employment.

Some folks are truly motivated by the desire to see vendors patch their software. This is sometimes a result as well.

The companies involved in the OIS have already established their reputation. They aren't doing this for fun. It is to their advantage to prevent others from competing with them. The idea here is to keep interesting research and discussions closed while charging naive corporations thousands of dollars to attend talks which provide little to no real information.

Look the goal here is to make money and that is noble and good. In order to do this people shouldn't just give away all of their hard work and research. The problem here is that these guys are protecting their bottom line under the guise of Internet Safety. It is a bit disgusting but I think might be irrelevant in the long run. Since SecurityFocus is part of this plan though I bet the mailing lists over there will be short lived. Oh well nothing lasts forever.

Dave Aitel makes some rather lucid observations.

2.2 Phases

The basic steps of the Security Vulnerability Reporting and Response Process are:

# Discovery. The Finder discovers what they consider to be a security vulnerability (the Potential Flaw).

# Notification. The Finder notifies the Vendor and advises it of the Potential Flaw, and the Vendor confirms that it has received the notification.

# Investigation. The Vendor investigates the Finderâ(TM)s report in an attempt to verify and validate the Finderâ(TM)s claims, and works collaboratively with the Finder as it does so. # Resolution. If the Potential Flaw is confirmed, the Vendor identifies where the Flaw resides, then develops a remedy (in the form of a software change or a procedure) that eliminates or reduces the risk of the vulnerability.

# Release. In a coordinated fashion, the Vendor and the Finder publicly release information about the vulnerability, along with its resolution.

Now look at this under the context of the recent MS Passport Vulnerability to see how effective this process is.

As an aside, this draft is backed by MS and SCO, amongst other companies. It'll be interesting to read the amount of bashing this gets over the weekend.

Do not click on the attachment!!!

I'm sorry, you guys are all wrong. This exploits the relatively new (Well - from November of 2002 - not 2 years in any case) iframe vulnerability in IE.

That's why you should never ever have dynamically linked setuid programs! (Or, if they do exist, they should give up root before calling any non-static functions. Some programs do that)

This evil user could just set LD_PRELOAD to his own library, without needing to mess with new filesystems.

A few years ago, several GNOME programs that were setuid were rearranged to no longer be root, because of this vulnerability. Xcdroast is one of the more famous ones.

Additionally, in a system where normal users are allowed to mount their own filesystems, they should only be permitted to place them in ~/mnt.

There is now more information here . It looks like an exploit is possible, though it would be difficult. Better to upgrade now and be safe.