Planet Security

Vuln: DotNetNuke User Account Security Bypass Vulnerability

2009-01-05T23:11:37+00:00

DotNetNuke User Account Security Bypass Vulnerability

OSSEC HIDS being detected as malware, (Mon, Jan 5th)

2009-01-05T23:03:15+00:00

Daniel from OSSEC has reported that a couple Antivirus products are currently detecting the Windows ...(more)...

MVP for another year

2009-01-05T22:19:18+00:00

Well, since everyone else is announcing it, I may as well follow the lemmings.

With many thanks to Microsoft. I have been awarded the distinction as an Enterprise Security MVP with developer focus for a 4th year. Much appreciated. It is truly an honour. I am in a category with several of my friends I have high respect for in the industry like Jesper and Alun. God help us all... we should have some fun again this year at Summit.

Oh, and congrats to Dan for being awarded this year. It's nice to have a friends who LIKE smartcards and crypto join the Enterprise Security MVPs :-)

Looking forward to seeing everyone at MVP Summit!

Bugtraq: [USN-702-1] Samba vulnerability

2009-01-05T21:13:16+00:00

[USN-702-1] Samba vulnerability

FBI's New Cryptanalysis Contest

2009-01-05T20:56:32+00:00

From their website.

UK Police planning to hack citizens' PCs, (Mon, Jan 5th)

2009-01-05T20:52:57+00:00

An interesting article from the TimesOnline - http://www.timesonline ...(more)...

Tim Callan: MD5 Hack Interesting, But Not Threatening

2009-01-05T20:12:07+00:00

MD5 Hack Interesting, But Not Threatening

Major security problem for Twitter

2009-01-05T20:03:20+00:00

High profile Twitter accounts have been compromised and reports suggest the hole may still be open despite Twitter's assurances that it is fixed

Attacking Intel® Trusted Execution Technology

2009-01-05T19:23:26+00:00

Press people: please read our press release first and also refer to the disclaimer at the end of this blog post. Thank you!

Update: 1/5/2009 19:21 CEST: minor typos/spelling corrections. Thanks to Jarred for point out some of the typos.

A word about Trusted Computing
The term Trusted Computing and related technologies, like Palladium, Trusted Platform Module, LaGrande, have always caused lots of controversy in the IT world. Most of the fear, however, has been a result of the lack of understanding of how a particular technology really works.

Nevertheless, Trusted Computing is becoming part of our lives, whether we want it or not. These days almost every new laptop comes with an on-board Trusted Platform Module (TPM). Microsoft's Palladium initiative have been renamed so many times in the recent years, that probably even people working at Microsoft are confused now. Nevertheless, some of the Palladium technologies made their way into Vista, and Microsoft BitLocker is, without doubt, the most successful, widely deployed product that is based on the idea of Trusted Computing. (In fact the Bitlocker is the only one thing that I really have been missing since I switched from Vista to Mac some time ago).

On the hardware side, besides the famed TPM, we also have had the LaGrande technology, that is often connected with things such as Remote Attestation, Protected Execution and other scary terms…

A word about Trusted Execution Technology
LaGrande, recently renamed Trusted Execution Technology (TXT), is Intel's response to the Trusted Computing trend. TXT is currently part of the vPro™ brand, and for about a year now users can buy a vPro/TXT compatible hardware in regular computer stores (the first one was the DQ35J desktop board with certain Core 2 Duo processors, which I was able to buy at the end of 2007 — remember that TXT requires support from both the CPU and the chipset).

TXT is not an alternative to TPM, in fact TXT heavily relies on the TPM to provide basic services like e.g. secure storage of measurements done by the TXT. Also, Palladium, or whatever it is called these days, is not a competition to TXT. Intel TXT can provide building blocks to e.g. Vista Bitlocker, arguably making it more secure then it is now (Current Bitlocker implementation, AFAIK, relies on a so called Static Root of Trust for Measurement, which requires TPM, but not TXT).

What kind of measurement would TXT like to store in our TPM? Well, the whole TXT is, in fact, all about making and storing software measurements, or, using a more familiar language, secure hashes of certain software components.

The sole purpose of Intel TXT technology is to provide a trusted way for loading and executing system software, e.g. Operating System kernel or Virtualization Machine Monitor. What is extraordinary here is that TXT doesn't make any assumptions about the state of the system before loading the software, thus making it possible for a user to ensure secure load of an OS or VMM, even in a potentially compromised machine.

In other words, our system can be all full of boot sector viruses and BIOS rootkits, and god-knows-what-else, and still TXT should allow to load a clean VMM (or OS kernel) in a secure way, immune to all those rootkits present in the system in a moment just before the load process. This TXT-supported load process is called Late Launch, and is implemented via a special new CPU instruction called SENTER.

It's a good place to mention that AMD has its own version of the late launch implemented via SKINIT instruction. We haven't looked at the AMD technology thoroughly yet, so I will refrain from commenting on this.

The late launch is a pretty amazing thing, when we think about. It promises to effectively provide all the benefits of a computer restart without actually restarting it.

