I was asked a rather unexpected question related mainly to this post of mine. It boils down to: How do you know where to look? How come that you can find vulnerabilities in the first place?
After working on the response, I figured that I might as well share it with all of you and just link it to the person who asked (btw: if you don't want to ask more questions publicly we can continue talking as we did previously). Keep in mind that I am by no means an expert! Honestly, I'm kinda dumb when it comes to computers. But that's a good thing, as it makes me ask questions. As per usual, I get ranty at places and it's far from short so read at your own discretion. Also, I'm a pretty shitty choice to ask this question. There are many more people on Hubski who are much more skilled, so don't take my stuff as some definitive writing on the topic. It's more of a personal perspective piece.
With all this in mind, here's my process and background:
1. I'm always curious about how stuff works.
That's a major part. If a service I'm using is open source, I'll give it a look just to see if the way it works is similar to my idea about its internals. On Hubski I have quite literally spent hours if not days going both through Github repository and HTML code in the browser. With this in mind, I'm usually similarly obsessive about most of the stuff that I'm using. For example, while I'm not a Linux kernel coder, I actually have a fairly good grasp on how most of it connects together. Same for Firefox.
2. To me, anomalies stick out like a sore thumb.
You know that 'wait, what?!' feeling that you get while watching a poorly edited movie? I have it constantly while browsing. "That's odd: X request took twice as long as Y", "Why is this thing highlighted?", "A visited link, eh? I don't recall ever clicking it!", "How come that I can see this page if I'm not logged in?"… these are the questions that just pop into my head. I don't need to ponder it, stuff that does not fit certain patterns just jumps at me.
If you can see something weird, odds are that it's not working as intended. Ask questions, try to think of a good answer. Combine it with the previous point and add to it the fact that…
3. … I just have to test my ideas!
Why wasn't it working as it should? Would this work? How does this bit look in the back-end source code? Oooh, there's exception for A, B and C, but nothing about D! Let's see if I can cause D to happen. Does it work? If yes, then I'm trying to think of a fix for it. If no, then I will get deeper into it just to see where this bit of logic is actually checked. That's how you can find most of the vulnerabilities. Or, at the very least, find ways to optimise the back-end of the service.
4. Usually, it's just an accident, though.
The problem that I have mentioned, one reported to mk, got discovered while I was working on something completely different! I ran a script that was scraping all posts and all 'shared by' information. However, I have noticed that there are actually two different pages for shares.
which gives information about shares on comments and
which gives information about shares on posts. There were also some peculiar things like X will give the body of the comment along with shares.
Here's the thing: I had to find a way to determine when something is a post and when something is a comment. It was hard to differentiate and outright impossible by ID alone. Perhaps it would be the size? Here's what hit me: surprisingly many posts (links with /pub/) had a size of exactly <some number of bytes>. That's odd, right? I've opened one and got something along the lines of "this is a private message". Oh, damn! I was scraping PMs as well as normal things. But then I'd looked at the size of /cdotby/ with the same ID and got a pretty damn big post. It was a private message's body!
I made a few more tests and checks to make sure if that's only valid for PMs, but my fears got confirmed: drafts and deleted posts also had a visible body on a /cdotby/ page. This was when I wrote about it to mk.
But what was my goal before this find? I wanted to determine a way to find tag associations and graph the interconnection of posts, people and tags in various configurations. Who knew, maybe my fucking around would help optimise Hubski? Unfortunately, it didn't happen. But instead, I found a pretty serious privacy issue that was mended by mk in literally under an hour since I'd informed mk about it.
5. I don't use any 'fancy tools'.
You'll read a lot about how you need to know ins and outs of programs like:
- <insert a specialised Python framework of the week>,
and, preferably, use either BackTrack/Kali Linux or something like Tails. To note, if a tutorial talks about BackTrack it's going to be seriously out of date. I think that the only actual advantage of Kali is the fact that it comes with a whole damn toolbox and you don't have to get pissed about installing and configuring most of this shit by hand. That's huge, as it comes with something like 400 preconfigured programs ready to use. On the other hand, that's a lot of stuff to learn about.
These look like amazing tools, right? Well, the thing is I don't understand the output or use cases for most of them (sans Wireshark and Nmap, but that's because they were recommended to me for local network diagnostics). My short attempt at learning basics of Metasploit ended with me being frustrated at that thing. There's no real understanding required, you just have to know which options you want to select and not really the 'why'. It's basically a program that does a bunch of tests and performs pre-made attacks. If you want to look like a Hollywood hacker while having very little know-how, you might as well get it. The only way for it to get simpler is to have a browser form with a field Target and a button that says Hack the shit out of it underneath it.
Fingerless gloves optional, but preferred.
- Free CCNA course - there are some problems here and there and I think that it's slightly out of date as far as certification material goes, but it works as a learning resource all the same. IIRC, it also uses Wireshark and Nmap, so you'll get to know some of the tools.
- Think Python: How to Think Like a Computer Scientist - that's a really good book that's worth recommending for two reasons. Firstly, you will learn about one of the most popular, supported and known programming language. Secondly, the book is only using Python to introduce you to much more general concepts in computer science.
- SQL and general databases - this site is the best thing that I have ever seen as far as SQL introductions go.
Also, this book combines teaching you about basic Python, SQL and making programs that connect to the Internet. My guess would be that you might want to start with it and use all of the other resources to expand your knowledge about the specific stuff, as a book about everything is not going to dwell too deeply on anything. And aim to learn Python3 instead of the soon-to-be-deprecated Python2. Differences are almost negligible to the end user, but the Python's internal engine got a major lifting between 2 and 3.
If that's not what you wanted or expected, sorry but that's what it boils down to: having a really good grasp on the basics. Just like you have to know basic anatomy to get yourself started on becoming a surgeon, or knowing linear algebra to do literally anything relating to higher mathematics, you must know at least that much.
Either way, even if you think that it's not impressive, here's what you will know afterwards:
- Basics of network engineering (i.e. design, how it works and rudimentary troubleshooting, knowing how and why you should setup simple switches and routers for a local network). That's enough to make a home/office LAN, setup a file server for backup storage and secure your network against 99% of intrusions*.
- Basics of algorithmic thinking and task automation (AKA scripting). This is huge because once you will solve a problem you can apply your solution to the task of any size. If it's truly efficient, you just have saved yourself a lot of time as every time you will need to do the task in the future… you just run a script and that's all you have to do.
- Enough about databases to avoid common fuck-ups and to actually be able to design (not so) simple data model.
- Current knowledge of if not web development, then its internal workings. Plus you'll know some HTML and CSS to boot.
That's seriously not bad! It at least seems like a bulk of what you would learn for some sort of IT-related Associate's Degree. Follow it up with something like PHP (I have no good resources for this one) and you are going to be very well prepared to deal with most of the stuff that happens through the browser.
6. Avoid (al)most (all) of the 'hacker FAQs' and 'tutorials'.
If you were ever thinking that I'm insufferable and with some serious ego you haven't seen anything. Most of such documents serve only as e-peen enlargement and are almost guaranteed to either/or/and:
- glance over major technical details;
- be written with an attitude of 'look how smart I am!' so thick that you would need a superalloy saw to cut through it;
- operate under the wrong understanding of the process.
There are some quality resources, but they are rare and far between. You want to hear about cool exploits and a method of pinpointing them? Look for videos from Def Con. They're better than almost all blog posts or essays that I read so far and, even if not deep or detailed enough, are almost guaranteed to be entertaining.
7. Take a moment to think if you should actually inform anyone about your eventual findings.
Unless the website, service or app has an explicit bug-hunt section, you should NOT bother. You will be, almost without exception, threatened with police, ignored or banned. However, if you still want to do the good thing, here are some tips. They didn't work for me, but who knows, maybe you'll be luckier.
- If possible, send your report to a dedicated security or administration account.
- Use an email that at least seems like it could come from a real person. Don't impersonate anyone, but simply send it from something that looks realistic. I mean, ask yourself, who would you rather trust: john.hannelore.smith (at) gmail.com or faggotcyte69 (at) gckpfff54qdsfs.onion? Both are obviously fake, but at least the former looks kinda OK.
- Provide a dry and technical report. It should almost look like something that could have been procedurally generated. Also try to be brief (yeah, I know "look who's talking". I'm getting there :P).
- Write them a detailed description of what you have done, what was the intention, the effect and what could be the underlying problem in your experience. Attaching a screenshot is also a good idea.
However, even with all of that, you are more than likely to be treated like a criminal. It's a thankless work and I would sincerely advise you to only report it to sites that openly offer reward (usually some sort of a t-shirt, branded bauble or simply a mention in the 'thanks' section. that said, some offer cash rewards). Also, don't bother with reporting if:
- There's no direct way to contact developers, administration or security.
- Helpdesk interactions look as if the IT tech on their side was some sort of a shaved monkey. Rude, dismissive, terrible writing, typos. That sort of thing.
- If it's a Japanese company, just fuck the hell away. You will most likely be served a bunch of insults in Engrish followed by being blocked/redirected to spam. I don't know what it is, but so far they are 3 for 3 when it comes to IT people from Japan. Also, how can you tell that it's a Japanese company? Their English is going to be worse than mine, and that is saying something.
8. Just think for yourself and have fun with it.
There's no hand-holding. It's OK to use Google, StackOverflow or similar resources, but it's only supplementary. Without knowing the basics, your insight is going to be useless and left to purely coincidental cases. Without trying to play around with stuff, you will fall back into patterns and this isn't going to aid you with trying to approach problems from a new angle. It's a lot like mathematics, where once you will go past the tedium of doing stacks of problems and asking "when I will use it in life" it becomes a creative (yet structured and formal) outlet for your ideas. As it should be clear by this point, I'm finding most of this stuff just by curiously bumming around and being observant. It's not enough to become a pro, but that's not my goal.
I think that that's it from me. If anyone has any questions or wants to provide better resources or insights I, by all means, welcome it!
*) Obviously, a determined person who knows a thing or two about security and isn't just gonna give up after unpromising nmap scan is still a threat, but that's a minority. Actually, you can harden your network by making a use out of the mentioned Metasploit. Attack yourself and try to find a fix for the successful intrusions. So there, now you have your own place where you can simultaneously experiment with both intrusions and prevention all while not needing anyone's consent. If you don't have a spare computer, buy something like Raspberry Pi or two and make a network in a box using some discount router. Seriously, all of it (including the router) can fit into a shoebox and can cost under 100 USD. Just keep the box open when it's all turned on for heating reasons.