What The Hack 2018?
By- December 11, 2018
As the current year comes to an end, many of us take this time to look back and reflect on how we can be a better version of ourselves for the upcoming new year. Let’s reflect on the data breaches that occurred in 2018, to encourage the companies we trust with our data to try and do better in 2019.
The past year brought us an unusual number of high profile breaches, with alarming amounts of data being exposed. Here are our 12 Hacks of Christmas:
1) The largest, in terms of records breached, was Aadhaar. For those of you who may not have heard of Aadhaar before, it’s the Unique Identification Authority of India (UIDAI). The UIDAI is mandated to assign a 12-digit unique identification (UID) number (termed "Aadhaar") to all the residents of India. According to a report by the Tribune News Services, there was a software patch that could be bought for as little as 500 Rupees and reportedly allowed unauthorized persons to generate Aadhaar numbers. An additional payment of 300 Rupees got you access to software through which anyone could print an ID card for any Aadhaar number. The data breach is believed to have compromised the personal information of nearly all 1.1 billion citizens registered in India.
2) More recently, there was a data breach of the Starwood guest reservation database, newly owned by Marriott International. This breach exposed the personal information of up to 500 million people. Hackers were able to access guests’ names, addresses, phone numbers, email addresses, passport numbers, dates of birth, genders, Starwood loyalty program account information, and reservation information. In some cases, they were also able to steal payment card numbers and expiration dates. According to Marriott, the payment card numbers were encrypted, but they are not sure yet if the hackers were also able to access the information needed to decrypt them.
3) Exactis is a marketing and data aggregation firm based in Florida that left a database containing two terabytes of information exposed on a publicly accessible server, including the personal details of hundreds of millions of Americans and businesses. This led to an estimated 340 million records being breached. The data exposed included email addresses, physical addresses, phone numbers, and highly sensitive details such as the names and genders of consumers’ children.
4) MyFitnessPal, now owned by Under Armour, was compromised, leading to 150 million records being exposed. The data exposed included customers' usernames, email addresses, and hashed passwords. Some welcome news was that their users’ payment information was not compromised, as Under Armour stores that database separately.
5) MyHeritage, an online genealogy platform, left 92 million of their users' emails exposed after a security researcher informed the company’s CISO of a file found on an external server. According to MyHeritage, they store family tree and DNA data on servers separate from those that store email addresses and they use third-party service providers to process payments, so other than email addresses, the rest of their customers’ data was not exposed.
6) The main hack most of us heard about was the whole Facebook / Cambridge Analytica exposé. Upwards of 87 million records were breached. Later, Inti De Ceukelaire (a security researcher) revealed another app, Nametests.com, had publicly exposed information of more than 120 million Facebook users as well.
7) One of the latest breaches happened to Informed Delivery, a service created by the US Postal Service (USPS), which allows customers to view their mail before it arrives at their home mailboxes. In addition to emailing the images, the USPS offers an API to allow users to connect their mail to specialized services like CRMs. However, it was discovered that the service accepted wildcards for many searches, allowing any user to see other users on the site. According to reports, hackers who accessed the data got to see where important documents and checks were being mailed, so they could go and steal them once they were delivered. The USPS has advised people sign up for the Informed Delivery service with your own email address before someone else signs up as you. Estimates say that 60 million records were exposed.
8) Panera Bread exposed 37 million of its customers’ records in early April. What was more concerning was that in August 2017, security researcher Dylan Houlihan attempted to disclose the vulnerability to Panera Bread, letting them know they had a weakness that resulted in Panerabread.com leaking customers’ records in plaintext. That data could then be scraped and indexed using automated tools. Houlihan claims that his disclosure was dismissed for almost eight months, until Houlian reached out to Brian Krebs (an investigative information security journalist) who reported the story. This finally forced Panera Bread to deal with the issue by taking their website temporarily offline so they could fix the vulnerability.
9) Ticketfly was asked to cough up a ransom for a vulnerability that was discovered by a hacker. When the company refused, the hacker vandalized, took down, and disrupted their site for a week. The hacker was also able to replace Ticketfly’s homepage and make off with 27 million records of customer and employee data, including names, physical addresses, email addresses, and phone numbers.
10) The Sacramento Bee newspaper was attacked by an anonymous hacker early in the year. The hacker gained access to 19.5 million records, after seizing two of their databases, and trying to get the paper to pay a ransom for their release. One of the databases contained data from California voter registration provided by California’s Secretary of State, and the other database stored the Sacramento Bee’s subscriber contact information. Sacramento Bee refused to pay the ransom and deleted the databases to prevent additional attacks. However, the attack still left 53,000 of their subscribers’ information and 19.4 million California voters’ data vulnerable.
11) It’s suspected that the fitness app, PumpUp, exposed 6 million of its users’ records after a backend server was found to be exposed to the Internet with no password to protect it. This vulnerability leaked sensitive customer data, such as user-entered health information, photos, and private messages sent between users. The exposed data also contained Facebook access tokens and, in some cases, unencrypted credit card data including card numbers, expiration dates and CVV numbers. ZDNet reported the story and reached out to PumpUp, after security researcher Oliver Hough discovered the vulnerability and reached out to ZDNet to disclosed the issue. PumpUp did not respond to ZDNet, but they did end up securing the server. It’s unclear for exactly how long the server had been sitting exposed.
12) Saks Fifth Avenue and Lord & Taylor became the source of 5 million credit and debit card records which were for sale on the JokerStash hacking syndicate. The discovery was made by security firm Gemini Advisory. After the discovery was disclosed, both Saks Fifth Avenue and Lord & Taylor took immediate steps to fix the issue. A class action lawsuit was filed against them by the customers whose data had been exposed and put up for sale.
In most of these situations, it was a journalist, outside researcher or a white hat hacker that found and disclosed the vulnerabilities. Often, it was too late to be dealt with. One of our Tinfoil Engineers wrote about this issue with disclosing vulnerabilities in a previous blog post. We still believe there are more good folks out there than bad folks, so we look forward to bringing joy and hope to the world of cybersecurity in 2019 and beyond!
Decking the Halls for Holiday Traditions
By- December 04, 2018
It’s that time of year when we’re thankful, our bellies are full of turkey, and we’re turning on heaters and bundling up in sweaters. The holidays are always a great time of year at Tinfoil. We’re typically working hard on fun wrap-up projects before the holiday exodus, and are most collaborative during this time. Tinfoil is a small team, and often our collaboration makes us much more like a family than most companies. Just like all families, we like to make time to celebrate the holidays with one another.
This week, we’re decking the halls with cheer. Each year, Tinfoil puts up a traditional non-denominational holiday tree, adorned nicely with hand-cut snowflakes, twinkly lights, and a hodgepodge of ornaments from different team members and different religions. Slowly it gets filled with surprise Secret Santa gifts, surprise founder-to-employee gifts, and surprise employee-to-employee gifts. Our tree is one of my favorite aspects of Tinfoil. We buy it just for a few weeks, and donate it immediately after our gift exchange to a family who can’t afford one themselves. We’ve given it to a retired firefighter with pensions too small for Bay Area rents, a family whose father was recently laid off, and a nice retired couple living frugally. Each person is so very different, and each one walked away in love with their tree.
Our Secret Santa is a simple event. Each team member automatically draws a name (thanks to drawnames.com) and anonymously picks out a gift with a price limit. We’ve had silly gifts, loving gifts, and gifts that seemed just right. Sometimes we even get visits from past employees. We have a small party to guess who Santa’d us and cider is enjoyed by many.
My cofounder and I like to make sure the tree is filled right up. We add some small additional gifts, ranging from joke gifts, to food, to fun toys for the entire team. One year each person got an animal onesie, and a different year they each got surprisingly good waterproof speakers. There are usually 2-3 gifts for each employee, making unwrapping a fun holiday evening.
Tinfoil’s traditions are similar to many startups. We keep it simple, try to incorporate as much diversity as possible, and try to end the year celebrating our successes together. I’ve heard so many wonderful ideas for holiday celebrations from other startups. What are yours?
Should I include CSRF protection on a login form?
By- November 20, 2018
Since I found Angel’s “Plain English” series of blog posts so helpful when I was first learning about different kinds of vulnerabilities on the web, I wanted to continue that series. I hope to expand into some of the nuances of more commonly known vulnerabilities, and touch on some of the less well known ones. Let’s get started with one special case that I often find questions about: CSRF on a login form.
To start, if you’re not familiar with the Cross Site Request Forgery (CSRF) attack, you should definitely give Angel’s blog post from a few years ago a read. In the typical way of thinking about a CSRF, an attacker is able to submit a form on behalf of a victim with data the attacker controls. In the classic example, you can imagine an online service that allows users to transfer money between each other, perhaps by first adding their credit card. In the absence of any protective measures against CSRF, the attacker can trick their victim into clicking a link that submits a form on their account, and transfers money into the attacker’s account. However, what if our humble service is aware of this risk, and includes some form of CSRF protection on all of their authenticated forms? Our attacker will have to get a bit more clever, and though the aforementioned example might often be the most dangerous case, it is not necessarily the only one.
Strictly speaking, a CSRF attack is one where an attacker is able to submit any request on behalf of the victim. So, the attacker begins looking for other ways to trick our poor victim, and finds that the login form is totally unprotected. Hatching a devious plan, our attacker crafts an attack that would submit the login form in the victim’s own browser, thus logging them into the attacker’s account. So our victim -- now perhaps only slightly confused as to why their credit card info is missing -- adds all of their personal information necessary to send money to their friend, and logs out, thinking nothing more of it. Now our attacker, having full control over their own account, logs back in to find that they have everything they need to siphon funds from our poor victim.
As you may have noticed, the impact of an exploit like this varies from site to site, depending a lot on how likely or possible it is for a victim to leave behind personal information. It also relies on tricking the users into completing at least one extra step, instead of just clicking a dubious link. However, the world of security frequently involves accounting for even very unlikely cases, because an attacker will often have hundreds or sometimes thousands of opportunities, and doesn’t need to succeed every time. It’s also worth mentioning that even seemingly harmless vulnerabilities can be leveraged to enable more potent attacks. You might already be able to imagine how one could use an attack like this to direct a user to a page with an injected XSS, but perhaps I’ll save that concept for a later blog post.
For these reasons, I like to err on the side of caution, and avoid giving an attacker the opportunity to exercise any functionality on another user’s behalf. For more information on how we suggest you implement your CSRF protection, you can refer to the article linked above.
I hope you found this short post helpful in understanding some of the nuance of one of the most threatening types of vulnerabilities on the web. I’m one of the support engineers here at Tinfoil Security, so if you have any thoughts, feel free to email me at firstname.lastname@example.org. I’d love to hear your feedback!
Today I Learned: Using SCSS in your Vue Components
By- November 13, 2018
If you haven’t yet looked into Vue.js, it might be time to. The front-end framework is a powerful, progressive alternative to its main rivals, Facebook’s React and Google-backed Angular, and has been continuously gaining traction among the open source community.
In this way, the CSS for a given component lives alongside the rest of its code, and with the
scoped attribute, will scope all style to only this component - preventing it from bleeding outwards and affecting global styling in unpredictable ways.
One might notice, however, that throughout much of Vue’s documentation and in countless tutorials, guides, and articles on all things Vue, the language used to this styling plain, vanilla CSS. In a world where SCSS exists, with it’s support for variables, mixins, and nested styles, can we do better? Yes we can.
Styling your Vue components with SCSS is incredibly simple - provided you have the right configuration.
Above is an example
webpack.config that makes use of
vue-loader. You’ll want to install both the
node-sass packages first, however.
npm install -D sass-loader node-sass
Once you’re configured, simply add a
lang attribute to the style tags in your components:
And you’re set! Enjoy all the features of SCSS in your Vue components.
When the unlimited vacation policy doesn’t work
By- November 06, 2018
Many of us startups provide what we call unlimited or flexible vacation policies, with the goal being to take as much time off as you need, as long as it’s manager approved and you can get your work done. There are so many pros and cons and I’ve seen so many people ask why to have or not to have an unlimited vacation policy in place.
Most people think that unlimited means people will take off all the time. And, yes, we have seen that happen on some very rare occasions. We do have a policy, for example, that interns no longer get vacation during their stint at Tinfoil. Internships are typically 3 months and have a set project. If an intern takes off too much time, they’re less likely to finish the project in the scoped out time. That doesn’t mean if all of their friends are going to Yosemite they can’t, but we don’t advertise vacation for them.
What we’ve actually found for the flexible vacation policy, though, is that usually we see the opposite of most founders’ concerns: employees don’t take nearly enough time off to avoid burnout. There are lots of different things we’ve implemented in order to make our flexible vacation policy work. The first thing we implemented was holidays. We try to have one holiday a month. Sometimes those are just fun, silly holidays like Pi Day, and other times they’re your standard federal holidays, like Thanksgiving. On occasion, they’re things we’re going to do together, like Tinfoil’s Anniversary. We try to make sure holidays are spread evenly throughout the year and allow time in conjunction with both weekend and weekdays throughout the year to break up the normal routine.
When we implemented holidays, the policy was that you could still come in to work, but shouldn’t expect anybody else to be in the office. Initially, many employees still worked holidays, but it eventually got to the point where we realized that we should really take those holidays off. We started to and we noticed a drastic drop in stress and burnout levels.
Once we implemented the holidays, we still had a couple of issues where some people were still going to the normal rhythm. They wouldn’t take longer vacation and, though the holidays helped a lot, they didn’t fix the entire problem. Part of what we noticed was that if someone did something outside of their normal routine on a weekend, for example, if they traveled or did something unique that they didn’t normally do, they typically got to the point of burnout way less frequently. This led to a solution: we took a handful of holidays (typically holidays such as Pi Day, that employees weren’t already traveling for or doing atypical events for) and called them special holidays. We’ve been beta testing special holidays for 2-3 years and they work wonderfully.
For a special holiday, we give you up to $60 to go out and do something outside of your typical routine. This could mean going camping, kayaking, skydiving, getting a fondue as a group… anything you wouldn’t normally do. Of course, we have had to create guidelines over time. We reimburse up to $60. If it’s under $60, that’s ok, but we ask our employees to be honest and we’ll reimburse up to the amount they actually spent. There are some things that we’ve rejected, as well. As always, you have to be flexible and revisit your policy over time. For us, we saw some employees doing the same thing every special holiday. We eventually made the rule of there needing to be at least a 12-month gap between repeating the same event or activity.
We did have to implement a few guidelines at the beginning, based off of questions employees asked. For example, if you want to host a party, that’s OK, but if you want to play a bunch of board games, you can’t buy six different games on the company and call it good. We wanted this to be for experiences, and not for physical items. We encourage employees to use it in a manner in which they can actually experience something that they wouldn’t usually do. We found that, when people actively partake in this benefit, they tend to come back refreshed and get excited about what they did, whereas those that didn’t do anything new don’t have the same level of “refresh.” People excitedly talk about the things they did and others end up wanting to do that experience the next time, so we have a page on our internal wiki to add fun weekend ideas to share with others. This is great for team bonding, great to make sure that people don’t hit burnout, and it’s one of the few things we’ve added to make sure our unlimited vacation policy works.
It’s true that every so often you’ll see somebody taking advantage of any policy you have in place that’s beneficial to them, but, on average, we believe our employees are honest, faithful, and act with integrity. Often, you’re going to see that unlimited vacation expectations are set by the top. If your management is not taking enough of a break, your employees won’t take enough of a break, and everybody will suffer. There are lots of little things you can do to make this policy successful. What have you found? Have thoughts on how we could improve our policies or new ideas we can try? Email me anytime with suggestions!