I've tried reporting a DoS to a company which literally just involves sending a request to their API with a deeply nested array as the request body, which wasn't accepted, making me all the more mad seeing these bogus reports getting accepted and receiving a bounty..
@Napert I think it's a fair option to tell them "if you think this isn't an issue, then clearly if I use this attack, you believe it won't cause a problem, right? So I'm gonna do that." and if they say "don't do that", you say "then it's a bug", and if they say "go ahead", then do it and bring the site down.
From personal experience, DoS vulnerabilities are usually addressed if and when they become an actual issue. There is no point in defending against theoretical scenarios, especially if they are rather contrived.
I've worked on react & node apps at large FinTech companies. I can't even count the number of hours wasted closing tickets that the security team created (from synk scanner) to address DDoS on packages that were only being used in the dev or CI pipeline. Not one was ever a legitimate threat of DoS.
There are instances though where theorectical vunerabilities highlighted by the OpenBSD team were shrugged off as unrealistic and paranoid by the Linux Kernel developers and a few years later these had to add it mitigation protection into the Kernel.
@@dave7244 There is a difference between DoS in the Linux kernel run by millions of computers, and proprietary software run by one business on a handful of servers through. Way different attack surface.
You are correct - a lot of organizations don't have a clear threat model to determine when an operational halt is warranted. The thing about security is the landscape is always changing and DevOps means code bases move fast. So security is always playing this reactionary game with numbers 1 to 10 (CVSS scores) as opposed to actually reviewing the threat and determining its actual validity in your environment. A lot of Security teams will push out a fix requirement to the Dev teams for every little DDoS mitigation their fancy AI-Powered Anti-Virus scanner points out. It's an incredibly reactive approach to security which ironically is a threat in itself (think about 0days). This is why it's so important to promote good security hygiene as part of everyones' role and involve security early in the Dev process. Right now - infosec is the compliance hall-monitor.
Alex from TCM Security recommended this channel in one of his live streams, and he's right; the content here is excellent; thanks for sharing liveoverflow.
@liveoverflow I am a pentester and for me there is a distinction between DOS 'attack by single ip' and DDOS 'attack by multiple ips'. If I see that I can render the server unavailable for other users simply by using one machine I will report it as an issue. To me it is unacceptable since a single machine should not have the ability to affect other users of the platform. Especially when it comes paired with a function that sends email or a SQL store since there is absolutely no reason why a legitimate user would need to inject 5000 calendar items in 1 minute time for example. It's not about complete protection but its about putting up boundries.
Okay. So you limit users being able to only create 6 calendar entries per minute? One very 10s? Now you get power users complaining about trying to quickly create 10 consequtive events in the calendar. Okay let’s put it to 60 entries - one per second. Now take 100 accounts to create 1 entry every second. IP rate limited? Well now you block a large company from using your website. Okay, let’s make it a feature of enterprise accounts to bypass IP rate limit. But great, now you defined an exception from where a DoS is allowed. And actually, now it turns out the problem is not 5000 entries in one minute. The server crawls because 5000 events are set to the same time, and notification logic now is in a 5000 item loop sending notifications. So now you can still have a single account over 100 minutes to add these 5000 entries. Ok we now need to ratelimit the notifications. Let’s actually combine them into a single notification, because they happen on the same time. Well that maybe doesn’t solve some server logic looping over the items. Oh, we managed to fix that with a nice efficient SQL query? Cool! But you entered 1000 participants to be invited that have to be notified. Is that too much, don’t allow that many invited participants? What if a company tries to organize a huge conference and sends out an invite. I could keep going and going. The circle of unfixable issues.
Actual realistic solution: don’t bother. Wait until you notice abuse. Ban the abuser. Try to add maybe some annoying things for the absuer. Move on until the next one happens. If in doubt, contact police due to cyber attack.
@@LiveOverflow Well, in this example the user is probably logged in, so per-account limiting might make more sense (edit: so the per-IP limit wouldn't need to be so low / exist). And in general, one can try to limit the impact of unauthenticated DOS to unauthenticated users, so logged-in users can keep minding their business, at least. edit2: To combat mass account creation, wouldn't it be better to IP limit that instead of all the logged-in endpoints? If the service is paid, even that probably wouldn't be necessary.
Or, in short: The assumption of "1 IP === 1 machine === 1 user" is, and always has been, flawed. In the nineties, it was those big *nix machines with plenty of terminals, in the 00s companies centralised their outbound traffic behind proxy farms, in the 10s, it was DSL users who now had their whole home network for multiple people behind a NAT router, and nowadays it's ISP-level NAT for IP4. And, BTW, if a single request can bring a service down, I wouldn't even call it a DOS. It's a bit sad that we use a single symptom as the name for a whole group of issues with different causes.
11:06 you're brushing off a legitimate report here. The report says that IPv6 rate limiting is not properly implemented, rate-limiting the single IP instead of the subnet. The IPv6 spec requires that each device can select its ip itself from a /64 subnet (at least). That is 2x the bit size of the whole ipv4 space, more IPs than you could ever use, making this way of IPv6 rate-limiting ineffective. IPv6 needs to be IP-Ratelimited/Banned differently from ipv4.
Yes I’m brushing off all of these “legitimate reports” as being unfixable. Of course the report is “valid” but there is no proper fix, the problems keep coming. That’s the whole point of the video. These “fixes” don’t really matter.
but then if you are on a shared network, then you can rate limit the everyone in the network. Shared networks may include workplaces, public wifi, school networks, and more.
@@acters124 So is the nature of IP-based rate-limits/bans; This has effectively always been the case with ipv4 as well. I'm not going to keep arguing because @LiveOverflow has clearly already made up his mind, but IMO this is more similar to trusting an X-Forwarded-For header than it is to using proxies. Code that was not designed to respect the intricacies of how IPv6 is generally implemented is put in an IPv6-Reachable deployment, causing IP-Ratelimiting to be literally fully bypassable without any proxies. It's just disappointing to see something like this put on the same level as reports such as the one in the start of the video, which seems to be simply incorrect (or at least was portrayed as such).
Are we talking about the same report? The weblate one? It does briefly mention IPv6, but it also mentiones many other things like “There are many botnets out there which can be used to overcome this hurdle, as well as cloud (VPS) services” and they specifically expect these fixes “No additional protection mechanism such as Captcha (pre-auth) or account lockout requiring additional email/phone verification (pre- or post-auth) were identified at any time.” So characterizing it as a “ipv6 ratelimit bypss” report is a little bit stretching. But in the end, still doesn’t matter much
It's funny how these people say "there is money in hacking, it's easy", but then fail to mention that all that money is pretty much unreachable from people at the start. All the veterans claim it by running automatization bots. This is the same with web bug bounties. Unless you're advanced level, you really don't have a chance.
Glad you mentioned threat models. One of the most annoying things that happens regularly in my job is we get messages that we need to "fix" CVEs related to third party dependencies. Normally we just end up patching the software even if there is no actual attack vector for the CVE to be relevant to our software because that's easier than analyzing and documenting why it is irrelevant. Same thing applies to most findings from penetration tests.
Interesting. I am one of those people who tell developers to update their dependencies. Can you go into further details about your perspective here? How would you go about fixing this issue?
@@Bluepaccao If you only use function 'a' in a library, and a vulnerability was found which only impacts function 'b', you aren't vulnerable. Of course it's good to update when you can, because one day a developer might add code which uses function 'b'. But if the new library update has some breaking api changes, and you're 100% certain you'll never use function b, it's not worth prioritising.
@@BluepaccaoNot sure what the right solution is. Because the fundamental problem is that it is easier/faster to do the update than to document the reasons why it is not necessary. Also as a developer if you give a risk assessment that says there is no vulnerability, then it kind of puts you in the line of fire if later there is a problem with that library. I think most people just come to the conclusion: "let's do the unnecessary work, since it is easier." The only solution I see is if the security responsible people have a more active role in the product and so have a better understanding of the software. My general experience is that non-coding technical roles have hidden productivity costs because of the impedance mismatch that creates. Which means any org I would create would try to avoid such roles. But at most companies that is a big ask. corporate culture likes specialists, even in situations where a bit of generalism would help a lot.
Just because your code doesn't use b doesn't prevent malicious code from acknowledging its existence. Aren't most breaches due to chaining vuln's now? Like 3 vuln's to obtain parameter manipulation chained into a de-referencing to arbitrary code execution then wrapped back in with parameter manipulation to have remote code execution. You are right, having to explore your vulnerable packages to this degree to understand any attack chains like this are feasible would be more expensive than just patching the problems as they arise.
a video to impress laymen with no clue. max string length setting for the input form? problem fixed. Second problem is a self own/dev skill issue. Don't use sleep to rate limit.Limit user actions.
IMHO there's an additional factor that needs to be considered - in at least some cases it would be difficult to exclude these bogus DoS reports without also excluding important security flaws from a bug bounty program, and even if the fixes for these trivial attacks cost more than just buying some bandwidth that extra cost might still be worth it to a project in order to catch those actually sinister bugs.
One of my professors runs a company with a bug bounty program (ironically it is an automated fuzzing service). He told us about so many dumb submissions that were unfixable or not worth fixing.
1. Keep up with the OWASP Top 10 2. Become "the security guy" at your company where everyone thinks they can outsource security to the framework and never have to think about it 3. ??? 4. Profit
I think the tradeoff between "bandwidth needed to send a long password" and "time server needs to compute hash" can be modified to the attackers advantage by using compression. If compression is possible at the TLS layer (which it shouldn't be anyways, CRIME is a thing), this is very easy, but depending on the way the password is transfered to the server, you may be able to use HTTP compression.
@@Diastolicflame There is the so-called CRIME attack which, under special circumstances, allows to recover secret plaintexts by injecting malicious plaintext into the data stream. The gist of the attack is that if the injected plaintext contains parts of the secret, the compression will change the length of the ciphertexts, which can be exploited. Therefore, most TLS servers and clients do not accept TLS layer compression.
Sleeping is a dumb solution for me , why not just check with a redis DB and just drop requests , why sleep and hang the process ? That's how i would do it because i'am so used to writing non blocking code for Single core microcontrollers usually we avoid a blocking state at all cost to avoid "wasting" cycles.
Offtopic, could you make a video about SMT and Z3? It would be really great, its a large concept in SMT and I think it would be the right cup of tea for your channel
Brute force is an attack on availability, so sleeping backends means that attack was successful, so request throttling by sleeping is not a fix to this attack.
Normally but not in this example, all the reports with regard to this video state, these bounties are about affecting availability with larger passwords and longer response times, emails sent, mentioned to bog down. No the intent with these bruteforce tests was not to discover the value of any password. Rewatch the video.
You said the term "brute force" and that is attack on confidentiality. The reports showed in this video are all "denial of service" reports, and those are an attack on availability. Generally the only time brute force is mentioned in this video it is when we talk about the issue in the past that introduced the `sleep()` that caused the "denial of service" issue later.
@LiveOverflow you're contradicting yourself in the video when you say "now we have a ddos". Bruteforce cannot be an attack on confidentiality when there is no real expectation of breach and the original intent is ddos. The world isn't as neat as you picture it, and things like bruteforce can have multiple intentions.
The solution seems likely to be making a dos require too many resources to be successful. Yes you gave a bunch of examples of how there is always still a way. But that doesnt change the fact you can optimize to make it harder to the point its not really worth it.
@@LiveOverflow Yes there is no clear point. You can progress some down that direction of making it harder for the attacker and then when it looks maybe probly decent you can pause your internal work and your bug bounty terms. And then possibly update in the future after things change like computing power. You dont need an exact end goal to progress in a rough direction and then stop when you think its maybe a decent place to stop. Approximation of a end goal is a decent "solution".
that is one of many reason why big company like google just deny login even when you have the correct account and correct password as long as you do not meet one or many of their additional Hidden request, like ip address from same city and same type of browser when you do not have the cookies...
I'm really shocked that the NextCloud team decided to add a sleep() into actual application code. And on top of that, an ever-growing sleep!? That's like a no-no and practically never a valid solution. For the login brute force, I'd do basic IP rate limiting and captcha prompt after X invalid attempts of User Y. This way, the worst that would happen with the real user Y is that they get shown a Captcha next time they log in (which is slightly annoying but not denial of service). IP rate limiting and captcha means that the attacker needs to spend some money to keep trying.
It's fixable: If you use async timers instead of sleeping with one thread per request, then your only real constraint is file descriptors. And if you start rejecting requests from the IP address before you reach the FD limit, then no single attacker can overwhelm your application. A DDoS is a different beast altogether and usually isn't something you can call a bug at all.
Unfortunatly, the solution you proposed does not actually 'fix' the issue. An attacker can always DoS a service if he can overpower the service provider, which can be made worse as usually server side will need more resource to process a single request compared to a client, even as simple as an plain old HTTP GET, no matter if the framework or code is async or not. DoS prevention is always an act of balancing between cost and benifit, and there is no 'fix'.
@@DWVoid0321 That's why that's a fix for the specific issue of the brute-force mitigation itself amplifying the attack. I'm not claiming that it's a fix for all possible single-source DoS attacks. That said, you're also wrong about the HTTP request overhead being an issue. You shouldn't implement IP blocking at the application layer; you do it at the network layer so the firewall can reject the packets before doing any inspection of the contents. And even then, HTTP requests are a largely symmetric cost. Without an amplification effect caused by code design that allows a single request to use up disproportionate resources, a flooding attack costs the attacker almost as much as it costs the victim. That's not something that can be classified as an exploit; that's just how network traffic works.
If you want to farm money from Dos bounties do not do that on Open Source projects please, those are already mostly underpaid projects that survives through kindness of the maintainers that put their own time and money in it.
> directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running. I'm not sure if password hashing is also classified as system call, but there are many ways you setting max request time isn't silver bullet also timeouts on nginx will kill request to client, but on php-fpm side request will still be executed taking up worker slots
Brute force attacks can be mitigated rather easily: Proof of Work with increasing complexity - easy for server to verify, expensive for attacker to scale attack you can make it global, so if there is any attack on your server users might in extreme cases wait extra 10s for password reset/login but that's it
Obviously the solution is to add a captcha to vulnerable API. So that DDOS and brute forcing are no longer an issue, and DOS has to be clever and use few requests because each one has to have a captcha solved /s ( but actually an interesting way to frame the problem ). In a way the rate limiting is a captcha because no human would reasonably send that many requests.
Captchas are no longer a valid DoS mitigation in times where AI Bots are more likely to solve them (and in a shorter amount of time) than humans. There is a recent study stating this iirc.
I think the problem with browser password managers, at least at the time when I was aware they were a concern, is that they were not encrypted in any way. A malicious program could simply steal passwords without having any form of key that unlocked those passwords, and you didn't need to be a privileged user to perform this, it could be anything, even a minecraft mod. Any form of on disk password manager should have some form of encryption, but chromium refused to implement encryption for some time. I don't have the exact bug report on me but I recall it being an issue.
Yes this, from my understanding if you wanted your malware to grab passwords from something like Bitwarden not only would you have to open the Bitwarden app but also wait for the user to click the copy password button at which point the password is decrypted and put into the clipboard. Not sure we can fairly compare browser password storage with a proper password manager
As soon as I figure out how to do it, I'll make my self-built login page on my website prevent new logins for a set amount of time if a set amount of failed login attempts has occurred within a set timeframe. It will accept requests from users who are already logged in but not allow them to log in again before the lock releases.
You seem to have missed a point that it's Sleep that's a problem, not rate-limiting per-se. Don't tie up all your servicing threads with Sleep! Instead, put it into a time queue and return to service other requests.
I wonder if having a ton of garbage tasks in a queue might also slow down legitimate requests. Though I guess it depends on how the waiting in queue is implemented. Putting sleeping tasks in a heap (since there is a clearly quantifiable measure to how long it will take) and occasionally checking if top one has finished sleeping is how I would do it PS using a thread pool with task queues instead of thread per user is a great rule of thumb to have IMO (especially when it's already built into framework used for a server)
@@aleksandertrubin4869 I have actually written a Command queue for several platforms. The data structure is called a Priority Queue, and you key it by wake-up time. It efficiently keeps the next job at the top, without having to constant sort or search. When a worker thread finishes, it checks the timer queue's top against the current time first, then the highest priority work queue, for what to do next. HTTP requests are queued on a work queue -- not a thread being queued, but the Command.
(continued) anyway, the command on the timer queue isn't the Login request; rather, that's a nested Command object and _this_ command says to put the enclosed command on the work queue of low priority. That way the repeated login attempts don't act as high priority and choke the system. When the time is up they go into a FIFO that is lower priority than the normal server Request.
In many server deployments all IP addresses are the IP of the ingress/loadbalancer/… so the denial of service rate limiting likely hits the normal users as much as the attacker. It might not show up in your dev test machine, but in cloud/Kubernetes/.. the code stops doing what it is expected to do.
Sleep is a crazy method of spam protection. IMO account and IP limiting should be moved to a CDN where you have no concerns with sending back millions of 400 responses. I don’t think it’s solvable on the real application backend
Ideally your application can instruct the CDN what to do, otherwise the CDN also can only guess whats acceptable behaviour of visitors in certain situations.
You definitely wont get rich. Most the people I know that do this do it as a hobby and they are constantly getting shafted by companies. After all the work you put in, wait to get paid, sue the bad actors, its basically pizza money. You misunderstand bug bounties as real security, they are marketing campaigns.
DoS is a symptom not a cause. If the cause of the DoS is due to a design flaw or code flaw then, generally, that is a considered a security vulnerability. If the cause of the DoS is due to a lack of capacity or resources then, generally, that is not considered a security vulnerability. The important distinction is when the former is the cause and the latter is the symptom... versus the latter being the cause and the symptom being former. Cause and effect, it's really not that hard.. so not hard that in my 15+ years i've never come across anyone raising this a philosophical conundrum like you have... it's just like say manufacturing a physical product, it's not really a conundrum figuring out what is or isn't considered a defect and when a recall is warranted... If i throw a newly bought coffee mug on the floor and it breaks, that's not a defect. If however on the first morning i go to take a sip from it, the handle falls off, it drops on the floor and breaks due to a non-heat reeistent glue being used to attach the handle, that's a defect. Same outcome, there's a broken mug on my floor, but it's whether that is the result of a flaw (the glue) or a flaw is the result (throwing it) At the end of the day, when all else fails, "it's a feature not a bug"
To play devil's advocate, I'm not entirely sure your analogy works on the field of cybersecurity since that's very often about protecting against malicious attackers (i.e. throwing the mug on the floor), not just innocent users (i.e. the mug's handle coming off during normal use).
It works, your mindset is wrong. Most ppl won't actually experience first-hand a DoS caused by an attacker in their careers, they will however almost certainly experience a situation where a fault or bug has inadvertently caused one. Most people don't throw mugs on the ground during their lives, it's much more likely you inadvertently drop one. It's not the most perfect analogy, it was the first thing that popped into my mind. Sheesh :) I'm getting too old for this 😂
@@sirtra Alright, but we're not talking about bugs, we're doing about security vulnerabilities, i.e. bugs triggered by an attacker. In cybersecurity, our sole concern is protecting against people throwing mugs at the floor. It doesn't matter if security bugs are less common than non-security bugs, because this video is about security bugs. The defects this video cares about are the ones that allow people to throw mugs at the floor
@@GrantGryczan throwing a mug on the ground and it breaking is not a bug, it's performing as designed and the outcome is expected - there is no fix as it's not something that needs to be fixed (well i guess if we want to get pedantic one could argue that you could make a mug to withstand being thrown on the ground, but that doesn't equate to a mug that does being insecure or a vulnerability. My point is on the premise that this is a grey area and confusing to know what is or is not a security flaw/vulnerability/exploit. It's not, or well shouldn't be for anyone in the industry with experience with high availability/scalability systems. Being able to steal and drive away in someone else's Hyundai armed with nothing more than a screwdriver or USB plug is a security flaw (i assume you are aware of this trend for reference - it's an issue unique to certain Hyundai's and i think Kia's too) Being able to steal and drive away in someone else's Ferrari armed with nothing more than a screwdriver BUT only after threatening the owner and them handing over the keys is NOT a security flaw. Personally i think this video starts really strong, digging into what actually happened and replicating the issue is top notch... but to then end it along the lines of well it's a grey area and unclear what is or isn't a vulnerability is doing the audience a disservice. But maybe it's just me, when you've been in the game as long as i have sometimes things you think are obvious aren't to a novice.. one could also make the claim of "well what would you know" and that's a valid point which i can only respond with "peer review". I'm not aware of anyone else with experience having difficulty determining the difference, just like it should be obvious to anyone working in automobile security which scenario above is or isn't a vulnerability.
Hi, I usually implement a cache layer to address these kind of issues, so for the same payload I can take the response from the cache instead of exhausting my backend resources, for unpredictable payloads such as images, presigned urls are the call.
But for example, when having the user account ratelimiting. Isnt it possible to force the user to unlock their account to change the name? I mean its not a beautiful solution but it would stop any bruteforces because the old attacked username no longer exists? Maybe im just wrong and overseeing something but in my opinion this should "fix" the issue
9:20 - fix[1] for sleepDelay is fairly simple - just move that to greenlets (or whatever similar technology) - essentially async sleep that won't block worker from performing more requests from other users until sleep ends. [1] of course, this will work until end of resources of server (like threads limit), but that's moving problem far, far, FAR away from it's current state. Can't believe such basic mistake was make with this sleep here to be honest and noone even noticed that it blocks whole worker.
So if password hashing with the most time-intensive, usable dedicated password hash function, Argon2, is practically unaffected by password length . . . WHY DOES MY UNIVERSITY HAVE A 15 CHARACTER MAX PASSWORD LENGTH?!
I'd implement making guessing logins awkward by first rate limiting by default to something like 3 seconds (the time it takes for someone to read an unsuccessful login attempt and enter the details again), then followed by having to enter the correct password twice (without any notification of having to) after too many tries. A human that knows the password will probably think they've entered it incorrectly or there is just a glitch if using a password manager, but an automated guesser won't know, and skip over the correct password without realising, if they can be bothered trying only 1 guess every 3 seconds in the first place.
Not the best idea because often someone forgets their password and tries a number of different ones, and they may pass over the correct one the same as a brute force script would
@@GrantGryczan Maybe not the best idea, but someone that knows the password is likely to try the same (hopefully correct) one multiple times. If you can't remember it, you usually just use the forgotten password system. I could swear one of the services that I use implements something similar. There have been times I swore I got the password correct, but got given the wrong username/password message forcing the use of the forgotten password system (and a lockout of 30 minutes).
@@threeMetreJim Yes, but likely isn't good enough. It needs to be sufficiently _unlikely_ that they _won't,_ which isn't the case. It happens all the time; I've seen friends and family members do it (even though I constantly advise them to use a password manager like Bitwarden lol). It usually ends in either giving up and not signing in, or in the event they really need to do what they're signing in for, requesting a password reset.
@@GrantGryczan You are probably right. Trying to confound an attacker while also not making it too awkward for a legitimate user seems to be a fine balancing act. I was thinking along the lines of short lockout times based on the likely number of times a legitimate user would make an attempt compared to automated attempts, aiming for the most frustrating timing for an attacker, linked to a short enough lockout so that the legitimate user would likely not notice after the attack was abandoned. The attack would need to be in progress for you to be locked out and notice - may be where the 30 minute lockout of that service I use comes from - there must be some optimal timing and I was thinking 'relatively short'.
That's why rate limit by IP is bad idea. Bruteforce is agains pair login+password usually, so rate limit should happen against login if too many different password attempts. And yes, it will lock user's account.
Well I don't know if you can report the same issue over and over, but if you can then is like they say, the problem is between the keyboard and the chair.
I just bypassed Steam's payment window PSD2/SCA, random clown closes ticket on the bug bountry site due to it "requiring a physical user device"..... well its actually the opposite.... ticket stayed close. Issue still exist. Free games forever.
Basically, you are preventing DDoS issue, by implementing sleep function, which is same as unresponsive server, as it is sleeping but it is just for a single IP, which is sending lot of requests. Well, to prevent that issue they are locking / rate limiting on user accounts, which again can become issue as well. So why can we just verify whether the user is sending request from a trusted User-Agent. Hence, block any other requests which are made through untrusted User Agent??
I mean you could demand that users solve a Hashcash-like challenge as a rate limit. As you have said the solution is more math. Make it expensive to generate valid requests.
How does github limiting the length of a password mean that it's not a vulnerability? If you can enter a long pw to slow down the server to the point of can be considered DoS, that's an issue. It might not be the issue of a long pw but the "hacker" technically sees a blackbox and is not paid to find the solution or the exact thing that's wrong in a complicated tool stack. I kick the door, I get in. That's vulnerability. I don't care if it's the lock or the wood or the doorframe that breaks.
Limiting the length means you can't enter a long password to use up server resources that leads to DOS. So limiting the length means no vulnerability due to long passwords.
Imo DoS are not issues at all, when the software is expected to process a large amount of data it's obvious that more data is equal to more processing time. Different thing is when your **small** input can crash the server due to validation issues in that's case it's a security concern
Id say a DoS is a vulnerability if it gives you unreasonably high leverage. Like, you can't complain that Ur pizza place starts up a car or grabs a bicycle if you order a pizza to your place, but if they charter a fucking lear jet to do it, their process is flawed.
17:10 Security of password manager can be improved by running it at higher privilege or with technologies like intel sgx enclave or trustzone. Such models works better for private key challenge based auth or encryption keys than for passwords which leaves 'secure world' to unprivileged clients. Bypassing that can be a vuln but there is a space for debate if lack of any theoretical security improvement is a security issue.
then you copy the password into the form of a website in a browser running under normal privileges. don't get me wrong, I'm a huge fan of password managers. but a browser PW manager already gives a lot of benefits against the BIGGEST issue we have, and that is credential re-use. I prefer my non-technical parents just safe it in browser, than nowhere.
4:54 Important DOS attack vector for sending extremely long passwords: it likely does not matter what the content of the string actually is, as long as it's sufficiently long. How does this help us/cause issues? If the server accepts gzip compressed POST data, that will allow the attacker to craft a very small compressed password that decompresses to potentially gigabytes. If you're not sure how gzip could do that, it's (basically) a steam of data and instructions, and one of those instructions could be (basically) "start from this byte and start copying the data stream for the next 10,000,000,000 bytes", so you start with a single byte, like 0x20, and then tell it to copy the datastream starting at 0 and going for N bytes. How does that work if there's only one byte to start with? When it gets to the second byte, thats after it already copied the first byte to the second byte, ad infinitum. Basically, a server accepting GZIP post data is often, in itself, a DOS attack vector bug. Keep a look out for that.
A bad php implementation would still be vulnerable, but usually noone really uses them anymore. So you cant lock up a thread, because its actually async and the thread simply does some other work while waiting for your sleep to time out.
GOOD Idea! What do you think of the Zero Day Project/Initiative that is very hard coding exploits? Stuff like ''Guest to Host Escape'' tactics. Never heard of such a advanced issues.
I think you need to inherit security budget of your country and implement same in your organization if you are doing business in that region of globe. This fixes most. Unfortunately defense in depth and layered security controls licensing are expensive and maintenance cost has great dependency on human intelligence or skill set. Typically perimeter level next gen firewalls + load balancer + WAF + Endpoint Protection + postgre SQL + latest endpoint system will do the job to stop something from internet and then you wait for zero day and then blame product owners.
1:28 I am at a loss I need help. I have nothing left. It's been 3 years, are there any resources that could help me? I can't even get a job. It's a living nightmare. Complete access and total control of my tech.
🤔nginx as proxy might kill the request after 30s or so but the server might still be computing in the background drawing resources - in that case it might be an interesting finding
Thanks for the video. I wanted to join the course and register my account but I see that the registration is disabled. I suspect that it will be reopened over time. Can you tell me please when I can register my account and join the course?
I'm curious to hear how a RCBH plays into preventing some of these DOS scenarios. Would that just be one of those Site-reliability engineer strategy that they'd have to decide whether its worth it or not based on frequency of that specific DOS method happening on their site?
Captcha is not a solution it an extra barrier for attackers. Services for automatically solving them exist and computers have become very good at solving them and beating humans so newer versions of captcha were developed. Even if a perfect captcha were made captcha solving services are just many times paying humans money to solve them for them, so captcha is a flawed solution. Think of it as a tool in your toolbox for DoS mitigation not a magical fix. Good security is build on layers not single magical bullets.
A important point: Most programs mention DOS reports are not eligible for bounty. So do read the policy before spending your time guys!
I've tried reporting a DoS to a company which literally just involves sending a request to their API with a deeply nested array as the request body, which wasn't accepted, making me all the more mad seeing these bogus reports getting accepted and receiving a bounty..
@Napert That's like a doctor making a patient sick so they take a vaccine. It's illegal and unethical.
@@Napert I must agree; Might be unethical but at the end of the day, you are helping them and yourself.
Don't encourage illegal actions, it sucks but if the company doesn't fix it then it's their loss
@Napert I think it's a fair option to tell them "if you think this isn't an issue, then clearly if I use this attack, you believe it won't cause a problem, right? So I'm gonna do that." and if they say "don't do that", you say "then it's a bug", and if they say "go ahead", then do it and bring the site down.
@@OhhCrapGuy Then you get a court order or banned from the platform for threatening a company
From personal experience, DoS vulnerabilities are usually addressed if and when they become an actual issue. There is no point in defending against theoretical scenarios, especially if they are rather contrived.
I've worked on react & node apps at large FinTech companies. I can't even count the number of hours wasted closing tickets that the security team created (from synk scanner) to address DDoS on packages that were only being used in the dev or CI pipeline. Not one was ever a legitimate threat of DoS.
There are instances though where theorectical vunerabilities highlighted by the OpenBSD team were shrugged off as unrealistic and paranoid by the Linux Kernel developers and a few years later these had to add it mitigation protection into the Kernel.
@@dave7244 Probably worth it
@@dave7244 There is a difference between DoS in the Linux kernel run by millions of computers, and proprietary software run by one business on a handful of servers through. Way different attack surface.
You are correct - a lot of organizations don't have a clear threat model to determine when an operational halt is warranted. The thing about security is the landscape is always changing and DevOps means code bases move fast. So security is always playing this reactionary game with numbers 1 to 10 (CVSS scores) as opposed to actually reviewing the threat and determining its actual validity in your environment. A lot of Security teams will push out a fix requirement to the Dev teams for every little DDoS mitigation their fancy AI-Powered Anti-Virus scanner points out. It's an incredibly reactive approach to security which ironically is a threat in itself (think about 0days). This is why it's so important to promote good security hygiene as part of everyones' role and involve security early in the Dev process. Right now - infosec is the compliance hall-monitor.
So what you're saying is instead of looking for bugs in code, look for bugs in the bug bounty programs
12:33 and 12:36 literally scared for a second, just thought that the background sound comes from my device.
It's up to the program's to adapt their policy. If DoS is in the policy, the bug hunter has no fault in reporting.
12:30 I thought there was in intruder in my house dude. scared the s out of me.
me too
Alex from TCM Security recommended this channel in one of his live streams, and he's right; the content here is excellent; thanks for sharing liveoverflow.
Wait, has LiveOverflow just found an exploit in the bounty system? Is this a vulnerability that should be fixed?
@liveoverflow I am a pentester and for me there is a distinction between DOS 'attack by single ip' and DDOS 'attack by multiple ips'. If I see that I can render the server unavailable for other users simply by using one machine I will report it as an issue. To me it is unacceptable since a single machine should not have the ability to affect other users of the platform. Especially when it comes paired with a function that sends email or a SQL store since there is absolutely no reason why a legitimate user would need to inject 5000 calendar items in 1 minute time for example. It's not about complete protection but its about putting up boundries.
Okay. So you limit users being able to only create 6 calendar entries per minute? One very 10s?
Now you get power users complaining about trying to quickly create 10 consequtive events in the calendar.
Okay let’s put it to 60 entries - one per second.
Now take 100 accounts to create 1 entry every second.
IP rate limited? Well now you block a large company from using your website.
Okay, let’s make it a feature of enterprise accounts to bypass IP rate limit. But great, now you defined an exception from where a DoS is allowed.
And actually, now it turns out the problem is not 5000 entries in one minute. The server crawls because 5000 events are set to the same time, and notification logic now is in a 5000 item loop sending notifications. So now you can still have a single account over 100 minutes to add these 5000 entries.
Ok we now need to ratelimit the notifications. Let’s actually combine them into a single notification, because they happen on the same time. Well that maybe doesn’t solve some server logic looping over the items. Oh, we managed to fix that with a nice efficient SQL query? Cool! But you entered 1000 participants to be invited that have to be notified. Is that too much, don’t allow that many invited participants?
What if a company tries to organize a huge conference and sends out an invite.
I could keep going and going. The circle of unfixable issues.
Actual realistic solution: don’t bother. Wait until you notice abuse. Ban the abuser. Try to add maybe some annoying things for the absuer. Move on until the next one happens. If in doubt, contact police due to cyber attack.
@@LiveOverflow Well, in this example the user is probably logged in, so per-account limiting might make more sense (edit: so the per-IP limit wouldn't need to be so low / exist). And in general, one can try to limit the impact of unauthenticated DOS to unauthenticated users, so logged-in users can keep minding their business, at least.
edit2: To combat mass account creation, wouldn't it be better to IP limit that instead of all the logged-in endpoints? If the service is paid, even that probably wouldn't be necessary.
@@LiveOverflow You make some fair points sir, Thank you for responding :D
Or, in short: The assumption of "1 IP === 1 machine === 1 user" is, and always has been, flawed. In the nineties, it was those big *nix machines with plenty of terminals, in the 00s companies centralised their outbound traffic behind proxy farms, in the 10s, it was DSL users who now had their whole home network for multiple people behind a NAT router, and nowadays it's ISP-level NAT for IP4.
And, BTW, if a single request can bring a service down, I wouldn't even call it a DOS. It's a bit sad that we use a single symptom as the name for a whole group of issues with different causes.
11:06 you're brushing off a legitimate report here. The report says that IPv6 rate limiting is not properly implemented, rate-limiting the single IP instead of the subnet. The IPv6 spec requires that each device can select its ip itself from a /64 subnet (at least). That is 2x the bit size of the whole ipv4 space, more IPs than you could ever use, making this way of IPv6 rate-limiting ineffective. IPv6 needs to be IP-Ratelimited/Banned differently from ipv4.
Yes I’m brushing off all of these “legitimate reports” as being unfixable. Of course the report is “valid” but there is no proper fix, the problems keep coming. That’s the whole point of the video. These “fixes” don’t really matter.
but then if you are on a shared network, then you can rate limit the everyone in the network. Shared networks may include workplaces, public wifi, school networks, and more.
You mean the SLAAC spec. Not all networks are SLAAC, but it is very useful that SLAAC exists, because every ISP gives out /64 or bigger.
@@acters124 So is the nature of IP-based rate-limits/bans; This has effectively always been the case with ipv4 as well. I'm not going to keep arguing because @LiveOverflow has clearly already made up his mind, but IMO this is more similar to trusting an X-Forwarded-For header than it is to using proxies. Code that was not designed to respect the intricacies of how IPv6 is generally implemented is put in an IPv6-Reachable deployment, causing IP-Ratelimiting to be literally fully bypassable without any proxies. It's just disappointing to see something like this put on the same level as reports such as the one in the start of the video, which seems to be simply incorrect (or at least was portrayed as such).
Are we talking about the same report? The weblate one? It does briefly mention IPv6, but it also mentiones many other things like “There are many botnets out there which can be used to overcome this hurdle, as well as cloud (VPS) services” and they specifically expect these fixes “No additional protection mechanism such as Captcha (pre-auth) or account lockout requiring additional email/phone verification (pre- or post-auth) were identified at any time.”
So characterizing it as a “ipv6 ratelimit bypss” report is a little bit stretching. But in the end, still doesn’t matter much
It's funny how these people say "there is money in hacking, it's easy", but then fail to mention that all that money is pretty much unreachable from people at the start. All the veterans claim it by running automatization bots. This is the same with web bug bounties. Unless you're advanced level, you really don't have a chance.
That's an interesting idea.
So, like the stock market? The little guys just lose, and big quant firms make all the moolah.
Thanks for this and your HospitalRun video; it is great to expose these issues that are potentially working against improving the state of infosec.
Bug Report: WTF is that voice at 12:33
you and Bimalpandey helped save my sanity. Pin this comment LiveOverflow
@@HopDodgeahhahah
Will The Circle Be Unbroken from Bioshock Infinite - scared the shit outta me ahhaha
Glad you mentioned threat models. One of the most annoying things that happens regularly in my job is we get messages that we need to "fix" CVEs related to third party dependencies. Normally we just end up patching the software even if there is no actual attack vector for the CVE to be relevant to our software because that's easier than analyzing and documenting why it is irrelevant. Same thing applies to most findings from penetration tests.
Interesting. I am one of those people who tell developers to update their dependencies. Can you go into further details about your perspective here? How would you go about fixing this issue?
@@Bluepaccao If you only use function 'a' in a library, and a vulnerability was found which only impacts function 'b', you aren't vulnerable.
Of course it's good to update when you can, because one day a developer might add code which uses function 'b'.
But if the new library update has some breaking api changes, and you're 100% certain you'll never use function b, it's not worth prioritising.
Ok, great that is what I thought. Thanks!
Do you know if there is anything else worth considering? @@amarkalibad2571
@@BluepaccaoNot sure what the right solution is. Because the fundamental problem is that it is easier/faster to do the update than to document the reasons why it is not necessary. Also as a developer if you give a risk assessment that says there is no vulnerability, then it kind of puts you in the line of fire if later there is a problem with that library.
I think most people just come to the conclusion: "let's do the unnecessary work, since it is easier."
The only solution I see is if the security responsible people have a more active role in the product and so have a better understanding of the software. My general experience is that non-coding technical roles have hidden productivity costs because of the impedance mismatch that creates. Which means any org I would create would try to avoid such roles. But at most companies that is a big ask. corporate culture likes specialists, even in situations where a bit of generalism would help a lot.
Just because your code doesn't use b doesn't prevent malicious code from acknowledging its existence.
Aren't most breaches due to chaining vuln's now?
Like 3 vuln's to obtain parameter manipulation chained into a de-referencing to arbitrary code execution then wrapped back in with parameter manipulation to have remote code execution.
You are right, having to explore your vulnerable packages to this degree to understand any attack chains like this are feasible would be more expensive than just patching the problems as they arise.
I thought it would be some normal video because of the title but being honest, this was one of the most informative video I've watched.
a video to impress laymen with no clue. max string length setting for the input form? problem fixed. Second problem is a self own/dev skill issue. Don't use sleep to rate limit.Limit user actions.
IMHO there's an additional factor that needs to be considered - in at least some cases it would be difficult to exclude these bogus DoS reports without also excluding important security flaws from a bug bounty program, and even if the fixes for these trivial attacks cost more than just buying some bandwidth that extra cost might still be worth it to a project in order to catch those actually sinister bugs.
One of my professors runs a company with a bug bounty program (ironically it is an automated fuzzing service). He told us about so many dumb submissions that were unfixable or not worth fixing.
I wish I can get a bounty for "I cracked your game and played it for a month, it was great. However, this is a vulnerability so please pay me."
They do give out bounties for that - police bounties
1. Keep up with the OWASP Top 10
2. Become "the security guy" at your company where everyone thinks they can outsource security to the framework and never have to think about it
3. ???
4. Profit
I think the tradeoff between "bandwidth needed to send a long password" and "time server needs to compute hash" can be modified to the attackers advantage by using compression. If compression is possible at the TLS layer (which it shouldn't be anyways, CRIME is a thing), this is very easy, but depending on the way the password is transfered to the server, you may be able to use HTTP compression.
I'm confused why compression wouldn't be available at the tls layer, almost all we traffic is compressed already
@@Diastolicflame There is the so-called CRIME attack which, under special circumstances, allows to recover secret plaintexts by injecting malicious plaintext into the data stream. The gist of the attack is that if the injected plaintext contains parts of the secret, the compression will change the length of the ciphertexts, which can be exploited. Therefore, most TLS servers and clients do not accept TLS layer compression.
Sleeping is a dumb solution for me , why not just check with a redis DB and just drop requests , why sleep and hang the process ?
That's how i would do it because i'am so used to writing non blocking code for Single core microcontrollers usually we avoid a blocking state at all cost to avoid "wasting" cycles.
Yeah.
If i was an attacker i would not wait minutes for my request to come back. Cancel and switch IP if possible.
Yes. IP range blocking and active monitoring are generally the way I do it.
Offtopic, could you make a video about SMT and Z3? It would be really great, its a large concept in SMT and I think it would be the right cup of tea for your channel
very interesting video, learned a lot about how people go about mitigating ddos
this is an actually great video! I subbed
Brute force is an attack on availability, so sleeping backends means that attack was successful, so request throttling by sleeping is not a fix to this attack.
I think bruteforce is an attack on confidentiality, because you try to figure out the password to get access to the confidential data.
Normally but not in this example, all the reports with regard to this video state, these bounties are about affecting availability with larger passwords and longer response times, emails sent, mentioned to bog down. No the intent with these bruteforce tests was not to discover the value of any password. Rewatch the video.
You said the term "brute force" and that is attack on confidentiality. The reports showed in this video are all "denial of service" reports, and those are an attack on availability.
Generally the only time brute force is mentioned in this video it is when we talk about the issue in the past that introduced the `sleep()` that caused the "denial of service" issue later.
@LiveOverflow you're contradicting yourself in the video when you say "now we have a ddos". Bruteforce cannot be an attack on confidentiality when there is no real expectation of breach and the original intent is ddos. The world isn't as neat as you picture it, and things like bruteforce can have multiple intentions.
The solution seems likely to be making a dos require too many resources to be successful.
Yes you gave a bunch of examples of how there is always still a way. But that doesnt change the fact you can optimize to make it harder to the point its not really worth it.
Where is that point? You will never reach it. Keep reporting bypasses or other weaknesses.
Where is that point? You will never reach it. Keep reporting bypasses or other weaknesses.
@@LiveOverflow Yes there is no clear point. You can progress some down that direction of making it harder for the attacker and then when it looks maybe probly decent you can pause your internal work and your bug bounty terms. And then possibly update in the future after things change like computing power.
You dont need an exact end goal to progress in a rough direction and then stop when you think its maybe a decent place to stop.
Approximation of a end goal is a decent "solution".
that is one of many reason why big company like google just deny login even when you have the correct account and correct password as long as you do not meet one or many of their additional Hidden request, like ip address from same city and same type of browser when you do not have the cookies...
I'm really shocked that the NextCloud team decided to add a sleep() into actual application code. And on top of that, an ever-growing sleep!? That's like a no-no and practically never a valid solution. For the login brute force, I'd do basic IP rate limiting and captcha prompt after X invalid attempts of User Y. This way, the worst that would happen with the real user Y is that they get shown a Captcha next time they log in (which is slightly annoying but not denial of service). IP rate limiting and captcha means that the attacker needs to spend some money to keep trying.
It's fixable: If you use async timers instead of sleeping with one thread per request, then your only real constraint is file descriptors. And if you start rejecting requests from the IP address before you reach the FD limit, then no single attacker can overwhelm your application. A DDoS is a different beast altogether and usually isn't something you can call a bug at all.
Unfortunatly, the solution you proposed does not actually 'fix' the issue. An attacker can always DoS a service if he can overpower the service provider, which can be made worse as usually server side will need more resource to process a single request compared to a client, even as simple as an plain old HTTP GET, no matter if the framework or code is async or not. DoS prevention is always an act of balancing between cost and benifit, and there is no 'fix'.
@@DWVoid0321 That's why that's a fix for the specific issue of the brute-force mitigation itself amplifying the attack. I'm not claiming that it's a fix for all possible single-source DoS attacks.
That said, you're also wrong about the HTTP request overhead being an issue. You shouldn't implement IP blocking at the application layer; you do it at the network layer so the firewall can reject the packets before doing any inspection of the contents.
And even then, HTTP requests are a largely symmetric cost. Without an amplification effect caused by code design that allows a single request to use up disproportionate resources, a flooding attack costs the attacker almost as much as it costs the victim. That's not something that can be classified as an exploit; that's just how network traffic works.
"There are no solutions, only trade-offs."
-Dr. Thomas Sowell
Superb """rant""" ! I love these "why?"s more than the "how?"s .
If you want to farm money from Dos bounties do not do that on Open Source projects please, those are already mostly underpaid projects that survives through kindness of the maintainers that put their own time and money in it.
Problems..
> directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running.
I'm not sure if password hashing is also classified as system call, but there are many ways you setting max request time isn't silver bullet
also timeouts on nginx will kill request to client, but on php-fpm side request will still be executed taking up worker slots
That's why maybe many websites dont accept DOS for bug bounty programs
Brute force attacks can be mitigated rather easily:
Proof of Work with increasing complexity - easy for server to verify, expensive for attacker to scale attack
you can make it global, so if there is any attack on your server users might in extreme cases wait extra 10s for password reset/login but that's it
In that scenario, it’s just easier to scam your cell provider into sim swapping you.
So just send a POST request with the data from my weekly time card in the body of the request?
Obviously the solution is to add a captcha to vulnerable API. So that DDOS and brute forcing are no longer an issue, and DOS has to be clever and use few requests because each one has to have a captcha solved /s ( but actually an interesting way to frame the problem ). In a way the rate limiting is a captcha because no human would reasonably send that many requests.
Captchas are no longer a valid DoS mitigation in times where AI Bots are more likely to solve them (and in a shorter amount of time) than humans. There is a recent study stating this iirc.
@@propella2935 AI Bots are expensive. In the end, it loops back to math and cost of the attacker vs defender.
Don't forget those rate limiting techniques can also be combined altogether.. (by IP+by user)
I think the problem with browser password managers, at least at the time when I was aware they were a concern, is that they were not encrypted in any way. A malicious program could simply steal passwords without having any form of key that unlocked those passwords, and you didn't need to be a privileged user to perform this, it could be anything, even a minecraft mod. Any form of on disk password manager should have some form of encryption, but chromium refused to implement encryption for some time. I don't have the exact bug report on me but I recall it being an issue.
Yes this, from my understanding if you wanted your malware to grab passwords from something like Bitwarden not only would you have to open the Bitwarden app but also wait for the user to click the copy password button at which point the password is decrypted and put into the clipboard. Not sure we can fairly compare browser password storage with a proper password manager
As soon as I figure out how to do it, I'll make my self-built login page on my website prevent new logins for a set amount of time if a set amount of failed login attempts has occurred within a set timeframe. It will accept requests from users who are already logged in but not allow them to log in again before the lock releases.
The random woman singing spooked me out :X
You seem to have missed a point that it's Sleep that's a problem, not rate-limiting per-se. Don't tie up all your servicing threads with Sleep! Instead, put it into a time queue and return to service other requests.
I wonder if having a ton of garbage tasks in a queue might also slow down legitimate requests. Though I guess it depends on how the waiting in queue is implemented. Putting sleeping tasks in a heap (since there is a clearly quantifiable measure to how long it will take) and occasionally checking if top one has finished sleeping is how I would do it
PS using a thread pool with task queues instead of thread per user is a great rule of thumb to have IMO (especially when it's already built into framework used for a server)
@@aleksandertrubin4869 I have actually written a Command queue for several platforms. The data structure is called a Priority Queue, and you key it by wake-up time. It efficiently keeps the next job at the top, without having to constant sort or search. When a worker thread finishes, it checks the timer queue's top against the current time first, then the highest priority work queue, for what to do next. HTTP requests are queued on a work queue -- not a thread being queued, but the Command.
(continued) anyway, the command on the timer queue isn't the Login request; rather, that's a nested Command object and _this_ command says to put the enclosed command on the work queue of low priority.
That way the repeated login attempts don't act as high priority and choke the system. When the time is up they go into a FIFO that is lower priority than the normal server Request.
In many server deployments all IP addresses are the IP of the ingress/loadbalancer/… so the denial of service rate limiting likely hits the normal users as much as the attacker. It might not show up in your dev test machine, but in cloud/Kubernetes/.. the code stops doing what it is expected to do.
Dr. Adam Back published the solution for DoS attacks decades ago. Nobody uses it because reasons.
Can you deepdive on other problems like this? I really enjoyed this one
You can combine it with transport compression. But still strange, use a fast hash for the first pass.
Well can you make a video on what to do with these security issues and how companies can avoid and identify these type of issues that are unfixable.
Sleep is a crazy method of spam protection. IMO account and IP limiting should be moved to a CDN where you have no concerns with sending back millions of 400 responses. I don’t think it’s solvable on the real application backend
Ideally your application can instruct the CDN what to do, otherwise the CDN also can only guess whats acceptable behaviour of visitors in certain situations.
12:34 there's a woman in my ear
So is it possible to prevent this brute-forcing by implementing 2FA(multiple factor authentication) ?
You definitely wont get rich. Most the people I know that do this do it as a hobby and they are constantly getting shafted by companies. After all the work you put in, wait to get paid, sue the bad actors, its basically pizza money. You misunderstand bug bounties as real security, they are marketing campaigns.
DoS is a symptom not a cause.
If the cause of the DoS is due to a design flaw or code flaw then, generally, that is a considered a security vulnerability.
If the cause of the DoS is due to a lack of capacity or resources then, generally, that is not considered a security vulnerability.
The important distinction is when the former is the cause and the latter is the symptom... versus the latter being the cause and the symptom being former.
Cause and effect, it's really not that hard.. so not hard that in my 15+ years i've never come across anyone raising this a philosophical conundrum like you have... it's just like say manufacturing a physical product, it's not really a conundrum figuring out what is or isn't considered a defect and when a recall is warranted...
If i throw a newly bought coffee mug on the floor and it breaks, that's not a defect.
If however on the first morning i go to take a sip from it, the handle falls off, it drops on the floor and breaks due to a non-heat reeistent glue being used to attach the handle, that's a defect.
Same outcome, there's a broken mug on my floor, but it's whether that is the result of a flaw (the glue) or a flaw is the result (throwing it)
At the end of the day, when all else fails, "it's a feature not a bug"
To play devil's advocate, I'm not entirely sure your analogy works on the field of cybersecurity since that's very often about protecting against malicious attackers (i.e. throwing the mug on the floor), not just innocent users (i.e. the mug's handle coming off during normal use).
tbh your analogy doesn't make sense
It works, your mindset is wrong.
Most ppl won't actually experience first-hand a DoS caused by an attacker in their careers, they will however almost certainly experience a situation where a fault or bug has inadvertently caused one.
Most people don't throw mugs on the ground during their lives, it's much more likely you inadvertently drop one.
It's not the most perfect analogy, it was the first thing that popped into my mind. Sheesh :)
I'm getting too old for this 😂
@@sirtra Alright, but we're not talking about bugs, we're doing about security vulnerabilities, i.e. bugs triggered by an attacker. In cybersecurity, our sole concern is protecting against people throwing mugs at the floor. It doesn't matter if security bugs are less common than non-security bugs, because this video is about security bugs. The defects this video cares about are the ones that allow people to throw mugs at the floor
@@GrantGryczan throwing a mug on the ground and it breaking is not a bug, it's performing as designed and the outcome is expected - there is no fix as it's not something that needs to be fixed (well i guess if we want to get pedantic one could argue that you could make a mug to withstand being thrown on the ground, but that doesn't equate to a mug that does being insecure or a vulnerability.
My point is on the premise that this is a grey area and confusing to know what is or is not a security flaw/vulnerability/exploit.
It's not, or well shouldn't be for anyone in the industry with experience with high availability/scalability systems.
Being able to steal and drive away in someone else's Hyundai armed with nothing more than a screwdriver or USB plug is a security flaw (i assume you are aware of this trend for reference - it's an issue unique to certain Hyundai's and i think Kia's too)
Being able to steal and drive away in someone else's Ferrari armed with nothing more than a screwdriver BUT only after threatening the owner and them handing over the keys is NOT a security flaw.
Personally i think this video starts really strong, digging into what actually happened and replicating the issue is top notch... but to then end it along the lines of well it's a grey area and unclear what is or isn't a vulnerability is doing the audience a disservice.
But maybe it's just me, when you've been in the game as long as i have sometimes things you think are obvious aren't to a novice.. one could also make the claim of "well what would you know" and that's a valid point which i can only respond with "peer review". I'm not aware of anyone else with experience having difficulty determining the difference, just like it should be obvious to anyone working in automobile security which scenario above is or isn't a vulnerability.
Hi, I usually implement a cache layer to address these kind of issues, so for the same payload I can take the response from the cache instead of exhausting my backend resources, for unpredictable payloads such as images, presigned urls are the call.
Complex locks keep the honest thieves out.
But for example, when having the user account ratelimiting. Isnt it possible to force the user to unlock their account to change the name? I mean its not a beautiful solution but it would stop any bruteforces because the old attacked username no longer exists? Maybe im just wrong and overseeing something but in my opinion this should "fix" the issue
9:20 - fix[1] for sleepDelay is fairly simple - just move that to greenlets (or whatever similar technology) - essentially async sleep that won't block worker from performing more requests from other users until sleep ends.
[1] of course, this will work until end of resources of server (like threads limit), but that's moving problem far, far, FAR away from it's current state. Can't believe such basic mistake was make with this sleep here to be honest and noone even noticed that it blocks whole worker.
So if password hashing with the most time-intensive, usable dedicated password hash function, Argon2, is practically unaffected by password length . . . WHY DOES MY UNIVERSITY HAVE A 15 CHARACTER MAX PASSWORD LENGTH?!
Couldn't you abuse gzip compression to send a ridicolous long passwords to Django even with a bad internet connection?
I'd implement making guessing logins awkward by first rate limiting by default to something like 3 seconds (the time it takes for someone to read an unsuccessful login attempt and enter the details again), then followed by having to enter the correct password twice (without any notification of having to) after too many tries. A human that knows the password will probably think they've entered it incorrectly or there is just a glitch if using a password manager, but an automated guesser won't know, and skip over the correct password without realising, if they can be bothered trying only 1 guess every 3 seconds in the first place.
Not the best idea because often someone forgets their password and tries a number of different ones, and they may pass over the correct one the same as a brute force script would
@@GrantGryczan Maybe not the best idea, but someone that knows the password is likely to try the same (hopefully correct) one multiple times. If you can't remember it, you usually just use the forgotten password system. I could swear one of the services that I use implements something similar. There have been times I swore I got the password correct, but got given the wrong username/password message forcing the use of the forgotten password system (and a lockout of 30 minutes).
@@threeMetreJim Yes, but likely isn't good enough. It needs to be sufficiently _unlikely_ that they _won't,_ which isn't the case. It happens all the time; I've seen friends and family members do it (even though I constantly advise them to use a password manager like Bitwarden lol). It usually ends in either giving up and not signing in, or in the event they really need to do what they're signing in for, requesting a password reset.
@@GrantGryczan You are probably right. Trying to confound an attacker while also not making it too awkward for a legitimate user seems to be a fine balancing act. I was thinking along the lines of short lockout times based on the likely number of times a legitimate user would make an attempt compared to automated attempts, aiming for the most frustrating timing for an attacker, linked to a short enough lockout so that the legitimate user would likely not notice after the attack was abandoned. The attack would need to be in progress for you to be locked out and notice - may be where the 30 minute lockout of that service I use comes from - there must be some optimal timing and I was thinking 'relatively short'.
@@threeMetreJim Yup, security is definitely at odds with convenience.
I have found that client side KDF + server side hash is pretty good bruteforce prevention
Looks like services nowadays protects from DoS just by removing all features with heavy requests 🙁
That's why rate limit by IP is bad idea. Bruteforce is agains pair login+password usually, so rate limit should happen against login if too many different password attempts. And yes, it will lock user's account.
Could you go into the difference between "information security" and "cyber security"? I think that may be different
Well I don't know if you can report the same issue over and over, but if you can then is like they say, the problem is between the keyboard and the chair.
Some programs make DoS and Rate limiting as out of scope unless escalated (e.g. no rate limit in password reset code)
the bug is not in each individual web service. the bug is in client-server topology.
Yes. Abolish servers and make everything Cloudflare. That's the only solution. Cloudflare should be the whole internet.
I just bypassed Steam's payment window PSD2/SCA, random clown closes ticket on the bug bountry site due to it "requiring a physical user device"..... well its actually the opposite.... ticket stayed close. Issue still exist. Free games forever.
Ticket or it didn't happen.
It would be great if you could make a deepdive video for network sockets, like you did with servers.
Basically, you are preventing DDoS issue, by implementing sleep function, which is same as unresponsive server, as it is sleeping but it is just for a single IP, which is sending lot of requests. Well, to prevent that issue they are locking / rate limiting on user accounts, which again can become issue as well. So why can we just verify whether the user is sending request from a trusted User-Agent. Hence, block any other requests which are made through untrusted User Agent??
Great Video!
Thanks for this video! Very interesting
I mean you could demand that users solve a Hashcash-like challenge as a rate limit. As you have said the solution is more math. Make it expensive to generate valid requests.
How does github limiting the length of a password mean that it's not a vulnerability?
If you can enter a long pw to slow down the server to the point of can be considered DoS, that's an issue. It might not be the issue of a long pw but the "hacker" technically sees a blackbox and is not paid to find the solution or the exact thing that's wrong in a complicated tool stack.
I kick the door, I get in. That's vulnerability. I don't care if it's the lock or the wood or the doorframe that breaks.
Limiting the length means you can't enter a long password to use up server resources that leads to DOS. So limiting the length means no vulnerability due to long passwords.
Imo DoS are not issues at all, when the software is expected to process a large amount of data it's obvious that more data is equal to more processing time. Different thing is when your **small** input can crash the server due to validation issues in that's case it's a security concern
Id say a DoS is a vulnerability if it gives you unreasonably high leverage. Like, you can't complain that Ur pizza place starts up a car or grabs a bicycle if you order a pizza to your place, but if they charter a fucking lear jet to do it, their process is flawed.
2:37 is this why cookiews are generally always the same size?
17:10 Security of password manager can be improved by running it at higher privilege or with technologies like intel sgx enclave or trustzone. Such models works better for private key challenge based auth or encryption keys than for passwords which leaves 'secure world' to unprivileged clients. Bypassing that can be a vuln but there is a space for debate if lack of any theoretical security improvement is a security issue.
then you copy the password into the form of a website in a browser running under normal privileges.
don't get me wrong, I'm a huge fan of password managers. but a browser PW manager already gives a lot of benefits against the BIGGEST issue we have, and that is credential re-use. I prefer my non-technical parents just safe it in browser, than nowhere.
Why just they can't simply put a captcha it's slow down the brute force or use adding multiple mitigation like captcha + IP based rate limit .
4:54 Important DOS attack vector for sending extremely long passwords: it likely does not matter what the content of the string actually is, as long as it's sufficiently long.
How does this help us/cause issues? If the server accepts gzip compressed POST data, that will allow the attacker to craft a very small compressed password that decompresses to potentially gigabytes.
If you're not sure how gzip could do that, it's (basically) a steam of data and instructions, and one of those instructions could be (basically) "start from this byte and start copying the data stream for the next 10,000,000,000 bytes", so you start with a single byte, like 0x20, and then tell it to copy the datastream starting at 0 and going for N bytes. How does that work if there's only one byte to start with? When it gets to the second byte, thats after it already copied the first byte to the second byte, ad infinitum.
Basically, a server accepting GZIP post data is often, in itself, a DOS attack vector bug. Keep a look out for that.
This is gonna do numbers. Hi hacker news!
9:00 kinda reminds me of the slow loris dos
A bad php implementation would still be vulnerable, but usually noone really uses them anymore.
So you cant lock up a thread, because its actually async and the thread simply does some other work while waiting for your sleep to time out.
All programs in Intigriti don't accept any type of DOS.
We have brute force protection in our platform but we don't sleep the request, we just immediately respond with 429 Too Many Requests.
GOOD Idea! What do you think of the Zero Day Project/Initiative that is very hard coding exploits? Stuff like ''Guest to Host Escape'' tactics. Never heard of such a advanced issues.
I think you need to inherit security budget of your country and implement same in your organization if you are doing business in that region of globe. This fixes most. Unfortunately defense in depth and layered security controls licensing are expensive and maintenance cost has great dependency on human intelligence or skill set.
Typically perimeter level next gen firewalls + load balancer + WAF + Endpoint Protection + postgre SQL + latest endpoint system will do the job to stop something from internet and then you wait for zero day and then blame product owners.
Implementing wafs is the fix in my opinion against rate limiting issues
IP rotation?
@@adityasingh-ov8ft no, Cloudflare firewall will take care
Loved the bioshock joke!
1:28 I am at a loss I need help. I have nothing left. It's been 3 years, are there any resources that could help me? I can't even get a job. It's a living nightmare. Complete access and total control of my tech.
tthank you for the video 🎉
🤔nginx as proxy might kill the request after 30s or so but the server might still be computing in the background drawing resources - in that case it might be an interesting finding
Thanks for the video. I wanted to join the course and register my account but I see that the registration is disabled. I suspect that it will be reopened over time. Can you tell me please when I can register my account and join the course?
I'm curious to hear how a RCBH plays into preventing some of these DOS scenarios. Would that just be one of those Site-reliability engineer strategy that they'd have to decide whether its worth it or not based on frequency of that specific DOS method happening on their site?
Doesn't password hashing happen on the client device?
Can't we use recaptcha after certain number of requests..
ty mate
Why doesn't implementing captcha solve the issue
Captcha is not a solution it an extra barrier for attackers. Services for automatically solving them exist and computers have become very good at solving them and beating humans so newer versions of captcha were developed. Even if a perfect captcha were made captcha solving services are just many times paying humans money to solve them for them, so captcha is a flawed solution. Think of it as a tool in your toolbox for DoS mitigation not a magical fix. Good security is build on layers not single magical bullets.
easy money
A WAF does a decent job vs. DOS attacks by limiting or outright blocking IPs.
Assuming that is not your bottleneck. In many cases its not.