Turkey.deb | TechSNAP 294

chris

6 years ago

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Akamai’s quarterly State of the Internet report: The Krebs Attack

“Internet infrastructure giant Akamai last week released a special State of the Internet report. Normally, the quarterly accounting of noteworthy changes in distributed denial-of-service (DDoS) attacks doesn’t delve into attacks on specific customers. But this latest Akamai report makes an exception in describing in great detail the record-sized attack against KrebsOnSecurity.com in September, the largest such assault it has ever mitigated.”
Akamai: “The same data we’ve shared here was made available to Krebs for his own reporting and we received permission to name him and his site in this report.”
“Akamai said the attack on Sept. 20 was launched by just 24,000 systems infected with Mirai, mostly hacked Internet of Things (IoT) devices such as digital video recorders and security cameras.”
“The first quarter of 2016 marked a high point in the number of attacks peaking at more than 100 Gbps,” Akamai stated in its report. “This trend was matched in Q3 2016, with another 19 mega attacks. It’s interesting that while the overall number of attacks fell by 8% quarter over quarter, the number of large attacks, as well as the size of the biggest attacks, grew significantly.”
“The magnitude of the attacks seen during the final week were significantly larger than the majority of attacks Akamai sees on a regular basis,” Akamai reports. “In fact, while the attack on September 20 was the largest attack ever mitigated by Akamai, the attack on September 22 would have qualified for the record at any other time, peaking at 555 Gbps.”
Krebs has also made a .csv of the data available: “An observant reader can probably correlate clumps of attacks to specific stories covered by Krebs. Reporting on the dark side of cybersecurity draws attention from people and organizations who are not afraid of using DDoS attacks to silence their detractors.” In case any trenchant observant readers wish to attempt that, I’ve published a spreadsheet here (in .CSV format) which lists the date, duration, size and type of attack used in DDoS campaigns against KrebsOnSecurity.com over the past four years.”
Some comments about the “mega” attacks on Kreb’s site:
“We haven’t seen GRE really play a major role in attacks until now. It’s basically a UDP flood with a layer-7 component targeting GRE infrastructure. While it’s not new, it’s certainly rare.”
“Overall, Columbia was the top source of attack traffic. This is surprising, because Columbia has not been a major source of attack traffic in the past. While Columbia only accounted for approximately 5% of the traffic in the Mirai-based attacks, it accounted for nearly 15% of all source IPs in the last four attacks. A country that was suspiciously missing from both top 10 lists was the u.s. With regards to Mirai, this may be due to a comparative lack of vulnerable and compromised systems, rather than a conscious decision not to use systems in the u.s.”
“There are a few distinctive programming characteristics we initially discovered in our lab, and later confirmed when the source code was published, which have helped identify Mirai-based traffic. At the end of the day what Mirai really brings to the table is a reasonably well written and extensible code base. It’s unknown as to what Mirai may bring in the foreseeable future but it is clear that it has paved the way for other malicious actors to create variants that improve on its foundation.”
The full report can be downloaded here
Some other data from the report:
“Last quarter we reported a 276% increase in NTP attacks compared with Q2 of 2015. This quarter, we analyzed NTP trends over two years and have noticed shrinking capabilities for NTP reflection.” — It is good to finally see NTP falling off the attack charts as it gets patched up
“Web application attack metrics around the European Football Cup Championship Game and the Summer Games, as analyzed in the Web Application Attack Spotlight, show us that while malicious actors take advantage of high-profile events, there’s also a lull that indicates they might like to watch them.” (see page 26)
Application Layer DDoS attacks (GET/HEAD/POST/PUT etc) account for only 1.66% of DDoS attacks. Most attacks are aimed at the infrastructure layer (IP and TCP/UDP)
“Repeat DDoS Attacks by Target / After a slight downturn in Q2 2016, the average number of DDoS attacks increased to an average of 30 attacks per target, as shown in Figure 2-13. This statistic reflects that once an organization has been attacked, there is a high probability of additional attacks.”
SQL Injection (49%) and Local File Inclusion (40%) make up the greatest share of attacks against web applications

