[#SVC-2693] Avatars triggering money() events in scripted ATMs but ATM owners not receiving funds

2. Second Life Service - SVC

Avatars triggering money() events in scripted ATMs but ATM owners not receiving funds

Created: 25/Jul/08 05:10 PM Updated: 27/Jul/08 08:42 PM

Component/s:

Scripts

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Environment:

Unknown what the users environment is.

Description

« Hide

http://www.intlstockexchange.com/punbb/viewtopic.php?id=407

"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.
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.

Here is a little information about what happened. In the ATM there is an event called money(). This event triggers if someone gives you money. When the event fires, it kicks off a chain of instructions that updates the back-end database of this exchange. What happened this morning is someone was able to trigger that event but no money was exchanged between my avatar and the other avatar. Linden scripting language has no check that my avatar actually received the money. This event was triggered but the actual money transaction did not take place, the system just thought the transaction did. Also disturbing, there was an object on the land of the ISE even though permissions were set for only me to build.

How do I know this event triggered and no money was exchanged? There is only one place that the call to the trading system can originate from, money(). If someone could see the script then they could obviously originate the call from somewhere else but this appears to not have happened. There are checks for where the call originates from. The ip address of the originating call was from the LL server for Kailua, I checked. All of the meta information for a call coming from an LL server was correct and I have one other check that is trivial but was satisfied. This means that the call had to originate from the script on the ISE land. So were they able to make a copy of the script and execute it that way, meaning that the money went to them or another alt? I don't know because I can't get Linden Lab representatives to help. They won't discuss or let me talk to anyone. So I am left in a situation where it appears that someone has figured out a very serious security exploit and LL has decided to just ignore me. What is even more bothersome is that other people have now been victims of the exploit. "

If LL would help out, then the exploit could be tracked down. Right now I have to conclude that someone is able to either copy scripts or is able to trigger the money event without money exchanging hands. Either option worries me greatly and the handling of this by Linden Labs is even more discouraging.

Description

http://www.intlstockexchange.com/punbb/viewtopic.php?id=407 "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. 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. Here is a little information about what happened. In the ATM there is an event called money(). This event triggers if someone gives you money. When the event fires, it kicks off a chain of instructions that updates the back-end database of this exchange. What happened this morning is someone was able to trigger that event but no money was exchanged between my avatar and the other avatar. Linden scripting language has no check that my avatar actually received the money. This event was triggered but the actual money transaction did not take place, the system just thought the transaction did. Also disturbing, there was an object on the land of the ISE even though permissions were set for only me to build. How do I know this event triggered and no money was exchanged? There is only one place that the call to the trading system can originate from, money(). If someone could see the script then they could obviously originate the call from somewhere else but this appears to not have happened. There are checks for where the call originates from. The ip address of the originating call was from the LL server for Kailua, I checked. All of the meta information for a call coming from an LL server was correct and I have one other check that is trivial but was satisfied. This means that the call had to originate from the script on the ISE land. So were they able to make a copy of the script and execute it that way, meaning that the money went to them or another alt? I don't know because I can't get Linden Lab representatives to help. They won't discuss or let me talk to anyone. So I am left in a situation where it appears that someone has figured out a very serious security exploit and LL has decided to just ignore me. What is even more bothersome is that other people have now been victims of the exploit. " If LL would help out, then the exploit could be tracked down. Right now I have to conclude that someone is able to either copy scripts or is able to trigger the money event without money exchanging hands. Either option worries me greatly and the handling of this by Linden Labs is even more discouraging.

Show »

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Harleen Gretzky added a comment - 25/Jul/08 05:31 PM

If this is more than just a normal L$ transaction failure, why isn't it filed under SEC?

[ Permlink | « Hide ]

Gordon Wendt added a comment - 25/Jul/08 05:34 PM - edited

Harleen, I'd argue that if it's something that anyone who owns an atm device or even vendor for that matter needs to be concerned about why isn't it being more openly publicized so that the creators and owners of these systems know about this? SEC is a joke, it is a way for LL to quietly either A) fix bugs or B) ignore them and if A normally after a long delay while residents are cluelessly ignorant of their existence and you are smart enough to know that Harleen. I don't think I need to say it but I am keeping copies of all this to put back up if need be if you decide to try to get this spirited away into the either and considering that this was from an exchange press release I bet Int is doing the same thing just in case you want to make this issue "disappear" That's probably the last (at least pending a reply from you) from me on the subject since we've already had this argument several times and this is neither the time nor the place especially since we should be dealing with the issue at hand.

I'll try to spread the word around about this since if this is a malicious exploit then everyone from SLX to automated rent boxes would be effected, I suggest everyone else does the same although I really hope that this doesn't mean that pretty much all scripted commerce comes to a halt until this is fixed.

[ Permlink | « Hide ]

Harleen Gretzky added a comment - 25/Jul/08 05:44 PM - edited

Filing as a SEC would cause LL to immediately look into and maybe nip it before a panic like this starts. If it is not really a SEC they would move it back to SVC and we would know there is no reason to panic.

And I have no intention to make it disappear, why the hell would I want to do that? Or how could I even do that? It will always be in the jira-notify archives anyway.

Plus there is no reason that it could not be filed here and another issue filed under SEC.

[ Permlink | « Hide ]

intlibber BnT added a comment - 25/Jul/08 05:49 PM - edited

Ok I've found that Cocky Daggers concerns are somewhat overblown as there is already a way to check lindex market transactions:

http://forums.secondlife.com/showthread.php?t=99525?lang=en

This is already in use by Apez and SLX. I will be using this to base our transaction history checking scripting. Recommend the other exchanges do likewise

[ Permlink | « Hide ]

intlibber BnT added a comment - 26/Jul/08 05:18 AM

Aria Paine
Genesis Xue
IntergalacticSpaceTimeContinuum Robonaught
Rocket Dean
Hail Fiertze

Ok, these are the avatar names we collected from the four stock exchanges who made fraudulent deposits.

At ACE I have since determined that Aria Paine and Hail Fiertze made a few legitimate deposits via our ATMs in Sentry and Venture Square. Aria Paine then made a fraudulent deposit of 9000 L$ from Island for Unit Tests sim in a counterfiet atm device with the following data:

View Node

Id
43
Type
A
Approval Status
U
Force Offline
1
Created
2008-07-25 05:27:34
Modified
2008-07-25 14:09:21
Location Notes

Sim
Island for Unit Tests
Coords

Last Transaction
0000-00-00 00:00:00
Xmlrpc Key
f5d1be8a-3ed7-d505-4efe-ece89d984c34
Object Key
a5ebfa33-5029-d2bd-4de6-96f3d488a91e
Owner Name
Aria Paine
Owner Key
ada1b928-f1ac-4325-b748-97dd0195b8ba
Version
1.2dev

This node (ATM) does not show up on our node list for some reason, so it is not making any initialization attempts when it is first rezzed. The fact it is reporting a version 1.2dev (our current ATM version) shows that the person has stolen the ATM script full perms.

We are implementing an ATM owner check on our server to prevent further activity, but this sort of exploit should not be possible in the first place.

[ Permlink | « Hide ]

Lex Neva added a comment - 26/Jul/08 10:55 AM

If I understand your latest comment correctly, you're saying: The way they tricked your system is by setting up a counterfeit ATM device, and not by managing to trigger the money() event in one of your own ATMs?

[ Permlink | « Hide ]

Gordon Wendt added a comment - 26/Jul/08 12:23 PM - edited

If Lex is right then arguably this isn't an lsl exploit (although if they can get access to the code then that itself is quite troubling) just an oversight in not properly implementing an ownership check in your code. Supposedly it's possible to implement your system with the assumption that the code is compromised (supposedly Slexchange is setup that way) however it shouldn't be necessary to do so. Do you have idea how they may have gotten access to the atm script code?

[ Permlink | « Hide ]

intlibber BnT added a comment - 26/Jul/08 02:44 PM - edited

This is the thing: They had to have used something like the 'supercopybot' I've been hearing about that can steal contents of a prim as well. ALL four stock exchanges were hit in this manner: SLCapex, ISE, VSTEX, and ACE. The only way one person could have gotten the scripts that all four exchanges use is by stealing a copy of a real ATM in each case, as all four exchanges use different ATM scripts.

The transaction records show that they always made a few legitimate deposits in a legit ATM before making an attempt with a counterfiet ATM in another sim.

So its quite clear that they did something while interacting with a legit ATM that allowed them to steal the ATM scripts full perms.

I agree that exchange servers should not be vulnerable even if the ATM code is known. When we worked with Unoti Qonset on installing this system, he claimed that if an ATM was not on an approved list it would not be able to interact with the system.

However as you may know, Yukiko Omegamu no longer works for us, she and Quanta Torok stole a copy of our server software before damaging our database tables, any vulnerabilities those two have figured out still would only apply to us and SLCapex, not to ISE and VStex.

Cocky portrayed it as an lsl exploit, however I agree, it is most likely not, I dont think his system stores enough data about transactions really to indicate what happened like ours does, but it is a permissions exploit that allows people to get full perms copies of scripts, which should be a serious issue for anybody. If it is a script theft issue, then this is even bigger a problem than previously thought.

I haven't heard of any new script permissions exploits like this, other than possibly the 'supercopybot', which is talked about but not seen (and I am told keeps the original permissions). Frankly this looks more like someone with Linden powers is behind it.

[ Permlink | « Hide ]

Gordon Wendt added a comment - 26/Jul/08 03:12 PM

I'm not sure what's client > SL Server > Your server and what's SL Server > Your Server and then SL Server > Client, the latter meaing your client wouldn't be able to intercept the script communications with your external database but it seems that if they have the keys to the castle as it were (your script) then yes I'd say you have a huge problem until you can implement an unspoofable (if there is such a thing) verification of ownership. If I'm wrong (as I often am) and the atm's are sending certain data to the client that they shouldn't then that's a huge flaw in the architecture of lsl since in theory the client shouldn't be getting any data from these db calls your scripts are making because if they did... well I'd rather not even think about it.

[ Permlink | « Hide ]

Strife Onizuka added a comment - 26/Jul/08 04:38 PM - edited

intlibber, you should verify that all of your ATMs are still in world. Look to see if any ATMs are missing.

My advice is to take advantage of the Next User permissions to lock down your scripts. Send the scripts through an alt before deploying them.

[ Permlink | « Hide ]

Lex Neva added a comment - 27/Jul/08 01:27 PM

As I see it, there are several possibilities here, some of which have already been ruled out:

1) money() event triggered but money not transferred
2) some kind of heretofor unknown exploit involving copying a script owned by someone else, full perms.
3) A rogue (possibly former) employee of intlibber is assisting the criminals.
4) As intlibber said, a rogue Linden is assisting the criminals.

