
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?
The end of vulnerabilities. Alternating between Python and Ruby; R&D, Consulting, and Ops; Linux and BSD. Moving from Austin to Skokie to Baltimore. Adoptive to Bio. Republican to Democrat, and other Things Done Backwards


Visit msnbc.com for Breaking News, World News, and News about the Economy
/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
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.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.
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.
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.

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.
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.
[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'
mfranz@mfranz-s10:~$ uptime
09:23:44 up 15:39, 4 users, load average: 0.53, 0.63, 0.59
mfranz@mfranz-s10:~$ free
total used free shared buffers cached
Mem: 1543920 1505324 38596 0 106532 571888
-/+ buffers/cache: 826904 717016
Swap: 1983988 668 1983320






mfranz@mfranz-s10:~/crap$ cat alctest.py
#!/usr/bin/env python
from sqlalchemy import *
from pprint import pprint
e = create_engine("mysql://moodle:blackboard@127.0.0.1/moodle")
m = MetaData(e)
user_table = Table('mdl_user',m,autoload=True,autoload_with=e)
pprint(user_table.columns.keys())
mfranz@mfranz-s10:~/crap$ ./alctest.py
[u'id',
u'auth',
u'confirmed',
u'policyagreed',
u'deleted',
u'mnethostid',
u'username',
u'password',
u'idnumber',
u'firstname',
u'lastname',
u'email',
u'emailstop',
u'icq',
u'skype',
u'yahoo',
u'aim',
u'msn',
u'phone1',
u'phone2',
u'institution',
u'department',
u'address',
u'city',
u'country',
u'lang',
u'theme',
u'timezone',
u'firstaccess',
u'lastaccess',
u'lastlogin',
u'currentlogin',
u'lastip',
u'secret',
u'picture',
u'url',
u'description',
u'mailformat',
u'maildigest',
u'maildisplay',
u'htmleditor',
u'ajax',
u'autosubscribe',
u'trackforums',
u'timemodified',
u'trustbitmask',
u'imagealt',
u'screenreader']
Q: Is Internet security broken?
A: Hardly. The presenters of this morning's paper stressed that it took them a long time and a great deal of computational power to succeed in their collision attack. VeriSign has already eliminated the attack as a possibility.
I'll fess up right away. I have no interest in playing hermenuetical games with redacted texts or trying to divine the flaws that will be released tomorrow.
And the first time I read the talk writeup I thought, "Oh, God, here we go again... more preconference disclosure bullshit."
And of course they were allready at it over on Dailydave. BGP. Crypto. Everybody loves BGP and Crypto. Some new DoS?
Get ready for the FUD machines to start. Time to get ill. Get the bucket ready. But after reading HD's blog (which was based on knowledge of the vulnerability) a second time (once wasn't enough) I'm thinking perhaps this one is different:
Their research combined a known weakness in one area with a massive resource investment in another to show that a third party was vulnerable to a practical attack that affects the security of all Internet users. Security researchers often release code and technical documentation to demonstrate a flaw, but in this case, they went a step further and used the attack in the real world to obtain proof that it works.
Not in terms of the vulnerability (or vulnerabilities) to be disclosed (although that very well be) but as way of disclosing critical vulnerabilities that does neither trivializes nor desensitizes flaws that need to be addressed by vendors and the end-user community. The current model isn't working so well.
As you can already see, if folks within the hacker/researcher community (who should know better) conflate all the scary Internet infrastructure vulnerabilities of course folks technology journalists will.
In the broader IT press, Kaminsky's DNS will be treated the same as Watson's TCP as Gont's ICMP as Oulu's ASN.1/SNMP as Guardent's TCP as Lee' TCP, etc. ad naeseum.
(If I weren't typing on this damn Netbook I'd add links but google them yourself if you are interested. But you get the point)
Within the mainstream media, each of these will be covered with approximately the same number of words, the same oversimplification and carefully selected, out of context quotes, regardless of the technical merit of the research, regardless of the scope of the flaws, and the professionalism (or lack thereof) of the finders.
And each time there where will be the Oh-My-God-the-Internet-is-Doomed-thank-God-for-the-Hackers-that-Saved-It narrative.
(Compare the recent wired article on Summer DNS flaws with the coverage of the 2003 TCP vulnerability discovered by Paul (Tony) Watson (aka the man that saved the Internet) and you will see an eerie similarity.)
Another wasted news cycle, and despite the claims of the finders, the security of th e Infrastructure is not improved. End users are either confused or cynical. It is conference season again. It is just too easy to dimiss the research as an individual trying to make a name for themselves and climb the corporate security ladder, a consulting company marketing its services or a vendor hawking their wares in the guise of a BlackHat talk.
Unless there is proof.
And that is where it looks like this will be different. There is a huge difference between what you can prove with a few boxes in your basement, a one-rack testbed with 50-100k of gear, an ISP with live users, or the larger Internet.
Each environment to demonstrate attack vectors and vulnerabilities is increasingly less contrived and more and more like reality. Each is an environment less out of the control of the attacker/adversary/researcher which is where it starts to get interesting. Meaning attacks on an Internet scale.
That is why real incidents (i.e. the smurf attacks of 98, the DDoS of 2000, the worms) teach far better lessons. They provide real data. They impact the bottom lines of vendors and users and impact operational best practicies.
Compare that with flash in the pan vulnerability presentations and you'll see why in the long run I wish more researchers would go beyond proof of concept and operationalize their exploits and discovered vulnerabilities.
Regardless of the technical details of the disclosure, it will be interesting to watch what happens. Will this be more of the same or the start of something new?