Violating Your Personal Space with Webex

Some time ago Karl Fosaaen with NetSpi came out with some pretty interesting research around Federated Services and Skype for Business. One of the attack vectors was being able to access other companies address books and sending them direct Skype for Business messages, including all the features that Skype for Business has, such as seeing when other users are online. There is something similarly fishy/phishy with Cisco’s Webex..

Webex is used by thousands of companies worldwide. It’s a video conferencing platform that allows customers to use domains such as “companyname.webex.com” to host their public meeting rooms.

One very useful feature is personal meeting rooms. A personal meeting room is given to each employee so that they may host meetings or conference calls in their personal room over Webex. Employees can share their personal meeting room link with those they wish to communicate with.

A screenshot of a cell phone Description generated with very high confidence

A common link is: “companyname.webex.com/meet/userid”. The user id is typically the users domain username or email address plus or minus a few characters. Once you know a company’s personal room naming scheme, you can now enter anyone’s personal room, as anyone you’d like, from anywhere you’d like! Here is an example below:

By navigating to a personal meeting room link, I am presented with this page.

Once you enter any details you want, you are then directly placed into the personal room, The best part is that if that person is not currently in their room, we are presented with this:

Once you click notify, an email sent to the owner of the personal room. This email is generated and sent from [email protected]. The name I entered “Fake Name” could have been anyone’s name I chose, for example, my targets boss.

So what does this allow us to do?

A couple of useful things as a red teamer or adversary:
  1. Enumerate Valid Usernames
  2. Direct access to anyone in the company, think C levels.
  3. Convincing Vishing platform, just turn off Video and treat it like VOIP.

How do I find out if my company is vulnerable to this?

  1. Check your personal room link URL by going into your Webex Settings.
  2. Try to access that link from a computer off your network, if you can get into the personal room, you are vulnerable.

What can I do about it?

  1. Depending on how it is set up, you may be able to change your personal room’s URL. Make it something unguessable!
    • e.g. if it is fname.lname, change it too lname.fname_<5 random characters>
  2. Encourage your IT department to change everyone’s room id to something unguessable or random.

A quick subdomain enumeration on *.webex.com discovered thousands of domains for companies that use Webex in this manner. With some quick Google Dorking, discovering what their naming scheme for personal rooms would be trivial.

Comments, suggestions, concerns… feel free to reach out to me on Twitter or by email!

Penetration Testing is Red Teaming

Red teaming is not penetration testing but penetration testing is red teaming.

Information Security does not own red teaming. Red Teaming has been around for centuries and has been used throughout time for various purposes, assuredly most of these uses weren’t cyber. At its core, red teaming is applying a critical mindset to a process, plan or anything else you want to put there. With that in mind, penetration testing is red teaming, just not what you might consider red teaming applied to information security.

Red Teaming adapted for the Information Security profession is a niche in the InfoSec career field whereas Penetration Testing is a much more common profession. Some organizations use these terms interchangeably though which causes some confusion, especially to those just getting in.

So what is the difference?
  • Penetration Testing typically has the goal: Find all the vulnerabilities in this subnet, web app, host, network, <Insertwhateveryouwant>.
  • Red Teaming has the goal: Emulate an adversary with as much realism as possible.
  • Penetration Testing usually has a narrow scope; set of IP’s etc.
  • Red Teaming usually has a massive scope; phishing, entire external perimeter, physical etc.
  • I see penetration testing as an audit function, validating controls, testing for common vulnerabilities, etc.
  • I see red teaming as a holistic organization security meter; testing the blue team, user security awareness as well as determining that path of least resistance to total organization compromise.

A penetration test report should get shorter and shorter every time the pentesters are brought back, finding less and less vulnerabilities. On the other hand, a red team report should get longer and longer, having to use more and more footholds and weaknesses to execute on the goals of the operation.

For those looking for jobs in one or the other, make sure you clarify in the job interview what the role is, a job could be listed as a red team role but consist of PCI pentests.

Elk + Osquery + Kolide Fleet = Love

Threat hunting on Linux and Mac has probably never been easier. With the combination of these tools, we can query all of our hosts on demand for IOC’s, schedule queries to run on an automated basis and feed all of these results into our SIEM. Osquery is even platform agnostic so we can deploy it across all endpoints, regardless of host OS.

Osquery – Is a tool that allows us to query devices as if they are databases. It was built by Facebook and is built with performance in mind.

Kolide Fleet – A flexible control server for osquery fleets. Fleet allows us query multiple hosts on demand as well as create query packs, build schedules and manage the hosts in our environment.

Elastic Stack – Elasticsearch, Logstash and Kibana are tools that allow for the collection, normalizing and visualization of logs.

This post will assume a couple of things:

  1. You have an Elastic Stack configured. This has most likely never been easier, simply check out Roberto Rodriguez’s HELK (Hunting ELK) and run the setup script. For this post, I am using HELK so it should be all you need. If you like to do things manually so you understand how things are working, Roberto Rodriguez has you covered, head over to his site and follow his tutorials (They are top-notch).

