Tag Archives: Security

About security issues.

Security Awareness for Distributed Teams

(Guest post from Cybernews)

According to researchers at Ladders, 25% of professional jobs in North America will be remote by the end of 2022. Remote jobs skyrocketed from under 4% in 2019 to 9% in 2020 alone. This means that working from home is here to stay.

With this change in the job market demand, distributed teams have become more common and will continue to be adopted by small and big businesses alike. The need to secure company and employee data is important given the rise of internet scams. It is advisable to have all team members engage in security awareness training to have them prepared against malicious hackers and phishing sites.

Here are measures distributed teams can take to protect themselves and the company from a security breach.

Public Wi-Fi

Avoid using public Wi-Fi, especially from unknown service providers. If you must connect to a public server ensure you have a VPN installed on your computer to prevent hackers from monitoring your internet activity.

Social engineering

Social engineering uses manipulative techniques to gain confidential information that can put an individual or company at risk of cyber-attacks. Hackers have gotten smarter over time creating the need to be cautious mainly when workers use their own devices for office duties. Here are tips to save you from falling victim to such scams.

  • Be suspicious if an unknown person asks you for information, they shouldn’t have access to it. All workers have team leaders they report to or team members that handle specific company data. If someone aside from the usual team member is asking for such data, be alarmed and report it to your team leader.
  • Pay attention to emails. It can be daunting to always have to check an email sender to be sure you’re not under a phishing attack, but it can save you from putting your company at risk. Look out for grammatical errors and the sender’s email address to be sure they aren’t impersonating your company’s or an employee’s email.
  • Beware of heightened urgency. Resist the rush to perform an action if you are feeling pressured to perform a certain action. Creating urgency is a common tool phishing scammers use to make their victims act fast. You should be more suspicious if the person is trying to make you ignore a mandatory security protocol.
  • Always hover over links to see where they lead. Don’t be quick to click links and open attachments sent to you from new contacts. Offerings of things that are too good to be true are not true. An example is an email congratulating you on an iPhone in a competition you never attended.
  • Never download unauthorised software or plug in an unauthorised drive or USB to your device.

Setting passwords

Most websites will tell you to create an 8-character password that contains uppercase letters, lowercase letters, numbers, and symbols that should be changed every 90 days. However, cybercriminals now use technology that allows them to crack an 8-character password in 4 hours. That’s why you should be using strong password management.

Instead, use a 12–16-character password with uppercase and lowercase letters, numbers, and special characters. You can create a passphrase using multiple small words like “tiNyTombSPoon.” Combining your passphrase with numbers and special characters is advisable for added difficulty. Complex passwords like this should be changed every two years.

Never save passwords to browsers. Never share your passwords with anyone or log in to your work accounts with public computers. Ensure you use a unique password for each account, you can use a password keeper if necessary.

Always use two-factor authentication for all your accounts. Never use the same passwords for your personal and work accounts. Make sure to separate your personal and work life.

Security awareness at home

In a world of distributed teams, it is normal for workers to spend more time at home than in an office. Here are measures that can be taken to stay safe when working from home.

  • Never grant anyone access to your desktop unless you sort the remote connection. Always be careful of remote desktop inquiries. Never give out your login details to anyone over email or phone without consulting your supervisor.
  • Don’t respond to non-company numbers or messages regarding an issue when you didn’t open a ticket.
  • If you will be filling your data into any websites while working, ensure they begin with https://
  • Ensure your Wi-Fi router is secured with a strong password. Always restart your router frequently.
  • Keep your working devices out of the reach of family and guests. Use a different internet network for work and family or guests.
  • Only use company-approved USB sticks. Never use unencrypted USB sticks to connect or charge your work device in public places.
  • Never leave your work device unattended. If you aren’t actively using your device ensure you exit your work screen and lock or close your device.

Security awareness in videoconferencing

All virtual meetings should be cyber-safe and not open to the public. Links to video meetings must not be shared on public sites. Ensure all meetings require passwords to join. Avoid starting a meeting without the host – rather create a meeting room.

Enable host-only sharing, accept one user at a time, and lock the meeting after all the participants are in.

Other security measures

  • Avoid using your personal computer or smart devices for work. Ensure your operating system, antivirus and apps are updated frequently.
  • Beware of phishing links sent to your email. Alert your family members on using your devices without your supervision.
  • Beware of pop-ups on free movie sites and apps asking you to install software from unverified sources.

Conclusion

Although it is impossible to be 100% secure, raising awareness of the cybersecurity risks and taking all security measures stated above is key to preventing a security breach that can lead to catastrophic events. Ensure each team member is properly oriented on security measures to employ and things to look out for to prevent getting hacked.

Guarding against XSS code injection

We had posted earlier about making sure that (malicious) users cannot inject code into Kerika, in any of the areas where user input is possible.

