# Should I report this vulnerability? Will I get a bounty? ## Метаданные - **Канал:** InsiderPhD - **YouTube:** https://www.youtube.com/watch?v=T4EhE5f7fQg ## Содержание ### [0:00](https://www.youtube.com/watch?v=T4EhE5f7fQg) Segment 1 (00:00 - 05:00) hello everyone and welcome to this week's video I'm going to be tackling a topic that I think a lot of people end up messaging me about and they get a little bit excited about finding something and they're right too finding a bug is big it's really exciting but they need to take a little step backwards because sometimes you can report something that's not actually a vulnerability at least not initially or how it seems in the first place So today we're going to be talking you found something or you think you found something what do you have to do before you report it just to confirm you found something just to confirm that you've actually got the bug you think you've gotten Etc and once again this video is very kindly sponsored by bug crowd they're sponsoring every video in the bug Bounty Core Series they're covering course series a great hacker needs a great platform and Bug crowd is the home of the hacker they provide hackers with the best opportunities to make money Advance their skills build community and unleash Ingenuity through their security knowledge platform they provide distinctive educational content for hackers you can rapidly pick up new skills through bug crowd University or gain practical experience with one of their many monthly challenges or maybe you want to follow real hacking experts like myself as we cover methodology shortcuts and tools bug Crow has an entire level up series unique to the industry that covers all of that so if you're interested in joining bug crowd head over to bug crowd. com hackers now and join the bug crowd Community thank you very much to bug crowd for sponsoring this video thank you so so let me tell you when you find your first vulnerability or even you think you find it the rush you get feels amazing and it's so easy to get caught up in the excitement of oh my God I found something and like also to mentally have also received the Bounty before you've even like actually submitted it but my advice is to try to avoid rushing to report something right away because one you could be leaving money on the table by you rush to report something and you realize oh I could have escalated that to an account takeover you could misunderstand the pre you can misunderstand the prerequisites of that vulnerability and actually you know it's something a user in intentionally has to do TOS like a self xss or you can actually go out of scope and if it's out of scope then you know you're not going to get paid by Bounty so my top tips tldr here think to yourself is this actually a good bug to report is it impactful is it something that I think is a genuine security issue I have had situations where I found something that could be a security issue but it's quite minor or it's debatable and I just don't want to have an argument with triage I'd rather find something that I know is a vulnerability to confirm that it is actually a bug a very common one is Idols I'll be talking a bit about that confirm it's actually in scope or owned by the company depending on if it's an open scope program understand the requirements of a vulnerability so what kind of setups do you need what kind of accounts permissions do make sure you really understand the impact SL escalator if you can and finally is it worth actually fixing this is this going to be a P5 kind of actually you know it's an accepted risk so one of the best piece of advices I got from Alex Chapman he's a full-time bug Bounty Hunter and he's does really well in a lot of live hacking events he doesn't report every findings he only report critical and high findings sometimes medium and what I really took away from this conversation with him is that you shouldn't really report every bug because it's not worth putting in the effort to spend like hours arguing back and forth with triages that this is a genuine vulnerability if the impact is really low and the security team doesn't care they just don't bother going for that argument a lot of the pros don't report anything below a P2 that means there's a good opportunity for us at the bottom to going to pick up those p3s and p4s but often they're not reporting p4s for a reason it's cuz it's just not worth their time so really think when you find a bug whether or not this is actually worth reporting and this is something you want to defend and a really common one I see is this idore so a lot of people will perform an idore by copying the cookie from one account putting it into another account and then seeing that the API returns back at ### [5:00](https://www.youtube.com/watch?v=T4EhE5f7fQg&t=300s) Segment 2 (05:00 - 10:00) 200 that is not an idore is when you can take an account cookie for account a use it on an end point that you originally hit with account B that has one of account B's IDs in there for example and be able to affect B's account with A's cookie it's not being able to AFF A's account with A's cookie that's just how cookies work and I really recommend this video called why your Idols get na which is the kind of full explanation of how cookies work um and I think is a really great example of people will find that they'll report it they'll get an aid and then they come in to me send me an email that says this program's screwing me over they're not screwing you over that's just how cookies work and this is why it's really important to make sure you really fully understand the vulnerability so whether that's something like reflective xss if you've got reflected xss but the field is only visible to the person who is performing the xss that's not a vulnerability a user has to do that to themselves and that is a significant barrier that a lot of organizations will say you know what yeah that's just a risk like if a user is putting stuff putting like random JavaScript payloads into their I don't know um Town notes that's on them or ssrf if the ping back from ssrf isn't from your target server it's from somewhere else that's not a vulnerability you can report to the client it just isn't so it's really important to understand have I actually found a vulnerability or have I found like known features the kind of follow-up to this is really is it in scope now personally this is my own personal opinions here you should not be expecting a bounty if a asset is out of scope even if it's resolved usually think things are out of scope because a client doesn't have the vulnerability Management in place they haven't got a way to make sure the vulnerability gets branded as the target so think about something like WordPress it can also be a recent acquisition that's actually covered under another vulnerability disclosure program now a lot of clients May forward it over to a third party or may forward it internally to something like a recent acquisition and their own security team but you really can't expect a bounty in that case you have gone out of scope you were doing so without the expectation of award now I know there's a lot of debate here and a lot of people will say it's been fixed they should pay a bounty and you can debate this but fundamentally most organizations won't be upset if it's once or twice but they're not going to reward it and actually if you continue to do out of scope vulnerabilities you can expect to get penalties because this is stuff they said do not touch so my advice would be never go out scope I think the really easy way to do that is to just look at the scope page and look for those big application or subdomains and just make sure that when you actually find something you're not hitting a subdomain understanding the requirement so I've actually been burned by this one I got a bug nade because I couldn't and neither could triages understand the account and organization setup that I had done so I found an ID you were able to delete somebody else's thing except for the role that the attacker had in the organization I didn't understand like how I'd set up the attacker account and the victim account and how the organization was set up so when the triaga couldn't perform it and I sent videos I was like look here's the video you can see this working I still got my bargain a and I kept on pushing with the client but it got to a point where I was spending more time on this and I'd spend actually on the vulnerability itself so it's really important to understand the requirements of your bug because otherwise it's just going to get an aid and there was nothing I could really do about that I mean I could have taken it to mediation but sometimes it's just not worth your time that will be for probably just like $100 $200 so think about what accounts you need what permissions you need what information you need from the victim what the victim has to do what the attacker has to do really make sure that you understand those requirements and similar understand the impact you know it's really important that you understand what the attacker needs from the victim and what damage you can cause the victim so the best impact bugs are going to be cases where you can damage the victim without the victim doing anything in some cases maybe like a stored xss ### [10:00](https://www.youtube.com/watch?v=T4EhE5f7fQg&t=600s) Segment 3 (10:00 - 15:00) they'd have to visit a specific page for something like xss in fact you may just do an alert one popup but you can do more you can escalate it cause more damages so the least amount of stuff the victim has to do the higher the Bounty is going to be generally so can you escalate it the most common first P1 I see are account takeovers if you are looking maybe you've got like a few p4s and you're getting things like xss or idors I really recommend looking to how you can take that to a account takeover and get a P1 so crosslite scripting to account takeovers because of csrf so you're able to write a little JavaScript function which calls say a reset password form do that all in JavaScript and because the xss is calling from the same site you actually won't be violating same site cookies or an idore to organization takeover because you can have permission issue you can escalate a privileges the top ones to look at money accounts permissions can all be p1s and p2s regardless of the bug so even if the bug say it's a P3 if you can demonstrate that impact often it will be escalated really think about the business logic and what a company will care about now I know a lot of you are still beginners and you haven't found your first bug yet so don't worry too much about this focus on those p3s cuz that's really where you'll see quite a lot of skill increase over time but when you are being able to get those p3s quite consistently do push yourself to grab things like p1s because you can like the skill increase is actually not that great as in if you're able to find an idol you can prob probably found an organization takeover it's just the right ID door in the right place and if you report something as soon as you see it's ult it's vulnerable then you may be missing out on that kind of business logic of okay if I have that I can start to do this so again it's about kind of taking the small things and pulling them out is it worth fixing so p4s p5s n arguing things like that are not going to be worth fixing if you're in a situation where you're arguing with a client over whether or not it's a P4 or a P5 it's probably not actually worth your time is valuable you'd be better off spending that hacking if you're using scanners like nucle it's going to be a dupe especially on public programs and especially where you're not you've not looked at like a really indepth Recon and finding all the subdomains and you're paying for data from security trails or whatever like they are going to be duplicates and honestly not everything will get a fix and very soon like it took me 2 years to get a vulnerability actually marked as resolved it's not worth the effort to argue back and forth with a triager whether or not your um exi data not being removed from a gif counts as a P4 rather than a P5 because phone cameras can't take P can't take if photos necessarily by default and again it's just this the constant arguing the back and forth it's honestly not worth it you'd be better off actually putting in extra time to hack and look at another client again you've got to value your time and if you are spending a lot of time goes in backwards and forwards with triage it's probably not worth it so just to summarize here these are my tips so first thing is this actually a good bug to report is it impactful is it worth your time is it something where you're going to have to argue with the client confirm that what you found is in fact a bug if you're looking at xss it should be somewhere that other people can see your EXs payload if it's an idore you should be able to access another account without using that account's cookies confirm that what you found is actually in scope and it's owned by the company if you are hacking out of scope a lot of clients won't be angry at you but just bear in mind that if you keep on doing that you will get penalties by the platform and the client may ask you to be removed from their program if you are consistently doing it and not in good faith understand the requirements of your vulnerability don't be like me make sure you understand the setup of users and organizations and permissions and really demonstrate and be able to tell the triager hey this is ### [15:00](https://www.youtube.com/watch?v=T4EhE5f7fQg&t=900s) Segment 4 (15:00 - 16:00) the initial setup make sure you really understand the impact of a vulnerability push it as far as you can try and escalate it again most common first p1s are going to be things like account takeovers and that can often be from things like reset password forms and reset password vulnerabilities and finally is it actually worth fixing your time is valuable it's not worth it to always be trying going backwards and forwards with triage trying to get them to care as much about your bug as you do and especially you are excited you have just found something excellent go through go report it go be excited go tell all your friends that like you found something don't give them the vulnerability details and just wait for that bounty to come in you know you've earned it all right thank you very much everybody I will see you in the next video we're going to be talking about how to write a report so once you found something you confirmed it's a bug how do you actually make people listen to you and how do you make the best possible report for quick triage easy acceptance and a nice Bounty so I'll see you all in next video bye everyone --- *Источник: https://ekstraktznaniy.ru/video/38631*