What is a Security Vulnerability?
Вставка
- Опубліковано 14 чер 2024
- When is a vulnerability actually a vulnerability? I can't answer this question easily, and thus we look at a few examples in this video.
=[ ❤️ Support ]=
→ per Video: / liveoverflow
→ per Month: / @liveoverflow
=[ 🐕 Social ]=
→ Twitter: / liveoverflow
→ Website: liveoverflow.com/
→ Subreddit: / liveoverflow
→ Facebook: / liveoverflow
Best bug bounty story I've heard:
Someone literally went to the company's site, saw their contact email and office address and proceeded to report that as a security vulnerability.
Well duh! If you expose your emails you're opening yourself up to phishing attacks! /s
And what happened....?
I found a very serious security vulnerability!
If you are root, you can edit important system files!
Now where's my $2,500?
Sasszem You don't randomly get money when finding vulnerabilities.
@@gyroninjamodder found another one!
If I press shift for a long time, windows makes an annoying noise!
This is seriously broken!
WHERE'S MY MONEY??!!
@@gyroninjamodder r/whoosh
Bah, that's nothing compared to my vulnerability! I found an attack for getting all kinds of passwords that works 99.9 % of the time and the best of all, it's unfixable! I call it "the dictionary attack", and it consists in immobilizing someone who knows the password, and hit them with a dictionary until they give you the password.
@@GRBtutorials I found a way to break a website. Walk to the data center then to the server and turn it off
Interesting "not security vulnerability" which still can be exploited:
in most companies if you try to login with incorrect password too many times, the account is blocked. Theoretically it can be used for DoS attack: Bad Guy can sabotage company usual workflow simply by inserting too many incorrect passwords for important people until they are blocked.
Fail2ban would probably be a good way to work around that
Seeing the video's title:
"What is going in his head, it's simple..."
Watching the video:
"Who am I?"
"Am I a vulnerability?"
Yes, you are. The user, just like any other human being, is fallible and is always a security vulnerability.
~in heisenberg voice~ i am the vulnerability
ua-cam.com/video/DRfTV5hmo_k/v-deo.html
A few months ago I found a way to bypass EICAR around Avast(and other AV's) by just placing a 42.zip (renamed without the zip part) inside the same archive as EICAR (in my case a zip file). There where 3 ways the Av's reacted:
- They look into the zip, see a zipbomb and just stop scanning, marking the zip as clean (WTF?)
- They look into the zip, see a zipbomb and mark the zip as suspicious
- They look into the zip, skip the zipbomb and correctly find EICAR
The Avast bug team for whatever reason had the opinion that sending someone a zip file containing an exe (Virus) and a random 42kb file where Avast has the strict opinion that its clean is ok...
When I started this video my general description was: any action/mistake that can undermine the security of a machine/network, but wowee you really made me think, thanks for the thought provoking content!
My understanding of computer security: code is like a Swiss cheese with moving holes
I love your videos. Your videos are the only videos that keeps me engaged for over 15 minutes otherwise I tend to bookmark all other security videos and never come back to view them. Keep it up, it is because you provide real world examples it helps to make sense of things.
I imagine Google's bug team would have a hard time triaging :c . (Arbitrary search causes error! Bug team: okay what was the search Guy: AAAAAAAAAAA.... etc Bug team: yes, that is supposed to happen Guy: What, errors are bad! )
Its a feature, not a bug
Apple be like
Inb4 todd wakes you up
It's the future, not a bug
lol @ you just explained how cookies work.
its like adding 1+1 using calculator from one computer then going to another computer doing the same then being surprised that 1+1 gives the same answer on both computers.
tbh, (depending on the kind of website you run ofcourse) I think php sessions should be tied to the IP-number of the user creating the php session from the beginning.
@@spotifysucksballs IP is a bad way to track sessions. Then *any* machine on your network would have the same session. No bueno
@@zacpier That's not what I meant, I meant that you still have the php-session as in the video example, but in your application you check if the IP in the session is the same as the IP of the user trying to use the session.
And when you have daily router reset and get a new IP, you always have to login again ;)
@@spotifysucksballs also not a good solution because of mobile networks swapping out IP addresses as you move between cell towers, and people doing multi-WAN load balancing
as always - great video! Thanks for showing/explaining what actually qualifies as a sec. vuln :)
you should do more of these explaining videos of basics. its great for people trying to get into this hobby
Love your videos
Very good video as always!
I think the pattern here is "some party can take an action, that it should not be able to." but that really just moves the goalpost. But I think this is an area that is often overlooked in software/hardware/system design. What SHOULD individual parties be allowed and not allowed to do with a piece of technology?
I would really like to have some kind of formalism to express that without natural language because this leads to misunderstanding and people that STILL USE CHROOT AS A SECURITY FEATURE, AAAAAHHH!
@Jan Hoekstra
based on your comment you probably are not the kind of person I mean :)
There also is a difference from the concept of the program vs how it's used out in the wild. While you might find ways to make your use of chroots improve security if you look hard enough into the matter, I would not put the blame on chroot if it didn't secure me/my system, because this isn't its intended use.
redstaros? Damn German North Korean hackers.
A security vulnerability is everything that can be exploited to violate the security goals (CIA etc) of a system/landscape, as defined in the security policy/concept.
This means:
a) if it can't be exploited, it's not a vulnerability.
b) if something is a vulnerability or not, not only depends on the general exploitability of something, but also on the specific security context. E.g. if something (lets say a web application) can be exploited (eg via SQL Injection) to get full read access to the connected database, but in this specific context confidentiality is not a required security goal, because everything is world readable anyhow, then it's not a vulnerability, while in the exact same system, but in another use case (eg if user credentials are stored), where confidentiality is a required security goal it certainly is.
Your cookie example: this certainly IS a vulnerability if could be exploited to violate the security goals of a system, e.g. if Amazon wouldn't use HTTPs it could easily be abused by e.g. a MITM attack to circumvent access control via session hijacking. In that case, this mechanism of managing sessions would constitute a severe vulnerability.
If it is not exploitable, because Amazon uses HTTPS and secures the connection against MITM using a proper certificate and strong algorithms and other attacks to retrieve the cookie wouldn't exist, then it's not a vulnerability.
This means the session cookie mechanism is in practice just not considered a vulnerability, because it is usually not exploitable, because it has already been secured (eg by using encryption etc). If it could be used to to compromise a specific system, it would be a vulnerability.
SSL example: by now everyone knows that AES in CBC mode is vulnerable to a padded oracle attack -> this means from a system perspective: using this IS a vulnerability if it can be used to exploit the system (which is why many abandon CBC and move to counter mode). If it can not be used to exploit the system, it's not a vulnerability. It's that easy.
If something constitutes a vulnerability or not has no general yes/no answer, but always depends on the specific use case and the security policy. It also changes over time (eg use of MD5, in 2000 vs 2019)
About the CVSS scores, I agree that they are very hard to correctly categorise, but I believe they're very useful.
I think there are many admins out there, who don't have the time or knowledge to judge for themselves just how severe an issue is. But by looking at the scores, they know if they will have to go out of their way to fix something right now (uses many resources) or if it can wait a few days/weeks and be integrated in the normal update/fix schedule (uses few resources).
"The client has to fix the issue"
Praise. We're in the current mess because tools tend to hand hold developers without proper error reporting instead of slapping them on the face saying you can't do this shit.
@LiveOverflow, as in example 3, the cookie it is not an issue, it is a weakness (a vulnerability) because it could be a step stone for mounting an attack.
My computer security course at uni defines a security vulnerability to be a property of a system, which under certain circumstances, may be exploited to perform a function that goes against the security policies put in place for the system. For example, even though many passwords cannot be brute forced by computationally bounded parties, under the circumstances of a computationally unbounded system, a password may be brute forced. Therefore no matter how trivial and useless, all passwords technically do yield a security vulnerability.
Now you shift the definition to the definition of a „security policy“. Which id equally hard and opinionated to define for a system
@@LiveOverflow Well the security policies for a system are defined by the designer of the system, no? The mechanisms to prevent or detect such policy violations are then implemented by people who are trying to enforce such policies. The people who don't design the system don't determine the security policy of such a system. It's analogous to how one branch of government may create laws (policies) and another branch may enforce laws (mechanisms to enforce policies) . You may debate whether these laws are good or bad policies, but they are still the policies created for the system the government designed.
Most systems have hundreds of engineers and designers ;) who gets to make the call? And in the end, who says they are „correct“? Maybe I believe that the security policy should be defined differently, as can be seen by the examples in this video ;)
@@LiveOverflowI understand your points. I also acknowledge it is -incredibly difficult- impossible to create an infinitely precise and fool-proof policy that reflects what the designers/users expect from a security standpoint. I'm also sure that many system vulnerability claims may be validated, or not, by the (mis)?interpretation of such policies. Nevertheless, thank you for responding and hearing me out :)
This reminds me of a really stupid vulnerability I found on a forum way back in the XP days. I'm never going to remember the exact details now but involved combining a perma-link and quote shared by an admin. You could right click the post title and open it in a new window and then become that user. It ended up looking like the user was replying to themselves even though it was a 3rd party making the post.
Regarding the padding Oracle issue. I think it's important to talk about who's the potential attacker. A paddaing oracle attack requires the attacker to issue repeated requests, so if he can't do that it's not really a big issue.
IMO, the vulnerability definition is pretty straight forward. Let me try.
Let's say you have some assets you want to protect (e.g. personal data, reputation, people, equipment, etc.).
Losing or damaging any of them will be considered a risk to you(refer to C/I/A).
So the possibility of malicious action to an asset that opens it to any risk(known or unknown to you as asset holder) - makes it a vulnerability.
Very good and thorough analysis. Thanks for your work!
In my opinion CVSS is primarily useful as a vector, not a score. The vector can be mapped to a risk management framework such as Att&Ck to help defenders assess whether they have compensating controls or mitigations for a given vulnerability. The vector tells a story that can be interpreted through the lens of a risk model, basically.
I would have to agree... If you have a good understanding for the way computers work and how the client wants it to work you can see how things can or can not be called a vulnerability... It can and is really contextual
1. CVE case: not a vuln.
You just cannot take CVE "badge" as a proof of vuln. CVEs are assigned by people and we all make mistakes :)
2. Smart Contracts case: a vuln.
This case is reported as "not following the documentation (white paper)" and as you mentioned, it is a big thing from the investors' perspective. However, such vulnerabilities can have PR consequences and ruin the project if it is hailed as a scam.
3. Session case: not a vuln.
;)
4. XSS case: a vuln.
IMO it is a vulnerability. For an argument that it is blocked by XSS Auditor you can reply that not every browser version supports it :)
5. Padding Oracle case: a vuln.
IMO definitely a vulnerability (low probability but still) for the same reason you mentioned. They added that for purpose.
there's a lot of meme-y comments, but I just wanted to let you know that this is very very interesting watch, thanks
Would you consider a reflected xss in a custom header a vuln? It looks that it cannot be exploited at all.
I paused at 32 seconds to give you view now and then I'll give it again at the end of the video to see if it's changed. Currently I view this as making a system, app or service performed tasks which it wasn't intended to do, or it's intended purpose. Let's see if I change my mind!
Ok, 2 years ago i had to report to a uni website about what i've done to a project every day!
But one day i forgot to do it and the message was blank. You can't edit past days!
So i edit my current message for today and i just changed the date that was inside an html tag, and when i sent the new data, it actually changed the message on a previous date that i should not be able to. I even logged in from another computer and the new message was still there so it worked. Is that a vulnerability ?
To me vulnerabilities are processes that allow access to data (or computing power) that lies outside of specifications. If a session token has only 1 hex value that is not a vulnerability in itself. Because the specifications provide the amount of protection. However if the specifications say that the token should not be accessible tto third parties within e.g. a month than the scenario becomes a vulnerability. But more often these things are not described in the specification so one has to make an educated guess on the intent of the security measure.
This feels really meta, but you may or may not have censored enough at 14:22. In the line "[blank] submitted a report to Aspen", the name is blanked properly when the page is static, but not right before that when the page is scrolling. On the other hand, I can see the name for myself by just going to the url, or looking in the signature at the bottom ("Your sincerely, [name]").
it's a public report - nothing secret there.
My definition:
Something that allows unexpected behavior or result or something that allows to bypass at least one layer of security.
This cover the bugs that can't be exploited because of a second layer of security. But "unexpected behavior" is still difficult to define. You still have to explain why session cookies is an expected behavior. And why **from the user's point of view** the smart contract is flawed.
13:29 "secret":"vaccines work" -LiveOverflow 2019 lmao
Shhh... That's a secret.
Some other type of "vulnerability": Selling a system responsible for protecting private user data with the feature of not enabling the protection at all. This resulted in a unintentionally incorrectlly configured system that exposed the data of all the users.
Heres the story: Back at my time in highschool there was a "vulnerability" in the schools IT system which allowed access to other students/teachers files because they where saved locally on the PC without encrypting them. No BIOS lock meant you could simply plug in a live usb stick of your prefered flavour and copy or edit the files of all users which previosly used this PC (like placing some programms in the windows autorun folder). That seems bad but it gets even worse: Because the Data on the PC was trusted (no server side checksums or something like that) the next time the actual user to whom the files belonged logged in to his account all changes somebody made (live USB) are synchronized to the main server. From that point no matter which PC you use the changes made will always be present. The company selling this system to schools responded that from their point of view there was no vulnerability present: The IT staff (from the school) simply unintentionally misconfigured the system by not enabling encryption for the data. That's at least what they said (i actually dont know if its possible to do so in a reasonable way). Selling a software responsible for handling private data with the feature of unintentionally setting it up in a way that data will not be protected at all was simply no vulnerability for them. To this day i don't know if this has been fixed.
Copying the cookie 🍪 😢
I saw it coming but I wanted it not to be true ^^
woot a new video
Vulnerability is something you might consider as plausible (where you don't have to rely on unlimited processing power or extreme luck) vector of attack?
I think why business need CVSS is because in risk management term they knew about Risk Rating, which relates between SLE (Single Loss Expectancy) with ARO (Annualized Rate of Occurence).
And vulnerability is tight coupled with risk so... Yeah maybe that's why they need CVSS.
Can someone explain SSL stripping to me? I’m a computer science student and my telecom teacher told me it was possible to intercept https requests at the connection stage, use the SSL data to establish a connection between the client and the MITM, whenever the client makes a request to the server, it is passed through the MITM, who decrypts the message and sends the request to the actual server and getting a response. It seems like it’s essentially a proxy that decrypts your data.
An someone explain to me if it is possible? He said he did it once for an assignment, but something tells me he is wrong (something with CAs and keys makes this seem impossible but I don’t know enough).
The idea is that the attacker creates a secure connection to the server and then proxies the page over http to the victim. In browsers a non valid certificate displays a huge warning banner but the difference (in older browsers ) between http and HTTPS was only the small lock icon. So the victim just sees the regular page without any warnings and without the green lock.
5:18, I once did that and got mad that the company I was reporting to got mad at me. I was just trying to help... or get recognition xD
Hey @Liveoverflow
I found an XSS: if you press f12, and select console, you can enter any javascript on any website!!
bounty plz
Just to be sure: What exactly is wrong with this definition of a security vulnerability?
"Given a security policy consisting of clearly defined requirements like e.g. 'It should be impossible/infeasible for any user of the site to gain knowledge of any personally identifying information (as defined elsewhere) of any other users.', a security vulnerability is an attack vector proving that one or more requirements are not met."
Using that definition wouldn't we be able to stop questioning whether something is a vulnerability? (Yes, I know that this would open the discussion on whether a given policy is sufficient, but that's a different question.)
Like you said, now you shift the definition to "what is a security policy"? I can come up with redicolous policies and then claim I found a vulnerability. Like the PHP session ID example.
My policy is: "a user should never be able to access another account." So when I copy the session ID of another user I get access to that account - but as mentioned in the video, that completly misses the point.
So now we argue about what is a proper security policy defintion
@@LiveOverflow That's right. But can't one require some idea on what a program is supposed to do? If a company really requires your policy regardless of whether the user owns that second account, then I would argue just like in your TLS/SSL example, that this is indeed a security vulnerability. On the other hand having a policy which isn't restricting enough, it might allow for some actions which might be controversial, but are not a security vulnerability following my definition. But to me that is a social problem and not a technical one. For example: Microsoft is able to collect all sorts of data from it's OS's users. Is this a security vulnerability or a "feature", as unwanted as it might be to some users? According to my definition this is a feature to Microsoft, but might impose a vulnerability to anyone using Windows, but requiring to stay completely anonymous. Whether this is a "good" feature on the other hand is open for discussion and not part of any technical debate.
Let me just say that to have security you have to sacrifice convenience/accessibility/speed so the idea of a cookie is to facilitate an easy method of login/access... If you are worried about the security then DON'T use them! It's simple..
@@LiveOverflow Surely the argument then is "how do you expect to get the session ID?"
I have found a vulnerability.
Type: *Alternate User Version Injection* - it is the situation when one version of a user commits permitted action that later version of the same user won't approve.
Reproduction steps:
1. Get drunk.
2. Log in to your Twitter account
3. Write a tweet where you say that your boss is ********
What happens: You are fired.
What should happen: Twitter should block action that wont be approved by future version of a user.
(In this case alternate version of user have been injected via alcohol)
Thank you for the videos.. Can you give me a resource where I can read pentesting report.. I want to get writing reports skills..
There is a public pentest report github :)
A vulnerability is something which subverts the control flow, data security, or integrity of a system, that _lies within the threat model_.
In your encrypted message example, the fact they encrypted the message shows their threat model includes TLS being broken/subverted, so because the data security of the message can be subverted, it's a vulnerability. If their threat model was the same, but they didn't encrypt the messages, that would still be a vulnerability. Obtaining a complete threat model is exceedingly important.
"Security specialists" in my country told me that being able to change the type of an input from password to text was a vulnerability
M3nd3z !! It might be. Maybe there are less protections on the memory backing of text than of password.
A vulnerability is a generally expected weakness or flew in software, protocol or algorithm that allow weird things to occur it can be a bug but in just a nature of a machine while bug is bad implementation in software that allows manipulation of calls bytes or packets that allows unexpected or unintended thing to happen exploit it a method of manipulating one or more bugs that do flip software to do very intended things in different way so it can bypass or change beehiver for example authentication, regular procedures, loops, permissions etc.
I think the PHP session cookie is debatable. It won't work on any of the major sites these days, they all fingerprint your browser etc. to make sure nobody stole the cookie. Is relying on just cookies for authentication a design decision or a vulnerability? If someone is using MD5 for password hashes these days, it is considered a security vulnerability but there is no known pre-image attack for MD5 (only collision). Weak passwords can be brute forced but that's also true for KECCAK. So what makes using MD5 for passwords a vulnerability and failing to implement extra authentication on top of a session cookie not a vulnerability?
@@ruakij6452 A session cookie would only be safe in a perfect world were there is no XSS, outdated browsers with old SSL implementations, malware etc. etc. Sadly we don't live in that world.
Indeed weak password can be brute-forced when using MD5, but if you use a single round of SHA256 it is also possible to brute-force the majority of passwords.
But if your password is strong enough, even generating a list passwords with a high probability that it contains the "strong" password would be impossible, so it doesn't matter how easy the hash algorithm is as long as there is no pre-image attack. And if you want to increase the time / power required, you can just add more rounds until it is safe today. In the end, you'll have to spend exactly the same amount of resources to check the correctness of a password as an attacker, independently of the hash algorithm used.
Off coarse that doesn't mean it's still safe tomorrow but that's also true for KECCAK. Just the fact that there is a collision attack and that it is a low-power hash algorithm doesn't mean that a good implementation is thus a vulnerability IMHO.
Off coarse I would not recommend using MD5, but still I think it is possible to make a password hash algorithm with MD5 that is still safe today.
@@ruakij6452 too much salt makes it salty
Hey liveoverflow would you please make a video on how hackers make money....interesting stories ....obviously apart from. Selling and buying exploits of bug bounty....
Another amazing video, but... redstar os? why?
I think a security vulnerability is just a piece of code or implementation that allows for something to go against (or beyond) its intended use. Here's why I think this (rather broad) definition fits in every case:
Case 1: The software designer (the guys who made Python) dispute this vulnerability, because this "vulnerability" is actually just a misunderstanding of what virtualenv is supposed to do. It's a matter of people not knowing how software works. I don't think this one counts.
Case 2: This one sounds like a vulnerability, even if the minter disagrees--they're taking the program they've got out of its original confines and creating unlimited supply where there shouldn't be any.
Case 3: Where we draw the line, in this case, is really a matter of how hard it would be to bruteforce it (given how long an average session lasts, who's using it when, etc. etc.). Does this one count as a security vulnerability? The act of copying cookies doesn't because you need to know the cookie first, and if you know the cookie, well, it's just working as it should. The issue comes from when the code itself is breakable--which if the 'intended use' is a week-long session, you'd best make sure your cookie can't be bruteforced in a week.
Case 4: Sounds like a matter of the object preventing said vulnerability being too weak to actually prevent anything from working out-of-line. Patching a hole in a leaky boat with jello isn't going to do much of anything. It's a matter of being a bad fix to an already existing vulnerability. Granted, they didn't do much to try and fix it in the first place and just said: "Let's let Chrome do it for us".
Case 5: I'm with you on this one. The second layer of protection didn't work as intended and basically allowed a hacker to resolve it to a point where it might as well have just been SSL again. That's a layer of protection gone which might come in handy later.
I think a vulnerability is any part of a program that provides *unintended or undocumented* (or not part of its design) behaviours, privileges or accesses.
So basically, it's a specific kind of bug.
For me, something is a vulnerability if you can do something you're not supposed to be able to do. In other words, it grants some extra capability that was not intended.
#1: Virtualenv is not designed to stop execution of system commands, so there are no additional capabilities ==> no vuln
#2: ICO shouldn't be able to mint new coins => vuln
#3: Session tokens are like passwords; if someone knows yours, they can log in as you => no vuln
#4: You shouldn't be able to inject JavaScript which is run in someone else's browser => vuln
#5: You shouldn't be able to decrypt the internal payload => vuln
Would you consider the following definition: "A vulnerability is a divergence between the expected behavior of the program and it's actual behavior", or stated differently, a vulnerability is a difference between the spec and the code.
This definition has a lot of advantages.
“Vaccines work” I love you lol
Security Vurn: alert(document.cookie) lol gotem hehehehehehhehe this is gonna work and be so funny lol lmao ha
The dislikes are the persons that are vulnerable
The dislikes are those who made xss auditor
Well the difference was perfect, apple vs orange 🍊 also the idea behind CVS score is not good as per my point of view a vulnerability is a vulnerability it all depends upon the impact I think I answered my own question :')
Hey LiveOverflow, just wanted to let you know that you spell the word "definitely" wrong very often. Thanks for making interesting videos.
Also "promise"
ahhahaha yeah I know T_T
@@LiveOverflow might help to remember it as de-finite-ly, even though you don't say it like that.
@@LiveOverflow Also, skeptical has a k in it.
@@JochemKuijpers I defiantly would never spell that word wrong.
Wait redstarOS?? I see you are a man of culture aswell
One time I think I found a vulnerability. It was for this web app that let you run python on a server.
They blacklisted some code, mainly stuff like import os etc, but I found a way to bypass it and run the blacklisted code/ access the terminal. It didnt seem that bad as I think everything gets deleted on disconnect but the fact they tried to block it shows they dont want people doing it.
I emailed them but they never got back to me.
I consider everything that MIGHT compromise a part of the CIA triangle a vulnerability.
Even if it not exploitable yet. Because it might be tomorrow. Therefore a fix needs to be implemented. The means even AES256-GCM is vulnerable to bruteforce. But there's no known risk right now. But nevertheless we try to "fix" it by creating even better crypto.
The next worse thing would be an emitiatly exploitable vulnerability.
Which is just a vuln with a high risk of successfull exploitation.
So far it works for me.
i'd define it as the ability to perhaps access or modify something you're not meant to.
so, bypassing the no-touchy-touchy code.
I can't believe someone actually called that virtualenv behaviour a vulnerability 😂
I'm fairly certain SSL itself is considered a security vulnerability at this point. TLS on the other hand is not. It really bugs me when people interchange the two terms. I know I'm just being pedantic but I don't think the name change should be ignored.
just use a JWT as a session cookie and at least the brutforce problem for sessions is fixed :3
Nice secret at 12:15.
Why are you running redstar os?
It's just his host name.
My sexiness is a security vulnerability.
Late 2018? How far ahead do you make these videos?
28th of october 2018, at least some parts of this video were recorded back than (google chrome bug bounty page)
I would call something a Security vulnerability if: "A program that has unexpected behavior, which can be used by outside entities to view or edit data".
5:46 lmao
if it allows somebody to maybe cause damage by using something a way that it's not intended, it's a vulnerability. In fact there is not many things that are more vulnerable than a kitchen knife.
There's a clear rule for that: "POC||GTFO". You either create a proof of concept that can do a clear harm to the vulnerable system, or just GTFO with your report :) Especially it's useful for triaging teams.
rock-n-roller One of the problems he pointed out was that what if you find a XSS vulnerability in a website, but your browser’s XSS auditor catches it? Technically, normal users are safe from the XSS because the XSS auditor catches it before it can do any harm, but it should still be considered a vulnerability, since the website itself has an issue that could lead to an XSS attack. In other words, the user got lucky that the browser caught the issue, but the website itself still has an underlying issue. I think most developers would agree that it should still be considered a vulnerability.
@@phaser4150 usually it's not that hard to come up with a PoC that bypasses XSS auditor or show it in a browser that doesn't have such a feature (Firefox, for example). However, I totally agree that XSS blocked by XSS Auditor or even CSP is still an XSS vulnerability that must be fixed.
Can we randomly generate session ids until we get a valid one and hijack that account?
It's a matter of probabilities rather than just yes or no. Cookies have an expiration date, so that's one more factor to consider.
@@smorrow Ah, fair enough
I can go to a computer and log in as some account, and go to another computer to log in to the same account using the same username and password! It's a session hijacking vuln!
My definition: A security vulnerability is an ability to cause unexpected behavior with consequences interfering with given service.
Your comment is a security vulnerability.
I know it when I see it
For me, a "security vulnerability" is any action that can be taken from a less-privileged context, that somehow bypasses or exploits the system to gain information or cause the program to react in a way that compromises the stability/security for other users. So in the case of the virtualenv "vulnerability", you are not operating in a less-privileged context (what exactly are you "escaping" out of? lol). Likewise, if you are an admin or root user, being able to strace or dump core of arbitrary processes is also not a vulnerability, since the expectation is that you already have full access. Same for the session cookie example, you as the user of both accounts have access to both session IDs, so you are not compromising the security of other users.
We seem to assume vulnerabilities can only exist in code. But this really isn't true. Even if we completely ignore the possibilities of social engineering attacks, there are other ways things outside of the code can make it vulnerable. Consider an error in documentation that leads developers to think a given function does some bit of extra check that it actually doesn't. What if a developer gives it inputs from a source that really needed that extra check, thinking that the function would handle them like the documentation said? Or maybe the documentation was just a bit unclear and ambiguous? This is itself a vulnerability, or at very least a "potential vulnerability", something that if not addressed will cause direct vulnerabilities in the future. Virtualenv would fall into this catagory if the documention wasn't immediately clear enough that it's not actually a sandbox like the name suggests it might be.
The example with the messages being sent through a tunnel, but with a second layer of (flawed) encryption beneath it is also definitely a vulnerability. The clear intent of the developer was to have a second, redundant layer of security, so that if something unexpected happens, like SSL being cracked, their messages will still be safe. However, the flaw in the encryption meant that this design parameter was not being met.
It is like running a server, and having a backup system. Suppose you find out the backups aren't working properly. Is this a problem? How could it be when the server is still running just fine? But of course it's a problem! You would not be making backups in the first place if you didn't think that you might well need them someday!
A vulnerability in only a single component of a redundant system remains a vulnerability even if the system as a whole is still secure.
Obviously there are no universal rule to determinate if something is a "vulnerability" or not.
it depends on what you want to be protected from, what you do consider (or not) as a threat and witch level of protection you need.
Authenticated remote code execution!!!
1. open terminal
2. execute this command: "ssh 127.0.0.1"
3. username: "root"
4. passcode: "security"
...
I need a better passcode...
The biggest issue I imagine is that people think vulnerbility is the same thing as risk
I have to argue with you about the third one - session hijacking. I believe that the ability to use a session cookie that belongs to another person is definitely a vulnerability if it gives you their account permissions. The vulnerability is that the site does not check if the session cookie actually belong to the sender. Although it may not be done perfectly, it can be done better by saving on the site side the ip address, user agent and any other identifiable information about the *session* and then checking that when the user gives the session key. Otherwise the session can be stolen and fall to a dumb replay attack. I also think that your thought about the length of the session id should have got you to the same conclusion, but you mistakenly confused the session hijacking vulnerability with another one - session forging - which is allowed by brute forcing. The difference is that for one you of course need to get the cookie itself while the other one allows you to get one without reaching a "real" one. For sure one is much worse then the other (meaning the difficulty of "exploiting" each very different) and so their "CVSS" score will be as such.
Anyway you had a great video! hope I was clear cause I wrote it on the phone at 2am...
Uhm. Cookies are the proof of identity. There is no other magical thing to identify the „real“ sender, otherwise we would use that instead of the cookie
@@ruakij6452 you are right, it is not a vulnerability if it is wanted BY DESIGN, but mostly you want the user to be able to keep browsing only from the same browser.
@@matan438 "but mostly you want the user to be able to keep browsing only from the same browser."
Why? And if you have the capability to steal someone else's cookies then what stops you from stealing the UA? Seems to me that you only annoy your users if their UA changes and they get logged out for no good reason.
Security is all about context.
Did you mean: *definitely* :D
13:13 Secret
Hi there
Could you please show some more asm patching
And also more linux stuff (like the new ubuntu 19.04) :p love you
woops! typo at 0:09 :D
If a bug can be exploited it is not a vulnerability?
Can someone explain in different words why #3 is not a vulnerability?
The cookie is a secret that is difficult to just steal and copy. It's the same as saying: "If I ask User1 for its password and goes to another computer I can log in as User1." The cookie is a secret known only by the users' browser. You can't guess it, you can't steal it. The "copy and paste" from the demo is not possible in a real practical scenario.
Actually cookie stealing can be the endgoal of an attack but you will need another exploit to actually steal the cookie. In that case, the vulnerability is not "If I have the cookie, then I can do that.", but it would be instead "If I do that, then I can steal the cookie.". The session cookie is a secret and you are not supposed to share it.
Also: It's way too long to guess it.
jydk37 It’s like claiming using a lock and key is not effective security because if someone else has the key, they can open the lock as well. Well, duh, that’s how locks work. If I make a copy of my key and give it to someone else, of course they would be able to break into my lock. The security comes from keeping the key itself safe. The same goes for cookies. The “lock” in this case is the website’s login form, and the “key” is the session cookie you get from the website. Of course stealing a cookie means that someone else can login as you, but the real difficulty comes from stealing that cookie in the first place.
the 2nd one IMO is merely false advertising, or we call it an unjust treaty.
But isn't that true of every vulnerability ever? They were just falsely advertising it as "secure".
@@Keldor314 Before they implementing mintInternal(), yeah, i'd agree with you.
Yeah, the 2nd one is a good deal more serious than a mere security vulnerability. In fact, depending on exactly what happens, there could be possible criminal bank fraud charges here.
Anyone who thinks that although cryptocurrancy is meant used just like money and even to be a money replacement, yet isn't *officially* money so none of the money rules apply will be in for a very rude surprise in a court of law.
I think the only one i'd really disagree with you on is probably example #5 and only in a specific context. For me it comes down to the relevant threat model. If the client (or the bug bounty program) is not concerned with packets being read out of the TLS channel then reporting a vuln that relies on packets being read out of the TLS channel is just wasting everyone's time and money.
Note: i'm not a security expert, generally i avoid having strong feelings on security matters beyond certain well accepted statements (e.g. security by obscurity is bad). This opinion is mostly formed by a talk by Deviant Ollam (who comes across on youtube as a fantastic speaker) from ua-cam.com/video/mj2iSdBw4-0/v-deo.html
@@ruakij6452 I'd argue the point is that we don't have enough context to make a snap decision (which is not to say LO doesn't have that context). We don't really know what the content was and we don't know what their security model looks like.
You're assuming they wanted that extra security but given that LO has stated he wouldn't have mentioned it if it wasn't encrypted, i'm assuming that the security model didn't specify that the messages were intended to be encrypted otherwise the lack of encryption WOULD be a vulnerability. Is "more secure than intended but not perfect" a vulnerability? More importantly is "more secure than intended but not perfect" something that the client is going to give a priority to resolving.
While i'm not a security expert I have had to do remediation of security reports and i've been in situations where issues were acknowledged and documented but the remediation work was prioritised at the "once hell has frozen over" priority level. Given the hugely unlikely probability of attack (assuming no other flaws, again... context, exploiting the padding oracle flaw would necessarily require a task equivalent to breaking modern credit card encryption in transit) i'd argue this isn't going to be getting a severity of anything higher than low.
This is making the assumption that TLS itself is secure. But is this really a good assumption?
Computer security has a long and storied history of people finding cracks and exploits to break systems previously thought to be impervious. This goes all the way back to the Allies using the first electric computers to break the Enigma Code during the second World War.
With that in mind, why are we so quick to assume that *any* of our current systems are so secure that someone might not discover a vulnerability or flaw that breaks them overnight as was the case with so many others before?
There's also a long and storied history of solid security algorithms being entirely bypassed because just a single programmer somewhere between the paper describing the algorithm and the end user screwed up.
I should think that adding a bit of redundancy might not be so bad an idea.
@@Keldor314 in general I don't disagree with you. But again I point out, LO wouldn't have mentioned it if not for the padding flaw. A policy of 2 layers of encryption is one that might be worth making but the client didn't have that policy and I'm not convinced that the industry is (yet) served by normalising dual encryption where the context hasn't mandated that policy already.
At another level, you have to ask what the second level of encryption is gaining you. It's just as legitimate to opine that the adding the extra encryption makes you vulnerable to new issues due to the interplay between encryption layers.
"something that can be realistically exploited"
Am i the only one is bug bounty here? 😂
My H1 profile : hackerone.com/man_shum
Instagram: instagram.com/evmannn