Here’s the complete list of user actions that we are checking for XSS injecton now:

  1. Board Name
  2. Board Description
  3. Template Name
  4. Template Description
  5. Tag Name
  6. Card Attachment Name
  7. Board Attachment Name
  8. Card Chat
  9. Board Chat
  10. Column Name
  11. Task Name/Detail
  12. Canvas Text
  13. Canvas Attachment Name
  14. Canvas Shape/Object Name
  15. Account Name
  16. Account Billing Information
  17. User’s Name

Guarding against XSS/code-injection

It’s possible to copy-paste text into a Kerika Chat message, and there are legitimate use-cases for this: for example, a developer may ask a question to a coworker who replies with a code snippet.

Kerika handles code in chat messages by storing two versions of the message: as plain-text, and as the original format. When a chat message is displayed, the original format is used but not executed, which means the embedded code is visible, but doesn’t run in the browser. This makes it easy and safe to share code snippets through chat messages.

While making this improvement, we went through all the places where a user can type in text, Card Title and Description, Board Name and Description, Tag, Attachment Name, etc. to make sure we are guarding against malicious code injection.

We will start to do IP blocking

Regrettably, we will start doing IP blocking to stop persistent spammers from setting up Kerika accounts.

We have seen a consistent pattern of misuse that goes like this:

  • Someone signs up with a sina.com email address.  Sina is one of the largest ISPs in China, but we don’t have any users in China for the simple reason that most of Google’s services are blocked by China’s Great Firewall, and Kerika has a tight integration with Google’s G Suite.
  • The spammer isn’t actually located in China; they are in Manila (Philippines) and come from IP addresses like 203.177.13.60
  • These spammers send out hundreds, sometimes thousands, of invitations for users from the qq.com domain to join their (spurious) Kerika team.
  • These recipients are all users of Tencent’s QQ messaging system, based in China. Again, none of them would be actual or potential Kerika users, since the recipients are all located in China.

The user impact of this spamming was relatively small: almost no one with a qq.com email address would reply to these invitations, but the conduct was a very clear misuse of Kerika and harmful to our reputation, quality and brand.

(Among other things, these spurious invitations would pile up in the thousands.)

We have decided, therefore, to start blocking IP addresses using Amazon’s VPC service (since we use Amazon AWS extensively on our back-end.)

This is a brute force method, and not ideal, but we were starting to get really annoyed with these folks.  We hope this doesn’t impact any of our real users in the Philippines; if you are affected, please let us know!

Managing the privacy of your Kerika boards

Kerika offers a great deal of control over how each board is shared:

  1. A board can be made public to everyone.  This makes sense for open-source projects and many nonprofit and advocacy groups, where the goal is to get maximum visibility and publicity rather than to hide the details of what the project is about.

    Making a board public means that anyone who has the URL of the board can view it, even people who are not Kerika users.  Note: we are talking about viewing the board; viewing doesn’t mean anyone who isn’t part of the board team can make changes.

    If a board is viewable by the public, it can be found by anyone using Kerika’s search function.

  2. A board can be viewable by everyone who is part of the account team. This is the default setting, and it makes a lot of sense for most organizations: you want your coworkers to be aware of what your team is doing, unless the project is particularly sensitive.

    An account team consists of everyone who is a Team Member or Visitor on any board owned by the account.

    As people get added to individual boards, they are also automatically added to the account team.  When someone is removed from every board owned by an account, they are automatically removed from the account team as well.

    As with public boards, described above, we are talking only about viewing, not changing: only people who are Board Admins or Team Members on a particular board’s team can make any changes to that board. (And, of course, the Account Owner who owns the board.)
    If you use Kerika’s search function, you can find boards that are being shared with the account team, provided you are part of that particular account team.

  3. A board can be kept private.  This means that only the people who are listed on the board’s team — as a Board Admin, Team Member or Visitor — can view the board.  (And, of course, the Account Owner who owns the board.)

    This is appropriate for any sensitive projects, e.g. stuff related to personnel matters or confidential contracts.

    Private boards can’t be found by Kerika’s search function either, and it doesn’t matter if you know the URL for the board: only the specific people listed on the board team can see anything related to that board.

For each board owned by an account, the Account Owner or Board Admins can manage the board’s team: decide who is part of the team, and what sort of role (Board Admin, Team Member, or Visitor) each person has.

  • Board Admins and Team Members can make changes to all the items on the board, including any documents attached to the board.
  • Visitors have read-only access to the board and all its documents.
  • A person’s role can be changed at any time by the Board Admin or Account Owner: the effect is immediate, and extends to all the documents associated with the board as well regardless of whether you are using Google or Box for your file storage, or whether you are storing your files with Kerika.

A board’s team and current privacy settings can be viewed by clicking on the Team button that appears on the top-right of the Kerika app, when viewing a board:

Board Team button
Board Team button

Clicking on this button brings up the Board Team dialog:

Board Team dialog
Board Team dialog

Each person who is part of the Board Team is listed in this dialog, in alphabetical order along with their role.

