Facebook insecure by design

In accord with the recent thread, "facebook spying on us?"

We should also worry about other spying on us. Without
some sort of rudimentary security, all that personally
identifiable information is exposed on our ISP networks,
over WiFi, etc.

Facebook claims to be able to run over TLS connections.
Not so much (see attached picture).

This wasn't an "app", this is the simple default content of a
page accessed after a Google search.

   CeeLo Green - Home | Facebook

Screen shot 2011-09-30 at 4.54.53 AM.png

Actually, the reason for what happened in your example is that Cee Lo's page has what is **technically** an app (called I Want You, as seen in the sidebar under his profile photo) set as the default screen for when you view his page. The app (that does admittedly looks like it could be an official feature from facebook) uses externally-hosted HTTP-only content, which Facebook will detect and warn you about.

-- Ben

William Allen Simpson wrote:

In accord with the recent thread, "facebook spying on us?"

We should also worry about other spying on us. Without
some sort of rudimentary security, all that personally
identifiable information is exposed on our ISP networks,
over WiFi, etc.

Facebook claims to be able to run over TLS connections.
Not so much (see attached picture).

This wasn't an "app", this is the simple default content of a
page accessed after a Google search.

I'm not sure why lack of TLS is considered to be problem with Facebook.
The man in the middle is the other side of the connection, tls or otherwise.

Mike

I'm not sure why lack of TLS is considered to be problem with Facebook.
The man in the middle is the other side of the connection, tls or otherwise.

That's where the X509 certificate comes in. A man in the middle
would not have the proper private key to impersonate the Facebook
server that the certificate was issued to.

Supporting TLS in their case is not good enough... they would need to
force all connections to be over TLS, to achieve security against
MITM.

As soon as an app causes the end user to switch to a non-TLS
connection, they are vulnerable.

My understanding of his statement is that Facebook itself is the MITM,
collecting all our personal information. Too true.

William Allen Simpson wrote:

Ooh.. subtle. :slight_smile:

Man in the Middle (MITM) is a technical term that refers to a rather
specific kind of attack.

In this case, I believe the proper term would be just "The man".
[Or "Man at the Other End (MATOE)"]; you either trust Facebook with
info to send to
them or you don't, and network security is only for securing the
transportation of that information
you opt to send facebook.

Yes, if Alice sends Bob an encrypted message that Bob can read, and
Bob turns out to
be untrustworthy, then Bob can sell/re-use the information in an
abusive/unapproved way for
personal or economic profit.

I'm not sure why lack of TLS is considered to be problem with Facebook.
The man in the middle is the other side of the connection, tls or otherwise.

Ooh.. subtle. :slight_smile:

Man in the Middle (MITM) is a technical term that refers to a rather
specific kind of attack.

In this case, I believe the proper term would be just "The man".
[Or "Man at the Other End (MATOE)"]; you either trust Facebook with
info to send to
them or you don't, and network security is only for securing the
transportation of that information
you opt to send facebook.

alice sends charlie a message using bob's api, bob can observe and
probably monetize the contents.

Yes, if Alice sends Bob an encrypted message that Bob can read, and
Bob turns out to
be untrustworthy, then Bob can sell/re-use the information in an
abusive/unapproved way for
personal or economic profit.

charlie is probably untrustworthy, bob is probably moreso (mostly
because bob has more to lose than charlie), alice isn't cognizant of the
implications of running charlie's app on bob's platform despite the
numerous disclaimers she blindly clicked through on the way there.

I'm not sure why lack of TLS is considered to be problem with Facebook.
The man in the middle is the other side of the connection, tls or otherwise.

Ooh.. subtle. :slight_smile:

Man in the Middle (MITM) is a technical term that refers to a rather
specific kind of attack.

In this case, I believe the proper term would be just "The man".
[Or "Man at the Other End (MATOE)"]; you either trust Facebook with
info to send to
them or you don't, and network security is only for securing the
transportation of that information
you opt to send facebook.

alice sends charlie a message using bob's api, bob can observe and
probably monetize the contents.

Yes, if Alice sends Bob an encrypted message that Bob can read, and
Bob turns out to
be untrustworthy, then Bob can sell/re-use the information in an
abusive/unapproved way for
personal or economic profit.

