Silk Road forums
Discussion => Silk Road discussion => Topic started by: thedoser on July 21, 2012, 03:35 am
-
Just a thought: it might be useful for the world-wide community if the software for running a site like SR were open source, should SR ever go down.
-
Yea good idea. Also, I think all the drugs offered on here would be beneficial for people that want to get high, so all vendors should give out drugs for free.
-
The software would be the easy part. It's basically a multi vendor store with some integration with btc
Who would risk their ass to keep this anonymous? It really takes some risk, so the profit is more than deserved.
-
Just a thought: it might be useful for the world-wide community if the software for running a site like SR were open source, should SR ever go down.
That would be good, but probably not for the reasons you're thinking of.
What I'd like to see is the message and order system released so that it can be independently audited to confirm there are no security flaws in it, that the encryption on the messages is up to par and that orders (e.g. addresses) are securely deleted when finished.
-
u guys r cracking me up lol
-
Yea good idea. Also, I think all the drugs offered on here would be beneficial for people that want to get high, so all vendors should give out drugs for free.
Also, all bitcoins should be split evenly among everybody!
BB
-
Can we remove the use of names, after all inside we're all the same people, you know what I mean man?
-
Just a thought: it might be useful for the world-wide community if the software for running a site like SR were open source, should SR ever go down.
That would be good, but probably not for the reasons you're thinking of.
What I'd like to see is the message and order system released so that it can be independently audited to confirm there are no security flaws in it, that the encryption on the messages is up to par and that orders (e.g. addresses) are securely deleted when finished.
If SR is doing encryption, they're doing it terribly wrong- EXCEPT if the database was kept on a TrueCrypt volume or similar, with a readily accessible way to permanently delete the key.
If you're relying on SR to encrypt your address, you might as well start preparing your anus while you have time. The entire point of GPG is that SR can't read your address.
-
Just a thought: it might be useful for the world-wide community if the software for running a site like SR were open source, should SR ever go down.
That would be good, but probably not for the reasons you're thinking of.
What I'd like to see is the message and order system released so that it can be independently audited to confirm there are no security flaws in it, that the encryption on the messages is up to par and that orders (e.g. addresses) are securely deleted when finished.
I would bet everything I own that this is not happening.
-
you always have to rely on yourself for properly encrypting everything and not sending cleartext messages and persona information.
as somebody else pointed out this is just a multivendor software with an forum attached and btc integrated.
What DPR and crew do is making it fast despite tor...moving it often I assume..organizing the mixing of coins..harden the server as much as possible..and keeping their heads :) and for that they deserve their ration absolutely..
-
Just a thought: it might be useful for the world-wide community if the software for running a site like SR were open source, should SR ever go down.
That would be good, but probably not for the reasons you're thinking of.
What I'd like to see is the message and order system released so that it can be independently audited to confirm there are no security flaws in it, that the encryption on the messages is up to par and that orders (e.g. addresses) are securely deleted when finished.
If I wrote the software and you asked for it to be open source, I'd probably tell you to get fucked. Any sensitive info should be encrypted PGP on your end, and if you don't that's your bad. You should realize that worst-case, they would be able to login to your account and few your current orders + feedback + any unencrypted messages. As long as you operate off of that assumption, I don't see too many potential risks.
Also if they released the source code, I'm sure someone would find some tiny hole and fuck us all and cheat the system. Security by source control isn't ideal, but hopefully it's written by someone with a little security background and the main things you'd easily discover on your own (WITHOUT it's source code) are taken care of.
-
Also dont forget guys should LEO ever work it out far enough I am sure DPR has some kind if script , which if he does not log in every 3 weeks or so (into the script CP) all registered emails get a copy of SR Source :)
So if LEO fucks up our beloved SR ..we will spawn a thousand of them worldwide :)
-
What I'd like to see is the message and order system released so that it can be independently audited to confirm there are no security flaws in it, that the encryption on the messages is up to par and that orders (e.g. addresses) are securely deleted when finished.
If SR is doing encryption, they're doing it terribly wrong- EXCEPT if the database was kept on a TrueCrypt volume or similar, with a readily accessible way to permanently delete the key.
They may or may not be doing it properly, but the problem is we have no way of knowing. Right now SR's actual security is like Schrödinger's Cat: it's both secure (alive) and insecure (dead) simultaneously.
If you're relying on SR to encrypt your address, you might as well start preparing your anus while you have time. The entire point of GPG is that SR can't read your address.
Yep, I assume that Schödinger's Cat is dead and behave accordingly.
-
If SR is doing encryption, they're doing it terribly wrong- EXCEPT if the database was kept on a TrueCrypt volume or similar, with a readily accessible way to permanently delete the key.
If you're relying on SR to encrypt your address, you might as well start preparing your anus while you have time. The entire point of GPG is that SR can't read your address.
I don't think you know how web servers and SQL databases work.
Your bank doesn't store your account details in a database on a truecrypt volume.
-
What I'd like to see is the message and order system released so that it can be independently audited to confirm there are no security flaws in it, that the encryption on the messages is up to par and that orders (e.g. addresses) are securely deleted when finished.
If I wrote the software and you asked for it to be open source, I'd probably tell you to get fucked. Any sensitive info should be encrypted PGP on your end, and if you don't that's your bad. You should realize that worst-case, they would be able to login to your account and few your current orders + feedback + any unencrypted messages. As long as you operate off of that assumption, I don't see too many potential risks.
Oh, I'm well aware of that. The shocking thing is the number of people here who aren't and how many of them are vendors.
Also if they released the source code, I'm sure someone would find some tiny hole and fuck us all and cheat the system. Security by source control isn't ideal, but hopefully it's written by someone with a little security background and the main things you'd easily discover on your own (WITHOUT it's source code) are taken care of.
Security through obscurity is no security at all.
Fortunately the majority of the site appears to just be HTML and CSS, although that can be deceiving (see below). DPR has also said that the new version will be the same, which is why I only really care about the message and order system. At least we don't have to worry about the sort of problems opened up by Javascript.
That said, a determined and sufficiently proficient attacker may still find a way in without access to the code and then we're still fucked. Remember, Tor can run just about any protocol across it if you configure your systems to handle it.
Now, I was going to say above that we didn't have to "worry about the sort of problems opened up by PHP and Javascript" but it turns out that isn't accurate. Going to a deliberately wrong page on the SR site (without logging in) results in this error message:
An Error Was Encountered
Unable to load your default controller. Please make sure the controller specified in your Routes.php file is valid.
PHP. Hmmm, now what happens if we do a Google search on "php exploit" ... I'm not going to bother because I already know the list is large.
Running a search on that specific error message indicates that error is common with a PHP framework called CodeIgniter. Then we just run another search for "codeigniter exploit" and lo and behold there's a list of SQL injections, remote file vulnerabilities, etc.
That's what I found in five minutes. Ten if you count wandering into the kitchen to make a cup of coffee.
The point is that flaws can be found in any system whether the source code is available to the attacker or not. Shit, hacker tales from the past thirty years are filled with such anecdotes. Opening the source code to peer review makes it more likely that flaws will be found quicker and more easily. More importantly it means that those flaws will be fixed.
I guarantee you there will be flaws and some enterprising person, whether in law enforcement or otherwise, will be looking for them.
-
Luis, PHP is by far one of the most exploited languages out there. It's not that PHP by itself is inherently insecure but most developers copy & paste insecure code because PHP offers you 100 ways to do the same thing, and 99 out of 100 of them are begging to be exploited.
Multiple people including myself have begged SR staff to shut off error reporting, its the most handy tool you can provide a hacker, in fact its how most exploit gets their information back, through error reporting. It's a shame to see that it apparently is still on for public viewing. Ideally you don't have any exploits at all, but making the hacker work with the same "error occurred" message makes their job a lot tougher and sometimes even impossible to be useful.
Some links discussing securing a PHP applicaiton.
http://net.tutsplus.com/tutorials/php/5-helpful-tips-for-creating-secure-php-applications/
https://learn.iis.net/page.aspx/744/secure-php-with-configuration-settings/
-
Luis, PHP is by far one of the most exploited languages out there.
Yep.
It's not that PHP by itself is inherently insecure but most developers copy & paste insecure code because PHP offers you 100 ways to do the same thing, and 99 out of 100 of them are begging to be exploited.
The history of the Mambo/Joomla is a fine example of that. The joke about that one was that it was a security hole large enough to drive a truck through with a CMS wrapped around it.
Multiple people including myself have begged SR staff to shut off error reporting, its the most handy tool you can provide a hacker, in fact its how most exploit gets their information back, through error reporting. It's a shame to see that it apparently is still on for public viewing. Ideally you don't have any exploits at all, but making the hacker work with the same "error occurred" message makes their job a lot tougher and sometimes even impossible to be useful.
I agree, that would be a great help. Ideally I should've just received a plain 404 error from what I did and not something which told me how to find the framework SR uses.
Some links discussing securing a PHP applicaiton.
http://net.tutsplus.com/tutorials/php/5-helpful-tips-for-creating-secure-php-applications/
https://learn.iis.net/page.aspx/744/secure-php-with-configuration-settings/
Thanks, they both look useful.
-
Here some additional links and interesting threads..
http://forums.freebsd.org/showthread.php?t=32823
http://www.martini.nu/blog/2010/06/tor-vbox.html
Anecdote to hiddeen service which got busted->
Those hidden services were traced after being hacked by the police. Some of them were not traced, because they used isolation that the police could not break out of (pretty sure they were using virtualbox for isolation actually, although of course hardware or paravirtualization or OS virtualization are better as was discussed at length in other threads).
Not a failure of Tor in these cases but a failure of the people who ran those sites to keep them fully patched.
Well, sure. However, good hardening practices include the assumption that the box can be compromised (if not already so), and configure it as such -- just like we assumed someone having root in the host (and chflag'ed accordingly.) The chances of "leaking" identifying information are greater from the guest OS to VirtualBox than they are from a jail to the host that is properly locked down. In addition, it adds an extra obfuscation layer that an attacker would have to break through. Root access in a jail is fairly useless. They can't make any permanent system modifications, nor read any additional system data that a normal user couldn't. They can't even see the current firewall ruleset. They can read other user's homedir data -- but just like the real operator of this service, an attacker would have no information available to determine identity.
Some other things to set up:
Bump up the LoginGraceTime in the sshd config, since Tor is slow.
Add automatic shell history removal to /etc/csh.logout and /etc/profile, depending on if the default shell is tcsh or bash, respectively.
Add a reasonable hostname to /etc/hosts for 127.0.0.2.
Disable adjkerntz in /etc/crontab -- time is set from the host.
Maybe precreate a bunch of users? If you're invited to a shell server by a pal, and there is only one other account... that would be an identity leak.
Install any additional ports/packages you want to offer from the shell. I like ntalk/ytalk!
How about a quick script for creating new accounts? Maybe linked to a guest account for anonymous creations?
I am pretty sure soon SR will run on some Raspberry PI behind hidden walls in cracked cable lans within virtualbox :)
-
SQL injections are easy to stop arent they?
Just set SQL to EXACT VALUES and accept nothing else?
I am in no way equpped with knowlege in those matters...just assumed :o
-
Luis, PHP is by far one of the most exploited languages out there. It's not that PHP by itself is inherently insecure but most developers copy & paste insecure code because PHP offers you 100 ways to do the same thing, and 99 out of 100 of them are begging to be exploited.
Multiple people including myself have begged SR staff to shut off error reporting, its the most handy tool you can provide a hacker, in fact its how most exploit gets their information back, through error reporting. It's a shame to see that it apparently is still on for public viewing. Ideally you don't have any exploits at all, but making the hacker work with the same "error occurred" message makes their job a lot tougher and sometimes even impossible to be useful.
Some links discussing securing a PHP applicaiton.
http://net.tutsplus.com/tutorials/php/5-helpful-tips-for-creating-secure-php-applications/
https://learn.iis.net/page.aspx/744/secure-php-with-configuration-settings/
I'm not totally sure it's fair to say that PHP is one of the most exploited languages, it just happens to be one that a ton of websites are authored in and as such become what gets exploited. It's no more open to exploits than any other language for the most part.
Joomla etc are all terrible examples, just because they're written in PHP isn't a reflection of the language but just poor code quality in many cases. In more than a decade, I've found a fair share of exploits in scripts, and to date none of mine have ever been exploited. With a stable grasp of security, it's really all about what data the user sends and making sure to sanitize it. If you have EVERYTHING that comes from the user mistrusted, then by default you go out of your way to intval(), mysql_real_escape_string() etc everything and it becomes very very difficult to find large, worthwhile exploits.
In terms of SR, if you #1 use PGP for every message and #2 don't keep money sitting around in your account for a period of time and #3 remove your messages etc... I honestly don't know much damage could really harm users. You can't decrypt my messages, you can't spend my money, you can't read my past history of purchases and messaging easily... beyond that I really hope DPR and his crew know their stuff. Open source though is just a problem waiting to happen, perhaps independent security audits by a few people with the right security knowledge would be a better idea.
SQL injections are easy to stop arent they?
Just set SQL to EXACT VALUES and accept nothing else?
I am in no way equpped with knowlege in those matters...just assumed :o
If you run EVERY piece of user data through mysql_real_escape_string() you should be 100% safe from MySQL injection. There is one scenario in a specific character set where they can send 2 characters together that gets parsed as a single quote (') instead, and the whole issue revolves around making sure single quotes are replaced by \' so MySQL knows where your string starts and stops vs thinking it stopped mid string and reading the rest of the string as more command (vs data storing to a column).
It's really not very difficult, any exploit that relies on it is probably due to lazy programming. I get super paranoid when it comes to sql injection, and even variables I KNOW are integers I sanitize once more JUST TO BE CERTAIN NO ONE FUCKED WITH CODE BETWEEN THE INITIAL VARIABLE AS A NUMBER AND WHEN I USE IT IN THE DATABASE. If you follow those rules, I'd dare say you can't go very wrong.
-
If you run EVERY piece of user data through mysql_real_escape_string() you should be 100% safe from MySQL injection. There is one scenario in a specific character set where they can send 2 characters together that gets parsed as a single quote (') instead, and the whole issue revolves around making sure single quotes are replaced by \' so MySQL knows where your string starts and stops vs thinking it stopped mid string and reading the rest of the string as more command (vs data storing to a column).
It's really not very difficult, any exploit that relies on it is probably due to lazy programming. I get super paranoid when it comes to sql injection, and even variables I KNOW are integers I sanitize once more JUST TO BE CERTAIN NO ONE FUCKED WITH CODE BETWEEN THE INITIAL VARIABLE AS A NUMBER AND WHEN I USE IT IN THE DATABASE. If you follow those rules, I'd dare say you can't go very wrong.
Using things like mysql_real_escape_string is a great example of putting a band-aid on a broken arm. Parametrized queries are a far better solution http://php.net/manual/en/pdo.prepared-statements.php . In fact if you ever use any string manipulations on a SQL string I'd say you are one step away from not realizing how someone could exploit what you just wrote. It gets even more tricky to think about when you get into the multi-stage injection attacks where the data in the database is whats used to cause the injection itself, yet one more reason you stay away from building SQL in any case.
-
If you run EVERY piece of user data through mysql_real_escape_string() you should be 100% safe from MySQL injection. There is one scenario in a specific character set where they can send 2 characters together that gets parsed as a single quote (') instead, and the whole issue revolves around making sure single quotes are replaced by \' so MySQL knows where your string starts and stops vs thinking it stopped mid string and reading the rest of the string as more command (vs data storing to a column).
It's really not very difficult, any exploit that relies on it is probably due to lazy programming. I get super paranoid when it comes to sql injection, and even variables I KNOW are integers I sanitize once more JUST TO BE CERTAIN NO ONE FUCKED WITH CODE BETWEEN THE INITIAL VARIABLE AS A NUMBER AND WHEN I USE IT IN THE DATABASE. If you follow those rules, I'd dare say you can't go very wrong.
Using things like mysql_real_escape_string is a great example of putting a band-aid on a broken arm. Parametrized queries are a far better solution http://php.net/manual/en/pdo.prepared-statements.php . In fact if you ever use any string manipulations on a SQL string I'd say you are one step away from not realizing how someone could exploit what you just wrote. It gets even more tricky to think about when you get into the multi-stage injection attacks where the data in the database is whats used to cause the injection itself, yet one more reason you stay away from building SQL in any case.
While I don't disagree that using a prepared statement may be EASIER in many capacities, I whole heartedly disagree with any notion that mysql_real_escape_string() etc is a problem by any stretch of the imagination. Give me just one ONE example of how you would be able to exploit a properly written query based around mysql_real_escape_string(). The only one I've ever been made aware of is a single issue with a character set and symbols that use multicharacters which would allow it to be interpreted as a single quote.
If you were teaching someone new, and wanted to take a few options off the table for them to screw things up, okay. But I've been doing this a really long time at this point, and have no reason to believe that directly sending your SQL query as such would be a problem. At the end of the day, your prepared statement IS sending a full SQL query to the database, so it has to be using internal functions to sanitize the data FOR you, and mysql_real_escape_string() IS the function that PHP bases safe SQL queries on.
-
If you run EVERY piece of user data through mysql_real_escape_string() you should be 100% safe from MySQL injection. There is one scenario in a specific character set where they can send 2 characters together that gets parsed as a single quote (') instead, and the whole issue revolves around making sure single quotes are replaced by \' so MySQL knows where your string starts and stops vs thinking it stopped mid string and reading the rest of the string as more command (vs data storing to a column).
It's really not very difficult, any exploit that relies on it is probably due to lazy programming. I get super paranoid when it comes to sql injection, and even variables I KNOW are integers I sanitize once more JUST TO BE CERTAIN NO ONE FUCKED WITH CODE BETWEEN THE INITIAL VARIABLE AS A NUMBER AND WHEN I USE IT IN THE DATABASE. If you follow those rules, I'd dare say you can't go very wrong.
Using things like mysql_real_escape_string is a great example of putting a band-aid on a broken arm. Parametrized queries are a far better solution http://php.net/manual/en/pdo.prepared-statements.php . In fact if you ever use any string manipulations on a SQL string I'd say you are one step away from not realizing how someone could exploit what you just wrote. It gets even more tricky to think about when you get into the multi-stage injection attacks where the data in the database is whats used to cause the injection itself, yet one more reason you stay away from building SQL in any case.
While I don't disagree that using a prepared statement may be EASIER in many capacities, I whole heartedly disagree with any notion that mysql_real_escape_string() etc is a problem by any stretch of the imagination. Give me just one ONE example of how you would be able to exploit a properly written query based around mysql_real_escape_string(). The only one I've ever been made aware of is a single issue with a character set and symbols that use multicharacters which would allow it to be interpreted as a single quote.
If you were teaching someone new, and wanted to take a few options off the table for them to screw things up, okay. But I've been doing this a really long time at this point, and have no reason to believe that directly sending your SQL query as such would be a problem. At the end of the day, your prepared statement IS sending a full SQL query to the database, so it has to be using internal functions to sanitize the data FOR you, and mysql_real_escape_string() IS the function that PHP bases safe SQL queries on.
You totally missed the point, you're relying on yourself to write proper code, 100% of the time. The best of the best fuck up, why write with a style you can easy accidentally forget one case that needed to be wrapped?
Prepared statements often do not reform the SQL, ODBC allows parameters to be passed down by value, ODBC drivers will use those values directly.
So end of the day you can argue all you want that you may be able to write safe code, but that depends on you not making mistakes. I stand by my advice.
-
You totally missed the point, you're relying on yourself to write proper code, 100% of the time. The best of the best fuck up, why write with a style you can easy accidentally forget one case that needed to be wrapped?
Prepared statements often do not reform the SQL, ODBC allows parameters to be passed down by value, ODBC drivers will use those values directly.
So end of the day you can argue all you want that you may be able to write safe code, but that depends on you not making mistakes. I stand by my advice.
As long as your point is that "everyone makes mistakes" then that's accurate. However, a lot of people (such as myself) have constructs in place that build and/or sanitize queries. They're built ON mysql_real_escape_string(), so the original point, and the only one that I was making, is from a SECURITY standpoint, you CANNOT get SQL Injected if you use mysql_real_escape_string() on all of your queries, period.
-
I agree that security through obscurity is not a secure approach.
Doesn't obscurity imply obfuscation, which is the practice of making the source code hard to read, which is entirely different than just having closed-source code that is presumably in unobfuscated files you could plainly read? Obscurity is looked down upon because it just makes you have a more difficult time of understanding the source code
-
I agree that security through obscurity is not a secure approach.
Doesn't obscurity imply obfuscation, which is the practice of making the source code hard to read, which is entirely different than just having closed-source code that is presumably in unobfuscated files you could plainly read? Obscurity is looked down upon because it just makes you have a more difficult time of understanding the source code
http://www.merriam-webster.com/dictionary/obscure
-
I agree that security through obscurity is not a secure approach.
Doesn't obscurity imply obfuscation, which is the practice of making the source code hard to read, which is entirely different than just having closed-source code that is presumably in unobfuscated files you could plainly read? Obscurity is looked down upon because it just makes you have a more difficult time of understanding the source code
http://www.merriam-webster.com/dictionary/obscure
It's an industry term, not totally applicable to apply a generic definition to it. Closed source may technically be considered obscuring, it's just not very specific and implies that something was intentionally put into play to reduce readability rather just maintaining it under lock and key.
-
what happened to " the doser " the NUB with his 15 posts that started this thread cough!
is this the security section?
-
what happened to " the doser " the NUB with his 15 posts that started this thread cough!
is this the security section?
What do you mean? I'm here.
-
After doing some analysis of the Silk Road website, it looks like they're using the CodeIgniter PHP framework on the backend. There's been a bunch of security vulnerabilities with this software, I just pray to god they're using the latest version and not an outdated one. I for one have found some interesting tidbits after manipulating some headers...
http://codeigniter.com
-
I really think u all r gonna have to find someone else to hand u all the keys to the castle!! lol
Someone lock this thread and put it out of it's misery!!