Security concerns

[Daniel Zhou]

Hi,

I am reading the BBB code, and I am wondering if there is some security issue here.

The procedures for a client joining a conference, to my understanding, are as follows:

     1) A conference is created through bbb-web api;

     2) Client joins the conference through bbb-web api using user name and password; 

     3) Client is redirected to use Flash

     4) Client tests RTMP/RTMPT

     5) Client "enters" the conference through bbb-web api, and get conference parameters including voice conference number.

      6) Client loads modules, connects to red5 apps (bbb-apps, bbb-voic, bbb-video)

      7) Client dials voice conference through netconnection.

All the security check happens in the bbb-web api. My concern is that a malicious client can bypass all the bbb-web api, and directly connects to the red5  applications and then dials into a voice conference. Even though the conference number can be a random number, a robot can try all the numbers very quickly, and break into a ongoing conference. Even if it does not get into a ongoing conference, it can cause performance issues by establishing many useless connections.

Do you think if my concern makes sense?

Daniel

[Fred Dixon]

Hi Daniel,

Your concern is valid.  With brute force, social engineering, man-in-the-middle, reverse engineering, spoofing, etc., there are a many vectors that hackers (good or bad) could use to exploit the underlying operation system, the open source projects we build upon, and BigBlueButton itself.

There is validation of incoming API requests using a shared secret.   That doesn't make BigBlueButton secure, but it does make it more secure than a version without validation of API requests.

Please see

  https://code.google.com/p/bigbluebutton/wiki/FAQ#Can_I_provide_secure_access_to_BigBlueButton_?

To paraphrase: there is no representation of security in BigBlueButton.  None.  We (the core developers) are not trying to build a secure web conferencing system. 

To answer your question, in a default installation, FreeSWITCH is listening to incoming SIP calls on 127.0.0.1, so a hacker would need to compromise the BigBlueButton server first.  Furthermore, all the RTMP streams for the conference are published in red5 and accessible without authentication -- so if you know the stream name, you can subscribe to the audio/video broadcast.

From one point of view, this makes BigBlueButton more open and easier to integrate with other applications.  From another point of view, this makes BigBlueButton less secure than if the streams had some authentication.  

We're not trying to scare people.  We're pragmatists.  If a vendor says their product is secure, most people would take it at face value.  But in reality, we live in a world where all operating system vendors and application vendors are constantly updating their systems to make them more secure than the previous version.  So it is with BigBlueButton.

We're also not trying to ignore the vectors for hacking BigBlueButton.  We're open source developers, and as such we're interested in identifying issues and improving BigBlueButton with each release.  See

  https://code.google.com/p/bigbluebutton/issues/detail?id=1427

Regards,... Fred

-- 
BigBlueButton Developer

http://bigbluebutton.org/
http://code.google.com/p/bigbluebutton

BigBlueButton on twitter: @bigbluebutton

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.
Visit this group at http://groups.google.com/group/bigbluebutton-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Walter Tak]

Quick thoughts:

My concern is that a malicious client can bypass all the bbb-web api, and directly connects to the red5  applications and then dials into a voice conference.

I can't recall the random number for the conference at the lower level (the exact name of the Red5 instance) but if this is something like a GUID or a 32 character string then you can only connect if you know this string/id

Even though the conference number can be a random number, a robot can try all the numbers very quickly, and break into a ongoing conference

Brute force is not 'viable' if the length of the ID is big enough. Even 8 lower-case alpha-numerical characters like "aa99cc33" create 8 ^ 36 possible IDs. Considering that at any given moment you have around 100 conferences on 1 server your chance to hit a valid conference is 1 in 3245185536584267267831560205762 (if my calculator is correct ).

Even if your 'robot' could connect at a speed of 1000 connections per second to test for a valid conference then 1 scan would take roughly 3245185536584267267831560205 seconds. That is more or less a few years of scanning. However a conference normally lasts around 1 hour (?) so the chance is really really slim.

BTW this is with 8 characters. If internally more are used then the 'security' is enhanced exponentially. Please do see this as security since an SSL connection can be hacked as well , as long as you have enough computing-power.

