The Advanced Technical Support Team has reviewed the escalation regarding your IP unblock request for 66.109.98.18. We have examined this issue and determined that this IP address is not currently eligible for unblocking. When we examined this IP address we found that it identifies itself as s5.lookwhois.com. However, s5.lookwhois.com does not resolve back to the server IP address. Because we cannot verify the identity of this server we cannot unblock the IP address. Once this is corrected, please contact us so that we can re-examine the request.

ok, either someone from my hosting provider for Most Significant Bit Labs or someone at GoDaddy is going to get punched in the fucking face.

If you've never been to PostSecret before you really are missing out. You can read more about it on PostSecret Wikipedia page, but in a nutshell, people send in postcards with secret confessions on them.

It's pretty popular in the mainstream, with many of the postcards being featured in the music video Dirty Little Secret by All American Rejects. The postcards have also been collected in to books.

Anyway the creator of the site, Frank Warren, is going to be speaking and signing books at this Barnes & Noble in Atlanta on Monday, 1/22/2007.

PostSecret creator coming to Atlanta

Jon Steward on Bill O'Reilly, sometime in 2004.

Jon Stewart on Bill O'Reilly

Want to be looked after the rest of your life in the company of big Otis, who likes to take showers? Then do what Jeffrey Brett Goodin did and become a criminal phisherman - now taken down by the US Department of Justice.

The US Department of Justice has reported that in verdicts reached late Friday, Jeffrey Brett Goodin, 45, was found guilty of operating a sophisticated phishing scheme targeted at AOL users. He was convicted under the CAN-SPAM Act of 2003 of sending thousands of emails to AOL users that appeared to be from AOL's billing department and prompted the customers to send personal and credit card information, which he used to make unauthorized purchases.

According to the US DOJ’s press release, the jury found that Goodin operated an Internet-based scheme designed to obtain personal and credit card information by tricking people into believing that they were providing information to a legitimate business.

Its nice to see CAN-SPAM being used to go after Phishers. I'm just amused as hell that phishing AOL users is still so profitable. I gave a presentation on this stuff once, and AOL has been fertile ground for over a decade now.

I have many fond memories of phishing logins/passwords from first time AOL members in the "New User Lobby" back in mid 90s.

AOL Phisher convicted possible 101 years in jail

Catonic wrote:

dc0de wrote:
I'm always amazed that with new programming languages, techniques, and plug-ins, that we continue to ignore the basic tenants of security, which is to "expect your application/code to be attacked."

I can't wait until the "next new thing" and then the "shock / horror" that it too can be attacked... unless the programmers learn to actually think like an attacker.

The more time I see pass, the more I see this cycle repeat. It almost seems as if the software companies are actively trying to keep other companies in business... job security.

-- Catonic

Decius has some good thoughts on this. Look at TCP/IP vulns. the Vista beta suffered from IP fragmentation attacks which hasn't been seen working in the wild since the Windows 95 days. The reason is simple: the programmers who solved those problems in Windows 95 are not the programmers who implemented the TCP/IP stack in Vista. Microsoft's mistake is even more retarded because the security issues with TCP/IP (Server state in the 3 way handshake, etc) and their solutions (SYN cookies, etc) are well known and studied area.

What was the lesson of the SYN floods of the mid 90s? Don't allow a single unauthenticated packet to cause state to be stored on the server or cause several packets to be sent by the server to an unverified address. Which class of protocols totally forgot this piece of knowledge? Begins with V and ends in OIP.

Security researcher Yoda says: Ignorance is the path to the dark side. Ignorance leads to poor choices. Poor choices leads to vulnerabilities. Vulnerabilities lead to IT suffering.

Cyle of pain

Security OPUS is an annual meeting of professional security researchers and information security practioners. The conference is a single track series of presentations designed to focus on new research/advances in the field. We are looking to ensure each talk contains relevant and current research and/or addresses today's issues. One-hour and extended presentation sessions provide attendees with a significant advantage, by being informed about current and future challenges.

SecurityOpus is a smaller conference with excellent speakers and a constructive atmosphere. The organizers do one of the best jobs I've seen at keeping the con running smoothly and the attendees happy. In short, more conference need to be like SecurityOpus, and I thank Richard for doing such an awesome job.

