Lately I have been doing a lot of Rootkit related research. While conducting this research, I spent a bit of time targeting the kmem system on BSD. The most direct way to read and write to running kernel memory on BSD is via libkvm. This library is provided to ease the burden of reading and writing kernel memory in places where it is legitimate. However this allows us, as potentially nefarious individuals, to abuse kernel memory to modify the operating system in ways of our choosing. Joseph Kong wrote about this exact technique in the book Designing BSD Rootkits and in Phrack Magazine issue 63 article 0x07. Actually, this code is based on his articles with only a slight tweak to make it a bit more "fun".

swapper.c:
/*
* Takes four arguments: Name of syscall one and corresponding number
* followed by the name of syscall two followed by its number.
*
* Code then uses libkvm to swap the two syscalls
*
* Example: ./swapper mkdir 136 rmdir 137
*
* Derived from Phrack63-0x07 by Jason Kong
* Based off of Stephanie Wehner's checkcall.c,v 1.1.1.1
*

Swapper locates the sysenter call and from there is able to determine the memory location for the syscall numbers you pass on the command line. These sysent structures contain the pointers to the syscall code itself. Then, using kvm_write, the code swaps the pointers within the sysent structures. Be careful which syscalls you swap or you will blow your system completely out of the water. A good and fun example is mkdir 136 and rmdir 137 (FreeBSD7.0).

Update 11/3/08: I had to convert this over to Solaris for something specific. The differences included a slightly modified #include list as well as a different offset passed into the kvm_write. This was due to the sysent structures being slightly different between BSD and Solaris.

I had a bit of a discussion with someone this morning on the nuances of partial disclosure and their effectiveness/risk within the greater security stage. The discussion was sparked by a recent post by Dan Kaminsky at www.doxpara.com. In this post Dan is essentially saying that partial disclosure in general is a bad idea; however it is occasionally required if the scope of the issue is so large and potentially dangerous that disclosure at any point would put a significant portion of the computing populous at risk. What Dan is afraid of (and I believe rightfully so) is that the research community and their affiliated companies and marketing machines realizes the fact that partial disclosure generates revenue. When distilled down, partial disclosure can be used as a way of putting FUD out there in an effort to generate buying impulses. Not everyone will directly attempt to utilize partial disclosure as a money making machine; However, I believe the majority of business minds will. They'll either do it with the approval of their researcher or occasionally without. Sometimes the researcher themselves will recognize the positive brand impact and money that can come from partial disclosure and exercise this model directly. So what do we do about this? We create a group to help police the partial disclosure process. We create a way for the populous to know if the released partial details is real or is it FUD.

The second part of our discussion centered around who should be responsible for vetting security related partial disclosure. Dan suggested that a group of security researchers be responsible for the determination if a particular vulnerability should be partially disclosed. This is where I disagree with Dan a bit. There are no parties that can truly act impartially within the security research community when it comes to vetting disclosure. We all have a stake, either directly or indirectly, at the release and disclosure of such information. I suggest that a higher level group that contains people outside of the general security research community be put in charge of vetting the legitimacy of a particular partial disclosure. They could bring in subject matter security experts as required but the group itself must be sufficiently removed from the process to be properly impartial while bringing in the technical expertise only on a consultative basis. The technical details are factual, the risk impact is always subjective.

Maybe I'm being too pessimistic in thinking that the abuse of partial disclosure is imminent. Maybe I'm being too altruistic in thinking that a group of people even at a higher level could ever be impartial enough to properly vet partial disclosure requests. But I do know one thing, this topic is very touchy and will certainly require a large scale effort and significant hand holding if it is ever going to come to fruition.

As always, comments are welcome...

Blogging is out, "Tweeting" is in. Twitter is the new black, it's the latest and greatest, it's.. well weird. I've posted on my thoughts regarding microblogging in the past (here). "At first I was afraid, I was petrified", but then I realized just how useful this type of medium can be. I've since found myself adopting this technology as a way to keep up with the latest and greatest information security minutia directly from the people that are creating it. With groups of people such as the Security Twits along with the researchers I know personally, it's a very useful 1:Many discussion medium. The down side of the microblogging thing is that it's been taking away from my time/energy to create real blog entries for my reader(1). I promise this will change soon.

In the mean time, follow me on twitter (txs_) if you wish to join in the interesting conversation. I'm always keen to hear what my reader(1) has to say.

Uninformed V10 has been released. As always the content looks top notch. I suppose it might have something to do with the authors (*GRIN*). Congrats guys on another piece of excellent work.

At a time when the financial crsis is taking the DOW below 8000pts and the world economy is starting to feel some of the repercussions, a high profile security breach is being reported. The World Bank has been under siege for at least a year and more information and details regarding the intrusions was published today by Fox News.

The first breach of the bank's secrets was discovered in September, 2007, after the FBI .while at work on a different cybercrime case . notified the bank that something was wrong. The feds pointed to a part of the bank's network that led out of the Johannesburg hub of the International Finance Corp. (IFC), a bank arm that lends to the private sector.

The second major breach . of the bank's treasury network in Washington . was discovered in April 2008. The World Bank's Treasury manages $70 billion in assets for 25 clients . including the central banks of some countries. It carries out substantial collaborations with the world's finance ministers on public wealth and debt management, runs an active bond-trading desk in Washington, and does everything from currency trading to capital markets financings.

What really makes this particular breach interesting (besides the target) is that at least one portion of the intrusion was allegedly sourced from one of the largest outsourcing firms in India. Why does the government and major financial institutions insist on the outsourcing model when it is readily apparent that the security of these organizations just isn't there. To really bring this home, how much of our software development has companies like Cisco, Microsoft, and even security vendors like Symantec outsourced to India. Obviously any is too much. If we really must continue to outsource overseas there really needs to be a requirement for independent security assessment of all outsourced development. *GASP* who would have thunk it.

To quote a great song by the band Fort Minor: "Where'd ya go, I miss you so. Seems like it's been forever, since you've been gone". Well it hasn't quite been forever, but it has been nearly a month. I have all sorts of good reasons why I've been too busy to give you kind reader (note the intentional use of singular) the type of interesting infosec jibber jabber that you deserve... BUT.. I'm not going to tell you about them. Frankly it's none of your business.

Instead I'm going to give you a pointer to an interesting piece of research journalism conducted by business week. In a previous post to this blog (here) I commented on the dangers of fake chips and hardware entering the market from China and the potential security implications of these pieces. Well now business week has conducted a multiple week research piece tracking back the origin of a number of chips that caused malfunctions in equipment provided through BEA to the US military. With an interesting video and five fact filled pages of story, this is a very good read indeed. (*Thanks to Chris Eng for pointing this story out to me*).