The uTorrent client was recently updated to fix a null pointer dereference (CVE-2020-8437), discovered by [whtaguy]. Triggering the dereference simply crashes the client — so far an actual RCE hasn’t been found. Given the nature of the null pointer dereference, it’s possible this bug is limited to denial of service. That’s extremely good, because the flaw is extremely easy to target.
BitTorrent is a clever protocol. It’s still used to distribute large files, like Linux ISOs. The concept is simple: Split a large file into small chunks. Send the chunks to a client one at a time. As each chunk is received, the client sends a copy of that chunk to the next client. As a result of this peer-to-peer (p2p) arrangement, the bandwidth available to the server is greatly multiplied. As with all other p2p arrangements, the sticking point is how to make those connections between peers, particularly when most of the world’s desktops are behind NAT routers. In practice, for two peers to share data, at least one of them has to have a port opened or forwarded to the client. This is often accomplished through Universal Plug-n-Play (UPnP) or the NAT Port Mapping Protocol (NAT-PMP). The idea of both protocols are the same; a client on an internal device can request a temporary port forward without manual intervention. Whether it’s a good idea to allow automatic port forwards is another issue for another day.
BitTorrent uses a custom data serialization scheme, bencode, to include more complex data structures in both .torrent files, as well as the handshake sent between peers when connecting. Bencode can represent multiple data types, one of which being a dictionary type. Of interest here is that a dictionary can contain a dictionary as a value, and the protocol doesn’t specify a maximum depth. In the uTorrent client, this depth is tracked internally by using an integer as a bit field, essentially bit-shifting a binary 1 into this integer for each level of dictionary parsed. The bencode decoding code overflows the integer when more than 32 dictionaries are nested. This overflow results in an attempted access of a null pointer, crashing the client.
This vulnerable code can be targeted in two different ways. The first is through a specially crafted torrent file. This is rather uninteresting, as the client simply crashes when trying to open the file. The interesting vector is through peer handshakes. The malicious bencode data can be sent as a part of the handshake, crashing the client on the other end. This ability is intriguing, because it could be used in a targeted DoS attack against a specific torrent.
It’s been pointed out that a popular older version of uTorrent doesn’t have this exact vulnerability, though the normal caution about running outdated software still applies. It’s also possible that similar vulnerabilities could be found in other BitTorrent clients.
Crowd-Sourced Fail2ban
If you run a service connected to the internet, then you probably know a bit about fail2ban. It’s a daemon that watches your system logs for repeated events, like an attempt at guessing an SSH password, and temporarily denies the IP address making the guesses. It’s a handy tool, but wouldn’t it be even better if that live deny-list could be used on many systems at once? Crowdsec aims to be that solution. Once installed and opted-in, each event of interest is turned into a data point consisting of the IP, event type, and timestamp, and uploaded to the central database. From there, each report is then folded in to the continually evolving deny-list. The project is young, but this might be one to keep your eyes on.
When a Cryptographer Goes to the (Virtual) Casino
Our old friends, the NCC Group, took aim at a niche industry, online gambling. Specifically, they took a look at online roulette wheel gambling, but their techniques are widely applicable.
The first principle to understand is that the house always wins. To put it another way, the gambling establishment is guaranteed to make a profit. Understanding exactly how that works can be important. In the case of roulette, both types of wagers are stacked slightly towards the house. The margin is small enough that even a minor advantage can turn the tables. So, one of the easiest avenues to examine is the random number generator. Find the list of winning numbers, and see if some numbers actually come up more often. A quick trick the authors shared: represent the numbers as a bitmapped image. The human brain is exceptionally good at recognizing patterns when the data is displayed the right way.
Another possible weakness is how the close of betting is implemented. If a user could modify the site’s JS in the browser, he could send bets later than intended. If the server-side doesn’t carefully check for such an attack, late bets could give a player an edge. The entire write-up is full of interesting strategies, both for general web security research, as well as gambling and roulette specific strategies.
Bits and Bytes
Remember the botched AES implementation in Microsoft’s Active Directory? The US Cybersecurity and Infrastructure Security Agency (CISA) has deemed it a severe enough risk that any government systems that haven’t been patched (as of the 22nd), are to be permanently disconnected from government networks.
Drupal just released an update that addresses a cross-site scripting (XSS) vulnerability. An XSS attack is one where one user can inject some JavaScript into a website, and it runs when other users view the impacted page. (The Samy worm on Myspace being the prime example.) There isn’t much additional detail available at this time, but this problem is in Drupal core, rather than a 3rd party plugin, so the impact is potentially quite wide. Go dust off those Drupal installs, and get them updated!
“The human brain is exceptionally good at recognizing patterns when the data is displayed the right way.”
That reminds me of when I ran a BASIC program on my Timex-Sinclair 1000…
The program would pull a (pseudo) random number and use it to map a black square to a white screen, and repeat.
I noticed after running the program several times that similar locations showed up early in the run.
I realized this during a security class I had. I was trying to understand a large ROM dump. I changed it to a 256 color BMP and was able to differentiate between instructions, text strings, NULL data, and images visually. Made it a lot quicker to analyze data.
I can see som potential issues with the Crowd-Sourced Fail2ban system.
Hopefully it only sends information in regards to multiple invalid attempts at access. And not valid ones.
Since if it were to also send valid IP addresses, then that can lead to the obscurity of the correct IP address being lost, if the crowed sourced data base leaks (Something it does by its very nature…). This could for an example be used to spoof the Fail2ban system into blocking the person running the server. Making Fail2ban an inconvenience.
Though, Fail2ban could also just have this as a “local”/”privet cloud” feature. Where one can simply make all one’s server keep a common list. By simply sending it to a server of one’s choice, and also retrieve updates from it occasionally.
Crowd sourcing though has its own advantages.
But just having one’s own servers update each other would have its own advantages as well. (Though, this can rather easily be implemented with a centralized database as is.)
Hi Alexander. Philippe from CrowdSec’s team. We’ll publish a manifest about data handling. But to put it very short, here is what CS does. 1/ it sends the scenario your machine is subscribe to, for update reasons and also to send you back a meaningful list of IP to ban given your context 2/ if your machine detects an aggressive IP, it’s sent back along with a timestamp and the scenario triggered, nothing more. Curation of this IP against poisoning and false positive is made on our servers. Our curation system is quite elaborated with canaris list, honeypot counterchecks, dual upvotes of highly trusted peers, trust rank, etc.
A centralized fail2ban database sounds like a great way to get locked out of your system by a hostile attacker…
You can do all kinds of fun stuff with this I would think.
Take the cloudflare ip’s or ip’s from the cdn a site is using. Report those to the central db and see what happens.
Let’s hope they have mitigations in place for stuff like that
A centralised database, outside of your control, always sounds like a bad idea.
My very first thought was how are they monetising the data that they are harvesting. And how are they paying for the bandwidth and servers ? Is it free now and pivot later once big enough to a monthly/yearly subscription model. Is it bootstrapping a service for free, that can they can not sell without the actual realtime data, and you can not get the data without a global presence. And because providing a global monitoring network would be cost prohibitive, they are outsourcing it for the cost of opensource client software (almost free, but not, software takes time which is money). At the pivot they could even do a freemium level with smaller delayed aggregated updates (download a blocklist once a month). And different pricing levels depending on how close to realtime the blocklist are updated.
Looking at the crowdsec website, it appears that this is a toe in the door to a client that will monitor for port scans, web scans, which I’m not saying is a bad thing.
P.S. I hate to be all PC, but “blacklist” is no more. In the article above “wouldn’t it be even better if that live blacklist could be used on many”, and in the linked github source code “whitelists” are everywhere, and on the frontpage of the crowdsec website “enriched by our community-based IP blacklists”. Get with the times long live blocklists and allowlists.
Indeed, that’s too PC.
“P.S. I hate to be all PC, but “blacklist” is no more.”
So, call it badlist.
Well put – glad someone said it. What’s next, ‘ a night and day difference’ will considered a racist saying because of the dark and light / black and white comparison? — It’s a bit over the top… If I’d ever heard whitelist/blacklist used with racial connotations, it might be a different story, but come on…
blocklist. one letter
Badlist and Wholesomelist? Bannedlist and Welcomelist? Oh, wait …
Great now I have to find a new chess set too.
Indeed.
The biggest irony is that these terms are religious references from the pre-medieval Catholic Church and nothing whatsoever to do with skin tone.
Jonathan, you expect the general population doing the hype to know history?
Sorry about that. “Block” and “allow” are certainly better.
Sadly, some people are going to pretend to be offended no matter what terms you use…
They can definitely use the data to compile marketable threat intelligence products; Proofpoint already does this; they ship a client with OPNsense and the user can get free access to their commercial Suricata rule set in exchange for sending them telemetry of which rules fire and the remote IP address.
brad: you nailed it. It’s pretty much the plan. People not participating (not feeding us back with the IP the block) or just not using the product, don’t get the blocklist for free. They have to subscribe to an API plan or a premium or enterprise plan to only access the blocking / proofing features.
Hi Truth, Ron & R4m0n,
R4m0n & Ron, as commented before, poisoning and false positives are dealt with proper methods to avoid that anyone can feed legit IP in the blocklist (which we call consensus). The curation system: Trust rank is earned overtime and through perfect, correlated by other, reportings. So if a member just came in and spammed IP, that wouldn’t work. Or at least before a year or so, time for him to reach TR1. Then this report would be contested very quickly and this year of work to becomes credible is lost. In the meantime, the hacker helped us by reporting, for a year, real attacks. Also, a canari system avoid shooting legit & known IPs, like the google bot or so. If you report is pointing at one of them, the scenario is tagged as potentially too sensitive and your report ignored. Also, our own honeypot and/or other trust rank 1 peers have to validate your findings.
Truth: actually you may already use centralized database almost everyday (dns, mail, storage, etc.). Here, we thought about a blockchain approach to distribute the signals, but it’s not really adapted. About the costs, we have a very fair policy. People using the free product, and sharing signals, will get back ip blocklist. Free. Forever. Period. The one not sharing get a modern fail2ban. The one premium & enterprise get other benefits like AI curation, private consensus between their machines, templating and automation of deployments & reports, self IP monitoring, etc.
Yes, this certainly seems like a risk.
Also the ability for a state actor to put pressure on them to block IPs they want is also dangerous. Of course, it doesn’t have to be pressure, it could just be sharing “intelligence” on what IPs they’ve found hackers using. Oh, sorry, was that IP a political opponent’s? “Oops”.
Dan: Good one. Actually we didn’t really thing about this one to be honest. But I’d say that if we ever are cought in such shenanigans, that would mean someone will fork the system and create another list. Also, at some point, we may reconsider a blockchain approach to make it as resilient as possible. A State actor could indeed be a threat to consider, at some point, but at that stage, it means the software is immensly successful and that we will have ways to defend our community and ourselves. But we’ll dig into this threat and thanks for opening our eyes on this one.