Here is a quick status update.  Someone has figured out a very serious security exploit in SL and based on talks with Linden Labs it won't be acknowledged or fixed any time soon.   Unfortunately we are not the only ones that have been affected and unfortunately others will be impacted.  I'll write up the security exploit and supporting information later.

What this means for you is ATM's will have to stay down.  I need to set up an alt, put money into it, and conduct manual transactions through the alt.  The reason for the alt is in case there are any ATM's I missed, it's not safe for the Cocky Dagger account to carry L$.  It will take me several days to figure this out and I will publish procedures on in-world L$ transactions.  I apologize for this inconvenience but exchanging Lindens through scripts is not safe in SL at this time.


If anyone needs Lindens immediately let me know.  At this time, no deposits will be taken until procedures and feasibility of running a non automated business is determined or LL fixes the problem.

Take your time Cocky.
I can wait

all exchanges are now closed....

Trading will open at 6pm SLT time.  There will be no ATM transactions at this time.  I believe sufficient time has passed that panic selling will be in check.  Trading will open at 6pm SLT time.  I believe enough people have reported and confirmed the exploit that LL will do something about it.

Thanks a lot Cocky.
I will continue trading.
LL makes me very nervous. I do not trust their tricks. Any day they closed the "chiringuito"
Good luck to all

Just a quick Monday update.  No contact from LL and the JIRA that IntLibber started was closed as resolved because it couldn't be replicated.  This is very disheartening.  I know the issue has been reported by other people and they have been victims.  My belief is that LL can not fix the issue since they can't even roll out a new server release therefor they are going to try to moderate the problem, unfortunately it isn't working very well.   The shame is I have looked back at history and the slightest hint of this problem caused a grid wide shutdown, it looks like those days are over.

I'll answer questions later and don't have time to go into detail but I will say this, my discouragement on Friday and the last few days with Linden Labs was premature and they have handled the situation exactly as they should have.

itchygamba wrote:

Hi Cocky,

over at ace I found this posted:

On the ATM transactions script:
a) php script checks the owner of the ATM against the key of ACE BnT
b) php script checks the node number against the list of approved nodes and ignores deposit requests from unlisted/unapproved nodes.
c) php script logs into secondlife.com to check ACE BnT's xml transactions history file for evidence of actual funds transfer before crediting amount to their account on the website.

as a fix for the problem to allow ATM's to run successfully.

Could you please give your thoughts on whether this would fix the problem.

Thanks

Sorry, yesterday was extremely busy and I have been trying to answer all questions asked and forgot to answer this one.

a) This won't stop all exploits only make it a little more difficult if someone can see the script.  This will stop in-world exploits but that doesn't mean that someone won't by pass in-world and go out of world.  With the ability to view the script,  example a nothing but in-world exploits.  It makes things more difficult, which is good, but with the ability to view the script still leaves you open to exploit from out of world.

b)  Same thing as a.

c)  Yes, this will stop any exploit in-world and out-of-world.  If someone can see the script they still have to get a money transaction to appear in SL and this is what I will be implementing.  There  is probably one other effective method of stopping that I am working through the details now but c is the sure thing and what I am developing.

One thing about "c" bothers me and that is the security of having the script "log into" SL.  I know that's the script on the server (purportedly under your full control) and not the "LSL script in the ATM in SL" (whose visibility is now comprimized), but I guess over all it's a good sanity check/solution.  Will that mean "you" (av holding the finances) will be "online in SL" full time? (watchdog/timeout to keep av alive or a delay for ATM transactions to log in to SL and check?  probably log in if not logged in then stay online for a while to speed up the next transactions if they happen soon afterward.)

Then again, I've used SLeek and other clients to log in so that can't be too hard to script in PHP (on your server).  Thanks for the ongoing commentary!  It's a clever little attack vector not directly taking L$ but tricking you into crediting the criminal's account.

"c" also seems to just be double checking "DEPOSITS" into ISE by an av - to make sure a transaction shows (paid the ATM) before crediting the user's account at ISE, whereupon if not really paid into the ATM but the command given (by spying and writing an alternative fraudulent script carrying any "credentials" [copied from the real script and supposedly secret]) the av requests the "money" (tricked into being "deposited" by Cocky into a user account at ISE without real payment) then a regular withdrawl from "their funds" at ISE into the SL av committing the fraud.  (The more direct "request a withdraw" fraud is where the transaction record won't show a fraudulent transaction until that's already happened (and too late)... but that relies upon the user security of what av walks up to the ATM to do the withdrawl.)  Actually, I think I'd agree that "a" and "b" aren't really going to help.  They'd stop someone from playing with an altered LSL script talking to the backend ISE server, but not an out-of-world attack (mimicing the traffic of a real ATM transaction with commands, data, and credentials read from the comprimized script) and spoofing the node/location and other info passing this directly into the (now revealed) back-end ISE server.

There's really (to my thinking so far) no way to validate the "script (LSL, in ATM or faked)" or "out-of-world spoofed transaction command" itself - if it can be seen, any validation method can be comprimised (and security by obscurity is not reliable anyway) so using a crypto token isn't going to help.  It seems that indeed the only sane way is to do the checking/validation of any transaction on the backend/server side under your full control... and have THAT (while logged in to SL) do the "pay or money transfer" (I know it can) or crediting the user's ISE account.  Sure, it's "easier" to do it all in LSL (in the ATM) but that just won't be secured.  This would leave an attack vector of a traffic sniffer (between your server and LL), but I think that's sufficiently remote to the end user/abuser, and isn't the log-in page at the SL web site to your account (transaction history) https as well?

heehee -- what I didn't mention was the DNS vulnerability where I might be able to trick the IP....  [I hate dynamic IPs and dynamic DNS lookups, but it's a fact of life on the Internet]