It is hard to overemphasize the potential impact that a technology such as TXT could have on computer security. One can immediately see that it could eliminate all the system-level persistent malware — in other words we can easily build systems (VMMs or even standard OSes) that would be immune to attacks that try to compromise system binaries on disk, or attack the system right from the bootloader or BIOS. Combining this with VT-x and VT-d technologies, system developers (for the first time, at least as far as the "PC" platform is considered) have gotten extremely strong tools into their hands that should allow them to create really secure VMMs and OSes…

Hopefully by now, my Dear Reader, you should have the feeling what kind of an animal Intel TXT is and how desperately the world needs it...

And now, we are going to move on and show practical attacks on current TXT implementations... :)

Attacking Intel TXT!
Ok, not in this post today, but rather at the upcoming Black Hat conference in Washington, DC in February. Over the recent months, Rafal and I have been looking at the Intel TXT technology as part of a work done for a customer, to see if this could be used to improve security of a product, from a typical user's perspective. We figured out that it definitely could, but that there are also some issues…

And those "issues" gave us a starting point in developing a proof-of-concept (albeit very reliable) exploit that shows how we can bypass trusted boot process implemented by Intel's tboot.

Tboot, which is also part of (scroll down to the end of the page) the Xen hypervisor, can be though of as a reference implementation of TXT-based system loader, that could be used to securely load either the Xen hypervisor or the Linux kernel, when run on a vPro/TXT compatible hardware.

[copy-and-paste from the press release follows]

Our attack comprises two stages. The first stage requires an implementation flaw in a specific system software. The second stage of the attack is possible thanks to a certain design decision made in the current TXT release.

While evaluating the effectiveness of the Intel® TXT technology, as part of a work done for a customer, we have identified several implementation flaws in the Intel's system software, which allowed to conduct the above mentioned stage-one attack. We have provided Intel with extensive description of the flaws in December 2008, and Intel is currently working on fixing those vulnerabilities.

We have also been in touch with Intel about the possibility of conducting the second-stage attack since November 2008. In December, after providing Intel with the details about the first-stage attack, Intel promised to release, in the coming weeks, an updated TXT specification for developers that would explain how to design their TXT-based loaders in such a way that they are immune to our attack. Intel claims the current Intel® TXT release does contain the basic building blocks that could be used to prevent our second-stage attack and the release of the additional specification would make it feasible in practice.

More details in February in DC :)

TXT useless?
Some people are skeptical about the TXT technology, and not only because of the Irrational Fear of the Trusted Computing (IFTC), but rather because they point out to the complexity of the whole technology. The complexity is bad, because 1) it leaves more space for potential attacks, and 2) it discourages developers (ISVs) from using the technology in their products (e.g. neither Microsoft, nor VMWare make use of TXT in any of their bare-metal hypervisors, even though TXT is very well suited for this kind of software).

It is true that TXT is a very complex technology (the SENTER instruction is probably the masterpiece of the CISC architecture!), but I personally like it. In my opinion this is the first technology available for the PC platform that has the potential to really change something, much more then the NX-feature did a few years ago. Before people will run to the comment box — if you would like to argue about the usefulness/uselessness of Trusted Computing/TXT, please base your opinions on technical facts (read the spec!) and not on your feelings!

Disclaimer (for press)

Starting January 2009, we (at Invisible Things Lab), decided to issue press releases in addition to this blog. The general rule is: press releases are written for journalists, while the blog is mainly written for other researchers, security enthusiast, etc.

The wording of our press releases is carefully chosen to minimize the potential of a possible misinterpretation. The press releases carry less information, but, we think, are better suited for a more general public, that doesn't have background in computer science, programming and security.

The blog is written in a much more casual way, without thinking for half an hour on every sentence. The articles on this blog might present some facts as extremely exciting, because e.g. for me, a person deeply involved in a system-level security research, they indeed might be very exciting, which might not be the case for a general audience. I sometimes might also use shortcuts, metaphors, or irony, and other figures of speech, that might not necessarily be obvious for a more general public.

If you are a journalist and you think you just found something very sensational on my blog, I would suggest that you double-check with me, before writing about it.

Thank you for your cooperation.
Joanna Rutkowska,
Founder and CEO,
Invisible Things Lab.

Bugtraq: Re: php 4.x php5.2.x all "show_source()" ,"highlight_file()" bypass‏

2009-01-05T19:12:53+00:00

Re: php 4.x php5.2.x all "show_source()" ,"highlight_file()" bypass‏

Bugtraq: Walusoft TFTPServer2000 Version 3.6.1 Directory Traversal

2009-01-05T19:12:53+00:00

Walusoft TFTPServer2000 Version 3.6.1 Directory Traversal

Bugtraq: Re: php 4.x php5.2.x all "show_source()" ,"highlight_file()" bypass‏

2009-01-05T19:12:53+00:00

Re: php 4.x php5.2.x all "show_source()" ,"highlight_file()" bypass‏

Boffin brings ‘write once, run anywhere’ to Cisco hijacks

2009-01-05T19:10:24+00:00

Curse of the ROMmon
A researcher has discovered a way to reliably exploit a known security vulnerability in a wide class of Cisco System routers, a finding that for the first time allows attackers to hijack millions of devices with a single piece of code.…

