100% Undetectable Rootkit based on Hardware Virtualization Technologies

The Blue Pill technology does not rely on any bug [like buffer overflow] of the underlying operating system [,but just exploits some design flaw]. I have implemented a working prototype for Vista x64, but I see no reasons why it should not be possible to port it to other operating systems, like Linux or BSD which can be run on x64 platform... This is all possible thanks to the latest virtualization technology from AMD called SVM/Pacifica. (Joanna Rutkowska's Blog)

I decided to implement Blue Pill on AMD64 processor and I spent my time on doing this... Indeed it *seems* possible to implement Blue Pill on Intel VT, but I haven't done this yet... Also, at Black Hat there will be another presentation, by Dino Dai Zovi, about VT based malware. But I don't know if (and how) Dino's work is similar to Blue Pill or not. (her blog's comments)

Generic detection could be written for the virtual machine technology, then Blue Pill can be detected, but it also means that Pacifica is "buggy."... Blue Pill does *not* rely on any bug in Pacifica neither in OS... Blue Pill uses only the documented features of Pacifica.. (her blog's comments)

Blue Pill is being developed exclusively for COSEINC Research and will not be available for download... Papers about blue pill (and more details) will be available after SyScan and Black Hat USA conferences... or to get more details you have to either come to SyScan or Black Hat ;) (her blog's comments)

I think it is not theoretically new. It is something like defective firmwares, CPU-level instead. [I don't want to separate the words 'bug' and 'flaw'.] Sure this is a security flaw (bug) but not something like buffer-overflows. This bug is here because of poor design. If buffer overflow is like a break in a wall(!), these bugs are similar to lack of the wall itself!

I also think that '100% undetectable' is unreal. By the way we will wait for the presentation.

See Kurt Wismer's post: 'the blue pill is NOT 100% undetectable'

Secure Browsing Mode (SBM v1.2)

It is widely accepted today that web applications are inherently insecure. A lot of energy was invested in the past years into making web applications more secure, but there is only so much we can do with the fundamentally insecure foundation. This brief document proposes a set of possible browser improvements that would allow us to establish, gradually, a secureenvironment for web applications.

As you know TCP/IP is insecure because the creators didn't think about its future growth. It is badly designed if you believe in security. If we want to be pragmatic and not make dreams about some better alternative for TCP/IP - which is impossible at least for now -, we can work on some minor security improvements in some parts for example web applications. Read this article (pdf file) written by Ivan Ristic. This article's main goal is to:

1. Reduce impact of insecure web applications by making the client devices more
security-savvy.
2. Create new, well-designed, standards to replace current insecure practices

I alse saw a presentation pdf file named "Case Studies in Finding Previously Unknown Vulnerabilities in Web Applications" in Kenneth Belva's Blog
which lists the main points to consider while developing webbased applications - but in the opposite aspect!

'Detailed Exploit' Published for Critical Windows Flaw (RASMAN)

In an unusual move, Microsoft has released a formal security advisory to warn of the publication of "detailed exploit code" that targets a critical Windows vulnerability. (eweek)

Read this eweek article. See mataspolit response to microsoft's move.

Although this exploit (microsoft Bulletin MS06-025) mostly affects Win2K (critical) and its hardly enough for win2K3 or XP (important) but the way microsoft choosed to response is odd and funny even if microsoft afraids that this may cause writing a world-spreed worm. I believe in "full disclosure" philosophy that its final result is to force the programmers to write safer codes - instead of praying for regular security patches. I also don't prefer "responsible disclosure" because it is not so effective -and cutting- compared to the former.

Fuzzers and Fuzzing (Fuzz testing)

Fuzz testing or fuzzing is a software testing technique. The basic idea is to attach the inputs of a program to a source of random data ("fuzz"). If the program fails (for example, by crashing, or by failing built-in code assertions), then there are defects to correct...
However, fuzz testing is not a substitute for exhaustive testing or formal methods: it can only provide a random sample of the system's behavior, and in many cases passing a fuzz test may only demonstrate that a piece of software handles exceptions without crashing, rather than behaving correctly. Thus, fuzz testing can only be regarded as a proxy for program correctness, rather than a direct measure, with fuzz test failures actually being more useful as a bug-finding tool than fuzz test passes as an assurance of quality. (wikipedia)

[I wrote this post to answer someone's question.] While seeking an intro article to help you start learning something, wikipedia.org and del.icio.us worth checking. I also recommend This wiki for fuzzers. It is a good gateway if you follow the links.

See also:
http://del.icio.us/search/?all=fuzzer
http://del.icio.us/tag/fuzzing
http://en.wikipedia.org/wiki/Fuzzing
http://en.wikipedia.org/wiki/Black_box_testing

Where is Nessus 3+ going?

No more source code!! Binary packages only (now):

- Linux : Fedora FC4 & 5, Red Hat Enterprise 3 & 4, SuSE 9.3 & 10, Debian 3.1 (i386)
- FreeBSD : FreeBSD 5 & 6 (i386)
- Solaris : Solaris 9 & 10 (sparc)
- Mac OS X : Mac OS X 10.4 (intel & ppc)
- Windows : Windows 2000, XP and 2003 (32 bits)

Yes, windows! Nessus(beta) for windows! Not OpenBSD, not NetBSD... Sure windows is more important compared openbsd - if you see from a scriptkiddy's point of view.

F******

Researchers hack Wi-Fi driver to breach laptop

The hack will be demonstrated at the upcoming Black Hat USA 2006 conference during a presentation by David Maynor, a research engineer with Internet Security Systems and Jon Ellch, a student at the U.S. Naval postgraduate school in Monterey, California.

It is the disapointing part of in-device-codes which are usually written badly and in-hurry. I prefer the way OpenBSD is in, to not use binary blobs despite loss of functionality some expect.

Link of the article
Binary BLOB

For now!

A blog for now... I will move to something better then!