Is your server (N)jinxed ?

A flaw in the way Debian (and Ubuntu) package nginx, can allow your server to be compromised.
The flaw allows an attacker who has managed to gain control of a web application, like wordpress, to escalate privileges from the www-data user to root.
“Nginx web server packaging on Debian-based distributions such as Debian or Ubuntu was found to create log directories with insecure permissions which can be exploited by malicious local attackers to escalate their privileges from nginx/web user (www-data) to root.”
“The vulnerability could be easily exploited by attackers who have managed to compromise a web application hosted on Nginx server and gained access to www-data account as it would allow them to escalate their privileges further to root access and fully compromise the system.”
The attack flow works as follows:
- Compromise a web application
- Run the exploit as the www-data user
- Compile your privilege escalation shared library /tmp/privesclib.c
- Install your own low-priv shell (maybe /bin/bash, or an exploit) as /tmp/nginxrootsh
- Take advantage of the permissions mistake where /var/log/nginx is writable by the www-data user, and replace error.log with a symlink to /etc/ld.so.preload
- Wait for nginx to be restarted or rehashed by logrotate
- When nginx is restarted or rehashed, it creates the /etc/ld.so.preload file
- Add the /tmp/privesclib.so created earlier to /etc/ld.so.preload
- Run sudo, which will now load /tmp/privesclib.so before other libraries, running the code
- sudo will not allow the www-data user to do any commands, but before sudo read its config file, it ran privesclib.so, which made /tmp/nginxrootsh setuid root for us
- Run /tmp/nginxrootsh as any user, and you now have a shell as the root user
- The now own the server
Video Proof of Concept
Fixes:
Debian: Fixed in Nginx 1.6.2-5+deb8u3
- Ubuntu 14.04 LTS: 1.4.6-1ubuntu3.6
- Ubuntu 16.04 LTS: 1.10.0-0ubuntu0.16.04.3
- Ubuntu 16.10: 1.10.1-0ubuntu1.1
Make sure your log directory is not writable by the www-data user

Hacking 27% of the web via WordPress Auto-update

