Thu, 14 Aug 2008

Adding and deleting pages on Google

Here is my list of links which describe how to add, block, and remove various items from Google's search engine. For now, the links are mostly from GoogleTutor. I've added them to the wiki to make them easier to find (for me) and as a precaution against GoogleTutor's disappearance. joat: 07:03:35 14 Aug 2008

| [/Theory] permanent link

Sat, 02 Aug 2008

Attack trees

A post over on Spark's Fedora blog about Anti-Virus, Anti-Spyware, and Rootkits in Linux prompted me to write a lengthy response. In doing so, I realized that I hadn't posted about basic security theory in a very long time. Semi-related to Spark's topic is the following: attack trees. A good starting place is Wikipedia's article on attack trees and Bruce Schneier's 1999 paper on the topic is also a very good read. joat: 09:53:51 2 Aug 2008

| [/Theory] permanent link

Sun, 16 Mar 2008

MySQL password reset

Inherit a box where you don't know the root-level password for MySQL? Or just plain forgot it? I've added notes for resetting the root password to the wiki. joat: 08:26:21 16 Mar 2008

| [/Theory] permanent link

Sun, 25 Nov 2007

I R one!

As of 2 p.m. today, I've recert'd GSEC and have picked up GCIH. I'm also quite brain dead and a bit computer-adverse at the moment. What a way to spend a Sunday afternoon! joat: 13:59:37 25 Nov 2007

| [/Theory] permanent link

Wed, 17 Oct 2007

The devil's in the details

For the benefit of anyone in Rob's class that's attempting to recreate what was done on the big display tonight --> when you're grabbing/compiling/running kmod-ptrace.c on the target machine, pay close attention to the details: use gcc, not make or cc when you run the program what is displayed? can you do anything (hint: type ls or whoami) if you hit Ctrl-C and run "ls -l", what do you see? re-run the program and try to answer these questions again Note: success may be specific to the version of the OS being run on the target machine. Your mileage will vary depending on a number of things (hint: the classroom lab is a controlled environment (i.e., each target is exactly the same)). Enjoy! But you should probably get your homework done first. You may spend more time than you should getting the exploits to work in your home labs. If you're frustrated, please note that Rob usually isn't adverse to you coming in when there isn't a class in the lab. Just check in with one of the techs in the fishbowl. joat: 22:47:11 17 Oct 2007

| [/Theory] permanent link

Wed, 26 Sep 2007

Getting the customer to speak

Tate Hansen, over on Clearnet Security has a post about getting the customer to provide input as part of a penetration test. It surprised me for two reasons: 1) I didn't know that it wasn't done and 2) it's so obvious an issue. I'm not saying that I don't believe that the condition exists. People (and therefore organizations) tend to take the path of least resistance, so if the penetration testers don't ask, the customer is not going to offer up the information. My surprise is that the question just doesn't come up. It may be because I'm the type to take a packet sniffer to a CTF contest. (Yeah, one of those that thinks that CTF is a spectator sport.)(I have Don M. at ODU and S-14 (hiya Pete!) to thank for that "bad habit".) To me, the "What did you see?" question is just so obvious that it's a "must ask". I can also see how organizations fall into the practice of not participating in their own penetration testing. It may have something to do with that other form of security testing called the vulnerability scan. It's usually performed more often and requires no input from the customer, except during the remediation phase, and that is usually an internal process (e.g., the CIO may have some "'splaining to do" to the CIO). The Hansen/Ranum/McGraw reference to the "badness-o-meter" is a good one. If your pen-testers have anything other than "we don't know" at the top end of the scale, the data they're providing about your level of security may be suspect. Pen-testing is an inverted business-model. The best you can hope for is: "We don't know. We failed." A few things to keep in mind: This doesn't mean that someone else doesn't already know It also doesn't mean that they won't know tomorrow or the day after To quote a semi-cliche: "Security is a process, not an end state." (Dr. M. E. Kabay, 1998) By extension, a pen-test is a snapshot of that process, not of an end state joat: 04:36:03 26 Sep 2007

| [/Theory] permanent link

Sun, 09 Sep 2007

Need to choose

I'm also having to decide (shortly) on a topic for this semester's term paper. As I blogged previously, Rob has encouraged me to work on one of the IPv6 vulnerabilities. I've tried to counter with an analysis of FastFlux. Both look interesting. The IPv6 work would be more directely related to the "Attacks" class. Rob suggested it knowing that I'm one of the few students with IPv6 at home. I'm interested in the FastFlux problem but I'm wary of where it might lead (remember, the problem is based on problems within the domain registration infrastructure). Then, too, it may also run into one of any number of dead ends as there is a massive bureaucracy between ICANN and the hosting providers, with the registrars in the middle). Without the ability to subpoena a number of people, investigation is limited to what you can extract via the local terminal window. Corruption at the hosting provider or registrar makes it that much more difficult. I'm a bit discouraged but not yet put off by that. Initial investigation of two FastFlux domains shows a massive number of systems attached to the Storm Worm (amazing since, for most of those boxes, someone had to click on "Click here" to get infected). In any case, I've got to choose soon. Rob's deadline is coming up fast. joat: 21:16:22 9 Sep 2007

| [/Theory] permanent link

Thu, 15 Feb 2007

File Carving Challenge 2007

For any of you forensics types that like contests, the 2007 File Carving Challenge is open. It's the one run by Carrier, Casey and Venema. joat: 22:08:50 15 Feb 2007

| [/Theory] permanent link