Thursday, January 29, 2009

Twitter Starts to Grow Up



Looks like they are actually starting to address twamming or or whatever (tweet-spam) is called. Cause I went to block JENNY and got this image.

Good for them. About time.

How long until they get non-Base64 authentication?

Tuesday, January 27, 2009

Is jennydddggeee too hot for you? (or, Automated Twitter Spam Blocking?)



If you are reading this blog, you don't know anyone like this, don't want to know anyone that looks like that -- and certainly don't want either of them following your every move.

So it should be pretty easy to write less than 25 lines of Python using Twyt that automatically removes any followers that have a single post.

But there have to be tools that already do this. Or any Twitter clients that will automatically block spam followers.

Sunday, January 25, 2009

Another Post-Twitter Poor Excuse for a Blog Entry

After getting hooked on Twitter, I really don't blog anymore (but in the tradition of Luv Them Firewalls, another picture of my my daughter on our now defunct Macbook) here was a picture tonight. Was barely able to get her unglued from Gcompris. It is funny how kids get attached to certain items of clothing. This year it was this Santa hat. Back in Austin it was this pink pair of snow boots.

Tuesday, January 20, 2009

Khe Sanh?

Yep, that stood out for me as well, but this is as good as an exchange as I heard/read today.

Childish Things and Hand Me Downs


I really wanted to blog on our new President's comments about "putting away childish things" behind us, but I'm too tired. I woke up 4-ish again, and made the drive in at 6:15 to avoid the traffic that never came. So instead I'll post a picture of my youngest child.

Appropriate, since my wife has some new project where she is rifling through old physical photos in plastic tubs.

Slightly more than nine years ago, my oldest son wore this same snowsuit in Samara and Moscow (yes, both are in Russia) but he never got played in the snow.

We returned home with him in the 2nd week of February in 2000 to our 1st "Green House" in Austin and Spring had sprung. This snowsuit was not worn again. At three months older and barely walking, my Chinese daughter, in March of 2005, was too small to wear this snowsuit on a ski trip to Utah.

But we kept it. And I remember packing it up in June, when I was single-handedly packed our 4 bedroom house in Skokie.

Yesterday, we had the first decent snow here in New Market (but not nearly as much as when his was born) but it was enough.

My wife found the snow suit and Sam wore it.

Wednesday, January 14, 2009

Inside the Gmail Login Sequence (or, has anyone documented all the parameters and JSON response codes)

I generally don't like Wiley books, but near the end of a chapter on how Gmail works actually isn't that bad.

I'm sure there has to be more stuff like

/gmail?
ik=344af70c5d
&view=cv
&search=inbox
&th=101865c04ac2427f
&lvp=-1
&cvp=0
&zx=9m4966e44e98uu

As you can see, this the message ID of the message I clicked on.
But the others are mysterious at the moment. At this point in the
proceedings, alarms went off in my head.Why, I was thinking, is
the variable for message ID th—when that probably stands for thread.
So, I sent a few mails back and forth to create a thread, and loaded
the Inbox and the message back up

elsewhere dissecting the URL parameters, but I haven't found it apart from looking at the libgmail source, the constants file in particular. Has nobody documented this stuff or is google burying any documentation on reverse engineering Gmail?

It is sort of curious that the author is using tcpflow. Fine tool, but using an interceptor proxy like paros or something like firebug is a hell of a lot more efficient than sniffing.

Monday, January 12, 2009

Another word for stakeholders



This is probably more worthy of a tweet (funny how tweeting has cut down on my blogging) but Alex Payne writes about the challenges of securing twitter (a relevant topic given my Twitter usage lately)

The thing about security is that it requires stakeholders. I have a security background, but Twitter’s security isn’t my job. In fact, my job is pretty much the opposite: I open up as much of Twitter’s functionality as I can without (hopefully) making the system insecure. So while I’ve usually been a “first responder” to security incidents because of my background, it requires a major mental context switch from the work I normally do.

Several months after I joined Twitter in early 2007, I suggested to the team that we do a full internal security audit. Stop all work, context switch to Bad Guy Mode, find issues, fix them. I wish I could say that we’ve done that audit in its entirety, but the demands of a growing product supported by a tiny team overshadowed its priority. Now we‘re in an unwelcome position that many technical organizations get into: so far into a big code-base that’s never seen any substantial periodic audits that the only way to really find all the issues is to bring in some outside help – something I sincerely hope we end up doing, but is not my call.
This post is depressing on a number of levels, mainly because it reminds me of the attitudes (and my own personal frustrations) from back in the early years of doing product security at Cisco.

I hear thing have actually have improved (however slowly) there, but obviously in the supercool world of 2.0 and social networking, they are still pre-2001.

Stakeholders, yeah I'll tell you another word for stakeholders: people that give a shit.

I remember a certain Director of Marketing in the Security & VPN BU. These guys have long since cashed out their options (and the product is killed off), so I don't feel any reservations about blogging about it. Yeah, he was a stakeholder all right, he told us (a small, understaffed, security testing team with no power or authority) that his remote access VPN product was a communication product so security didn't really apply. (Leaving out the far more interesting & cynical quote from a GSR Director of Marketing)