“At Wordfence, we continually look for security vulnerabilities in the third party plugins and themes that are widely used by the WordPress community. In addition to this research, we regularly examine WordPress core and the related wordpress.org systems. Recently we discovered a major vulnerability that could have caused a mass compromise of the majority of WordPress sites.”
“The vulnerability we describe below may have allowed an attacker to use the WordPress auto-update function, which is turned on by default, to deploy malware to up to 27% of the Web at once.”
“The server api.wordpress.org has an important role in the WordPress ecosystem: it releases automatic updates for WordPress websites. Every WordPress installation makes a request to this server about once an hour to check for plugin, theme, or WordPress core updates. The response from this server contains information about any newer versions that may be available, including if the plugin, theme or core needs to be updated automatically. It also includes a URL to download and install the updated software.”
“Compromising this server could allow an attacker to supply their own URL to download and install software to WordPress websites, automatically. This provides a way for an attacker to mass-compromise WordPress websites through the auto-update mechanism supplied by api.wordpress.org. This is all possible because WordPress itself provides no signature verification of the software being installed. It will trust any URL and any package that is supplied by api.wordpress.org.”
“We describe the technical details of a serious security vulnerability that we uncovered earlier this year that could compromise api.wordpress.org. We reported this vulnerability to the WordPress team via HackerOne. They fixed the vulnerability within a few hours of acknowledging the report. They have also awarded Wordfence lead developer Matt Barry a bounty for discovering and reporting it.”
“api.wordpress.org has a GitHub webhook that allows WordPress core developers to sync their code to the wordpress.org SVN repository. This allows them to use GitHub as their source code repository. Then, when they commit a change to GitHub it will reach out and hit a URL on api.wordpress.org which then triggers a process on api.wordpress.org that brings down the latest code that was just added to GitHub.”
“The URL that GitHub contacts on api.wordpress.org is called a ‘webhook’ and is written in PHP. The PHP for this webhook is open source and can be found in this repository. We analyzed this code and found a vulnerability that could allow an attacker to execute their own code on api.wordpress.org and gain access to api.wordpress.org. This is called a remote code execution vulnerability or RCE.”
“If we can bypass the webhook authentication mechanism, there is a POST parameter for the GitHub project URL that is passed unescaped to shell_exec which allows us to execute shell commands on api.wordpress.org. This allows us to compromise the server.”
There is security built into the system. Github hashes the JSON data with a shared secret, and submits the hash with the data. The receiving side then hashes the JSON with its copy of the shared secret. If the two hashes match, the JSON must have been sent by someone who knows the shared secret (ideally only api.wordpress.com and github)
There is a small catch
“GitHub uses SHA1 to generate the hash and supplies the signature in a header: X-Hub-Signature: sha1={hash}. The webhook extracts both the algorithm, in this case ‘sha1’, and the hash to verify the signature. The vulnerability here lies in the fact the code will use the hash function supplied by the client, normally github. That means that, whether it’s GitHub or an attacker hitting the webhook, they get to specify which hashing algorithm is used to verify the message authenticity”
“The challenge here is to somehow fool the webhook into thinking that we know the shared secret that GitHub knows. That means that we need to send a hash with our message that ‘checks out’. In other words it appears to be a hash of the message we’re sending and the secret value that only api.wordpress.org and GitHub know – the shared secret.”
“As we pointed out above, the webhook lets us choose our own hashing algorithm. PHP provides a number of non-cryptographically secure hashing functions like crc32, fnv32 and adler32, which generate a 32bit hash vs the expected 160 bit hash generated by SHA1. These hashing functions are checksums which are designed to catch data transmission errors and be highly performant with large inputs. They are not designed to provide security.”
So instead of having to brute force a 160 bit hash (1.46 with 48 zeros after it) you only have to brute force 32 bits (4 billion possibilities). But it gets even easier
“Of these weak algorithms, the one that stood out the most was adler32, which is actually two 16 bit hashing functions with their outputs concatenated together. Not only are the total number of hashes limited, but there’s also significant non-uniformity in the hash space. This results in many hashes being the same even though they were supplied with different inputs. The distribution of possible checksum values are similar to rolling dice where 7 is the most likely outcome (the median value), and the probability of rolling any value in that range would work its way out from the median value (6 and 8 would have the next highest probability, and on it goes to 2 and 12).”
“The proof of concept supplied in the report utilizes the non-uniformity by creating a profile of most common significant bytes in each 16 bit hash generated. Using this, we were able to reduce the amount of requests from 2^32 to approximately 100,000 to 400,000 based on our tests with randomly generated keys.”
“This is a far more manageable number of guesses that we would need to send to the webhook on api.wordpress.org which could be made over the course of a few hours. Once the webhook allows the request, the attack executes a shell command on api.wordpress.org which gives us access to the underlying operating system and api.wordpress.org is compromised.”
“From there an attacker could conceivably create their own update for all WordPress websites and distribute a backdoor and other malicious code to more than one quarter of the Web. They would also be able to disable subsequent auto-updates so that the WordPress team would lose the ability to deploy a fix to affected websites.”
“We confidentially reported this vulnerability on September 2nd to Automattic and they pushed a fix to the code repository on September 7th. Presumably the same fix had been deployed to production before then.”
“We still consider api.wordpress.org a single point of failure when distributing WordPress core, plugins and theme updates. We have made attempts to start a conversation with members of Automattic’s security team about improving the security posture of the automatic update system, but we have not yet received a response.”

Turkey.deb | TechSNAP 294

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Akamai’s quarterly State of the Internet report: The Krebs Attack

Is your server (N)jinxed ?

Hacking 27% of the web via WordPress Auto-update

Feedback:

Round Up: