Understand Security Risk vs. Security Vulnerability!

[@emblemi6345]

Bounty hunter: I found your code is written in C company: Thanks, that was a security risk

[@freemail1774]

Its like when others report this type of bug vs me reporting account takeover (* gets rejected )

[@VivekYadav-ds8oz]

Thanks, now you need to give me a proof-of-concept in Rust to get a payment *laughs in evil because he'll not be back for atleast 2 months*

[@juliankwiatkowski1441]

How is code written in C a security risk?

[@emblemi6345]

@@juliankwiatkowski1441 heard about memory (un)safety?

[@john.dough.]

It's not a bug, it's a feature!

[@michellamberg3230]

"you used a feature on our website, YOU owe us!"

[@charlottenburg]

True XD

[@RoiEXLab]

Regarding the ssh auth: I think a more realistic use case is when you have multiple users and you don't trust them to all create a secure password. In this case key auth is better than any secure password policy

[@VivekYadav-ds8oz]

The real reason why key auth is better is because the application chooses a randomised key for you. Had the application required you to type in a key, in fact it would be even worse as keys are longer, so people would be more likely to slack off and choose 0x0000.. or 0xFFF.. or 0xABCDEF123456890ABC... . The real thing to solve here is to have the application set a randomised password on user's behalf and only report the randomised password to it, not giving him/her the privilege to change it.

[@soryuushi]

It’s definitely a defense-in-depth thing. If you have a security program at a company, mandating SSH keys (which can be checked automatically and easily) is much easier than requiring secure passwords. If a human is going to make a mistake, is it going to be leaking the key, or is it going to be using a weak password, reusing a password from a different system, or accidentally pasting it into the wrong form and getting phished? A bug bounty participant has absolutely no way to know by interrogating the system what kind of internal policies or procedures are in place, and therefore, it’s always kinda up in the air. There are different risks with PKI to consider too, so it’s not always binary. What if someone is transporting their private key unsecured on a flash drive because they use multiple secure systems, when they could just use a strong passphrase? What if the PKI is just too complex or unfamiliar, and someone makes a bad decision setting it up because of lack of familiarity? What if the key is lost?

[@rogervanbommel1086]

@@VivekYadav-ds8oz I totally agree, and also(but not at all security related) way easier to use

[@semitangent]

3:55 - "so you type `useradd`" (types `adduser`) - the "which way does the USB connector go?" of the command line :)

[@overlisted]

one of them is a standard unix command and the other is an utility preinstalled in distros

[@znxster]

They are actually different and there is a reason for using one or the other. adduser is a "high" level method of adding users, it has presets in /etc/login.defs which it uses to determine answers. useradd is "low" level, requiring you to provide all the information. For instance, useradd would not make a home directory unless you specified the requirement.

[@TheGrimravager]

yeah and it gets even more confusing when you alternate a lot between writing Dockerfiles for alpine containers and debian-slim containers :p

[@soryuushi]

Unlike a USB-A drive, I have to worry about the consequences of getting it wrong (which I will always do the first time I try to do it).

[@MCTTABOB]

lesson is: dont report open redirects until you have something to chain them with

[@Tsunakumura]

Understanding RISC requires even more knowledge about how computers work

[@kebien6020]

I see what you did there

[@userou-ig1ze]

@@kebien6020 explain xD

[@_Jayonics]

@@userou-ig1ze reduced instruction set computing, like an arm CPU.

[@userou-ig1ze]

@@_Jayonics why would a reduced instruction set require more knowledge? xD

[@manjoos4906]

@@userou-ig1ze 5:52

[@thecommenter4933]

For any practitioners out there who are still confused, security risk is a way to measure your overall exposure to some sort of security event or circumstance. It's most commonly a function of likelihood the event will materialize and, if it does, what the impact will be. How orgs do this varies quite a bit, and how elaborate you get depends. A good risk analysis weighs a combination of everything from which vulns exist that could be used to materialize the risk event, who your adversaries are, etc. Check out NIST 800-30 for an overview of the basic risk concepts. Vulnerabilities on the other hand are weaknesses (technical, procedural, human, or otherwise) that could be exploited. Putting it all together, one risk a healthcare org might have is compromise of an RDS instance containing patient health information. When assessing the risk, you'd take into account what data are stored there, what the response cost would be, what the loss of reputation in your industry would be, breach notification costs, etc. You'd also weight that against any vulnerabilities. For example, one vulnerability might be that the RDS instance is open to the public internet. In this case, the vulnerability would shift your likelihood calculations; if the RDS instance is exposed like that, it's very likely to be identified and targeted. In most real world applications though, risk is not assessed just based on how likely an adversary is to be successful. Our risk models, for example, account for everything from what would be exposed, how we'd have to respond, how regulators would get involved, etc.

