Somehow we (the programming profession) are doing this whole thing wrong, and I'm not sure why.
The implementations across languages are remarkably similar, I suppose due to the lineage of the original C apis from the various DB vendors.
I don't see any easy way to fix it. If it's possible, and easy to do, it will keep happening.
Pretty much only explicit checks are able to remove the tainted flag from the data. As such you limit the security problems to faulty checks. It is impossible to forget to check something.
Above is used in Bugzilla. Despite all of that, it's still pretty easy to make mistakes. IMO it's rather unfortunate that not more languages have such a feature. This as Perl code if often pretty difficult to read (it doesn't have to be!).
Maybe it can be pitched to Rust.
Additionally, there is open source decompiler called Snowman [2] that is pretty neat also.
[1] https://www.hex-rays.com/index.shtml [2] http://reverseengineering.stackexchange.com/questions/3546/e... [3] https://github.com/yegord/snowman
[1] "This obfuscation is intended to discourage GitHub Enterprise customers from making modifications to the VM. We know this 'encryption' is easily broken."
> So, let’s open IDA Pro!
The custom SQL query is something that is hard to prevent. It is still hard to use ActiveRecord/Arel for everything. I'm sure GitLab is not immune to it.
GitHub chooses to encrypt their source code to prevent modifications. Our experience at GitLab is that customer modifications don't cause a lot of extra load on our support team. But of course that might be caused by having different architectures and customers.
Most of the companies I have worked at that require code obfuscation and / or encryption do so because they believe someone will steal their source and re-use it or at least discover how it works and re-implement it in an attempt to steal customers (typically they suggest China in all of those). I'm not sure what GitHub's reasoning is but I hadn't heard of someone doing it to prevent additional support load.
That's an interesting an angle I hadn't thought of.
"This obfuscation is intended to discourage GitHub Enterprise customers from making modifications to the VM. We know this 'encryption' is easily broken."
So that's probably why he assumed their reasoning was to do with reducing support by avoiding modifications by customers.
Otherwise if you're concatenating strings to invoke your stored proecedures you're in the same boat.
What's causing that, your ISP?
In similar bug bounty posts, a user will post all this brilliant setup code, these tools I never heard of to decompile binaries, view source, get through obfuscation, etc.
Then, when you get to the meat and bones, they just go "Ok and vulnurability is here, and you exploit it like this. Ta data."
It's very anti-climatic, and I don't learn much in the process. I would like to learn more about what your thought process is like after you get the code. How did you narrow your focus on ActiveRecord? Did you just know from seeing it? I would love to learn more. Do expert pen-testers have this checklist of exploits they try?
Sorry if it sounds like whiny, I would just love it if these had more meat in the actual finding of the exploit as they did the setup.
Something WAHH touches on, and experienced pentesters get a feel for, is more complex interactions. Often that means chaining several not-so-bad bugs together to build something really exciting. Sometimes they're just obscure consequences of say, a rather complex authorization system. These are typically a lot harder to find, and may involve simultaneous code audits. Ideally, your long-term in-house security people find these, because any attacker that does is in the 95th cleverness percentile.
So, TL;DR: start with WAHH; then go find some vulns, and start thinking about what the app does in terms of alternative things a program could do that a reasonable programmer who was just trying to get it to work might not have thought about.
If you're looking for tools to play with, you can do worse than downloading Kali and running it on a VM. If nothing else, it'll give you a pretty big catalog of tools to start looking at. I think WAHH covers basic Burp Suite usage, but Kali has some other tools like sqlmap and BeEF that aren't too tricky to get started with.
WAHH: http://mdsec.net/wahh/ Kali: https://www.kali.org/
https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table...
It literally contains almost everything for Webapps.
The next step is finding your own exploits or doing bug bounties.
If you are more interested in the other side of hacking (i.e. everything but webapps, usually OS level stuff) someone more informed than me can probably give you advice, but starting with microcorruption or similar won't hurt.
[0] http://guides.rubyonrails.org/active_record_querying.html#or...
The lesson is you should always strongly assert the type of user input (where you can, convert to known good values which is even better), and never magically convert types as rails/ MySQL does here. It's less convenient but safer.
Edit: Can't see to format it correctly, just check the original source.
2016/12/26 05:48 Report vulnerability to GitHub via HackerOne
2016/12/26 08:39 GitHub response that have validated issue and are working on a fix.
2016/12/26 15:48 Provide more vulneraiblity detail.
2016/12/28 02:44 GitHub response that the fix will included with next release of GitHub Enterprise.
2017/01/04 06:41 GitHub response that offer $5,000 USD reward.
2017/01/05 02:37 Asked Is there anything I should concern about if I want to post a blog?
2017/01/05 03:06 GitHub is very open mind and response that it’s OK!
2017/01/05 07:06 GitHub Enterprise 2.8.5 released!
Day 1 - Setting VM
Day 2 - Setting VM
Day 3 - Learning Rails by code reviewing
Day 4 - Learning Rails by code reviewing
Day 5 - Learning Rails by code reviewing
Day 6 - Yeah, I found a SQL Injection!