Consumer advice: Giggle vulnerability

Another week passes and another organisation chooses to deny a critical vulnerability in their site rather than fix it. I’m talking of course about Giggle, the social network site designed as a safe space for women to, “give girls choice, control, consent and connection”.

If you are not aware, over the last few days Saskia Coplans (@ms__chief) a security researcher at Digital Interruption attempted to disclose a serious vulnerability in the Giggle platform. It meant that an unknown, unauthenticated attacker could see:

• all users phone numbers
• the selfie used to sign up
• the users location.

That’s pretty much as bad as it gets for a platform like Giggle.

Sadly, Sall Grover the Giggle CEO fell in to 3 days of denial and threats against Saskia and Digital Interruption. Initially choosing to ignore the researchers, then blocking them on Twitter and starting a war of words against the security research community. Eventually 3 days later realising it wasn’t working, asked for more information and finally fixed it.

All the while the CEO denied it was an issue and even went as far as threatening Digital Interruption with legal action. This way of carrying ononly served to shine a massive ‘Streisand’ light on the problems at Giggle.

On Sep 11, 2020 Sall Grover Tweeted a conciliatory statement:

Consumer guidance

It’s important to note that the flaw has since been fixed.

As mentioned, it was possible for attackers to obtain users photos, phone numbers and locations. According to Digital Interruption, the location data uncovered is from the time of sign-up, as is the photo. If you had moved or changed your appearance in the interim it did potentially reduce the risk, but not remove it entirely.

Although the flaw is fixed we don’t know how long it existed, nor do we know if anyone else exploited this while it was still vulnerable. Unless Giggle can confirm otherwise, it should be assumed if you use the service your phone number, location and photo has been compromised.

This can be distressing, especially if you are, for example, in the process of escaping an abusive relationship. Your partner could have exploited the flaw, found you signed up with your phone number and then could view your location at the time. What is not clear from the report is what changes when you have a valid account, its implied that with a phone number used at registration an attacker could look up the AccountID (or GUID in this case), which one presumes is constant, meaning an attacker could then find your username, your current location, any images you have uploaded and your current photo, among other data points.

If that is the case then Giggle should be extremely clear with users.

Here are some simple steps you can take when signing up to these type of services:

• Try to avoid using 100% real information. Does Giggle (or any social network for that matter) really need to know your real name and date of birth?
• Consider using a virtual mobile phone number or getting a different SIM card/phone. Virtual numbers will forward calls to you and can receive SMS messages.
• Be careful allowing phone apps access to your location. Does a social network need your location?
• Consider a separate email address for each service, this is really easy to do with a free Gmail account. Simply add “+anything” to your email name. e.g. if your email is [email protected] (note this is not my gmail account, though doesn’t look registered), when registering on the site if you use [email protected], for example, any email from the platform will be delivered to the [email protected] account.
• Use a password manager like LastPass/Dashlane/1Password/KeePass to generate and store a really strong password for the site. Whilst this wouldn’t help with the Giggle issue its great practice.
• Turn on two factor or two-step authentication. Be sure to use an authentication app, rather than SMS. Again, whilst this wouldn’t help with the Giggle issue its great practice.

Advice for Giggle

In virtually all cases security researchers are there to help. They are usually friendly, they want the best for your customers, and they aren’t looking to damage your business or make money.

We know that you have spent years building a product or service and that you are passionate about it. We totally get it.

We have done the same in building our reputation as honest, reputable security researchers. The problem is that when things are built in haste mistakes happen. Security researchers are passionate about identifying flaws that could lead to compromise of your customers.

They want to help. Ignoring them, blocking them, calling them out on Twitter, burying your head in the sand and threatening them with legal action only leads to hostility and serves no-ones cause well. This creates the effect that more people will talk about it turning what could be a positive story in to a negative press story.

No one talks about the flaws that get fixed within minutes. Everyone talks about the Twitter fall out.

My advice to Giggle and organisations on the receiving end of a vulnerability disclosure is:

• Clear polite communication is key.
• Don’t ignore the researcher. Even if you can’t fix the problem immediately, keep communications open.
• Be open about your situation. Researchers want things fixed but should be willing to give you time. Most adhere to a standard 90 day disclosure policy.
• Be clear about when you will fix it and stick to that. Delays are fine, but be willing to explain why.
• Most researchers will want to publicly disclose the findings, BUT usually not until you have fixed them. You don’t get to decide the publishing date or what gets published. You can of course turn it in to a positive by getting ahead of the publishing date and creating joint communications.
• Avoid involving PR/marketing. Engage your technical staff instead. PR/marketing will look to play down the significance, and this usually doesn’t end well.
• Make sure you let your customers know. They are your business, without them you have nothing but an app and a set of servers. Treat them fairly by explaining the situation clearly and honestly. They will respect you much more for it.
• Don’t engage your lawyers. That WILL result in an escalation of words which you are unlikely to win.
• Set up a [email protected] email address and make sure the correct people can be contacted. This will reduce the hassle from non-technical staff mishandling things.

Advice for researchers

We have done hundreds of disclosures. Every one is different, but in our experience its critical to put yourself in to the shoes of the person receiving the disclosure. They are likely to have never had to deal with a security researcher before, and they may not know that your intentions are genuine.

They have built their product, service, and user base over many years, then you come along and tell them that its got terrible security and that they are putting their customers at risk. How do you think they will feel about you?

I think Digital Interruption broadly did a good job, however, if you are disclosing a vulnerability to an organisation it’s important to:

• Be courteous in all communications, avoid mentioning anything about personal views of the organisation.
• Exhaust ALL known contact info before you use a public channel like Twitter.
• Social media teams rarely know how to handle a security issue and are usually non-technical and work in public relations. They won’t know how best to handle it.
• Connecting with the CEO/CTO on LinkedIn is often a better way to disclose without sending a message on the public Twitter handle.
• Be clear on what you feel the risks to their customers are, focusing on the impact rather than the findings is important when performing initial disclosures, the detail can come once you are speaking to the right person.
• Make sure you have clear and concise information when disclosing, its important to proof read what you disclose so that the recipient can understand it.
• Be prepared to wait, if you have a vulnerability disclosure policy ensure you adhere to it when disclosing, you can push the vendor to fix quicker, but be prepared that they may not.