Leak -- Compromised POSTING key successfully protected

@keys-defender 69

over 2 years ago

CyberSecurity

❗❗❗ 💀 ⚠️ 💀 ⚠️ ❗❗❗
It's a new day and another user leaked one of their private keys into the Hive Blockchain.

They COMPROMISED their:

private POSTING key

HOW: in a transfer operation

The compromised account owner has now been notified in multiple ways. The identity of the user will be disclosed only in the monthly report in order to give them time to address the issue.

Compromised account stats:

Reputation: 62
Followers: 47
Account creation: 3/2023
Last social action on chain: 2023/10/15
Estimated account value: $ 104.76

Top 5 private ACTIVE keys protected:

_{1. @nextgen622:}~$ 28,000 _{2. @cryptoandcoffee:}~$ 8,400 _{3. @runridefly:}~$ 3,300 _{4. @globalmerchantio: ~$ 250}
_{5. @j3dy: ~$ 120 (500 HIVE automatically protected for 9 days)}

_{My security disclosures for Hive:}
_{- _{XSS vulnerabilities in #########.com}}
_{- _{XSS vulnerabilities in hive-db.com}

- _{XSS vulnerabilities in scribe.hivekings.com}

- _{XSS vulnerabilities in hiveblockexplorer.com}

- _{Malicious ads redirecting all Steemit iOS users to a phishing site}

- _{Reverse tabnabbing and clickjacking in steem.chat and steeemit registration page}}

_{Other contributions:}
_{- _{Universal script to prevent phishing in all Hive frontends}}
_{- _{Commands for community reports and ban/mute lists}} _{Future development: _plan} _{Last report: _{https://peakd.com/@keys-defender/monthly-report-june-july-august-2021-hive-13323}}

Keys-Defender features:

- _{Keys protection_{[live scan of transfers/posts/comments/other_ops.
Warnings (reply and memo), auto-transfers to savings until fully restored, auto-reset of keys, ..] {see automatic posts on leak and monthly reports}}}
- _{Phishing protection
_{[live scan of comments and posts to warn users against known phishing campaigns and compromised domains or accounts, scan of memos and auto-replies, anti phishing countermeasures - eg. fake credentials]}}
- _{Re-posting detection
_{[mitigates the issue of re-posters]}}
- _{Code injection detection
_{[live scan of blocks for malicious code targeting dapps of the Hive ecosystem]}}
- _{Anti abuse efforts
_{[counteracts spam from hive haters and milking campaigns]}}

To support this project..

- _Delegations: _{10, 50, 100}

- _{Curation trail:} _{_{join my curation trail to upvote all my posts with a fixed weight.}}

- _{Downvote trail:} _{_{join my downvote trail to follow my downvotes on security threats and abuse.}}

- VOTE for our WITNESS !!

_{This project is sponsored by} @cryptoshots.nft
_{Browser-based play-to-earn} 3D Shooter on HIVE

_Discord _Twitter

hive-138876 hive hacking stem bot neoxian stem

0.000

1 comments

@gaottantacinque 62

7 months ago (Edited)

DoS coverage: 6 of the 8 slow-playbook tests demonstrated actionable DoS exposure: slowloris (Portal/z2__DoS_singleMachine_SLOW/reports/2_blockMode/slowloris-report.md:1),
staged R.U.D.Y uploads (…/rudy-report.md:1), slow-read dispatcher drain (…/slowread-report.md:1), raw TCP connection flood (…/tcpConnFlood-report.md:1), persistent HTTPS keep-
alives (…/persistentHttps-report.md:1), and the MUFG-style slow upload (…/slowUpload-report.md:1). The TLS handshake stress and 50 RPS configRefresh hammer did not uncover a
weakness—TLS handshakes completed cleanly (…/tlsHandshake-report.md:1), and the API flood was blocked outright (…/apiFlood-report.md:1).
Protection posture: Current ModSecurity/Apache defenses only police high-rate, fully completed requests. Anything that keeps a socket half-open (slowloris, R.U.D.Y, slow-read,
idle TCP/TLS sessions, multipart drips) bypasses the per-minute counter entirely, so a single client can starve Apache workers and downstream servlets. The API DoS rule, on
the other hand, is so aggressive that even a moderate 50 RPS burst is rejected within seconds, suggesting a “hard block” that could also impact legitimate maintenance jobs. TLS
handshake capacity is healthy at ~9–10 negotiations/sec, but there is no admission control at the TLS layer, so higher rates would rely purely on raw CPU headroom.
Real-world impact: Because most of these vectors tie up resources without ever finishing a request, an attacker with minimal bandwidth can exhaust Portal’s thread pools while
staying under WAF radar—slowloris and slow uploads can immobilize EncryptUtility/dispatcher threads for minutes, preventing real customers from submitting documents or viewing
pages. The idle TCP/HTTPS tests show that even basic connection-flood tools can fill the listener queues before ModSecurity evaluates anything, giving volumetric attackers
a low-effort path to disruption. Meanwhile, the overzealous API DoS rule means defenders risk self-inflicted outages: any legitimate automation burst near 50 RPS would be
blocked, yet attackers can simply shift to low-and-slow tactics that the rule set ignores. Overall, the system remains highly vulnerable to starvation-style DoS despite recent
WAF tuning—current defenses mostly stop fast, high-RPS floods while leaving the more common “slow and resource-hungry” patterns wide open.

0.000