[@juanpabloamorochod.752]

"For any practitioners out there who are still confused ...". Yeah, I´m more confused about the difference after watched the video. How do these two relate to bug bounties? No idea.

[@coder_rc]

"I'm luckily not into bug bounties" I felt it 😂

[@wannabe1337]

Ha ha ha 😂

[@prazolbista]

they way he said "I'm luckily not into bug bounties" explains everything 😂

[@idanba3482]

I manage the Bug Bounty program in the company I work for. Our rule of thumb as to if something is valid as for bounty or not is whether the reported issue will lead to us fixing the issue or not. If it will lead us to fixing the issue, its a valid for bounty. It doesn’t really matter if its a vulnerability or a risk. If its risk its sometimes harder to get R&D onboard to fix/prioritize the issue, but that’s another problem

[@LiveOverflow]

What about functional bugs. Like an exception in the client. Will I get paid for reporting that?

[@idanba3482]

@@LiveOverflow Only if the exception contains sensitive data, otherwise I don’t see why that would be a security issue.

[@LiveOverflow]

And open redirects are not a vulnerability either. So why would you pay for that one? 🙃

[@idanba3482]

@@LiveOverflow we do consider open redirects to be a vulnerability, mainly due to the phishing potential. Same goes for stuff like reverse tab nabbing. Our goal is reduce the risk for our customers as much as possible. We are less worried about the semantics of risks vs vulns. Another important factor that comes into place from our perspective is making the bb program appealing, if we narrow the scope too much we won’t see a lot of traffic in the program.

[@LiveOverflow]

There is no phishing potential. That argument is so bad. Don’t teach people to look at links. So many websites or emails can fake links. It makes no sense. Just teach people to look at the URL in the browser URL bar.

[@logiciananimal]

I always regard open redirects as a pretty minor vulnerability if at all, and certainly agree that it is usually just a case of "makes other things worse". But I do think it makes sense to also use them as a warning - more than a canary but a reason to look for more.

[@woodenwaste]

Let me add real borderline example. Putting a corp Domain Controller on the public internet, RDP accessible, no other mitigations. Clearly a risk but not a vulnerability. As of today* there are no public vulnerabilities in RDP that would allow takeover. If all your passwords are strong you should be fine. However in terms of "real security", this will get you hacked. Either 1) someone in the company will have a weak/reused password or 2) a vulnerability will be discovered in RDP and you will have literally minutes to patch before it is exploited. This is a risk so severe I no longer care if there is a distinction between risk and vulnerability. Also, thanks for the video. It helped me get my mental models of risk/vuln clearer.

[@alonzy989]

... Bluekeep?

[@daviddelille1443]

Interesting distinction. Perhaps a better example would be: SQLi is a vulnerability, not having a WAF is a risk.

[@JuanCarlos-ro3kn]

Not necessarily, WAF is a control, not having a control is not a risk. In order to identify a risk you have first to identify a vulnerability, a threat, an asset and the impact this threat could cause to the asset, if you lack one of these 4 components you do not have a risk. Surely you could have a vulnerability in a system but not necessarily a risk.

[@silva_andrre]

Great view, I think that nowadays a huge challenge is to look at a context and get the risk at all and not a piece isolated (vulnerability), the impact is more important than the vuln. About the bounties… it’s complicated when the result of your job is (sometimes) subjective…

[@Invisible12345ful]

The point is that not every vulnerability is a security risk. Just like you don't invest in a 15'000$ door lock in your house where you keep things that in total may be worthy of 500$, there is just no significant risk in that.

[@deadmanzclanleader]

3:43 this has actually happened to me. "test" as a password. Got myself a crypto miner and then decided to never leave pw auth on because I can't trust myself to always think about that risk when making a purely-for-research user on a development box.

[@peterhindes56]

Just make pass login a whitelist

[@gabiold]

And this is why I consider the sudo approach a security risk! If someone want to do administrative tasks, then log in as root. The default approach in Ununtu (-like) distros is use sudo. If you add your non-privileged username to the sudo group, you practically have two root accounts, one with precious care, and very little care for the other.

