Обсуждение: [GENERAL] [OT] Help: stories of database security and privacy
Hi folks, in a few weeks I will start a short course on the basics of database security for a group of high-school students with a background in elementary relational theory and SQL. I plan to discuss the usage of grant/revoke, RBAC, DAC, and inference in statistical databases. I'd like to take the opportunity to also engage students about the topic of privacy (or lack thereof). So, I am here to ask if you have interesting/(in)famous stories to share on database security/privacy "gone wrong" or "done right"(tm), possibly with technical details (not necessarily to share with the students, but for me to understand the problems). I am asking to this list because I will use PostgreSQL, so maybe I can collect ideas that I can implement or demonstrate in practice, or use as case studies. Thanks in advance, Life.
On 2017-04-12 09:09, Lifepillar wrote: > Hi folks, > in a few weeks I will start a short course on the basics of database > security for a group of high-school students with a background in > elementary relational theory and SQL. I plan to discuss the usage of > grant/revoke, RBAC, DAC, and inference in statistical databases. > > I'd like to take the opportunity to also engage students about the > topic > of privacy (or lack thereof). So, I am here to ask if you have > interesting/(in)famous stories to share on database security/privacy > "gone wrong" or "done right"(tm), possibly with technical details (not > necessarily to share with the students, but for me to understand the > problems). I am asking to this list because I will use PostgreSQL, so > maybe I can collect ideas that I can implement or demonstrate in > practice, or use as case studies. > > Thanks in advance, > Life. One case that I remember from an ancient version of the book "hacking exposed" was about a MySQL server that was running under the root user. A badly written application allowed some SQL injection that let a hacker issue a SELECT INTO OUTFILE query that "selected" a bash script into the .login file of the root user, and the next time the root user logged in, the script would create a new superuser account for the hacker. I remember this particular example mainly because of the way that people I told it to reacted; some were of the opinion that the application was at fault for allowing injection, some thought the DBA was to blame for running as root, but the vast majority did not know that MySQL could write files, let alone overwrite system files. Their responses really made it clear that hackers generally know a lot more about how a setup works than it's maintainer does. Just because you cannot think of a way that a right can be exploited Ever since then I live by the motto; "If it's not absolutely required to be possible, then it should be made absolutely impossible.". As for privacy, the same applies; if a website doesn't have to print the real lastname of a user, then the JSON API should not send that to the client. In fact, the API should refuse to send it, even when asked, unless the user who's asking has rights to do so. Again; denied unless specifically allowed.
On 12/04/2017 10:57, vinny wrote: > On 2017-04-12 09:09, Lifepillar wrote: >> So, I am here to ask if you have >> interesting/(in)famous stories to share on database security/privacy >> "gone wrong" or "done right"(tm), possibly with technical details > > One case that I remember from an ancient version of the book "hacking > exposed" > was about a MySQL server that was running under the root user. A badly > written > application allowed some SQL injection that let a hacker issue a SELECT > INTO OUTFILE > query that "selected" a bash script into the .login file of the root user, > and the next time the root user logged in, the script would create a new > superuser account > for the hacker. After tweaking MySQL to be really insecure by unsetting secure_file_prev, using grant file, etc..., I am indeed able to write anywhere where the user running MySQL is able to. This, combined with a trivial SQL injection vulnerability in a popular web application, makes (I think) an interesting and easy to explain example of how one might take over a system or an account. Correct me if I am wrong, in PostgreSQL something similar can be achieved using lo_export(), although you must connect as a superuser to do that (while in MySQL you may grant file system access to any user). > I remember this particular example mainly because of the way that people > I told it to reacted; > some were of the opinion that the application was at fault for allowing > injection, > some thought the DBA was to blame for running as root, > but the vast majority did not know that MySQL could write files, let > alone overwrite system files. Good point. Thanks! Life.
On 2017-04-26 11:47, Lifepillar wrote: > On 12/04/2017 10:57, vinny wrote: >> On 2017-04-12 09:09, Lifepillar wrote: >>> So, I am here to ask if you have >>> interesting/(in)famous stories to share on database security/privacy >>> "gone wrong" or "done right"(tm), possibly with technical details >> >> One case that I remember from an ancient version of the book "hacking >> exposed" >> was about a MySQL server that was running under the root user. A badly >> written >> application allowed some SQL injection that let a hacker issue a >> SELECT >> INTO OUTFILE >> query that "selected" a bash script into the .login file of the root >> user, >> and the next time the root user logged in, the script would create a >> new >> superuser account >> for the hacker. > > After tweaking MySQL to be really insecure by unsetting > secure_file_prev, using grant file, etc..., I am indeed able to write MySQL used to be "really insecure", I'm glad to see they have taken measures to prevent this attack. (now let's just hope that you cannot use SQL to change tose security settings :-) > > Correct me if I am wrong, in PostgreSQL something similar can be > achieved using lo_export(), although you must connect as a superuser to > do that (while in MySQL you may grant file system access to any user). Technically, yes, but you cannot supply a path as easily as in MySQL. The moral of the story is not so much that MySQL is unsafe, but that attacks can come from the most unexpected places. Even from things you did not even know to be possible. Again: if something sis not required to be possible, then measures should be taken to make it impossible.