wwward.expressions

Rootkits may foil hardware detection/memory audit in theory

An article over on ZDNet talks about Joanna Rutkowska's Black Hat presentation on her rootkit research and how rootkits may foil hardware memory retrieval for auditing. A memory-obfuscating rootkit will complicate research and may call into question forensic evidence, depending on the court case and what activity is alleged.

When a user is accused of performing a malicious or illegal (in law) action on a computer, one defense seen in the courtroom involves a computer under the influence of a virus or direct manipulation an outsider. Rootkits enable both scenarios by providing an interface permitting another actor to circumvent the security context of the OS, or indeed perform functions outside of the OS audit and data logging facilities. It can act under the guise of the legitimate user, or it can act in secret.

I won't mention any specific instances, although a diligent reader can find them all over the web, but to a security researcher or forensic examiner the system RAM provides a good place to look for malicious activity, since the state of the machine at runtime is reflected in the RAM. New developments in exploiting peripheral processors and memories (such as the graphics processor and it's firmware storage,) provide more places to look, but the rest of the world moves slowly and most examiners will still rely on a copy of the hard disks, a "live" software memory dump if possible, and if available, a hardware dump of the memory (to avoid interference by malware on the machine.)

Joanna's research has shown that the memory may become unreliable using current retrieval methods. This is but one more step in the cat and mouse game of computer security, where the complex systems comprised of the work of many disjoint companies come together with many seams to poke through.

Check out the article here: http://blogs.zdnet.com/security/?p=109 including her presentation slides.

Great stuff, good to know, and Joanna's work is impressive.

SSH Remote Port Forwarding on Mac OS X

Last night Andy and I were planning to do a short demo of our control panel for the folks at the Metaverse Meetup. Unfortunately, neither the apartment's local network or my fancy mobile wireless would permit us to accept inbound network connections. I had counted on being able to forward some ports on the local router, but it wasn't happening. After some frantic work to get remote port forwarding to work, I spent time this morning learning to configure it properly and have pasted some useful information for fellow NAT/Firewall sufferers who may need it in the future.

In my case, I tested this operation using my T-Mobile Total Internet package, using a Nokia E62 mobile and a Macbook running Mac OS X 10.4.8. Most anyone using SSH should be able to do the same, but I find it helpful to be platform-specific when I'm searching for configuration quirks. If you're using Cingular, Verizon, or Sprint in the USA, or one of the many other wireless data service providers throughout the world - you should be able to use these instructions to work around any filtering limitations provided you can establish SSH out. Be clever - if you need to change the port to circumvent an outbound block on port 22, do it!

The instructions below should also work for most default installs of SSHD on various Linux distributions.

How-To Configure Remote Port Forwarding on Mac OS X
1. Ensure /etc/sshd contains "GatewayPorts yes" to allow binding remote ports to an external interface, else you'll be limited to localhost.

2. Use the syntax "ssh -N -R remotebindaddress:remoteport:localbindaddress:localport user@remotehost on the machine behind the firewall or NAT that you wish to tunnel into.

Notes: Beware of idle timeouts (I believe there is a default for this, but I'm satisfied that my configuration will work as I need it to, and I have other things I need to move on and get done.) Also beware of SSH being finicky about the host key if you attempt to grab an SSH shell session on the firewalled host. Since you're connecting to a forwarded port on a host you likely use for other SSH sessions, your client will complain that the host key doesn't match the host IP. You'll have to override this. Using a command line override will prevent password authentication, so unless you're using a fingerprint, you'll need to jump in your ~/.ssh/known_hosts file and delete the host. Not the most secure method of operating, just be mindful that you're taking a risk on man-in-the-middle traffic manipulation. The probability of this is low for most folks, but forewarned is forarmed and some folks are bigger targets than others. I think I might have better odds of winning the lottery.

Security Implications: I'm not going to preach about security, if you're forwarding remote ports you're already competent enough (or should be,) to know what you're doing. This method will allow you to circumvent the firewall policy of your host network. In some places, this is an employment hazard. From my personal experience, while you might feel good about sticking it to your network administrator or CISO, just remember that a steady paycheck beats reading those forbidden blogs any day. Tunnel wisely from the office, the security admins are probably more mindful of it than you think. It's something I look for on my corporate network, and while I sympathize with you there are reasons beyond simply securing the network against data theft or malware that govern firewall policy. Some of it trumps geek pride.

Take care.

Data Standards Matter

I was considering a much more elaborate post regarding patch management as a whole, but I realized that it would probably make for a better article - considered, planned, pointed and edited - than a 'blog post.

So let me just point out something I deal with today, that in fact consumes the vast majority of my paid hours at work: compensating for inconsistent data in shared databases.

Most major enterprises have some sort of "data architecture" or "schema architecture" or "data standards" groups which are intended to ensure data consistency and promote reusable software products. These teams are generally attached to application development departments (from my experience.) They don't usually look past application development to the great wilderness of the ad-hoc user application.

Thanks to companies like Microsoft, the average information worker has a remarkable - even revolutionary - set of tools at hand. These tools enable the end user to craft applications to suit immediate needs without the hurdles and expense of engaging the in-house application development team. Without these ad-hoc tools, many of your end users would never be able to leverage the computing power they need to streamline mundane tasks. Formal application development is a substantial undertaking, and few businesses have built sanctioned frameworks that enable such ad-hoc computing within a managed environment.

Even when formal processes are followed, many data architecture teams are focused exclusively on "data warehousing" projects, which are not always leveraged for applications which aren't considered part of the core warehouse mission.

To stress my point: Data architecture standards are extremely important for the efficiency of your entire IT operation. Never mind that your architecture team spends most of its time worrying about standards for packaging or pricing data! The architecture team should represent the single source of schema for any application undertaken by user or developer alike. Ensuring consistency in schemas across a business concern will ensure that paid employee time has a measure of efficiency and reusability and does not contibute to a data silo culture.

How do you ensure that employees, working alone with Excel or Access, maintain respect for enterprise schema standards? Well, it isn't easy.

First, every employee who has broad access to computing resources should be trained on corporate computer use. This is rare! Only two of my employers, Gartner and GlaxoSmithKline, had computer training. These corporations wisely invested money in introducing new employees to the resources provided by IT and some of the expectations that went along with the offering. However, getting senior management to agree to mandate computer orientation for new hires is difficult to say the least.

Second, every self-respecting company should have an internal "employee portal" website. This provides the employee with a single entry point to all available resources on offer. My current employer (who shall remain nameless,) provides an outstanding portal - tying together service requests, nearly all Human Resources services (including online information and payroll management,) corporate news and limited collaborative forums. I'm hoping to see more collaborative development, but they've achieved the most in my experience.

Relevant to our discussion, the Employee Portal must also guide the employee to policies and standards. One of our tasks as information security professionals is to ensure that policy is communicated to the employee. It follows that computer standards should be treated in a similar way. The end-user is then aware of resources available from IT, which leads me to my next point.

Third, data architecture groups must maintain an online reference of standards, examples and a means to collaborate with the architecture team for small projects. This may involve something as simple as email, or preferably a collaborative forum where an end-user can review previous efforts and avoid mistakes or leverage existing "tribal" knowledge.

In short: Make data standards self-service friendly. Architecture teams will continue to engage large projects, but by making standards accessible to the end-user or small project developer - you'll have a greater probability of compliance and a bigger bat to wield when they don't comply.

The benefit to the business emerges with more interoperability between applications, less time "wasted" in single-use projects, and better efficiency. It will take less time, for example, to connect two datasources on a whim. Many great ideas come together without a plan, and enabling your employees with equally flexible technology has vast untapped value even now.