[@tobiashammer17]

Can recommend setting AllowUsers as one of the first things after enabling ssh server

[@sygo]

interesting, at my university we definitely learnt to consider security by risk rather than absolute vulnerabilities, now I understand why I disagreed with your server hardening video so much!

[@dr.humorous447]

Simple answer: A vulnerability is a security bug that allows a potential attacker to gain access to a system. Complicated answer: A vulnerability is caused by a logical error that requires a certain mindset to fully understand the security bug. The most common and yet most dangerous is a vulnerability that allows for (arbitrary code execution) things that allow this can vary between programming languages in C language you have bugs that allow ACE by buffer overflow, dangling pointers and etc... these vulnerabilities are classified as memory violations. There are also input vulns if not sanitized correctly that allow for injection attacks like code injection, XSS, format strings and etc... Conclusion: a vuln is common sense imagine if you were under attack by a man but you have not fighting skill everything has a weak point the eyes, groin, joints and etc... computers are the same just find the function that allows for ACE or input errors and I recommend looking up vulnerable functions in the programing language you work with and try to understand it at the logical level. Hint computers are dumb they need the users input just to function so if you want to discover a vuln just think like a computer on how it executes functions at the literal sense. Good luck and have fun bug hunting

[@wouterr6063]

Too, that conclusion was super smooth!

[@rafinrahmanchy]

Vulnerability = Security weakness(es) that could be exploited by any threat actor, e.g. lack of rate-limit in OTP form, improper input validation, failure to invalidate session after logout, etc. Threat = An entity or situation which took advantage of exploitable vulnerability intentionally/unintentionally to produce risk, e.g. Hacker, Malware, Natural disasters, Non-vigilant employee, etc. Risk = Potential damage or impact if attacker successfully exploit the vulnerability to compromise the system, e.g. reputation loss, data breach, identity theft, etc. Risk = Threat * Vulnerability

[@shivam.kumar.the.boy.]

Love these verses videos. Keep them coming. 🤝👨‍💻

[@ThomasOrlita]

There was an open redirect used as a part of a chain in one of Google's desktop apps that ran on Electron, which lead to the window loading a user-controlled URL and (likely because of security features that were disabled by default) it could use `require`, i.e. leading to an RCE.

[@InfiniteQuest86]

Exactly. All these "non-vulnerabilities" can still be use to access your system. It makes no sense not to pay someone to find them and fix them.

[@mthf5839]

I have a slightly different viewpoint: on a server where creation of accounts with weak password could be expected, ssh password login is a vulnerability.

[@cryptonative]

Love this security absolutism thingy!

[@arivanhouten6343]

Finally another masterpiece!

[@lilp4p1]

this new style of video is really cool 👍👍

[@DynoosHD]

A improvement tipp for your lightning: Put a rim light behind you.

[@cadeathtv]

People are reporting things, but couldn't exploit but asking for $$. However, all vulnerabilities are security risk and risk can be answered by accept, mitigate, avoid, or transfered. If vuln are found to be exploitable, they should be paying depending on the impact x asset value.

[@markgacoka9704]

I have watched you for so long that you feel like family lol.

[@wrng-i9f]

Sehr gutes Video :)

[@hellfishii]

what an insightful video, love it

[@Demonslay335]

It's like having a shitty lock on my front door is a vulnerability, whereas leaving it unlocked anyways is a risk. However, change that context to be an interior door, and it's no longer either because it doesn't matter for the general use case.

[@wannabe1337]

Vuln is in the lock while your home is at risk. And if it the door is interior, still there are risk, I will break into your home by cutting off your door 😂😅

[@Marenthyu]

Nice vid!

[@ceilingfun2182]

Don’t use password instead use authentication key.

[@tanmay______]

Looks like we’re early

[@larryslobster7881]

Yeah i guess

[@TheJobCompany]

I mean I guess technically.. yeah

[@GigaBoost]

Holy shit, this guy does videos with cameras nowadays huh

[@Belioyt]

Huh? How are videos done if not with cameras?

[@GigaBoost]

@@Belioyt all the videos I've ever seen on this channel before were just screen captures and animations, no recorded video with a camera (no "live action", if you will).

[@wrng-i9f]

Yep, i think his videos are way better now.

[@du42bz]

@@GigaBoost What ? Literally just look at one of the most recent videos and you will find plenty of videos in which they record video using a camera

