Last year an attacker forced thousands of unsecured printers to spew racist and anti-semitic messages. But this year’s attack is even bigger. An anonymous reader writes: A grey-hat hacker going by the name of Stackoverflowin has pwned over 150, 000 printers that have been left accessible online. For the past 24 hours, Stackoverflowin has been running an automated script that searches for open printer ports and sends a rogue print job to the target’s device. The script targets IPP (Internet Printing Protocol) ports, LPD (Line Printer Daemon) ports, and port 9100 left open to external connections. From high-end multi-functional printers at corporate headquarters to lowly receipt printers in small town restaurants, all have been affected. The list includes brands such as Afico, Brother, Canon, Epson, HP, Lexmark, Konica Minolta, Oki, and Samsung. The printed out message included recommendations for printer owners to secure their device. The hacker said that people who reached out were very nice and thanked him. The printers apparently spew out an ASCII drawing of a robot, along with the words “stackoverflowin the hacker god has returned. your printer is part of a flaming botnet… For the love of God, please close this port.” The messages sometimes also include a link to a Twitter feed named LMAOstack. Read more of this story at Slashdot.
Taken from:
A Hacker Just Pwned Over 150,000 Printers Exposed Online
An anonymous reader quotes a report from The Register: Source-code hub Gitlab.com is in meltdown after experiencing data loss as a result of what it has suddenly discovered are ineffectual backups. On Tuesday evening, Pacific Time, the startup issued the sobering series of tweets, starting with “We are performing emergency database maintenance, GitLab.com will be taken offline” and ending with “We accidentally deleted production data and might have to restore from backup. Google Doc with live notes [link].” Behind the scenes, a tired sysadmin, working late at night in the Netherlands, had accidentally deleted a directory on the wrong server during a frustrating database replication process: he wiped a folder containing 300GB of live production data that was due to be replicated. Just 4.5GB remained by the time he canceled the rm -rf command. The last potentially viable backup was taken six hours beforehand. That Google Doc mentioned in the last tweet notes: “This incident affected the database (including issues and merge requests) but not the git repos (repositories and wikis).” So some solace there for users because not all is lost. But the document concludes with the following: “So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.” At the time of writing, GitLab says it has no estimated restore time but is working to restore from a staging server that may be “without webhooks” but is “the only available snapshot.” That source is six hours old, so there will be some data loss. Read more of this story at Slashdot.