Creating Your Alarm On The Fly

November 5, 2022 by Matthew Carlson 4 Comments

We suspect that most of us who use an alarm clock have our particular sound memorized. Common choices are annoying beeping, energetic marimbas, or what used to be your favorite song (which you have now come to despise). [Adam Kumpf] wanted a more pleasant alarm clock and came up with WakeSlow, an alarm clock audio stream, which is a spiritual successor to an earlier project he did called Warmly.

Some might say, “an audio stream? You could create an acceptable alarm tone generator with a 555 and a 2N2222”. The idea behind WakeSlow is to use your existing internet-connected alarm clock that can play an audio stream. You generate a URL using WakeSlow, and it plays the alarm. A custom URL is helpful since it incorporates weather data, letting you know if it’s going to rain, blowing wind, or be sunny that day. It mixes CC0 audio to form the stream, and includes a 5-minute fade to wake you up gradually. After five minutes, it’s jazz time, and it plays a sample of some CC0 jazz.

The code is super simple, and he makes it available on his website under a public domain/CC0 license. The simplicity offers something powerful, making it exactly how you like it. You could incorporate holiday information, a text-to-speech news announcer reading the news of what’s on your calendar that day, or anything you can dream of.

Hackers are generally particular about clocks, and alarm clocks fall under the same umbrella. WakeSlow allows you to skip the hardware part of making your customized alarm, but if you prefer to have the whole thing be custom, we have a few suggestions for alarms to look at.

This Week In Security: PHP Attack Defused, Scoreboard Manipulation, And Tillitis

October 7, 2022 by Jonathan Bennett 1 Comment

If you use PHP, you likely use the Composer tool for managing dependencies, at least indirectly. And the good folks at SonarSource found a nasty, potential supply chain attack in this tool, when used in the Packagist repository. The problem is the support for arbitrary README filenames. When a package update shows up on Packagist, that service uses a Version Control Service (VCS) like Git or Mercurial to pull the specified readme location. That pull operation is subject to argument injection. Name your branch --help, and Git will happily run the help argument instead of doing the pull intended. In the case of Git commands, our intrepid researchers were unable to weaponize the issue to achieve code execution.

Composer also supports projects that use Mercurial as their VCS, and Mercurial has a --config option that has… interesting potential. It allows redefining a Mecurial command as a script snippet. So a project just has to contain a malicious payload.sh, and the readme set to --config=alias.cat=!hg cat -r : payload.sh|sh;,txt. For those keeping track at home, the vulnerability is that this cursed string of ugly is accepted by Composer as a valid filename. This uses the --config trick to redefine cat as a bit of script that executes the payload. It ends in .txt because that is a requirement of Composer.

So let’s talk about what this little hack could have been used for, or maybe still used for on an unpatched, private install of Packagist. This is an unattended attack that jumps straight to remote script execution — on an official package repository. If discovered and used for evil, this would have been a massive supply chain attack against PHP deployments. Instead, thanks to SonarSource, it was discovered and disclosed privately back in April. The official Packagist repo at packagist.org was fixed the day after disclosure, and a CVE and updated packages went out six days later. Great work all around.
Continue reading “This Week In Security: PHP Attack Defused, Scoreboard Manipulation, And Tillitis” →

Get GitHub Tickets IRL With A Raspberry Pi And A Receipt Printer

March 25, 2022 by Dan Maloney 14 Comments

Thermal receipt printers are finding their way into all sorts of projects that are well beyond the point-of-sale environment that they normally inhabit. And while we applaud all the creative and artistic uses hackers have found for these little gems, this GitHub physical ticket printer has to be the best use for one yet.

According to [Andrew Schmelyun], seeing a fast-food order pop up on a thermal printer was the inspiration for this build. Maintaining over one hundred GitHub repos as he does, it’s easy for the details of any one bug report or feature request to get lost in the swarm of sticky notes that [Andrew] previously used to keep track of his work. To make it happen, he teamed an Epson thermal printer up to a Raspberry Pi Zero W and worked out the details of sending data to the printer using PHP. Luckily, there’s a library for that — the beauty of GitHub.