[@GigaBoost]

@@du42bz I've not watched this channel for quite a while so it was a big surprise to me!

[@Rea892]

Like always, genius 😎

[@zZAnubisZz]

@LiveOverflow A great explanation. another commonly use terms but understanding and definition is subjective in bug bounty / VR is "exploitable vulnerability" and "non-exploitable vulnerability". Would love to hear your thoughts on this. Some people label exploitable vulnerability that is having exploit that immediately compromise system or gain system access. While some people label it as having a way exploiting vulnerability even when does not immediate compromise system Just a suggestion of examples that draw lines between the definition. Web example would be "information disclosure vulnerability that leaks username which can further allows user enumeration." Another example in the case of exploitable and non-exploitable vulnerability situation would be in binary vulnerability. As this might be sightly different definition from web example.

[@LiveOverflow]

"user enumeration" or "leak usernames" are another great example where I think in most cases it's not a vulnerability. There are certainly some applications where it is an issue, but I think for many it's not.

[@zZAnubisZz]

@@LiveOverflow icic..so it is like risk rather than vulnerability. Thanks for the clarification. what about ur stand and definition of exploitable vulnerability and non-exploitable vulnerability?

[@LiveOverflow]

“Non exploitable vulnerability” sounds like a contradiction in itself. So not sure :S

[@zZAnubisZz]

@@LiveOverflow haha..ya..it does seems like a contradiction for non-exploitable vulnerability. Thank u for your response and time to read our comments and questions.

[@GeorgeHafiz]

This is almost a semantics thing. The configuration or software behaviour being described might make the system more vulnerable to compromise (or some other interpretation of malicious activity), in combination with other configurations or behaviours, but not facilitate that on its own. I think in this video you’ve tried to differentiate between these two by calling one thing a risk and the other a vulnerability. But in reality and by this definition, you could have two issues you’d refer to both independently as risks, but which combined represents a vulnerability. This applies even in your example of ssh + weak password. A weak local user password is only a risk, if you can argue the only possible user of the machine is yourself and you have root privileges. Hence I would suggest that actually the weak password was not a vulnerability in itself, in the use case mentioned, because it was only a security concern when combined with ssh password auth being enabled and the host being internet exposed. So I think actually the point is, it’s only easy to call something a vulnerability if you can demonstrate that the risks or combination of risks resulted in unwanted activity taking place, and that’s why you might not get paid for such reports of risks. This is kind of unfortunate, because if you fail to encourage researchers to identify all your risks, you might not know that there are less reputable individuals out there taking advantage of that risk in combination with another that you’re yet to be made aware of.

[@villandoom]

Yeah that's a way for companies to get away with not paying bounties a company did that to me but not in that way. They just said I was gonna be arrested if I asked for the bounty they promised

[@InfiniteQuest86]

Terrible. Don't have a bounty program if you aren't going to pay.

[@villandoom]

@@InfiniteQuest86 they had a unofficial official bounty. A developer set up its own bounty program. It made me belive it was officla tho it wasnt

[@rootz4912]

Awesome one

[@FedoraRose]

Thanks 😁

[@wannabe1337]

After watching this, I perceived the Risk as something that may or may not lead to an insecure system depending upon the cases scenario; while the Vulnerability, if it is exploitable, it can be exploited in each cases. Does it right ? Or is my understanding not clear yet ?

[@sithnazguls325]