The CFP is still open and I encourage the many west coast hackers on Memestreams to submit (I'm looking at you Mike!). Also, anyone in the bay area should look into attending. It’s held at the W Hotel in download SF across from the Moscone center. All meals are provided, with hor dourves and cocktails in the evening. You can register online as well.

Security Opus 2007- CFP

Brilliant!

We thought it sure would be handy if life came with status codes, but since it doesn't, we did the next best thing and printed them on stuff you wear. But not just any old stuff - we had to try something different, and print them on undies. So we bring you HTTPanties for the discriminating woman who would prefer a web-savvy and somewhat-direct approach in the romance department.

Feeling frisky? Well then don the black "200 OK" panties and see where they take you. Alternatively, the white "403 Forbidden" style sends a very different and hopefully clear message. New for 2005 we bring you two more styles: 411 Length Required and 413 Requested Entity Too Large.

And now, in what will surely drive a "Not Safe For Work" flag, your moment of zen.

As some of my co-workers noted, there are many more HTTP code that could be pantified:

300 Multiple Choices
305 Use Proxy
402 Payment Required
406 Not Acceptable
415 Unsupported Media Type
417 Expectation Failed
501 Not Implemented
502 Bad Gateway

ThinkGeek :: HTTPanties

Last week a reporter asked me to comment on a story he was writing that detailed this hack. I couldn't post this to Memestreams until after that article was published.

I plug in the register URL and start inserting my information. The second screen is where your Priority Code gets entered. Being the curious person I am I took a peek at the source code. Much to my chagrin I find this:

Well huh. These look like MD5 hashes. So what we need to do is crack the MD5 passwords with what we know about our keyspace: All upper case, most likely keyboard ASCII characters and numbers only. We can probably rule out non-printable ASCII so now we're just looking at A-Z0-9. Just an educated guess.

We begin the crack. Less than 10 seconds and I've already cracked a code that looks interesting. Lets see what we get: A Platinum Pass for $0.00? Special line access to the Keynote! Alright!

My thoughts are this is an excellent example of security issues with Web 2.0 applications. Specifically, the leaking of an application's programing logic to the attacker.

In the case, IDG tried to make their website more responsive by performing some of their validation on the client. They did this by pushing some JavaScript to the client's web browser. Even if IDG still performed that validation on the server, they have leaked how the priority code is verified and used by their website. This is the leaking of control logic All an attacker needs to do is look at the JavaScript code and see how the priority code is verified against a list of valid codes. Even though those codes are encrypted, the JavaScript again aids the attacker. It provides step by step instructions showing how the priority code is encrypted as well as the algorithm used allowing the attacker to easily brute force the valid codes. By accessing the JavaScript code, the attacker could also see that IDG made some mistakes before they encrypted the code, making the discounts even easily to brute force (IDG first capitalized the code and the removed a number of special characters and symbols, etc). This drastically reduced the number of combinations an attacker needs to try to brute force all the priority codes)

Once the attacker knows all the priority codes, it is obvious which ones gave the attacker a free pass worth thousands of dollars.

The moral of the story: JavaScript code is visible to an attacker. It is impossible to completely obfuscate or hide it. More and more Web 2.0 technologies like Ajax means more and more programs are placing application logic in JavaScript, making it even easy to attackers to find flaws in web applications. In this case, by trying to enrich the user's experience, the programmers exposed all of there discount offers in JavaScript, allowing an attacker to discovery them and perform fraud for thousands of dollars.

Web developer's need to make sure they don't leak vital information about how their applications work. In today's Web 2.0 world of rich web interfaces like Ajax and Adobe's Flex, this is a very easy mistake to make.

Your Free MacWorld Expo Platinum Pass

Obviously the need for spaces in tags is an important one. Whether it’s “Semantic Web” or “Ford Interceptor” that you need to tag, it’s rather different from “Windows AND Vista” and “Ford AND Interceptor” - and it gets worse if you have a search engine that places OR in there instead of AND. Much worse. The big question is, why doesn’t such a standard already exist? It’s obvious that Web 2.0 is all about connecting ideas and bringing articles, content, and readers together. But anyone looking at the tagging process would immediately assume it’s about the exact opposite: splitting up content, making things difficult to find, and purposely making bloggers’ lives miserable.

With Habari, so far we’ve gone through all the forms, and at the moment we’re at number 3 for compatability and familiarity’s sake. But that may change - hence the need for a visible, tangible tagging standard. The only problem is, tagging isn’t some new concept. A tagging standard isn’t something that we can just whip up and serve on a platter.

What about the noun/verb argument? Look at the tags for this post: “Blogs, Blogging … Tags, Tagging” We just don’t know what people will search for - and we try to cover all the bases. But then you have so many possibilities! Code, Coding; Design, Designing; Research, Researching. For every pair there is one word more likely than the other. But people like to have all the bases covered, hence all the clutter. Tagging is fun, but only if done the right way.

This article touches on a few of the more obvious issues with implementing a tagging system properly. Tom, Rattle and I have already scoped all the places in Memestreams that use the topic system and are discussing ways to replace it with a tagging system. Believe me, it is not an easy problem!

Tagging by its very nature is more chaotic than a hierarchical topic system. Having a a good implementation is only half the battle: people must tag items well. A item that contains odd or tags that don't best describe the article is in danger of fading away. No one knows exactly what terms it could be filed under. This is where topics do very well. By imposing a controlled vocabulary, a searcher can presumably read the entire vocabulary to see all possible topic words they might be interested in.

In a nutshell, here are some big problems with tags:

-How to handle multiple words
-If/how to allow tag delimiter inside a tag
-Does letter case matter
-Punctuation and symbols
-Handling plural or singular words
-Date formating
-Multiple language support
-Colloquialisms/slang

The Need for Creating Tag Standards

This article started up quite nicely about about how to run SQL commands against a database in a shared hosting environment where you don't have a SQL console access.

It quickly spiraled into creating a webpage that will run arbitrary .SQL commands against a database.

Once uploaded, hit the remote RunSQL.aspx page via your browser. This will cause the page on your remote server to parse the .SQL file, and execute all of its statements.

A picture is worth one thousand words.

Granted the article says to use obscure filenames and to delete it when you are done, but we all know most people won't. That like giving a kid a gun and reminding them to put on ear protection ahead of time and to clean it properly once they have finish shooting themselves in the foot!

Scott Guthrie may be smart but this deserves a "WTF were you thinking!"

Remote Database management... now with a backdoor!