With the “Hello, World!” bit out of the way, [Andrew] turned his attention to connecting to GitHub. He set up some webhooks on the GitHub side to send a POST request every time an issue is reported on one of his repos. The POSTs are sent via ngrok to a PHP web server running on the Pi, which formats the data and sends the text to the printer. There’s a short video in the tweet below.

Between the sound of the printer working and the actual dead-tree ticket, it’ll be hard for [Andrew] to miss issues now. We’ve seen thermal printers stuffed into cameras, used to send pictures to Grannie, and even watched them commit suicide slowly, but we say hats off to [Andrew] for his solid work ethic and a fun new way to put a receipt printer to use.

Continue reading “Get GitHub Tickets IRL With A Raspberry Pi And A Receipt Printer” →

PHP Gets A Demoscene Engine Of Its Very Own

May 9, 2021 by Lewin Day 6 Comments

When we think demoscene, our first thought is typically of 80s computers, particularly the Commodore 64 and Amiga 500 which were widely regarded as the awesomest of their time. However, you can write a demo on any platform you wish, and [OxABADCAFE] has done just that – in PHP.

Going by PDE, standing for Pointless, Portable, or PHP Demo Engine, the code is available on GitHub for the curious. The code is set up for RGB ASCII terminal output, for a beautifully old-school aesthetic. Demo sequences can be programmed in JSON files, with the code executing a default in-built demo if none is provided.

There’s no audio yet, so you’ll have to cool your thumping chiptune jets until that’s available in a later release. With that said, we look forward to more development expanding what can be done with the engine – after all, there’s nothing more demoscene than pushing the limits. Video after the break.

Continue reading “PHP Gets A Demoscene Engine Of Its Very Own” →

Does PHP Have A Future, Or Are Twenty Five Years Enough?

June 29, 2020 by Ben James 51 Comments

In June, 1995, Rasmus Lerdorf made an announcement on a Usenet group. You can still read it.

Today, twenty five years on, PHP is about as ubiquitous as it could possibly have become. I’d be willing to bet that for the majority of readers of this article, their first forays into web programming involved PHP.

Announcing the Personal Home Page Tools (PHP Tools) version 1.0.

These tools are a set of small tight cgi binaries written in C.

But no matter what rich history and wide userbase PHP holds, that’s no justification for its use in a landscape that is rapidly evolving. Whilst PHP will inevitably be around for years to come in existing applications, does it have a future in new sites?

Continue reading “Does PHP Have A Future, Or Are Twenty Five Years Enough?” →

Fooling Google Search Console With Tricky PHP

July 17, 2015 by Rick Osgood 42 Comments

When [Steve] received a notice from Google that a new owner had been added to his Google Search Console account, he knew something was wrong. He hadn’t added anyone to his account. At first he thought it might be a clever phishing tactic. Maybe the email was trying to get him to click a malicious link. Upon further investigation, he discovered that it was legitimate. Some strange email address had been added to his account. How did this happen?

When you want to add a website to Google’s services, they require that you prove that you own the actual website as a security precaution. One method to provide proof is by uploading or creating an HTML file to your website with some specific text inside. In this case, the file needed to be called “google1a74e5bf969ded17.html” and it needed to contain the string “google-site-verification: googlea174e5bf969ded17.html”.

[Steve] logged into his web server and looked in the website directory but he couldn’t find the verification file. Out of curiosity, he tried visiting the web page anyways and was surprised to find that it worked. After some experimentation, [Steve] learned that if he tried to load any web page that looked like “googleNNNNNNN.html”, he would be presented with the corresponding verification code of “google-site-verification: googleNNNNNNNN.html”. Something was automatically generating these pages.

After further investigation, [Steve] found that some malicious PHP code had been added to his website’s index.php page. Unfortunately the code was obfuscated, so he couldn’t determine exactly what was happening. After removing the new code from the index.php file, [Steve] was able to remove the hacker’s email address from [Steve’s] Google account.

This is a very interesting hack, because not only did it allow this one hacker to add himself to [Steve’s] Google account, but it would also have allowed anyone else to do the same thing. This is because each new hacker would have been able to fool Google’s servers into thinking that they had uploaded the verification file thanks to the malicious PHP code. It makes us think that perhaps Google’s verification system should use a separate randomized string inside of the verification file. Perhaps one that can’t be guessed or calculated based on known variables such as the file name.