The AddToAny Share Buttons WordPress Plugin was, until recently, vulnerable to a DOM-based cross-site scripting issue. The file in question is hosted on the author’s site, so you’re not vulnerable anymore (you’re welcome). If you just want the vulnerability details, go here. Now for the story of this bug.
At the risk of spoiling a somewhat-well-known XSS game, I want to share an XSS vector I had never thought of before it forced me to. The premise of this level was, essentially, that you couldn’t use any letters whatsoever in the attack vector, and you had to call alert(1).
So, without further ado, here it is:
What a mess, right?! What the hell are we doing here? Let’s take it piece-by-piece.
Here is their example (with minor edits so as not to call out the author of that how-to post too explicitly):
Do you notice anything fishy?
The “snippet preview” functionality of the Yoast WordPress SEO plugin was susceptible to cross-site scripting in versions before 2.2 (<= 2.1.1). This vulnerability appears to have been reported 2 years ago by someone named “badconker”, but the plugin author said that it was already patched. Unfortunately, it appears that this is not the case. If you are running this plugin, I recommend updating to the latest version.
I’m happy to announce the latest version of a project that the Security Engineering team at Rackspace has been working on: DefectDojo! DefectDojo is an open source defect tracking system that was created by our team to keep up with security engagements, but it can be useful for tracking any type of application testing. It supports functionality like Finding templates, PDF report generation, metrics graphs, charts, and some self-service tools for doing port scans, for example.
Checking out DefectDojo
Login as admin:
Login as product owner / non-staff user:
I noticed a while back that when I carelessly entered my login credentials to the form for registering a new user account on the front page of the DigitalOcean site, it would still log me in. Neato.
However, I was slightly less amused when I noticed that the login event didn’t show an IP address in my security history.
I reported this at the time the screenshot was taken several months ago. It appears they have recently fixed the issue.
Just a reminder that not all vulnerabilities are obvious, and you can’t find them all with BURP.
Earlier today I wanted to explore using Growl / GNTP to listen for notifications from a remote server. I checked out the Growl developer bindings page, found the Python implementation, and started working on a simple app to send me notifications about various things.
I was planning on running this on my server so I could also interface with Twilio and accept callbacks, without having to expose a webserver on my local machine to the internet. To do this, I was going to accept remote notifications in Growl using a password. I realized pretty quickly this was a worse idea.
I started poking around in the source code, and found that the password is hashed using MD5 by default. In fact, it’s quite a pain to change from the default, since there is no configuration option to change the algorithm within the basic helper methods that are actually documented. This appears to be the case for all the other language bindings as well. This isn’t necessarily the end of the world, but it’s definitely not great.
More poking revealed that the packet contents are not encrypted with the password, but the password is merely used to determine whether the listening Growl instance will accept notifications from the remote source. A notification will actually come across the wire looking like this:
19:32:20.244428 IP (tos 0x0, ttl 64, id 53700, offset 0, flags [DF], proto TCP (6), length 13716, bad cksum 0 (->359d)!) localhost.60465 > localhost.23053: Flags [P.], cksum 0x3389 (incorrect -> 0xe50a), seq 1:13665, ack 1, win 12759, options [nop,nop,TS val 266111329 ecr 266111329], length 13664 x.L$......1.3........1Z ...a...aGNTP/1.0 NOTIFY NONE MD5:B80803CFA6C2F303266DC99501ED837D.D89A5B677CDA639FDF3305D233FA0487 Application-Name: poke Origin-Software-Name: gntp.py Notification-Sticky: True Notification-Name: Timer Notification-Text: Derp? Origin-Platform-Version: ... Origin-Software-Version: ... Origin-Machine-Name: ... Notification-Icon: x-growl-resource://fcaeca33ea9ee6fa902f79aa47f980f0 Notification-Title: Timer Alert Origin-Platform-Name: Darwin ...
As you can see, the name of the application, the name of the notification, the actual contents of that notification, and the title of the notification are easily readable (in blue).
What about that weird string starting with “MD5” (in red)?
The meat of the password hashing algorithm can be seen here. Basically, they use a hash of the system’s time as a salt (which they call a “seed”), and include it with messages sent to the server (D89A…0487 above). The other component of the string is a hash of the concatenation of the password and the salt’s hash (B808…837D above).
To see if it was really as easy as it appeared to crack these hashes, I wrote a quick script called Growl Crack that will first bruteforce the “seed” (timestamp/salt), then the “secret” (password + salt). Obviously the difficulty of cracking the password is dependent on its complexity, but the seed is usually cracked pretty much instantly.
In short, if you’re using Growl remotely, you should probably stop unless you want all your notifications being read, or want to expose your password for easy cracking to anyone listening to your communications.
I recently paid for something online using what I considered a secure online payments processor, and they asked that I provide a password to create an account to complete the transaction. You will understand in a second (if you don’t already) why I was so angry when, a few seconds later, I got this:
I couldn’t believe it. Please enter a shorter password.