At the bottom of the dialog is the board’s current privacy setting: in the example shown above, the board is being shared with everyone who is part of this user’s account team. (We have obscured the URL in the screenshot for security reasons.)

If you are a Board Admin or the Account Owner, you can change the privacy of the board using the Change Privacy link that’s shown on the bottom of the dialog:

Board Privacy options
Board Privacy options

So, every board can have it’s own privacy settings: private, shared with account team, or public.

When you are viewing the boards in an account, Kerika shows clearly what the privacy setting is for each board:

Privacy settings, at a glance
Privacy settings, at a glance

If you are part of someone’s account, you will be able to create new boards in that account: you will automatically be a Board Admin on those new boards, but the owner will always be the account you are working in.

You can set your privacy preferences for each account; this will determine whether new boards you create are automatically shared with your coworkers or not:

Privacy preferences
Privacy preferences

All your preferences can be set at https://kerika.com/preferences.  The default setting is Share with Account Team, which works well for most people, most of the time.

 

Switching to Let’s Encrypt for our SSL certificates

We have mentioned below the problems we had with GoDaddy’s SSL certificates; we have fixed this by switching to the open-source certificate authority called Let’s Encrypt.

Lets Encrypt SSL
Lets Encrypt SSL

Let’s Encrypt is a free, automated, and open certificate authority brought to you by the non-profit Internet Security Research Group (ISRG). It lets us host our own certificates, so we don’t have to rely upon third parties and can have better control over the quality of our service.

Learning to live with email sandboxing

We spent hours recently trying to understand why a particular user wasn’t able to join her coworkers boards, before finally figuring out that it was her company’s “email sandboxing” that was messing up Kerika’s invitation flow

The problem was a real nuisance to debug, and we fear it will affect more of our users in the future so we are going to make a change to our invitation process to make sure it continues to work well for everyone.

Some background:

“Email sandboxing” refers to a process that tries to trap malicious URLs that are included in emails.  While the exact implementation varies by security vendor, the basic process is the same: use a virtual machine as a sandbox, and click on every URL contained within an email.

This can trap a lot of malware emails.  If the URLs are designed to be single-use only, i.e. the URL is unique and intended to be clicked upon just once, the sandbox will “explode” the mine before the user gets to it.

More sophisticated implementations of sandboxing will handle multi-use URLs by watching for return traffic from the sender’s machine, which would indicate (potential) attempts to download malicious software onto the recipient’s computer.

The problem with sandboxing:

The sandboxing approach takes the same brute force approach to all links, in all emails, without trying to understand the context of the email itself.

One consequence may be that “Unsubscribe” links contained in newsletters are clicked on automatically by the email sandbox virtual machine, so the recipient gets just one copy of a newsletter that she signed up for.

To get around this, systems that generate emails automatically, like a newsletter, have to move from a one-click unsubscribe (which would be more user-friendly) to a two-step unsubscribe process (which is more annoying to the user.)

You will have seen the two-step unsubscribe process more and more often in your own newsletters and other mass mailings: you click on the “Unsubscribe” link in a newsletter, and you land on a web page where you are asked to, once again, confirm that you want to unsubscribe.

The user might think this is a last-ditch attempt by the newsletter publisher to hold on to their readers, but it might actually be an attempt to safeguard the newsletter’s subscribers from their own brute force security implementations!

How this affected Kerika:

When you invite someone to join your Kerika board, as a Team Member, Board Admin or Visitor, the invitation gets sent to them by email as well from within the Kerika app.  The emailed invitation looks like this example:

Example of invitation email

Example of invitation email

The email contains two links: the most prominent is the Accept Invitation, but there’s also the Reject Invitation.

Email sandboxing plays havoc with this sort of email invitation: there is an equal possibility that a particular sandbox will click on the Reject Invitation link before it clicks on the Accept Invitation link, which leads to a completely random experience for users who are being invited by the coworkers to join Kerika boards, since Kerika lets you act just once upon an invitation: once you accept it, or reject it, you can’t act upon it a second time.

How we discovered this problem:

One of our users, based in California ,was trying — repeatedly and unsuccessfully — to invite another user, based in Taiwan, to join one of her boards, and the process kept failing.

And for the longest time we couldn’t figure out why!

Our debugging seemed to suggest Kerika itself was somehow auto-rejecting invitations on the user’s behalf, which had us really worried about a serious bug in the server before one of our developers got the idea that perhaps the problem was with the user’s email system, and not Kerika.

When he examined the headers on an email we got from the affected user, he found references like these:

Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.10])

A little more sleuthing led us to Symantec’s “threat protection” service, which is one of the common email sandboxing systems out there.

How we are fixing this:

We are moving to a two-step process for people who want to reject invitations that come to them by email: clicking on the Reject Invitation will now take you to a Web page where you will be asked to confirm that you want to reject the invitation.

It’s one more step for users, and not the kind of superb user experience we aim for, but without this there’s no way for us to make sure that the best intentions of security vendors don’t end up crippling our own business!