[Research] SSH Honeypot (honey.it-securityguard.com)

Dear followers,

I’ve recently set up a honeypot tool called Kippo, Kippo runs a virtual SSH environment and tracks all the SSH bruteforce attemps on our Server. We started the test on third of November and got about 4000 bruteforce attempts on our Server, what is remarkable here is that almost all of the logins came from servers based in china.

Our research showed that almost all the attacking machines run the Windows IIS Webserver, we are currently not sure wether those machines are zombies (hacked machines with the aim to hack other machines) or if those servers are explicitly designed to attack wide ranges. Till today we’ve collected about 2500 distinct Username/Password combinations,

the Top 10 List of combinations is below:

 Username, Password
admin,[email protected]
admin,[email protected]
admin,[email protected]#

I collected some charts of the latest attack trends if you want to find out more, have a look at honey.it-securityguard.com


connections_per_country_pie connections_per_ip_geo connections_per_ip_geo_pie


We will keep you up to date with the latest trends of our analysis,

hope you enjoyed!

All the best



[WordPress] 3x vulnerable Chat Plugins

Dear followers,

during an installation for one of our customers, we had to install a suitable chat plugin for WordPress. There are a lot of them but we decided to choose the first one that comes in the row. Due to the fact that we like security we of course tested the plugins against some well known vulnerabilites, the result was frustrating. Every single plugin of those we’ve tested is vulnerable to stored cross site scripting.

Since we are white hats we’ve reported all of them first to the vendors, only one of them (https://wordpress.org/plugins/wp-live-chat-support/) anserwed us and wanted to have more information, big thumbs up them! for this reason we’ve waited to publish this until they’ve fixed the issue.

1.) WP-Live Chat stored Cross Site Scripting

2.) MyLiveChat stored Cross Site Scripting

3.) Provide Support stored Cross Site Scripting


Google Chrome Security: Multiple leading slashes in URLs may confuse some server-side XSS filters

Today i  reported a strange bug to the devs of the Chromium Project, look at the following lines of code :


You see those leading slashes ? Do you think that this is an valid URL a Browser would process ? In fact it does not look like a valid one, but for Google  Chrome it is. As you can see in the picture the Url gets executed regardless of how many backslashes there were added.

Bildschirmfoto 2014-06-17 um 20.25.19
Feel free to try this out on your own, we set-up a site, head over to monitor.it-securityguard.com/test2.html and  inspect the Javascript Console on your Google Chrome browser, you will see that the simple Javascript message (console.log(‘this is weird’);) has been executed. This technique also works if you only use one slash, a pretty weird szenario imho. If you check this on  Firefox the URL and the correspondig Javascript won’t get executed
Bildschirmfoto 2014-06-17 um 20.36.26
The questions arising at this point should be : Why does Google Chrome treats URL different then other Browsers ? Is this a security issue which could bypass XSS Filters ? With all this question marks in my head i went over to the Chromium site and requested a ne Issue, some hours later :
The repsonse from @tsepez from the chromium team was pretty clear :

“This is one of those cases where we’ve chosen to support broken pages rather than being strict about URL syntax.”

So in others words, it’s a wontfix.

What do you think about this issue ?

Let us know

All the best

Patrik Fehrenbach – IT-Securityguard