1 seems to be ruled out by the evidence of an illegitimate ATM. With the exploit suggested in #2, I could imagine much more effective ways of making money and/or causing havoc. 3 is what I started to think before I started to read intlibber's latest comment. It fits the evidence we've heard so far, including the limited details of the system's security that intlibber has described (namely, a secret key in the ATMs). It's also a simple explanation, and with the revelation of rogue former employees that have already sabotaged the business, this is starting to look rather likely. #4 is a serious allegation, and I don't think it's a good idea to make it lightly. I think #3 should be explored fully before slinging accusations against mysterious Lindens.

I'm not saying there's no exploit here... but it does seem at least convincingly possible that this is due to a rogue insider.

[ Permlink | « Hide ]

Lex Neva added a comment - 27/Jul/08 01:28 PM

Incidentally, if the former employee had the ability to damage your database tables on their way out, they likely had the ability to compromise one or more servers in your network in order to forge deposits later. It can be impossible to detect a skilled intrusion on a live system if the attacker has had a chance to dig in.

[ Permlink | « Hide ]

Quanta Torok added a comment - 27/Jul/08 06:49 PM

While I don't want this to become a flame war on JIRA, I feel like I must respond to IntLibber BnT's statements regarding Yukiko Omegamu and myself, Quanta Torok.