Read more…

Twitter Security Collapses; Obama, Fox and Britney Accounts Hacked

2009-01-05T18:04:41+00:00

"Days after a wave of phishing attacks fooled thousands of Twitter users, it appears that another security hole has been found by...someone. Obama's account, unused since election day, sent out an affiliate link to a survey with a gas card prize, Fox News said that "Bill O'Reily is gay" (not that...

jonudell

2009-01-05T18:01:57+00:00

Sam Ruby offers the following advice to those of us who would like to improve the interoperability of iCalendar feeds:

Identifying real issues that prevent real feeds from being consumed by real consumers and describing the issue in terms that makes sense to the producer is what most would call value.

I’ll be documenting issues as I encounter them. Here’s the first: Should feeds use, or not use, blank lines between components? (A component is a chunk of text representing an event, or something else that can show up in an iCalendar file, like a todo item.)

The presence of blank lines is a reason why this feed is one of two I’m tracking that won’t parse in DDay.iCal.

The unmodified feed looks like this:

BEGIN:VEVENT
...stuff...
END:VEVENT

BEGIN:VEVENT
...stuff
END:VEVENT

Part of the “fix” is to make it look like this:

BEGIN:VEVENT
...stuff...
END:VEVENT
BEGIN:VEVENT
...stuff
END:VEVENT

But I’ve put “fix” in air quotes because, well, who’s wrong in this case? The feed producer (in this case, the Keene Chamber of Commerce), or the feed consumer (in this case, DDay.iCal)?

I looked at the spec and didn’t find evidence pointing one way or the other. Neither did this person:

> 1) yes, KOrganizer adds empty lines between VEVENT, VTODO and
> VJOURNAL. I just checked the specification (RFC 2445), and it
> doesn't say anything about blank lines... (neither explicitly
> allowed, nor explicitly not allowed)

This is a perfect example of why the process that Mark Pilgrim and Sam Ruby went through for RSS/Atom feeds will be so valuable for iCalendar feeds. Quite a few details that affect interoperability turn out to depend on assumptions and interpretations that aren’t explicit.

Maybe I’m misreading the spec, and it really does forbid blank lines between components. If so, great, the validator can enforce that rule. But maybe it neither allows nor forbids. In that case, the validator can say so, and suggest a best practice. In this case, my guess is that the best practice would be not to include blank lines.

But I said that remvoing the blank lines is only part of the “fix” — and here’s why. When I remove them, the feed still won’t parse in DDay.iCal, but for a different reason. Now the problem lies here:

BEGIN:VCALENDAR
X-WR-CALNAME:GKCC
BEGIN:VEVENT
...stuff...

In this case, the reason is clearly stated in the spec. A feed is supposed to include VERSION and PRODID properties like so:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
BEGIN:VEVENT

If I inject those into the Chamber of Commerce feed, and remove blank lines, it parses in DDay.iCal.

Note that the unmodified feed is reported to be valid by this iCal4J-based validator. A more robust validator, in the style of the Pilgrim/Ruby RSS/Atom validator, would fail the feed, and would cite the relevant part of the spec in its explanation of the failure.

The spec says, by the way, that both VERSION and PRODID are required elements. When I saw that DDay.iCal was rejecting the Chamber of Commerce feed, which contains neither, I figured that was why. And sure enough, it accepts this:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:Keene Chamber of Commerce
X-WR-CALNAME:GKCC
BEGIN:VEVENT

But it also accepts this:

BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:GKCC
BEGIN:VEVENT

And this:

BEGIN:VCALENDAR
PRODID:Keene Chamber of Commerce
X-WR-CALNAME:GKCC
BEGIN:VEVENT

But not this:


BEGIN:VCALENDAR
PRODID:Keene Chamber of Commerce
BEGIN:VEVENT

Eventually I twigged to the fact that it’s evidently just looking for two (or more) non-empty lines between the BEGINs. For example, this parses:

BEGIN:VCALENDAR
FOO:BAR
BAZ:FOO
BEGIN:VEVENT

In practice this isn’t a big deal. None of the metadata matters to me, for my purposes, so my aggregator can just elide it before sending a feed to the parser. But the metadata might matter for someone, for some purpose. A proper validator would help ensure that it will be available to those people, for those purposes, by enabling feed producers and feed consumers to more easily produce and consume valid feeds.

For what it’s worth, I’m going to track this category of issue using the tag icalvalid, and I invite other interested parties to do the same. As in the case of the grl2020 tag, I know the tag can appear in a variety of places including del.icio.us, Technorati, WordPress, and nowadays of course Twitter. So I’ll create a metafeed that tracks icalvalid in all of those places.

Update: OK, here’s the icalvalid metafeed, based on this Yahoo Pipe.

2009-01-05T17:47:00+00:00

Attacking Intel® Trusted Execution Technology by Joanna Rutkowska

Exploits of the Week #4

2009-01-05T17:37:13+00:00

Megacubo 5.0.7 Download & Execute Remote Exploit

JJunior

PHP GD Library Information Leak Exploit