The good thing about internet is that it has latency unlike a local brute force attack where a password can be tried a million time per second since everything resides in local memory.
You can't hack more than say 100 connections per seconds ; after that you effectively would DDoS the server, rendering the attempt to break into the conference useless.

FYI this is also how "serials" or "codes" for online games work to prevent piracy. They give you a code, a string of alphanumerical characters and if you consider how long that string is then you will understand that brute forcing a "valid" key is so small and would take so long that in reality nobody tries to do that. After all ; in the end you might get one (1) valid serial and once you start to use it (either in a game or in the conference) then the users will quickly notice and perhaps restart the conference with a new code and the guy with the game will ask for a new serial from the support/helpdesk.

My 2 cents,

Regards,
Walter

[Daniel Zhou]

Below is a scenario that I am not absolutely sure makes sense. 

A malicious client does not need to subscribe to an existing stream. Instead, it connects directly to bbb- voice, then it will have its own connection and stream. It can then dial into Freeswitch from the connection. The Freeswitch conference number is currently 5-digit, which will not be hard to break into. 

If the conference number is configured to be 20-digit through Freeswitch dial plan, it will be really hard to break into a valid conference, but it is still easy to create a lot of connections/streams to the Red5 server, and a lot of links through the Red5 server to Freeswitch, exhaust the server resources and deny the server of service.

Daniel

[Daniel Zhou]

Hi Fred,

I think bbb is great stuff. What you guys have done is really wonderous and is exactly the kind of system that I am looking for. That is why I put in a lot of time studying the code.

But my concerns about the security is real. If I am going to use it to teach students, I believe there is no lack of smart ones who want to become a hero by hacking or breaking the system.

As a potential solution for the scenario that I described in my previous email, valid conference ids (rooms) can be conveyed from bbb-web to the bbb red5 apps through redis, and bbb apps reject connections that are connecting invalid rooms. Currently bbb-voice does not use room/scope, I believe. It needs to be changed to use rooms.

Again, does this make sense?

[Walter Tak]

On Fri, May 17, 2013 at 2:24 AM, Daniel Zhou <daniel.ya...@gmail.com> wrote:

Below is a scenario that I am not absolutely sure makes sense. 

 

A malicious client does not need to subscribe to an existing stream. Instead, it connects directly to bbb- voice, then it will have its own connection and stream. It can then dial into Freeswitch from the connection. The Freeswitch conference number is currently 5-digit, which will not be hard to break into. 

If you allow people to dial in by phone then yes the security is suddenly much less, limited to 100.000 combinations. You can disable calling in, most people can/could/would use BBB as a webonly conference system.
 

If the conference number is configured to be 20-digit through Freeswitch dial plan, it will be really hard to break into a valid conference,

Even 8 digits already gives 100 million combinations. Small chance that someone can try them all before a conference is over.

 

but it is still easy to create a lot of connections/streams to the Red5 server, and a lot of links through the Red5 server to Freeswitch, exhaust the server resources and deny the server of service.

That however is a feature of all software. It is easy to add a firewall before Red5 (e.g. Linux with IPTABLES) and insert a rule that a single IP is not allow to connect more than say 3 times per second.
Even the total amount of connections to a certain port can be limited, protection the software/service/daemon that is running on that port.

Here is an excellent article how to rate limit incoming connections to a certain port based on 'attacks' from a single IP:

best: http://www.debian-administration.org/articles/187
also: http://www.cyberciti.biz/tips/howto-limit-linux-syn-attacks.html
and: http://blog.serverbuddies.com/using-iptables-to-rate-limit-incoming-connections/
and a discussion about protection a complete port from being overflooded: http://nixcraft.com/networking-firewalls-security/16762-linux-iptables-rate-limit-port-110-25-smtp-pop3.html

Protecting a complete port can protect your server but effectively result in a DDoS of your own service ; if you do not accept any more connections that also means (new) valid users cannot connect anymore.

However it that is perhaps a better situation than having thousands of brute force attempts which would probably bring your service to it's knees anyway (and also interfering with existing, running conferences).

However this discussion is NOT related to BBB ; this scenario is also applicable to Webservers, Emailservers, POP-servers, Samba-servers, DNS-servers, SSH-servers etc etc ; that is why most examples talk about SSH/HTTP/POP/SMTP.