to cite the CISSP traning book: "Risk: is the POSSIBILITY of damage or Harm and the likelihood of damage or harm will be realized" you are close yes... (note that harm and damage is a relative term to whomever or whatever is desired to be "secured"

[@AnPham-uz3td]

Perfect video doesn't exi.... oh wait

[@0xf172]

lol this happend to me with youtube , injection xss

[@sahilabbasi7184]

I reported to the PicsArt but it was closed my report as not applicable and after some times fixed the vulnerability in their latest version in the playstore 🤬🤬🤬🤬😡😡😠😠

[@interseba5456]

Why don't you call weakness a security risk? CWE exists exactly for this

[@LiveOverflow]

uhm no clue. I do not know CWE™ and other weird industry things

[@JuanCarlos-ro3kn]

Because a vulnerability/weakness is just one component of a risk. In order to identify a risk you have yo identify an Asset, a threat, a vulnerability and an impact in terms of C,I, A. If you do not have one (or more) of these 4 components you can't say you have a risk.

[@JuanCarlos-ro3kn]

It is like having an open door in a house that actually is empty, you do not have assets inside the house that should be protected, but you clearly have a vulnerability (open door), a threat (a robber) and an impact (loss of money for being robbed, actually since you have no asset, there is also no impact), that is why you couldn't call it a risk even if you have a vulnerability.

[@interseba5456]

@@JuanCarlos-ro3kn what are you saying is true and reenforce what i was saying. During the video by "security risk" he means weakness not an exploitable vulnerability as you said.

[@aidenthomas7711]

It's not a bug it's a feature

[@LemonChieff]

Ok I'm going to state something that is logically factual. Most people disagree. They are wrong. For both C and C++: ANY "potential" nullptr dereference, by definition, CAN be a nullptr dereference. If it happens: that is a vulnerability, not a risk. That is: you do NOT need any actual exploit. Why? Because whatever the code compiles to is NOT a program. It has no defined behavior. It can do exactly what you want, nothing, or anything. What it cannot do is: produce any deterministic output. Again, most people disagree. It's irrelevant. Here is my best attempt at a metaphore: (Best as in: I can't be bothered to do better) Would you get in a car which can cease to exist at any moment, isn't required to move, doesn't follow the laws of physics, and can make your cat pregnant. You can keep calling it what you want, but it doesn't fit the definition of a car anymore. Now if you agree: please prove it because I'm getting sick of fixing the same bug every week.

[@user-ko7oo2qg1g]

Who the f disliked his video?

[@vaisakh_km]

Not me...

[@JoPraveen]

Vanten thala

[@jerryplayz101]

If I ever go into a bug bounty program it wouldn't go well for the business who runs it.... I can get very legal very quickly if I want to...

[@grainfrizz]

Threat + Vulnerability = Risk

[@ImHeadshotSniper]

MR. BEAST

[@edwardwray9056]

Hello!

[@greedy-x-ploit6190]

#DEJAVU this same scenario happened to me today by tomato > i reported them and they rejected saying it's not applicable and then few minutes later i saw that bug was fixed

[@zanez7953]

It's not a vuln it's a feature

[@_AN203]

So simple and fast Vuln : a payload that when exec can access sth not be accessed (%100) risk : can help to exploit the target with x% y% chance

[@अंशुमानअवस्थी]

nth

[@gigog27]

2⁴th lol

[@TechSolutionHindi]

1st

[@InfiniteQuest86]

If you have a bug bounty program and don't pay out for something that you found risky and fixed, then you are acting in incredibly bad faith. Shame on you.

[@aim2986]

If he says "I care about both security risks and vulnerabilities but will only pay for vulnerabilities" then there is no bad faith involved. It's YOUR fault giving information for free. He's not responsible for rejecting your "favour".

[@InfiniteQuest86]

@@aim2986 Please. That's an excuse to get out of paying for it. Could you use that defense to use what you found to leak critical data from the server and then extort a payment from them? Then say it wasn't a vulnerability so they weren't going to pay so I just used it to get paid.

[@aim2986]

@@InfiniteQuest86 By definition, you cant exploit a security risk. If you can, then it's not a risk but rather a vulnerability. Even if what you found is an actual vulnerability, whether they should reward you or not depends on the rules of that specific vulnerability reward program. Some programs only reward specific types of vulnerabilities. It is their problem if they dont reward other types of vulnerabilities. But they dont have to give you a penny unless they explicitly stated they will. It's important to correctly interpret the rules of the reward program. I'm not saying that nobody is unfair. Im just saying that when you think that they are unfair, just be sure that they really are.

[@InfiniteQuest86]

@@aim2986 Sure, if they explicitly say they won't pay for things, then you shouldn't submit them. That's insane. I'm assuming most people are submitting because they expect to be paid for it. Anything can be used to exploit something given enough time, so the distinction is just really an excuse to not pay rather than a legitimate reason. Literally we are talking about XSS not being a security vulnerability in this video. This is probably one of the most exploited things in history. How is that not a vulnerability?

[@InfiniteQuest86]

@@aim2986 If there's any bad behavior you won't pay for, then you don't want to be running a bug bounty program and should just cancel it completely. It's called bug bounty, not I have RCE to root bounty. Even just $25 or $50 is way cheaper than whatever bad stuff could happen or paying someone full time to audit your code and find these problems.

[@flash_gif]

First

[@MystixHalo]

FIRST

[@tg7943]

Sehr gutes Video :)