> Using a sniffer, they are reading the name of the service calls, then
> connecting from some IDE like flexbuilder where they can quickly build
> an array of calls.
I need to check out flexbuilder - so far I thought it was an IDE similar
to regular Flash?
Thing is, they are connecting the actual client. The client is
encryptend (= obscured to the point no decompiler can handle it :) and
without a decompiled client it's pretty much impossible to spoof the
challenge/response handshake for the autorization. Then while they are
connecting, they are adding RTMP packets. I don't know if it's injected
in the same connection or if they are actually opening a new one. But
why connect with the regular client first then?
Also the server does check the referer the client is including. I know
that this is no security at all on a professional level, but we are
talking about hurt egos with some google talents here. I doubt they can
snoop and resend packets or even build their own RTMP connect with
arbitrary parameters. They must be using some sort of tool for it, and
if it runs in the flash client, at least the referer cannot be spoofed,
can it?
> The other problem is the 'someone'. It is time to connect real accounts
> with users on red5 to eliminate the 'someone' and turn it into an id/ip.
Can't do that. Some versions of the chat are completely open without a
login. There is just a ban mechanism, which checks IP, a fingerprint,
and stuff like that. But that's a manual process not tied to an account
or such.
> Assuming you have some SQL, add a collumn for a session variable. Create
> a hash out of some random information, and store it in a db associated
> with the user who logs in.
>
> Give this hash to the user as a flash var. Your flash code must give
> this variable to red5. Red5 will reject any client without a valid hash
> in the db. Hash is not shared between users.
That's something to consider. Though the database is on a different
machine, but since they are on the same network, the delay should be
neglectable.
> If you lose connection of the netconnection to the point that you get a
> netConnection.Closed status message, you must manually reconnect any
> shared object.
Hm, then this can't be an accident. Thanks! :)
> ----- Original Message ----- From: "Thomas Auge" <
auge@...>
> To: <
red5@...>
> Sent: Saturday, July 04, 2009 5:19 AM
> Subject: [Red5] Are SOs automatically reconnected?
>
>
>> Hello list,
>>
>> I'm trying to figure out some unusual activity on my server.
>>
>> If I lose connection to the server while connected to a shared object,
>> then reconnect the server, is the shared object automatically
>> reconnected, too? This is flash.
>>
>> The background is the following: For a long time I didn't have any
>> security for the actual messages being exchanged in my chat room. Now
>> lately someone has started to inject RTMP packets (I have no clue how)
>> into the data stream between server and chat applet.
>>
>> So I've started to sign the communication packets, so they could not
>> be spoofed. As a result, the person has started to just copy packets,
>> to spam things.
>>
>> Since both the messages and the signature contain the connection ID
>> I've started to match the sent connection ID against the real one in
>> onSharedObjectSend().
>>
>> Now some warnings appear for spoofed messages, which COULD be a race
>> condition on reconnect. If the client reconnects. It receives the
>> new connection ID from the server and should not do anything before
>> that. But if SOs would be automatically reconnected, some of the SO
>> functions could fire with the old ID. This does sound unlikely, but
>> some of the spoofing attempts come from an internal message type,
>> which is triggered a lot through the SO and makes very little sense to
>> mess with. ;)
>>
>> tl;dr: see second paragraph. ;)
>>
>> Thanks,
>>
>> Thomas
>>
>> _______________________________________________
>> Red5 mailing list
>>
Red5@...
>>
http://osflash.org/mailman/listinfo/red5_osflash.org>>
>
>
> _______________________________________________
> Red5 mailing list
>
Red5@...
>
http://osflash.org/mailman/listinfo/red5_osflash.org>
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org