Firstly, I would like to state unequivocally that I have never supplied, I am not currently supplying, nor do I have any intention of ever supplying agents within Second Life the so-called "exchange code" that I received from Mr. IntLibber. Well, I take that back – I had to hire a very prominent coder to modify the ATM code back in February / March-ish in order for it to do what I wanted it to do during the development phase of my website, AndalusiaFinancial.com.

Mr. Brautigan's statement:

"However as you may know, Yukiko Omegamu no longer works for us, she and Quanta Torok stole a copy of our server software before damaging our database tables, any vulnerabilities those two have figured out still would only apply to us and SLCapex, not to ISE and VStex. "

I don't even know where to begin, so I will just state this:

I feel that he makes this statement, not because he has any information regarding my 'activities' but because I am suing him in Grafton County Court, New Hampshire to attempt to collect some of the monies I paid for him to develop and launch my website (Case #08SC00155). If I were to engage in surreptitious behavior, then I would be endangering any court proceedings. I would rather skewer Mr. Brautigan in court, rather than online.

So, thank you for reading this post and I'll leave you to your dissection of the ATM code issue

[ Permlink | « Hide ]

Suki Rush added a comment - 27/Jul/08 08:10 PM

I don't see how to repo this issue if there's a working example to show how to repo this issue then please post not actual code but an example code to show that it is possible.

[ Permlink | « Hide ]

Gordon Wendt added a comment - 27/Jul/08 08:42 PM

Suki I'll leave reopening this to Lex or Int if they feel like it but I think in this case an argument that could be made that since nobody really knows as of yet what the specific cause is it would be difficult if not impossible to provide a repro and thus one shouldn't really be necessary. Once it can be narrowed down what to even repro I'd be very interested in seeing one too though.

@Int,Quanta, you've both said your piece however I think it would be better if this didn't devolve into you two sniping at each other (just preemptively saying that since that's what usually happens in cases like this) or at least take it off JIRA if you decide to do so. I don't know what the facts are, I don't want to know really but unless it's relevant to the issue I think I can preemptively state that it should be kept off here.