Hamid Ebadi

Destiny Media Player 1.61 “lst file” Local Buffer Overflow Exploit

Encryt3d.M!nd

VMware Remote DoS Exploit

Laurent Gaffie

Konqueror 4.1 XSS & Crash Exploits

staker

Let the experts make sure your website is safe. Vulnerability Assessment is the answer.

HTTP Verb Brute Forcing

2009-01-05T17:21:53+00:00

I read a few interesting posts here and here regarding brute forcing HTTP verbs. The F5 post suggested that it is possible to thwart people who are looking for what options you support by giving a fake response. That’s certainly one way to do it, but it’s not as robust as it might appear.

By actually testing each verb by hand, it’s pretty easy to skip using options, if that’s not available to you. Or, if you are on the defensive side, if you are turning off one verb, turn off everything that you don’t use, so you don’t have to worry about it. Iterating verbs can be super useful for finding open/unprotected Webdav servers, finding open directories that allow PUT, or open proxies. In general automated worms just try to perform the exploit rather than iterate options anyway, so in general it’s probably a good idea to shut down all HTTP verbs and open them up as you need them, rather than close them down one at a time as you figure out why they could be used for nefarious purposes.

Flashy botnet is Flashy

2009-01-05T17:14:53+00:00

We did some co-operation recently with a company called Clarified Networks. Some of you might remember them as the guys who did the *wow* visualization of the Kaminsky DNS hole for his Black Hat presentation.

So we collected some botnet data and asked them to visualize it.

The end result is a quite nice animation. You can get more info and the actual end result from their blog at www.clarifiednetworks.com

On 05/01/09 At 04:56 PM

Mandriva: Subject: [Security Announce] [ MDVA-2009:002 ] msec

2009-01-05T17:08:00+00:00

