Apache 2.4.50 included a fix for CVE-2021-41773. It has since been discovered that this fix was incomplete, and this version is vulnerable to a permutation of the same vulnerability. 2.4.51 is now available, and should properly fix the vulnerability.

The original exploit used .%2e/ as the magic payload, which is using URL encoding to sneak the extra dot symbol through as part of the path. The new workaround uses .%%32%65/. This looks a bit weird, but makes sense when you decode it. URL encoding uses UTF-8, and so %32 decodes to 2, and %65 to e. Familiar? Yep, it’s just the original vulnerability with a second layer of URL encoding. This has the same requirements as the first iteration, cgi-bin has to be enabled for code execution, and require all denied has to be disabled in the configuration files.

Breaking Youtube With Super SloMo

[Florian Mathieu] was playing with mp4 muxing, and was struck by the complexities of multiplexing audio and video together. He had a ten second video that was playing back in only eight seconds. This was odd. The culprit was the timescale value specified in the mp4 header. The muxer he was working with was ignoring that value, leading to improper playback. Now what would happen if that value was set to something truly odd? Setting a much smaller value resulted in a 4 MB file that actually plays for 15 hours, in excruciating slow motion.

In possession of such a strange file, what is the logical next step? Upload it to YouTube, of course. The YouTube encoding process cranked on the video for several days, before finally timing out. Is this really a vulnerability, you may ask? YouTube has a failsafe where it aborts the processing of a file if it goes too long. The YT security team opted not to pay a bounty on the bug, but did add [Florian] to their security Hall of Fame. I still haven’t identified a practical attack that would use this bug — even with using it, it would be hard to build a DoS attack that would approach the traffic and processing requirements of the entire world using and uploading to YouTube all at once.

Dev-0343

Microsoft’s Office365 and Azure platforms are a powerful analytics tool for tracking malicious activity. In a new report, they have detailed an actor that has been doing account discovery and mass password brute-forcing against a targeted group of victims — groups like defense contractors, Persian Gulf port operators, and Middle Eastern transportation providers. The prevailing theory is that this actor is associated with Iran, but the details are difficult to nail down, as the attacks are all performed over Tor. It is telling that traffic is much higher between 7:30 AM and 8:30 PM local Iran time.

The normal security precautions apply here. Don’t use compromised passwords and enable two factor authentication. Microsoft suggests also blocking traffic from known anonymizing services — in other words, block Tor exit nodes.

Hijacking Github Actions

Almost exactly a month ago, we covered a flaw in Github Actions, where a symlink in the pull request could allow for unintended behavior by the check-spelling workflow. Well there’s more. Now this vulnerability is both better and worse. It’s harder to exploit, as it’s limited to a user account with write privileges. But it’s also more ubiquitous, as every organization has Actions enabled by default.

Any user with write permissions also has permission to create a new workflow. The process of creating a workflow also includes setting permissions for the token used by that workflow. And thus, any user with write permission potentially has nearly full permissions, including approving pull requests on protected branches. And to make matters worse, the action bot counts as a separate user, meaning it can approve pull requests initiated by the malicious user.

The takeaway is that you should disable Github Actions anywhere it’s not being used. Protected branches are not a bulletproof solution if Actions are enabled. It appears that for the time being, this is an outstanding issue in Github.

Shooting the Messenger

And finally, in an incredibly disappointing story, the governor of Missouri has referred a journalist for prosecution for discovering and responsibly disclosing an information leak in a state website. The flaw in the State’s Department of Education website potentially exposed the social security numbers of teachers.

As you might anticipate, quite a few security professionals have sounded off in support of the journalist. The vulnerable site was taken down before the report was published, and the exact flaw has not been disclosed. The plainest description of the vulnerability states, “Though no private information was clearly visible nor searchable on any of the web pages, the newspaper found that teachers’ Social Security numbers were contained in the HTML source code of the pages involved.” It could be as simple as it seems, that a lookup triggered a “SELECT *” SQL statement, and those results were encoded directly as JSON in a script embedded in the page source.

Now to be fair, it could be that there’s more to the story. There may be a SQL injection or request manipulation that was deemed too technical to have been covered in the story. That said, threatening prosecution for what appears to be a good faith vulnerability disclosure is a terrible move. If more concrete details come to light, we’ll let you know.