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
I collected some charts of the latest attack trends if you want to find out more, have a look at honey.it-securityguard.com
We will keep you up to date with the latest trends of our analysis,
hope you enjoyed!
All the best
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
Today i reported a strange bug to the devs of the Chromium Project, look at the following lines of code :
<script src=http:\\\\\\\\\\\\monitor.it-securityguard.com\\\\\\\\\\\\\test.js> </script>
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.
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
we recently found 160 sites of the german finance system vulnerable to reflected cross site scripting. We sent the information the well known IT-News site heise.de And they sent it to the CERT Team Bund (Computer Emergency Response Team)