#sicherheit geht uns alle an:
Welche Punkte/Regelungen/Belohnungen erwartet ihr in der #responsibledisclosure Policy von einer Seite wie LinuxNews.de? Bin da aktuell etwas planlos…

Hashtags damit wir volle Kanne in der #itsecurity Bubble einschlagen: #cybersecurity #cybersec #opsec #security #databreach #hackerangriff #hacker #itsec #credentialtheft #digitalsafety #digitalesicherheit #threatintelligence

(post describes my experience and does not represent my employer)

LinkedIn post (see also screenshot): https://www.linkedin.com/posts/johannes-greil-189bb813b_cybersecurity-infosec-workexaminer-activity-7386384177107116032-T3ow

I was involved in the mentioned cases and can only warn every penetration tester of bug bounty platforms.

I worked in an official CVE Numbering Authority (CNA) and we were legally threatened multiple times by vendors.

While bug bounty platforms claim to be a "safe harbor" and claim to mediate in difficult situations, in every instance they told us we have to adhere to the policies of the platform and didn't help any further. So, any user of these platforms has a double liability: first, to your country's law, second to the bug bounty platform's policy.

In the case of #HackerOne, they delegate this policy to the vendors:
"Security Teams will publish a program policy [...]. You should always carefully review this program policy prior to submission as they will supersede these [H1's] guidelines in the event of a conflict."
Source: https://www.hackerone.com/terms/disclosure-guidelines

So vendors can create a policy "no one is allowed to publish if we don't agree" and defeat responsible disclosure. In fact, some vendors do exactly that. Bug bounty platforms are paid by vendors and have no incentive to protect the researchers.

➡️ If you submit your vulnerability via email or similar directly to the vendor, then you are not legally bound to the bug bounty program's policy.
➡️ If there is trouble, involve your national CERT, they truly mediate.

Stay safe and warn your pentesting friends.

#PenetrationTesting #CVE #ResponsibleDisclosure

@bobdahacker @BobTheShoplifter

I'm really having a hard time getting past

"Drive-thru voice recordings of customers accessible"

#InfoSec #CyberSecurity #ResponsibleDisclosure #Privacy #GDPR #API #GraphQL #SecurityResearch #VulnDisclosure #RestaurantBrands #BurgerKing #TimHortons #Popeyes #vulnerability

🤖 Hacked China's Biggest Robotics Company (Pudu Robotics)

Pudu makes those cat-faced BellaBot robot waiters you see in restaurants, plus cleaning robots, disinfection bots, and even FlashBots with mechanical arms for offices.

Found critical vulnerabilities in their app controlling their entire global fleet:

• Zero authentication on APIs
• Could control any robot worldwide
• Accept 20k store IDs in single request, no rate limiting
• Could steal food, documents, redirect hospital medicine delivery
• FlashBot with arms could grab files & use elevators

Reported Aug 12. Sent emails to sales, support, tech teams - all ignored.

Had to email Skylark Holdings (7000+ restaurants) and Zensho directly about their compromised robots.

Pudu responded in 48hrs with obvious ChatGPT template - forgot to replace "[Your Email Address]" placeholder. Fixed 2 days later.

Thousands of robots (BellaBots, KettyBots, FlashBots, etc) in hospitals, restaurants, offices worldwide were vulnerable for a long time.

Full Technical Writeup: https://bobdahacker.com/blog/hacked-biggest-chinese-robot-company

#infosec #robotics #BellaBot #PuduRobotics #security #vulnerability #responsibleDisclosure #cybersecurity

Security Flaws in the WebMonetization Site

https://shkspr.mobi/blog/2025/08/security-flaws-in-the-webmonetization-site/

I've written before about the nascent WebMonetization Standard. It is a proposal which allows websites to ask users for passive payments when they visit. A visitor to this site could, if this standard is widely adopted, opt to send me cash for my very fine blog posts.

All I need to do is add something like this into my site's source code:

A user who has a WebMonetization plugin can then easily pay me for my content.

But not every website is created by an individual or a single entity. Hence, the creation of the "Probabilistic Revenue Share Generator".

Probabilistic revenue sharing is a way to share a portion of a web monetized page's earnings between multiple wallet addresses. Each time a web monetized user visits the page, a recipient will be chosen at random. Payments will go to the chosen recipient until the page is closed or reloaded.

Nifty! But how does it work?

Let's say a website is created by Alice and Bob. Alice does most of the work and is to receive 70% of the revenue. Bob is to get the remaining 30%. Within the web page's head, the following meta element is inserted:

The visitor's WebMonetization plugin will visit that URl and be redirected to Alice's site 70% of time and Bob's 30%.

If we Base64 decode that weird looking URl, we get:

Rather than adding multiple URls in the head, the site points to one resource and lets that pick who receives the funds.

There are two small problems with this.

The first is that you have to trust the WebMonetization.org website. If it gets hijacked or goes rogue then all your visitors will be paying someone else. But let's assume they're secure and trustworthy. There's a slightly more insidious threat.

Effectively, this allows an untrusted 3rd party to use the WebMonetization.org domain as an open redirect. That's useful for phishing and other abuses.

For example, an attacker could send messages encouraging people to visit:

https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDk5LCJpbWciXV0

Click that and you'll instantly be redirected to a domain under the attacker's control. This could be particularly bad if the domain encouraged users to share passwords or other sensitive information.

If the Base64 data cannot be decoded to valid JSON, the API will echo back any Base64 encoded text sent to it. This means an attacker could use it to send obfuscated messages. Consider, tor example:

https://webmonetization.org/api/revshare/pay/W1siUGxlYXNlIHZpc2l0IFJlYWxfZ29vZF9DYXNpbm9zLmJpeiBmb3IgbG90cyBvZiBDcnlwdG8gZnVuISEhIiwxMjM0NTYsImltZyJdXQ==

Visit that and you'll see a message. With a bit of effort, it could be crafted to say something to encourage a visitor to enter their credentials elsewhere.

When I originally reported this, the site could be used to to smuggle binary payloads. For example, this URl would display an image - however, it seems to have been fixed.

Nevertheless, it is important to recognise that the WebMonetization.org domain contains an unvalidated redirect and forwarding vulnerability.

I recommended that they ensured that the only URls which contain legitimate payment pointers should be returned. I also suggested setting a maximum limit for URl size.

Timeline

• 2025-03-27 - Discovered and disclosed.
• 2025-08-05 - Remembered I'd submitted it and sent a follow up.
• 2025-08-26 - Automatically published.
• 2025-08-27 - A day after this post was published, the issue was made public on their repo.
• 2025-09-10 - Confirmed fixed.

#BugBounty #CyberSecurity #ResponsibleDisclosure #WebMonetization #xss

🆕 blog! “Security Flaws in the WebMonetization Site”

I've written before about the nascent WebMonetization Standard. It is a proposal which allows websites to ask users for passive payments when they visit. A visitor to this site could, if this standard is widely adopted, opt to send me cash for my very fine blog…

👀 Read more: https://shkspr.mobi/blog/2025/08/security-flaws-in-the-webmonetization-site/
⸻
#BugBounty #CyberSecurity #ResponsibleDisclosure #WebMonetization #xss