LinuxSecurity.com: This update fixes the following two issues with msec: when changing to a higher security level, permit_root_login is not handled correctly (bug #19726)

Phishers Now Twittering Their Scams

2009-01-05T16:48:19+00:00

Phishers are trying to trick Twitter users into forking over their user names and passwords by sending tweets that direct users to fake Twitter login pages, security experts warn. Blogger Chris Pirillo spotted the Twitter phishes on Jan. 3, after receiving a tweet that asked him to log in at a counterfeit Twitter site called “twitter.login-access.com” (it’s probably best to avoid visiting this site, which is still active as of this writing.) Suspecting that access-logins might be a domain used by phishers to scam any number of popular online brands, I ran a reverse lookup on the Web site name. While that domain appears tied to just this one scam, the Internet address tied to that domain - an address in China - is currently home to a number of other phishy domains that include misspellings of popular social networking sites, such as: beboaccess.com (currently points to a facebook phishing

Read more…

Microsoft tells how it missed critical IE bug

2009-01-05T16:33:04+00:00

Microsoft developers overlooked a critical bug in the Internet Explorer browser because of a lack of adequate testing tools and training, a company official acknowledged last month.

Four information points on Twitter phishing

2009-01-05T16:22:53+00:00

I don’t have a lot of time this morning, but here are four bits of information on Twitter and the phishing attack against it that started this weekend. Haven’t there been a number of us that have been saying for a while “Don’t put your username and password into 3rd party applications on the web!”?

Twitter and the Password anti-pattern - I’ve only gotten about half way through this paper, but I like the ideas I’m reading. This is basically an argument for taking Twitter beyond username/password and adding in functionality that would allow you to share some of your capabilities as a user with a third party.
Phishing Scam spreading on Twitter - This was the first article I read on the Twitter Phishing this weekend.
Gone Phishing - This is Twitter’s take on the phishing scam. Glad they’re being proactive.
Twitter Users attacked by Phishing efforts - Symantec’s take on events.

I asked once before “Is Twitter a security risk?“. This isn’t a problem with twitter, this is a problem with people who are willing to give up their usernames and passwords for … what? A little sense of an ego boost as they find they’re relevant somehow? A pretty graphic that shows how they’re connected to other Twits? People don’t seem to realize this is another extension of their digital identity, just like a facebook account or email address.

Cryptol Language for Cryptography

2009-01-05T16:18:54+00:00

Galois has announced ""

Cryptol is a domain specific language for the design, implementation and verification of cryptographic algorithms, developed over the past decade by Galois for the United States National Security Agency. It has been used successfully in a number of projects, and is also in use at Rockwell Collins, Inc.
... Cryptol allows a cryptographer to:

Create a reference specification and associated formal model.
Quickly refine the specification, in Cryptol, to one or more implementations, trading off space, time, and other performance metrics.
Compile the implementation for multiple targets, including: C/C++, Haskell, and VHDL/Verilog.
Equivalence check an implementation against the reference specification, including implementations not produced by Cryptol.

The trial version & docs are here.

First, I think this is really cool. I like domain specific languages, and crypto is hard. I really like equivalence checking between models and code. I had some questions, which I'm not yet able to answer, because the trial version doesn't include the code generation bits, and in part because I'm trying to vacation a little.

My main question came from the manual, which ~~First off the~~ manual states: "Cryptol has a very flexible notion of the size of data." (page number 11, section 2.5) I'd paste a longer quote, but the PDF doesn't seem to encode spaces well. Which is ironic, because what I was interested in is "does the generated code defend against stack overflows well?" In light of the ability to "[trade] off space, time [etc]" I worry that there are a set of options which translate, transparently, into something bad in C.

I worry about this because as important as crypto is, cryptographers have a lot to consider as they design algorithms and systems. As Michael Howard pointed out, the Tokeneer system shipped with a library that may be from 2001, with 23 possible vulns. It was secure for a set of requirements, and if the requirements for Cryptol don't contain "resist bad input," then a lot of systems will be in trouble.

Biometric Fail reported

2009-01-05T15:46:58+00:00

A South Korean woman entered Japan on a fake passport in April 2008 by slipping through a state-of-the-art biometric immigration control system using special tape on her fingers to alter her fingerprints, it was learned Wednesday...
During questioning, the woman allegedly told the immigration bureau that she had bought a forged passport from a South Korean broker who told her to purchase an air ticket for Aomori Airport.
The woman also was quoted as saying that the broker gave her the special tape with someone else's fingerprints on, and that she slipped past the biometric recognition system by holding her taped index fingers over the scanner.

So reports the Yomiuri Shimbun, "S. Korean woman 'tricked' airport fingerprint scan." The story doesn't mention a name, but if anyone has more details, I'd love to know more.

[Update: DanT has some interesting speculation in the comments about both operational aspects of the entry being an inside job, and that the bureaucracy in question would re-assign the insider rather than prosecute.]

jonudell

2009-01-05T15:24:30+00:00

On this week’s Interviews with Innovators show I spoke with Jeff Jonas whose work (and narration of that work on his blog) first captured my interest in 2007.

If you follow Jeff you’ll know what he means when he uses phrases like perpetual analytics, non-obvious relationship awareness, semantic reconciliation, sequence neutrality, and anonymous resolution. If not, and if you’re interested in how we can connect the dots across siloes of data, I recommend that you peruse his blog first and then listen to this interview, which clarifies a couple of points I’d been wondering about.

One of Jeff’s tenets is that new information has be able to answer old questions, and answer them in near-realtime. On the face of it that seems impossible. How can you compare a newly-ingested fact with every existing fact in a database, and run every imaginable query?

Well of course you can’t, and don’t, visit every record in the database. You consult an index, and the interesting question becomes: What kind of index? In Jeff’s world, it’s an index based on keys that represent entities (people, places, organizations) and “features” (locations, relationships). And these entities are fuzzily defined. I think of them as clouds of associations. So for example the key for Jon Udell would point to items where Jon is misspelled as John. Most systems abhor this kind of variation, but Jeff embraces it, and I find that fascinating.

Another intriguing idea was reported by Phil Windley in his write-up on Jeff’s ETech talk:

Jeff treats query as data. When a query is made against the context, and gets no response, it’s stored in the database. Later if data shows up that matches the query, you get a match. Treating queries like data makes it so you don’t have to ask every question every day.

Here again, I wondered how you avoid running every query against every new fact. What does it mean for data to “match” a query? Part of the answer, as I understand it, is that both queries and data are indexed semantically, using keys that encompass clouds of associations.

Another part of the answer emerged in this interview. You have to be really sure about those associations. If you put a John Udell record into the Jon Udell bucket, you had better be certain that this is a legitimate misspelling in an item that refers to a particular instance of Jon Udell (i.e., me, not this guy), rather than a legitimate reference to one of the John Udells.

Now that I know about this constraint, the whole thing makes more sense.

Ubuntu: Samba vulnerability

2009-01-05T15:19:00+00:00

LinuxSecurity.com: Gunter Höckel discovered that Samba with registry shares enabled did not properly validate share names. An authenticated user could gain access to the root filesystem by using an older version of smbclient and specifying an empty string as a share name. This is only an issue if registry shares are enabled on the server by setting "registry shares = yes", "include = registry", or "config backend = registry", which is not the default.

[3/5] NPDS Multiple Vulnerabilities

2009-01-05T15:04:29+00:00

Some vulnerabilities have been reported in NPDS, which can be exploited by malicious people to disclose sensitive information or conduct cross-site scripting attacks.

http://secunia.com/Advisories/33305/

NOTE: This RSS feed does not include information about updated Secunia advisories. You should note that Secunia on average issues more than 20 updated advisories per day, containing information about exploit and patch availability, new and in depth research, and all other details that are relevant. Learn more about receiving complete and customised Secunia advisory information:
http://secunia.com/advisories/business_solutions/

Tape vs Biometrics - tape wins!!

2009-01-05T14:36:33+00:00

A South Korean woman barred from entering Japan fooled the biometric fingerprint scanner by putting "special" tape over her fingers.

Anti-malware and Police surveillance

2009-01-05T14:17:17+00:00

Security product vendors deny they allow back-doors for police surveillance software. However their compliance could be forced by future regulations

The 7 worst tech predictions of all time

2009-01-05T14:15:18+00:00

Predicting the future ain't easy. That's why astrologers and fortune tellers tend to keep their forecasts as vague as possible. But in the high-stakes world of high technology, the future belongs to those who see it coming well in advance.

[2/5] Lito Lite CMS "id" Cross-Site Scripting Vulnerability

2009-01-05T14:03:42+00:00

darkjoker has reported a vulnerability in Lito Lite CMS, which can be exploited by malicious people to conduct cross-site scripting attacks.

http://secunia.com/Advisories/33381/

NOTE: This RSS feed does not include information about updated Secunia advisories. You should note that Secunia on average issues more than 20 updated advisories per day, containing information about exploit and patch availability, new and in depth research, and all other details that are relevant. Learn more about receiving complete and customised Secunia advisory information:
http://secunia.com/advisories/business_solutions/

More Privacy, Bit by Bit

2009-01-05T13:45:02+00:00

Before the Holidays, Yahoo got a flurry of good press for the announcement that it would (as the LA Times puts it) "purge user data after 90 days." My eagle-eyed friend Julian Sanchez noticed that the "purge" was less complete than privacy advocates might have hoped. It turns out that Yahoo won't be deleting the contents of its search logs. Rather, it will merely be zeroing out the last 8 bits of users' IP addresses. Julian is not impressed:

dropping the last byte of an IP address just means you've narrowed your search space down to (at most) 256 possibilities rather than a unique machine. By that standard, this post is anonymous, because I guarantee there are more than 255 other guys out there with the name "Julian Sanchez."

The first three bytes, in the majority of cases, are still going to be enough to give you a service provider and a rough location. Assuming every address in the range is in use, dropping the least-significant byte just obscures which of the 256 users at that particular provider is behind each query. In practice, though, the search space is going to be smaller than that, because people are creatures of habit: You're really working with the pool of users in that range who perform searches on Yahoo. If your not-yet-anonymized logs show, say, 45 IP addreses that match those first three bytes making routine searches on Yahoo (17.6% of the search market x 256 = 45) you can probably safely assume that an "anonymized" IP with the same three leading bytes is one of those 45. If different users tend to exhibit different usage patterns in search time, clustering of queries, expertise with Boolean operators, or preferred natural language, you can narrow it down further.

I think this isn't quite fair to Yahoo. Dropping the last eight bits of the IP address certainly doesn't protect privacy as much as deleting log entries entirely, but it's far from useless. To start with, there's often not a one-to-one correspondence between IP addresses and Internet users. Often a single user has multiple IPs. For example, when I connect to the Princeton wireless network, I'm dynamically assigned an IP address that may not be the same as the IP address I used the last time I logged on. I also access the web from my iPhone and from hotels and coffee shops when I travel. Conversely, several users on a given network may be sharing a single IP address using a technology called network address translation. So even if you know the IP address of the user who performed a particular search, that may simply tell you that the user works for a particular company or connected from a particular coffee shop. Hence, tracking a particular user's online activities is already something of a challenge, and it becomes that much harder if several dozen users' online activities are scrambled together in Yahoo!'s logs.

Now, whether this is "enough" privacy depends a lot on what kind of privacy problem you're worried about. It seems to me that there are three broad categories of privacy concerns:

Privacy violations by Yahoo or its partners: Some people are worried that Yahoo itself is tracking their online activities, building an online profile about them, and selling this information to third parties. Obviously, Yahoo's new policy will do little to allay such concerns. Indeed, as David Kravets points out, Yahoo will have already squeezed all the personal information it can out of those logs before it scours them. If you don't trust Yahoo or its business partners, this move isn't going to make you feel very much safer.
Data breaches: A second concern involves cases where customer data falls into the wrong hands due to a security breach. In this case, it's not clear that search engine logs are especially useful to data thieves in the first place. Data thieves are typically looking for information such as credit card and Social Security numbers that can make them a quick buck. People rarely type such information into search boxes. Some searches may be embarrassing to users, but they probably won't be so embarrassing as to enable blackmail or extortion. So search logs are not likely to be that useful to criminals, whether or not they are "anonymized."
Court-ordered information release: This is the case where the new policy could have the biggest effect. Consider, for example, a case where the police seek a suspect's search results. The new policy will help protect privacy in three ways: first, if Yahoo! can't cleanly filter search logs by IP address, judges may be more reluctant to order the disclosure of several dozen users' search results just to give police information from a single suspect. Second, scrubbing the last byte of the IP address will make searching through the data much more difficult. Finally, the resulting data will be less useful in the court of law, because prosecutors will need to convince a jury that a given search was performed by the defendant rather than another user who happened to have a similar IP address. At the margin, then, Yahoo's new policy seems likely to significantly enhance user privacy against government information requests. The same principle applies in the case of civil suits: the recording and movie industries, for example, will have a harder time using Yahoo!'s search logs as evidence that a user was engaged in illegal file-sharing.

So based on the small amount of information Yahoo has made available, it seems that the new policy is a real, if small, improvement in users' privacy. However, it's hard to draw any definite conclusions without more specific information about what information Yahoo! is saving. Because anonymizing data is a lot harder than people think. AOL learned this the hard way in 2006 when "anonymized" search results were released to researchers. People quickly noticed that you could figure out who various users were by looking at the contents of their searches. The data wasn't so anonymous after all.

One reason AOL's data wasn't so anonymous is that AOL had "anonymized" the data set by assigning each user a unique ID. That meant people could look at all searches made by a single user and find searches that gave clues to the user's identity. Had AOL instead stripped off the user information without replacing it, it would have been much harder to de-anonymize the data because there would be no way to match up different searches by the same user. If Yahoo's logs include information linking each user's various searches together, then even deleting the IP address entirely probably won't be enough to safeguard user privacy. On the other hand, if the only user-identifying information is the IP address, then stripping off the low byte of the IP address is a real, if modest, privacy enhancement.

VU#958563: SSH CBC vulnerability

2009-01-05T13:23:32+00:00

Vulnerability Note VU#958563

SSH CBC vulnerability

Overview

A vulnerability exists in SSH messages that employ CBC mode that may allow an attacker to recover plaintext from a block of ciphertext.

I. Description

The Secure Shell (SSH) is a network protocol that creates a secure channel between two networked devices in order to allow data to be exchanged. SSH can create this secure channel by using Cipher Block Chaining (CBC) mode encryption. This mode adds a feedback mechanism to a block cipher that operates in a way that ensures that each block is used to modify the encryption of the next block.

SSH contains a vulnerability in the way certain types of errors are handled. Attacks leveraging this vulnerabilty would lead to the loss of the SSH session. According to CPNI Vulnerability Advisory SSH:

If exploited, this attack can potentially allow an attacker to recover up to 32 bits of plaintext from an arbitrary block of ciphertext from a connection secured using the SSH protocol in the standard configuration. If OpenSSH is used in the standard configuration, then the attacker's success probability for recovering 32 bits of plaintext is 2^{-18}. A variant of the attack against OpenSSH in the standard configuration can verifiably recover 14 bits of plaintext with probability 2^{-14}. The success probability of the attack for other implementations of SSH is not known.

II. Impact

An attacker may be able to recover up to 32 bits of plaintext from an arbitrary block of ciphertext.

III. Solution

We are currently unaware of a practical solution to this problem.

Use CTR Mode

SSH can be done using Counter (CTR) mode encryption. This mode generates the keystream by encrypting successive values of a "counter" function. For more information see the Block Cipher Modes article on wikipedia.

In order to mitigate this vulnerabilty SSH can be setup to use CTR mode rather CBC mode. According to CPNI Vulnerability Advisory SSH:
The most straightforward solution is to use CTR mode instead of CBC mode, since this renders SSH resistant to the attack. An RFC already exists to standardise counter mode for use in SSH (RFC 4344) ...

Systems Affected

Vendor	Status	Date Notified	Date Updated
Bitvise	Vulnerable	2008-11-07	2008-11-24
FiSSH	Vulnerable	2008-11-07	2008-11-24
Icon Labs	Vulnerable	2008-11-07	2008-11-24
OpenSSH	Vulnerable	2008-11-07	2008-11-24
OSSH	Vulnerable	2008-11-07	2008-11-24
PuTTY	Vulnerable	2008-11-07	2009-01-05
Redback Networks, Inc.	Vulnerable	2008-11-07	2008-11-24
SSH Communications Security Corp	Vulnerable	2008-11-07	2008-11-24
TTSSH	Vulnerable	2008-11-07	2008-11-24
VanDyke Software	Vulnerable	2008-11-07	2008-11-24
Wind River Systems, Inc.	Vulnerable	2008-11-07	2008-11-24

References

http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
http://isc.sans.org/diary.html?storyid=5366
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

Credit

Thanks to CPNI for reporting this vulnerability.

This document was written by Chris Taschner.

Other Information

Date Public:	2008-11-14
Date First Published:	2008-11-24
Date Last Updated:	2009-01-05
CERT Advisory:
CVE-ID(s):
NVD-ID(s):
US-CERT Technical Alerts:
Metric:	0.30
Document Revision:	14

The State of Spam: What to Expect in 2009

2009-01-05T13:05:58+00:00

Spam, oh spam -- can we ever get rid of you? 2008 saw a promising blow to the endless sea of junk mail, but the relief didn't last for long. Now, spam experts say new forms of annoyances are on the way for the new year.

[3/5] PostNuke PNphpBB2 Module Multiple File Inclusion Vulnerabilities

2009-01-05T13:04:23+00:00

StAkeR has discovered some vulnerabilities in the PNphpBB2 module for PostNuke, which can be exploited by malicious people to disclose sensitive information.

http://secunia.com/Advisories/33365/

NOTE: This RSS feed does not include information about updated Secunia advisories. You should note that Secunia on average issues more than 20 updated advisories per day, containing information about exploit and patch availability, new and in depth research, and all other details that are relevant. Learn more about receiving complete and customised Secunia advisory information:
http://secunia.com/advisories/business_solutions/

[2/5] Links SSL Verification Security Issue

2009-01-05T13:04:23+00:00

A security issue has been discovered in Links, which can be exploited by malicious people to conduct spoofing attacks.

http://secunia.com/Advisories/33391/

NOTE: This RSS feed does not include information about updated Secunia advisories. You should note that Secunia on average issues more than 20 updated advisories per day, containing information about exploit and patch availability, new and in depth research, and all other details that are relevant. Learn more about receiving complete and customised Secunia advisory information:
http://secunia.com/advisories/business_solutions/

[3/5] PhpMesFilms "id" SQL Injection Vulnerability

2009-01-05T13:04:23+00:00

SuB-ZeRo has discovered a vulnerability in PhpMesFilms, which can be exploited by malicious people to conduct SQL injection attacks.

http://secunia.com/Advisories/33332/

NOTE: This RSS feed does not include information about updated Secunia advisories. You should note that Secunia on average issues more than 20 updated advisories per day, containing information about exploit and patch availability, new and in depth research, and all other details that are relevant. Learn more about receiving complete and customised Secunia advisory information:
http://secunia.com/advisories/business_solutions/

[2/5] Samba Root File System Access Security Issue

2009-01-05T13:04:23+00:00

A security issue has been reported in Samba, which can be exploited by malicious users to bypass certain security restrictions.

http://secunia.com/Advisories/33379/

NOTE: This RSS feed does not include information about updated Secunia advisories. You should note that Secunia on average issues more than 20 updated advisories per day, containing information about exploit and patch availability, new and in depth research, and all other details that are relevant. Learn more about receiving complete and customised Secunia advisory information:
http://secunia.com/advisories/business_solutions/

Constitutionality of FISA to be Reviewed

2009-01-05T12:49:33+00:00

Steven Aftergood writes on Secrecy News:

A federal appeals court in Oregon will hold a hearing next month on a government appeal of a 2007 judicial ruling that said the Foreign Intelligence Surveillance Act (FISA) is unconstitutional.

The FISA is a statute that regulates domestic intelligence, and generally requires judicial authorization for intelligence search and surveillance within the United States. Critics of Bush Administration electronic surveillance activities such as the “Terrorist Surveillance Program” have argued that they unlawfully circumvented the provisions of the FISA.

But the FISA itself, as modified by the USA PATRIOT Act, is unconstitutional, a federal court ruled [.pdf] on September 26, 2007.

That ruling came in response to a challenge by Brandon Mayfield, who was erroneously arrested in connection with the Madrid bombings in 2004 based on a false fingerprint match and subsequent surveillance under the Foreign Intelligence Surveillance Act. The FBI later apologized for his mistaken arrest and provided a financial settlement. But Mayfield continued to challenge the legal foundation of the arrest.

More here.

Planet Security

Vuln: DotNetNuke User Account Security Bypass Vulnerability

OSSEC HIDS being detected as malware, (Mon, Jan 5th)

MVP for another year

Bugtraq: [USN-702-1] Samba vulnerability

FBI's New Cryptanalysis Contest

UK Police planning to hack citizens' PCs, (Mon, Jan 5th)

Tim Callan: MD5 Hack Interesting, But Not Threatening

Major security problem for Twitter

Attacking Intel® Trusted Execution Technology

Bugtraq: Re: php 4.x php5.2.x all "show_source()" ,"highlight_file()" bypass&#8207;

Bugtraq: Walusoft TFTPServer2000 Version 3.6.1 Directory Traversal

Bugtraq: Re: php 4.x php5.2.x all "show_source()" ,"highlight_file()" bypass&#8207;

Boffin brings ‘write once, run anywhere’ to Cisco hijacks

Twitter Security Collapses; Obama, Fox and Britney Accounts Hacked

jonudell

Exploits of the Week #4

HTTP Verb Brute Forcing

Flashy botnet is Flashy

Mandriva: Subject: [Security Announce] [ MDVA-2009:002 ] msec

Phishers Now Twittering Their Scams

Microsoft tells how it missed critical IE bug

Four information points on Twitter phishing

Cryptol Language for Cryptography

Biometric Fail reported

jonudell

Ubuntu: Samba vulnerability

[3/5] NPDS Multiple Vulnerabilities

Tape vs Biometrics - tape wins!!

Anti-malware and Police surveillance

The 7 worst tech predictions of all time

[2/5] Lito Lite CMS "id" Cross-Site Scripting Vulnerability

More Privacy, Bit by Bit

VU#958563: SSH CBC vulnerability

Vulnerability Note VU#958563

SSH CBC vulnerability

Overview

I. Description

II. Impact

III. Solution

Systems Affected

References

Credit

Other Information

The State of Spam: What to Expect in 2009

[3/5] PostNuke PNphpBB2 Module Multiple File Inclusion Vulnerabilities

[2/5] Links SSL Verification Security Issue

[3/5] PhpMesFilms "id" SQL Injection Vulnerability

[2/5] Samba Root File System Access Security Issue

Constitutionality of FISA to be Reviewed

Bugtraq: Re: php 4.x php5.2.x all "show_source()" ,"highlight_file()" bypass‏

Bugtraq: Re: php 4.x php5.2.x all "show_source()" ,"highlight_file()" bypass‏