[HN Gopher] Meris botnet, climbing to the record
___________________________________________________________________
Meris botnet, climbing to the record
Author : iwitaly
Score : 75 points
Date : 2021-09-09 10:50 UTC (12 hours ago)
(HTM) web link (blog.qrator.net)
(TXT) w3m dump (blog.qrator.net)
| jtchang wrote:
| To block something like this you need to determine what is botnet
| traffic vs legit traffic. It's hard.
|
| Source IP doesn't work since it is random and changes. You need
| to look at things such as HTTP headers, TCP window and any odd
| flags that might be set. If you're lucky the botnet isn't capable
| of running a copy of Chrome or Safari or using a random sample
| template from legit traffic. Lots of botnets are made up of low
| power IOT devices so once these devices are capable of running a
| full headless chrome it will get harder.
|
| Not to mention when you do figure out how to discriminate traffic
| you have to code it. And the code to determine valid traffic vs
| invalid better run fast because you are getting hit with 100k
| requests per second. Oh did I mention the attacker can change
| their algorithm whenever they want? Hope you have a full
| tensorflow ML/AI pipeline that configures your hardware based
| ingress of choice just in time. All this while making sure your
| current production traffic is being served at a speedy pace and
| not blocking legit customers.
|
| These are some of the issues Cloudflare and companies like them
| have to deal with.
| achillean wrote:
| In cases like this it's actually not that difficult as they're
| using devices that can be fingerprinted from the Internet. We
| at Shodan provide a local, embedded database (SQLite or
| RocksDB) so you can see which open ports connecting IPs have.
| If an IP is connecting from a device that's running weird
| ports, is compromised or has other unusual characteristics then
| you can either flag the connection as high risk or outright
| drop it if you're under attack. It's mostly used by banks etc.
| for fraud prevention but we have a few that use it for blocking
| traffic based on IP risk.
| jtchang wrote:
| How does fingerprinting them help? You can fingerprint them
| but they are just desktops/mobile phones/laptops that have
| been compromised to be part of the botnet.
|
| The compromised hosts that are part of the botnet look
| exactly like normal traffic.
| _e wrote:
| Introducing javascript into the mix will not make the botnet
| more difficult to detect. Headless browsers have their own
| fingerprints which allow defenders to identify them from
| legitimate traffic. You can spoof the features that headless
| browsers don't have but that will always be a cat and mouse
| game.
| potamic wrote:
| I think in future servers will ask clients to solve a small
| computation. It can be theoretically incorporated into the
| handshake and if it takes something like 100ms, human users
| would not notice but botfarms will feel the pinch. An
| additional benefit is that servers can monetise the computation
| offsetting some of their costs.
| dimitrios1 wrote:
| we need something like anonymized identity. Something that
| can prove you are human being, but without requiring your
| personal data.
| pope_meat wrote:
| Thumb print reader that pricks you to make sure you bleed.
| gkop wrote:
| This was a mainstream idea when I was in CS school 12 years
| ago. There are creative alternatives too, eg. by requiring
| the client to complete a network scavenger hunt: https://peop
| le.cs.pitt.edu/~adamlee/pubs/2012/abliz2012ijas....
| EvanAnderson wrote:
| Wouldn't bot farms just incorporate that as a "cost of doing
| business" and expand to absorb the computational load? After
| all, it's not like the bot farmers are paying to add more
| hardware.
| aj3 wrote:
| This attack was 20m requests per second, not 100k.
| iforgotmypass wrote:
| Interesting name. "Meris" in Latvian means "plague". I wonder if
| it is on purpose. Too lazy to read the article or look up,
| though.
| PragmaticPulp wrote:
| 20 million requests per second from a single beefy AWS server is
| easy to detect and block.
|
| 20 million requests per second coming from a rotating list of
| hosts from generic IP addresses is a nightmare:
|
| > However, we suppose the number to be higher - probably more
| than 200 000 devices, due to the rotation and absence of will to
| show the "full force" attacking at once.
|
| If your site normally has 10,000 users per day and suddenly
| you're flooded with 200,000 additional IP addresses hammering at
| your site, you have a problem.
|
| To put it in perspective, the top post on HN most of yesterday
| was about someone benchmarking their personal server as being
| able to handle about 5 million requests per day (Granted, that's
| quite slow, but it will suffice for making a point). This botnet
| can deliver 4X that server's total daily capacity every second.
| colejohnson66 wrote:
| But how do you distinguish an abnormal traffic spike (HN hug-
| of-death) vs a botnet? Cloudflare's solution is a CAPTCHA, but
| are there better options?
| jgrahamc wrote:
| Cloudflare's solution is _not_ a CAPTCHA. We have a ton of
| stuff going on that detects bots. CAPTCHAs are a small part
| of the tools we use. https://blog.cloudflare.com/cloudflare-
| bot-management-machin...
| geitir wrote:
| Do you have a scraper that looks for mentions of Cloudflare
| or did you just happen upon this?
| jgrahamc wrote:
| Yeah. I use something like this:
| https://github.com/jgrahamc/hncomments
|
| Although I really need to commit the final version as
| that one isn't quite what I use.
| colejohnson66 wrote:
| Sorry. I didn't mean to imply that you don't have anything
| but CAPTCHAs. My wording could've been better.
| mleonhard wrote:
| Cloudflare uses CAPTCHA to drive away proxy users. Privacy
| conflicts with Cloudflare's endgame of profiling every
| Internet user and then monetizing that data.
| aj3 wrote:
| Generally you don't. Just be prepared to scale resources and
| handle everyone.
| smasher164 wrote:
| An attack-resistant trust metric? Although I haven't seen
| them used against denial of service attacks.
| aj3 wrote:
| Thankfully these attackers haven't heard about Layer 7 attacks
| yet.
| ximaera wrote:
| They have. These are 20 million Layer 7 requests per second.
| _wldu wrote:
| Now that everything is in the cloud, DDoS is no longer an
| availability issue, just a billing issue.
| baybal2 wrote:
| "Connect to cloud by default" should be banned in any sensible
| network.
|
| It's probably even more devastating that "default password by
| default" if exploited successfully.
|
| A single stolen cert, or access to the device provisioning server
| instantly gets you "keys to the kingdom," and all of the devices
| online.
|
| A default password, or a vulnerable API on the device, in
| contract, will still need the attacked to individually find, and
| hack each vulnerable device.
| [deleted]
| datameta wrote:
| Can someone please explain-like-I'm-not-versed-in-botnets?
| morsch wrote:
| Yes. That is what the article is? RPS is requests per second,
| 20m RPS is apparently a lot, and there's a new botnet that does
| it.
| datameta wrote:
| One could surmise as much, but thanks. I'm also looking for
| some of the 'why' perhaps moreso than the 'what'.
| FDSGSG wrote:
| it make website no worky
| datameta wrote:
| I understand the purpose of a botnet. I was asking for an
| explanation of the technical details of this apparent
| advancement. But apparently snide comments purposely
| devoid of any detail is what I'm getting here now. Cheers
| junon wrote:
| It is not clear to us which information is not clear to
| you.
| datameta wrote:
| I would like to understand the significance of each
| bullet point under "Specific features of Meris botnet".
| nik41tkins wrote:
| The main point of this article seems to be to highlight
| the 20 million requests per second arbitrary metric.
|
| Otherwise the bullet points are about the functionality
| in place in the infected clients. The port is likely a
| detection metric for infected clients.
| giantrobot wrote:
| SOCKS proxy: the botnet allows tunneling non-WWW traffic
| through it so users of the botnet can route say
| BitTorrent or other P2P traffic through it.
|
| HTTP Pipelining: instead of simplistic one-request-one-
| resource requests to a server the botnet supports HTTP
| 1.1 pipelined requests. A single request can ask for
| multiple files meaning even more demand on target
| servers. Request resources not cached in memory can see
| the server eat up its IOPS trying to read files.
| michaelbuckbee wrote:
| DDoS attacks like this are usually launched from large number
| of malware ridden personal computers. Since the attacks are
| coming from an IP addresses on a residential network they're
| very hard to differentiate from legitimate traffic.
|
| What's different about this attack is that it appears to not be
| PCs but network devices (routers) that are being taken over and
| used to launch attacks.
|
| People are much less likely to catch that this is occurring and
| as a result there's concerns that this botnet is going to
| persist as a threat for a much longer time than is typical.
| Additionally, network devices may have access to a greater
| amount of bandwidth than a PC increasing the threat.
|
| One more thing: when the botnet makes a request (attack)
| against a site it's using a modern performance optimization
| technique of "pipelining" where instead of a GET to
| "/index.html" just interacting with the index.html file it's
| holding a connection open to also then request all the other
| assets from the site. In normal usage this is great as it makes
| a site feel more responsive and reduces network overhead.
| However, in the context of this botnet it also increases the
| number of requests that each bot can make (which is bad).
| _e wrote:
| Great explanation... For anyone interested, the following
| jupyter notebook explains three different ways to process
| HTTP requests: serial requests (the baseline), pipelined
| requests and parallel requests with multiple connections (and
| without threads).
|
| https://gist.github.com/coady/f9e1be438ba8551dabad
| ogurechny wrote:
| 0. There seems to be a MikroTik exploit, and all versions are
| vulnerable. Well, it possible that someone collected the
| passwords back in 2018, and used them to access updated devices
| this year, but I guess naaah.
|
| I wonder what should happen to that fine company to make them
| stop running all the potentially vulnerable system
| configuration services on all interfaces by default. IP >
| Services is one of the locations anyone should check ASAP to
| make sure unneeded ones are disabled, but it's actually
| misleading. These are just preconfigured wrappers for some
| components, and others, like DNS or bandwidth test server
| mentioned in the article, are not shown even if they are
| running. There isn't even a netstat-like command to check which
| ports are open.
|
| 1. While reaching a record number, the attack against something
| on the scale of Yandex and Cloudflare is more of a maximum
| capacity test not limited by target's connectivity, and/or an
| advertisement for someone's DDoS services.
|
| 2. Still, it's an application-level DDoS, so you have to have a
| swift application-level detection in place if you don't want to
| just ban IP addresses (and potentially cut legal users from
| HTTP(S) APIs and other services that might be shared on the
| server or network).
|
| 3. Some skill was demonstrated in finding no-trivial weak
| points to amplify the server load.
| kreetx wrote:
| Is there anything specific Mikrotik owners can do? (other than
| updating their firmware)
| neonate wrote:
| http://web.archive.org/web/20210909125816/https://blog.qrato...
| swiftcoder wrote:
| In other words, this entire botnet can perform the work of... a
| few dozen decent size AWS instances?
|
| We used to push ~million request per second from each m4.10xl
| instance when running load tests.
| junon wrote:
| Yes and to mitigate your puny attack I need to block a few
| dozen IPs.
|
| A botnet is probably coming from hundreds, if not thousands of
| IPs, sprinkled in with normal user requests and often with
| similar frequency.
| yabones wrote:
| What makes it dangerous is that those requests aren't coming
| from a single source - it's a _distributed_ denial of service
| attack. Anybody can push huge throughput from an XL cloud
| server with good networking, but it 's just as easy to block
| that IP. Blackholing thousands of nodes is much more difficult.
| menmob wrote:
| Legitimate IPs, at that. These are networks that are not
| hostile 99% of the time.
| FrankSansC wrote:
| Original link: https://blog.qrator.net/en/meris-botnet-climbing-
| to-the-reco...
| chalst wrote:
| Thanks for linking to this.
|
| Given the amount of misinformation in infosec, we should not be
| linking to intermediate sources for this kind of story.
| ogurechny wrote:
| Well, it's the same article officially posted by the same
| company on a community site.
| chalst wrote:
| Right. I don't think conscientious HN readers should have
| to check this.
| jcpham2 wrote:
| Very difficult or slow to load for me: >
| https://archive.is/RLkSX
| dang wrote:
| Changed above from
| https://habr.com/ru/company/yandex/blog/577040/. Thanks!
___________________________________________________________________
(page generated 2021-09-09 23:01 UTC)