Regards,
Walter
 

--

[HostBBB.com]

Daniel,

I just add rate limiting commands on port 5060 1935 9123 using
standard iptables hashing counters.

There are lots of examples on how to do this on net, google iptables
rate limiting.

Since we have freeswitch externally open on a lot of our
infrastructure for dids, sip-phones and skype access, this works well
stopping the rogue guys trying sip attacks.

If the same IP hits the port more than x times a minute, they are
blocked for x minutes. You can cascade this by chaining multiple
commands so eventually they are permanently blacklisted.

Also if you really need security like telemedicine does... Place the
systems in a VPC (Virtual private cloud) with no internet access. and
use VPN access servers forcing all your users to secure tunnel into
solution. I documented how to do this on list a few months ago.
Its easy, all of traffic is encrypted at transport level and
performance is great since all the decryption/encryption is handled in
vpn server.

Walter provides some great links to research.

Regards,
Stephen
hostbbb.com

On May 17, 3:08 am, Walter Tak <wal...@waltertak.com> wrote:
> On Fri, May 17, 2013 at 2:24 AM, Daniel Zhou

> <daniel.yanjun.z...@gmail.com>wrote:

> and:http://blog.serverbuddies.com/using-iptables-to-rate-limit-incoming-c...
> and a discussion about protection a complete port from being overflooded:http://nixcraft.com/networking-firewalls-security/16762-linux-iptable...

> >> On Thu, May 16, 2013 at 8:19 PM, Fred Dixon <ffdi...@gmail.com> wrote:
>
> >> Hi Daniel,
>
> >> Your concern is valid.  With brute force, social engineering,
> >> man-in-the-middle, reverse engineering, spoofing, etc., there are a many
> >> vectors that hackers (good or bad) could use to exploit the underlying
> >> operation system, the open source projects we build upon, and BigBlueButton
> >> itself.
>
> >> There is validation of incoming API requests using a shared secret.
> >> That doesn't make BigBlueButton secure, but it does make it more secure
> >> than a version without validation of API requests.
>
> >> Please see
>

> >>https://code.google.com/p/bigbluebutton/wiki/FAQ#Can_I_provide_secure...
> >> ?

[Fred Dixon]

Excellent discussion.

Regards,... Fred

-- 
BigBlueButton Developer

http://bigbluebutton.org/
http://code.google.com/p/bigbluebutton

BigBlueButton on twitter: @bigbluebutton

[Daniel Zhou]

That's a lot of great info. Thank you very much, Walter, Stephen and Fred. Definitely I will look into it. As you know, I am new to this field, lots for me to learn.

Regarding

"If you allow people to dial in by phone then yes the security is suddenly much less, limited to 100.000 combinations. You can disable calling in, most people can/could/would use BBB as a webonly conference system. "

No, I am not talking about allowing people to call in.  If you have a connection to bbb-voice, you can then do a remote procedure call to call into Freeswitch. The bbb-voice application has a  SIP call agent, through RPC call (remoting) a client can make a SIP call to Freeswitch. So in this scenario, the rate limiting commands with iptables won't be able to fend off the attack. All the client need is one connection to bbb-voice, from there it can launch many SIP calls to Freeswitch, which are all internal to the server. Clients may even be able to establish parasite conferences without bbb-web knowing it. This will steal resources from the server, and interfere with ongoing conferences.

Daniel

[HostBBB.com]

1) you can configure freeswitch to only allow inbound calling, no risk
of toll fraud if outbound if not enabled. Also set 5060 to only
accept packets with the ip address of ITSP.

2) Your dialplan controls what calls complete. In my configs the only
conferences that can be setup by inbound DIDs are active BBB sessions
that already exist, and controlled by pin (custom dialplan script) You
can't create adhoc conferences period.

3) The BBB client is talking to red5, which talks to freeswitch on
separate port (profile) If you have no demo pages on server, you need
to authenticate with BBB api with a valid checksum, so salt is needed
to create a rogue session. and the checksum is unique for every
attempt when params are changed.
You should change the ESL, and SIP username/password to something
other than defaults.

Lastly if your business or application needs Security compliance,
secure the network with a VPN.

Regards,
Stephen
http;//hostbbb.com