What you will need:

  1. At least one Linux host to run your osquery daemon, you can also run it on the same box as you are running Kolide or your Elastic stack.
  2. An Ubuntu 16.04 Server to run Kolide Fleet, you can run this on the same box as your Elastic stack. This tutorial uses a separate host to run Kolide Fleet so I will let you know what you might need to change to make it work on the same server.

Before we begin, make sure to run:

apt update && apt upgrade

Kolide Setup:

You can use Kolides official documentation for most of this if you’d like. I basically customized their install guide to be more fitting for our purpose.

Official Setup Guide

Install MySQL:

Use the password: ‘kolide’ (Or whatever you want, just adjust accordingly as you go)

Install and run Redis:

Or if you have time, use the proper procedure to run Redis although totally not necessary for the purpose of this guide!

Fleet Server Setup:

Now, if you go to https://localhost:8080 in your local browser, you should be redirected to https://localhost:8080/setup where you can create your first Fleet user account.

We need to create some queries now, you can do this with the GUI, or you can run the importer tool found here. The importer tool is a bit buggy so for the purpose of this post, we will just configure the queries manually.

Go to Packs –> Manage Packs –> Create New Pack

Name the pack ‘linux_collection’ and add a description of you’d like. Under Select Pack Targets, choose All Hosts.

Now on the right hand side of the page, you should see Select Query. Click that drop down and choose ‘crontab’.

Set the interval to 60, the Platform to Linux, the minimum version to All and the Logging to Snapshot. Set the shard to 100.

The logging set to Snapshot will simply return all the results, differential would return the changes since the last query, and this is good for monitoring for malicious changes.

The shard is the percent of hosts that this Osquery pack will query. In a large environment, it might make sense to only query a portion of the hosts every time instead of all of them.

Repeat these steps for the following queries: etc_hosts, iptables, listening_ports, mounts, open_files, and shell_history..

All of these queries can be run on demand as well.

OSQuery Install:

Now on your Linux host we need to install OSQuery, like I mentioned in the beginning of the post, you can install this on the same machine that’s running Kolide, your Elastic stack or a standalone box.

Back on your new Kolide instance, select ‘Add New Hosts’ and copy the enroll Secret. Select Fetch Kolide Certificate and move certificate to your Linux box at /var/osquery/server.pem. Instead of using scp or the likes, you can simply open the certificate file with a text editor and copy/paste into you Linux terminal.

Now, back on the host that you are installing OSQuery, replace <enroll secret> with your secret that was provided from Fleet and on line 11, replace localhost with the server IP running Kolide Fleet.

If you go back to you Kolide app, you should see your new host appear!

FileBeat Installation:

We need to use FileBeat to move our osquery logs over to our Elastic Stack. If you are running osquery on the same machine as your Elastic Stack, you don’t need FileBeat, you can simply use the Logstash file plugin to pull the logs from the log file and push them to Elasticsearch.

On the server running Kolide run:

In the filebeat config file paste the following:

On line: 31, update localhost with your Logstash server IP.

If you are using TheHELK out of the box, you will not need to configure the ssl.certificate_authorities, however, if you followed the manual ELK setup and/or would like to use an SSL cert to encrypt the log traffic, you will need to comment this line and add the cert that Logstash is using.

Now run:

service filebeat start

Logstash:

On you Elastic Stack server, or the server that Filebeat is forwarding osquery logs to, you will need to add some Logstash filters.

Add a new output filter:

sudo nano /etc/logstash/conf.d/60-osquery-output.conf

Replace ‘fleet-controller’ with the hostname of you Kolide server and paste this in to the conf file you just opened:

Kibana:

Choose Management -> Index Patterns -> Create Index Pattern

In the Index Pattern box, enter osquery-result-* and choose Next Step. From the Time Filter field name drop down, choose @timestamp and then choose Create index pattern.

Now go to Discover and choose osquery-result-* from the Index dropdown. You should see your queries filter in.

Go To Management -> Import and import the two files found in this gist. One is the visualizations and one is the dashboard for osquery.

Recap:

This was all done with free tools. Add in sysmon to the mix and you now have a comprehensive threat hunting platform and a rudimentary SIEM. Osquery has support for Windows as well allowing you to query every. single. host. in your environment in a matter of seconds. If you are security and need the support from other teams before you can roll it out, sell it to them. osquery isn’t just a security tool. Operations, helpdesk, compliance teams etc can all get value from this, and the best part? Its free!

Further Reading/Resources:

https://medium.com/@palantir/osquery-across-the-enterprise-3c3c9d13ec55

https://blog.kolide.com/monitoring-macos-hosts-with-osquery-ba5dcc83122d

https://medium.com/@clong/osquery-for-security-b66fffdf2daf

https://medium.com/@clong/osquery-for-security-part-2-2e03de4d3721

The osquery slack channel: https://osquery.slack.com is super active and helpful! Also, if you run into any issues, /var/log/ is your friend 😉

Comments, suggestions, concerns… feel free to reach out to me on Twitter or by email!

The advice and scripts contained and referenced in this point are provided with no warranty. As always, never blindly trust scripts off the internet.