So I understand the frustration, but the idea (that even even if you are a developer, product manager, system administrator) that suddenly you put on your security security hat, stop the presses, fix everything is a quaint notion alongside that 20th century concept that your application, device, or TCP/IP enabled Kleenex box (a big shout out to the Hewitt appsec crew!) is behind a firewall (or not on the Internet) so therefore security isn't a big deal.

You are the stakeholder. And to paraphrase The Wire, "Is you up or is you not?"

Security is not about losing the big battles. It is about winning the small ones. The one's you can win. You do what you can and don't whine about it. If it is not your call, then it is not your problem. Worry about what is your call. That is all you can do.

Been there and done that, you are wasting a lot of time and energy. Trust me.
If you don't believe me, read Unfettered. Bless his heart, Joe is still preaching (nobody gets it, nothing is being done, etc.) the same way he did the first conference of his I attended on SCADA security back in 2003.

Either they get it or they don't and maybe if they don't appear to get it, it is because it really isn't that important in the grand scheme of things. Or maybe you aren't explaining it well enough. If it is really important it work itself out in the long run.

Wednesday, January 07, 2009

Verisign's Big Takeaway (And Pigs Need Wings, Too)

How unsuprising is Tim Callan's "big takeway" for anyone that has had experience on the disclosure front either inside a vendor or as a finder:


The big takeaway for me from this incident is that we need an environment where researchers and security vendors can trust each other. Alexander has explained why his team did not feel they could place that trust in VeriSign. I have explained why I feel they could have. We at VeriSign would like to see an environment where researchers need not mistrust security vendors and vice versa. We're committed to doing our part to bring back that environment, and we encourage security researchers in the future to reach out directly to us. We promise to treat you fairly and respectfully.


Yup, we'll see when that happens.

Tuesday, January 06, 2009

Moodle External-Internal Authentication/Enrollment Synchronication

This is something I'd wish I'd blogged about because I wasted time remembering how to do this.

This assumes an Ubuntu 8.10 install

First you must sync up the users:

php -c /etc/php5/apache2/php.ini /var/www/moodle/auth/db/auth_db_sync_users.php

Then your must sync up the enrollments

php -c /etc/php5/apache2/php.ini /var/www/moodle/enrol/database/enrol_database_sync.php

Will flesh this out later...

Saturday, January 03, 2009

Hello CouchDB (or, does Erlang make it Cool?)


Today I ran across CouchDB in Ten reasons why CouchDB is better than MySQL (provides a high level overview but not terribly interesting) and a more interesting discussion among a bunch of database guys (which I'm obviously not,) about what sort of problems this (and similar approaches) are most suited for. I must say after having played around with ORM (ActiveRecord, Django, Hibernate) over the years and more recently had my nose is Moodle databases I'm sympathetic to the idea that maybe not everything should be stored in tables, rows, and fields and having to design (or discern) the relations. There is just something sort of contorted about the process of viewing the world (or the data we are trying to capture in the world) this way. I have also definitely felt the pain of having to adjust your schema (as you realize new requirements) and perform "migrations" so there is definitely something intriguing about CouchDB.

Some of the aspects I found interesting


In an SQL database, as needs evolve the schema and storage of the existing data must be updated. This often causes problems as new needs arise that simply weren’t anticipated in the initial database designs, and makes distributed “upgrades” a problem for every host that needs to go through a schema update.


and


CouchDB is a peer based distributed database system. Any number of CouchDB hosts (servers and offline-clients) can have independent “replica copies” of the same database, where applications have full database interactivity (query, add, edit, delete). When back online or on a schedule, database changes are replicated bi-directionally.


And there is also OReilly book in progress that provides a much more readable introduction and Standalone Applications with CouchDB is also definitely worth reading.

(Oh and on Ubuntu 8.10 it is in the repo so it is an "apt"-get away)

start-stop-daemon on CentOS/RHEL5 (and probably other RedHat derivatives)

Some packages depend on the start-stop-daemon command which is not available in CentOS (or the dag repositories, AFAIK) but the solution is to pull down the source for dpkg and compile it. Basically do a ./configure at the top level of the package and then do a make, make install the utils directory


[root@moodle_dev utils]# make
gcc -std=gnu99 -g -O2 -Wl,-O1 -o start-stop-daemon start-stop-daemon.o ../get
opt/libopt.a
[root@moodle_dev utils]# ls
enoent enoent.o Makefile.am start-stop-daemon start-stop-daemon.o
enoent.c Makefile Makefile.in start-stop-daemon.c
[root@moodle_dev utils]# make install
make[1]: Entering directory `/root/dpkg-1.13.26/utils'
test -z "/usr/local/lib/dpkg" || mkdir -p -- "/usr/local/lib/dpkg"
/usr/bin/install -c 'enoent' '/usr/local/lib/dpkg/enoent'
test -z "/usr/local/sbin" || mkdir -p -- "/usr/local/sbin"
/usr/bin/install -c 'start-stop-daemon' '/usr/local/sbin/start-stop-daemon'
make[1]: Nothing to be done for `install-data-am'.
make[1]: Leaving directory `/root/dpkg-1.13.26/utils'