On May 17, 11:44 pm, Daniel Zhou <daniel.yanjun.z...@gmail.com> wrote:
> That's a lot of great info. Thank you very much, Walter, Stephen and Fred.

> YDefinitely I will look into it. As you know, I am new to this field, lots
> for me to learn....
>
> read more »

>
> Regarding
> "If you allow people to dial in by phone then yes the security is suddenly
> much less, limited to 100.000 combinations. You can disable calling in,
> most people can/could/would use BBB as a webonly conference system. "
>
> No, I am not talking about allowing people to call in.  If you have a
> connection to bbb-voice, you can then do a remote procedure call to call
> into Freeswitch. The bbb-voice application has a  SIP call agent, through
> RPC call (remoting) a client can make a SIP call to Freeswitch. So in this
> scenario, the rate limiting commands with iptables won't be able to fend
> off the attack. All the client need is one connection to bbb-voice, from
> there it can launch many SIP calls to Freeswitch, which are all internal to
> the server. Clients may even be able to establish parasite conferences
> without bbb-web knowing it. This will steal resources from the server, and
> interfere with ongoing conferences.
>
> Daniel
>
>
>
> On Fri, May 17, 2013 at 6:24 AM, Fred Dixon <ffdi...@gmail.com> wrote:
> > Excellent discussion.
>
> > Regards,... Fred
> > --
> > BigBlueButton Developer
> >http://bigbluebutton.org/
> >http://code.google.com/p/bigbluebutton
> > BigBlueButton on twitter: @bigbluebutton
>

> >> > >> to- Hide quoted text -
>
> - Show quoted text -

[Daniel Zhou]

Stephen,

I am not talking about outbound either. It is still in bound.

1. Client connects to bbb-voice

2. Client makes remote procedure call to bbb-voice 

3. bbb-voice calls freeswitch using sip call agent, creates user-listen stream, and listens to user- talk stream.

4. Client repeatedly makes the RPC call using the same or different conference number.......

....

All of the above is done without using external phone(no external dial in, do dial out to external).

Daniel

> >>http://blog.serverbuddies.com/using-ip> >> > >> to- Hide quoted text -

>
> - Show quoted text -

[HostBBB.com]

The ability to use the same join url over and over is possible with
just the demo pages or any legitimate join URL since BBB doesn't
prevent multiple users.

But in the typical setup a front end system is authenticating users
and demo pages disabled so the only way to get a legitimate url is
being validated user of system. Your url has your username in it, so
its not hard to detect abuse.

You also can rate limit red5 connections 1935 and 9123 and set limits
per IP address if you are really worried.

But then again a simple VPN eliminates this all together...

Somebody also could break into the data center and pull the power cord
out of the wall :)

If you want, you could document for us what we should do to make BBB
super secure, a lot on the list might benefit.

Have fun...

Stephen

> > On May 17, 11:44 pm, Daniel Zhou <daniel.yanjun.z...@gmail.com<javascript:;>>

> > > On Fri, May 17, 2013 at 6:24 AM, Fred Dixon <ffdi...@gmail.com<javascript:;>>

> > > >>http://blog.serverbuddies.com/using-ip<http://blog.serverbuddies.com/using-iptables-to-rate-limit-incoming-c.>>

> > >> > >> to- Hide quoted text -
>
> > > - Show quoted text -
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "BigBlueButton-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to bigbluebutton-...@googlegroups.com <javascript:;>.
> > To post to this group, send email to bigblueb...@googlegroups.com<javascript:;>
> > .

> > Visit this group athttp://groups.google.com/group/bigbluebutton-dev?hl=en
> > .

> > For more options, visithttps://groups.google.com/groups/opt_out.- Hide quoted text -

[Daniel Zhou]

Stephen, 

I don't want to harass you too much:-) 

But my point is that one does not need any join URL. All you need is rtmp to bbb-voice and make many RPC calls. Any anonymous user can do that.

I am planning to use bbb for private tutoring, not really super paranoid about security. But I just wonder if there is a big hole here.

If my concern is so hard for you guys to understand, then it is likely not making sense.

Again, thank you for your response and keep on the excellent work.

Daniel

