​@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

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.

me too

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.

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

That's an interesting idea.

So, like the stock market? The little guys just lose, and big quant firms make all the moolah.

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

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.

They do give out bounties for that - police bounties

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.

Yeah. If i was an attacker i would not wait minutes for my request to come back. Cancel and switch IP if possible.

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.

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".

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.

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?

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.

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

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.

Dr. Adam Back published the solution for DoS attacks decades ago. Nobody uses it because reasons.

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.

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.

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.

Yes. Abolish servers and make everything Cloudflare. That's the only solution. Cloudflare should be the whole internet.

Ticket or it didn't happen.

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.

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.

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.

IP rotation?

@@adityasingh-ov8ft no, Cloudflare firewall will take care

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.

Assuming that is not your bottleneck. In many cases its not.