charlie is probably untrustworthy, bob is probably moreso (mostly

                                                           ^
              trustworthy

+1

I assume that any MITM is actually going to try and prevent our data from
making it to the end point i.e the real attacker.

Jason Leschnik wrote:

Is this not the nature of social media? If you want to make sure something is secure (sensitive information), Why is it on social media. If you are worried about it being monetised, I think Google has already done that.

[ if you were already over this topic, plonk the thread ]

From: "Bill.Pilloud" <bill.pilloud@gmail.com>

Is this not the nature of social media? If you want to make sure something
is secure (sensitive information), Why is it on social media. If you are
worried about it being monetised, I think Google has already done that.

No.

Because "sensitive" is a word with different definitions at different times
for different people.

I don't mind my friends knowing that I (used to) go to Rocky Horror every
Saturday night and run around in my underwear. I don't particularly want
a potential employer to know that, and I might not want a new girlfriend to
know it *immediately*.

The promise of Social Networking is *precisely* that it permits this more
fine-grained *control* (that's the key word, for those who weren't playing
the home game) over the information you disseminate, as opposed to just
posting all of it on your blog.

*Telling people you're going to provide them that control* and then being
sloppy about it -- or worse, purposefully evil -- is the thing that has people
up in arms.

As usual, the underlying issue is one of trust.

Alas, I see no theoretical way that distributed systems like Diaspora *can*
provide some of the functions that are core to systems like Facebook, *exactly
by virtue* (vice?) of the fact that they are distributed; there is no central
Trust Broker.

Cheers,
-- jra

You know I don't need Facebook to introduce (broker) me to anyone! I am more than happy managing my own relationships (gradations of trust included!) Oh and my friends are distributed in the real world as well!

This works pretty well even without a "social network" or a "system". When the Diginotar certification authority was badly compromised I got a bunch of information from many sources using those protocols which span the standards sphere of the Internet each bringing information that I value at varying levels of trust and applicability. Between and in combination of all this input I was able to take action and remove Diginotar from my keychain. I could have waited for Apple to stir its stumps but didn't need to.

All those independent distributed "trust brokers" did a fine job!

thanks folks!

Christian

At the end of the day Social Networks just want to make interactions as
natural as possible so they can continue to mine and monetize your
relationship data as you get more comfortable sharing the 'real you.' Anyone
who hasn't and has an interest in privacy, graph and content ownership on
social networks should check out the Diaspora project.

-Travis

Hey all!

I'm a IT Security Manager (policy creation) that has been lurking on NANOG for about 3 years. I have some experience in networking but nothing like what is mostly talked about on here. I just love the talks you experts have and researching the tools you all mention. I was having a tough time yesterday explaining to one of my nosey co-workers why I had the word Octopussy on my screen yesterday!

I'm trying to put a baseline policy together for all my network equipment and I have a few questions:

1. Should config files be consistent? By this I mean; does the STIG apply its baseline to the config files or elsewhere?

2. Are config file change alerts necessary for the security of network equipment? We have just purchased the SolarWinds suite.

3. Should we obfuscate our Private addresses on our Network Diagram? What is the common practice?

4. How can I get a grip on my ACLs or is it even possible? How do you all maintain them without going insane!

If this isn't the correct forum for this "low level" stuff I understand; just guide me in the right direction.

Thanks in advance!

TG

1. Should config files be consistent? By this I mean; does the STIG apply its baseline to the config files or elsewhere?

Hi Timothy,

STIGs are a DoD thing. http://iase.disa.mil/stigs/. They're not
particularly relevant to public Internet operations. In a few cases
they're not particularly sane. (Manually install the latest bleeding
edge version of OpenSSL whose bugs have not yet been found and whose
API is incompatible with every linked app in the OS? Really?)

2. Are config file change alerts necessary for the security of network equipment? We have just purchased the SolarWinds suite.

Depends on the configuration. If it's one that rarely changes, it's
not a bad idea. But don't saturate yourself with alerts or you'll
misinterpret or ignore the important ones.

3. Should we obfuscate our Private addresses on our Network Diagram? What is the common practice?

It depends. My personal predilection is that IP addresses belong in
configurations while explanation and structure belong on network
diagrams so I rarely reach the question of whether there's also
security value in removing the IP addresses from the pretty pictures.

4. How can I get a grip on my ACLs or is it even possible? How do you all maintain them without going insane!

Simplify. Don't overdo it. Do you really need ACLs for 100 popular
trojan horse TCP ports? The 500 outbound port whitelist? If your
security is so complex you can't understand it then it almost
certainly isn't secure. If you have a particular subsystem with
special needs, it never hurts to give it its own firewall so you can
strip the related complexity from your main firewall.

Regards,
Bill Herrin

Hey Tim,

We recently bought the NCM tool by SolarWinds as well. We've had it
for two months, and I personally am quite happy with it. We had
Cisco's CiscoWorks product for the last 5-6 years but ditched it
because of it never quite works consistently. The thing to be aware
of for config auditing, like with NCM's reports, is that in some
environments config is ALWAYS changing. I'm in a small enterprise
setup with a very dynamic datacenter and it is not abnormal to have a
few hundred changes across a week with the number of server
moves/rebuilds/expansions going on in our place. So in our case, we
are primarily using NCM for pushing configs, and using the alerting of
changes mostly to do spot checks on the fellow team-members. Since
there are so many changes, it is nice to have visibility to make sure
that appropriate standards are being met.

David.