> > > >> > before Red> > > >>http://blog.serverbuddies.com/using-ip<http://blog.serverbuddies.com/using-iptables-to-rate-limit-incoming-c.>>

> > >> > >> to- Hide quoted text -
>
> > > - Show quoted text -
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "BigBlueButton-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to bigbluebutton-...@googlegroups.com <javascript:;>.
> > To post to this group, send email to bigblueb...@googlegroups.com<javascript:;>
> > .
> > Visit this group athttp://groups.google.com/group/bigbluebutton-dev?hl=en
> > .
> > For more options, visithttps://groups.google.com/groups/opt_out.- Hide quoted text -
>
> - Show quoted text -

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.

[HostBBB.com]

Daniel, Can you please provide me a reference exploit (preferably off
list) to do what you say, and I will give you a demo server to attack.
I can stop a single IP from using bbb-voice more than a few times
every hour pretty easily if needed.

Its a good exercise in learning and should be documented.

Regards,
Stephen

On May 18, 8:19 pm, Daniel Zhou <daniel.yanjun.z...@gmail.com> wrote:
> Stephen,
>

> > On May 18, 8:38 am, Daniel Zhou <daniel.yanjun.z...@gmail.com<javascript:;>>

> > wrote:
> > > Stephen,
>
> > > I am not talking about outbound either. It is still in bound.
> > > 1. Client connects to bbb-voice
> > > 2. Client makes remote procedure call to bbb-voice
> > > 3. bbb-voice calls freeswitch using sip call agent, creates user-listen
> > > stream, and listens to user- talk stream.
> > > 4. Client repeatedly makes the RPC call using the same or different
> > > conference number.......
> > > ....
>
> > > All of the above is done without using external phone(no external dial
> > in,
> > > do dial out to external).
>
> > > Daniel
>

> > > On Saturday, May 18, 2013, HostBBB.com <207t...@gmail.com <javascript:;>>

> > > > email to bigbluebutton-...@googlegroups.com <javascript:;><javascript:;>.

> > > > To post to this group, send email to

> > bigblueb...@googlegroups.com <javascript:;><javascript:;>

> > > > .
> > > > Visit this group athttp://
> > groups.google.com/group/bigbluebutton-dev?hl=en
> > > > .

> > > > For more options, visithttps://groups.google.com/groups/opt_out.-Hidequoted text -

[John Roy]

An interesting (and oft-used) little tool is fail2ban, here:

http://www.fail2ban.org/wiki/index.php/Main_Page

It's released under GPL. It monitors logfiles for repeated failures and blacklists the offending IP for a configurable period of time. You can customize it to be triggered off any software. Invaluable for thwarting automated (aka script-kiddie) stuff. A lot of freeswitch installations with public SIP access run this. 

I mention it because I don't see this on the .8 VM or on wiki. Might make a good addition to BBB. It's small with negligible performance impact. I don't roll a public instance without it.

-J

--

https://bblr.co -- be virtually awesome

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.

[HostBBB.com]

John, yes in early versions BBB defaulted to use the external port,
and we discussed adding fail2ban as a good tool, then it was decided
to just set freeswitch to 127.0.0.1 as default and eliminate the
threat all together for standard installs that don't need DID access.

Some one last year wrote a module as well to integrate better with
freeswitch http://wiki.freeswitch.org/wiki/Mod_fail2ban

Regards,
Stephen
hostbbb.com


On May 19, 6:53 pm, John Roy <j...@babelroom.com> wrote:
> An interesting (and oft-used) little tool is fail2ban, here:...
>
> read more »
>
> http://www.fail2ban.org/wiki/index.php/Main_Page

>
> <http://www.fail2ban.org/wiki/index.php/Main_Page>It's released under GPL.
> It monitors logfiles for repeated failures and blacklists the offending IP
> for a configurable period of time. You can customize it to be triggered off
> any software. Invaluable for thwarting automated (aka script-kiddie) stuff.
> A lot of freeswitch installations with public SIP access run this.
>
> I mention it because I don't see this on the .8 VM or on wiki. Might make a
> good addition to BBB. It's small with negligible performance impact. I
> don't roll a public instance without it.
> -J
>

> --https://bblr.co-- be virtually awesome

> > > > > > > >> > someone can try- Hide quoted text -