Showing posts with label Hacks. Show all posts
Showing posts with label Hacks. Show all posts

Monday, August 5, 2019

How I fell in love with i3

Understand what i3 is and how it can drastically change how you use your Linux desktop.

I've been using the i3 window manager for a couple of years and would like to share some thoughts about it. But first let's understand what i3 is and how it can drastically change how you use your Linux desktop.

What is i3?

The official documentation describes i3 as:
a tilingwindow manager, completely written from scratch. The target platforms are GNU/Linux and BSD operating systems, our code is Free and Open Source Software (FOSS) under the BSD license. i3 is primarily targeted at advanced users and developers.
But what's a tiling window manager?

Tiling Window Managers

A tiling window manager is a program that runs on top of your operating system's graphical user interface (GUI) that auto-manages your windows for you. The most common way users interact with their computers these days is via desktop mangers (GNOME, KDE, XFCE, etc). That same program includes tools to set wallpapers, login managers, drag and move windows around and interact with other running windows and services.
Source: DevianArt

Differences

So what are the differences between a tiling window manager and a desktop manager? Many. For simplicity, tiling window managers:
  • are way simpler than full desktop managers
  • consume way less resources
  • require you to setup most things yourself
  • auto-place windows on the desktop
  • automatically split window space
  • do not allow dragging or moving windows around
  • always use 100% of the allocated space
  • are easily customizable
  • allow managing desktop applications using the keyboard
  • can be configured to pre-load specific configurations

Why i3

Working with i3 may be a radical shift in how we use our computers, so why should one switch from traditional desktop environments like Gnome, KDE, MATE, Cinnamon to i3? In summary, you should consider i3 because i3:
  • will make you more productive
  • is simple, concise
  • is lightweight
  • is fast, super fast
  • is not bloated, not fancy (but can be)
  • is extremely customizable allowing you to configure it the way you like
  • reduces context switching, saving you time and brain power since you will stop wasting time dragging and searching for windows around
  • allows you to manage your workspace entirely using the keyboard
  • has vim-like keybindings (yes, this is a plus!!)
  • has easy support for vertical and horizontal splits, and parent containers. 
  • improves your battery life
  • can integrate with other tools of your system
  • will make you feel less tired after a day of work
  • will make you learn better the GNU/Linux operating system
  • will make you more the terminal and terminal-based tools
So let's review some of the main reasons to switch to i3.

A Beautiful Desktop

i3 will make your desktop beautiful. Through its simplicity you will discover a more uniform and elegant experience. For example, take a look at this beautiful Arch desktop running i3. See how all applications integrate seamlessly. No overridden windows, no pixels wasted.
Source: Reddit

Productivity

My productivity increased significantly using i3. Why? Because it's keyboard-friendly nature made me stopped using the mouse significantly. Yes, I still have to use the it but now I try to keep that to a minimum. Today, 90% of my work can be easily accomplished via keystrokes.
Source: Reddit

Efficiency

On traditional desktop environments spend a lot of time dragging windows around and alt-tabbing between them. i3 saves hundreds of alt-tabs and hand-right-hand-left movements to reach the mouse. That's a lot of context switch saved, and a lot of efficiency gained!

Less Fatigue

i3 will also reduce your fatigue. Why? Arm right, Arm left, that involuntary movement we do thousands of times a day to reach the mouse adds a lot of fatigue to our body and it's one of the main reasons we feel exhausted after using the computer for a day. With i3, you'll keep your hands on the home row of my keyboard and move less your arms to achieve the tasks you need. You'll probably feel less tired after a day of work on my Fedora at home than after a couple of hours on Windows.

Highly Customizable

Unless you're super minimalist, you will like customize your i3. There are a lot of tutorials out there and I urge you pick some specific for your distro. In general people add a different color scheme, change icons, fonts, the toolbar, and the Gnome theme when applicable. Some examples can seen here.
Source: Reddit
Source: Reddit

The i3 configuration is simple to read, understand, share and modify. Don't like that keybinding? Change your ~/.config/i3/config file and do your changes. For example, here are some of my custom bindings:

Easy to get started

i3 is available on repositories for Fedora, Ubuntu, Arch and other major distros. That said, installation should be straightforward by using your package manager (see below). After you start i3 the first time, you are prompted for an initial configuration that will set the basics for you to get rolling.
After installation, you'll be prompted with this screen on your first login

Compatible with GNOME/KDE tools

Be assured that you will still use all your GUI applications with i3. Firefox, Chromium, Calculator, Nautilus, Gnome settings or Gimp, everything should be available and accessible trough the default  dmenu.
Source: https://i3wm.org/screenshots/

You will use more the terminal

I realized that with i3 I've been using more and more the terminal. I replaced most of the visual GUI applications with tools like:
  • system management: systemctl, dnf, journalct, etc
  • networking: nmcli, ifconfig, iwconfig, netstat, etc
  • process management: top, htop, etc
  • text editor: Vim
  • text manipulation: sed, awk
  • search: fzf, find, grep
  • file management: ranger, xargs

You may not realize but once you memorize the commands and rely less on the mouse and on graphical applications which by design are less feature-rich, you will become more confident using your system, improve and accelerate your workflow. Then you learn more and repeat the cycle.

You will learn new tools

You will also learn new tools. And because you'll be using more and more the terminal, you will probably change your whole workflow and realize you'll be more productive using the terminal. For example, these are the tools I'm using more and more:
  • Vim - my main text editor. Adheres very well to the i3 workflow.
  • Mutt - not perfect but very decent email client for the terminal
  • Ranger - a fantastic file management for the terminal!
  • rtv - Reddit on the terminal
  • w3m/lynx/links - Terminal-based web browsers
  • Tmux - essential with WSL and on a SSH session. But not a strong requirement for i3 users
  • fzf - fantastic command line fuzzer. Also available as a fzf.vim plugin
  • Grep - powerful search from the command line
  • Awk, Sed - utilities manipulate streams

Better performance, less memory

Computational performance is like free beer, we never say no =). GNOME was already fast on my notebook but i3 makes it even faster. Add to that less memory consumption (my system running i3 utilizes around 400Mb of memory, while GNOME consumes 1GB) and you realize how performant your machine be! And it gets even better with old hardware paired with XFCE, LXDE or LXQT.

You will learn more about Linux

Using i3 made me learn and know more about the Linux system and the GNU tools. Because I drastically shifted how I do my work on my Linux box to using tools such as grep, Vim, Tmux, ranger and mutt. I've also stopped and finally learned how to work well with sed, awk, systemd, firewalld, networkd, auditctl and lots of other system tools that I never bothered with.

Installing i3

If you sympathized with i3, let's see how to install it.

Installing on Fedora

sudo dnf install i3 i3status dmenu i3lock xbacklight feh conky

Installing on Ubuntu

sudo apt update
sudo apt install i3

Logging in

Assuming the installation was successful, logout and before logging in, remember to change the toggle to use i3:

Source: Fedora Magazine
On your first login, you should be presented with this screen that will automatically generate a configuration for your user:

Next Steps

The best way to get started with i3 (and its sibling Sway) is of course, by using Fedora. The community has produced two spins with the basic setups called Fedora i3 Spin and Fedora Sway Spin. Please check those pages for more information.

Test it on a VM

Once you read the documentation, I'd recommend to install it on the VM hypervisor of your choice. (Hyper-V, VirtualBox or VMware workstation are the most popular). Please git yourself some time to familiarize yourself with the proposal before giving up.

Read the docs

The first thing you should do is read and understand well the documentation. i3's official documentation is also an excellent resource and very well documented. YouTube, GitHub and the i3wm community on Reddit are also great resources to get started and learn how to tweak your setup.

Get used

Once you're comfortable with the setup, consider doing some of these:

  • Get used to using the <mod>+enter to start your terminal
  • Map applications you use the most i3 bindings (see Customization above for some examples)
  • Configure your toolbar to add/remove information you need
  • Keep learning more about i3. Use it for some time before removing removing it if you're struggling. 
  • Once you start getting comfortable with it, start replacing GUI-based applications for TUI-based applications (those that run on the terminal)
  • Consider changing your workflow to optimize repetitive actions (using aliases for example)
  • Continue learning and tweaking your config files until you're productivity goes up

Tweak

Next, feel free to tweak i3 as much as you need! In case the defaults don't appeal to you (probably they won't), remember, you can always change. For example, it's simple to switch the defaults to:
  • change the toolbar: i3blocks or polybar
  • add padding between tiles (windows): i3-gaps
  • add fancy UI transitions with compton
  • enhance your desktop background: conky, feh
  • replace your application launcher: rofi

Conclusion

Let me be clear: i3 is not for everyone. If you're a mouse person, if you don't like to spend time configuring your desktop, learning new tools, using the terminal, don't bother with i3. Linux desktop environments are amazing and have everything that a user already needs out of the box.

But, if you want to be more productive, learn better your Linux system, configure your system as you want, I would urge you to try i3. Set aside some time to learn the default key bindings, learn how to configure it and use it for a couple of weeks. Don't give up before that. Let your muscle memory work 😉.

See Also

Posted by
Labels: , , , , , , , , , , , ,

Monday, October 22, 2018

Integrated security vulnerability alerts on GitHub - Why it matters

How GitHub's integrated security vulnerabilities could help developers using the platform?
Last week during GitHub Universe 2018, GitHub announced support for security vulnerability alerts for Java and .NET platforms. It's a significant contribution for the .Net and Java communities on GitHub because it simplifies, clarifies and alerts organizations and project owners about vulnerabilities on dependencies used on their code base.

Sounds complicated? Let's review what the announcement says:
With security vulnerability alerts, organization owners and repository admins receive a notification when any of their projects has a dependency with a known vulnerability.

How it works

By tracking public vulnerabilities in packages from supported languages on MITRE's Common Vulnerabilities and Exposures (CVE) List, GitHub notifies repo owners and alerts them of the risk.  By default, security alerts will be sent to owners and people with admin access in the affected repositories.

Apart from alerts, you should also see on your dashboard something like the below on the Insights tab, Alerts navigation menu of your GitHub repository:

GitHub now alerts about public vulnerabilities on your project

Apart from the above, other nice additions were added:
  • You will get weekly emails summarizing security alerts for up to 10 of your repositories
  • Most of that is configurable within GitHub
  • Works for both public and private repos
  • More importantly, GitHub never publicly discloses identified vulnerabilities for any repository.

Fixing the vulnerability

But knowing of potential vulnerabilities is just the first step. The next step is to address the issue and update the packages. Since .Net users usually update their packages using the Nuget package manager with packages located on Nuget.org, let's look at a concrete example: how to fix a recent vulnerability on Microsoft.Data.OData.

Microsoft.Data.OData is a very popular package. With 33+ Million downloads, it's being used in multiple 3rd party packages and probably you're using it on your projects too. Here's what I see on Nuget.org:

According to GitHub, CVE-2018-8269 was opened just last month and includes a vulnerability on every version < 5.8.4. Here's what the issue says:
A denial of service vulnerability exists when OData Library improperly handles web requests, aka "OData Denial of Service Vulnerability." This affects Microsoft.Data.OData.

So let's update the dependency and patch the vulnerability.

Updating Microsoft.Data.OData

As you know, the update of a package can be done in multiple ways. Using Visual Studio or from the command line with:

Using the Package Manager:
Install-Package Microsoft.Data.OData -Version 5.8.4

Using the .NET CLI:
dotnet add package Microsoft.Data.OData --version 5.8.4

Once you've done that, rebuilt and redeployed, you're protected from CVE-2018-8269 at least =) .

Conclusion

Bugs security issues are always being found and fixed on libraries that we use. Reason why we should always try to keep our packages up to date.

But it's not trivial to scan all packages we use against the CVE database. Note that the CVE above does not state which version it applies to. Imagine how difficult and time-consuming it would be monitoring all the dependency chain ourselves. That's why this service from GitHub is very much appreciated!

Let's leverage this very useful feature for our benefit and keep our code secure.

And please, spread the word!
Posted by
Labels: , , , , , ,

Monday, February 26, 2018

Why you should consider using 1Password

Using an online password manager has its advantages. Let's review them.

This is a very good week for 1Password users. AgileBits reports that they have integrated the 1Password online password manager with Troy Hunt's Have I Been Pwned? (HIBP) service. I mentioned Troy in this blog a couple times and I always point his blog and his HIBP service here and to people who are somehow interested in their security online.

Have I Been Pwned?

HIBP allows you to search from 500 million passwords collected from various data breaches. Checking your passwords against this list is crucial to keep your data safe. Apart from passwords, ut can also check if your email account, a website you use or a domain has been compromised in a data breach. And there's a lot of data there. We're talking about half a billion leaked passwords.

So, HIBP has my password. Does it mean I was hacked?

Not necessarily. If it's a common password, maybe it was being used by someone else. If it was a complex one, probably.

HIBP tells me my email address has leaked, was I hacked?

Also not necessarily. But unfortunately, it's highly probable that your email is already in the hands of spammers.

Is it safe? 

Well, if Troy with all his expertise in the field cannot be trusted, who else can? Also, AgileBits and lots of other people use his services. Don't see why we shouldn't. For more info, check this FAQ.

Are my passwords kept secret?

Yes. HIBP doesn't have access to your password. Here's what AgileBits reported:
First, 1Password hashes your password using SHA-1. But sending that full SHA-1 hash to the server would provide too much information and could allow someone to reconstruct your original password. Instead, Troy’s new service only requires the first five characters of the 40-character hash. To complete the process, the server sends back a list of leaked password hashes that start with those same five characters. 1Password then compares this list locally to see if it contains the full hash of your password. If there is a match then we know this password is known and should be changed.

If my passwords wasn't leaked, am I safe?

No. This is only a dataset of know breaches. Obviously there's way more circulating out there that neither Troy nor other researches have yet reported. Also, don't forget that a website you use may yet be exposed to a security breach meaning that your credentials can be leaked in the future. As a suggestion, keep returning to the site to make sure that your account hasn't leaked. You can also use the NotifyMe feature or even the RSS feed.

How does it work?

If you want to learn more, the video below shows how the feature works.

Benefit for 1Password users

This integration is immensely beneficial for 1Password users and I would be very happy to see more integration with HIBP. Basically because the service will notify you upfront that you're using a weak password.

Conclusion

This is a very welcome feature to 1Password and I sincerely hope that more websites integrate with that tool. I also urge you to start using that service or any tool that generates more secure password. In the meantime, let's all thank Troy for his awesome work, shall we?

References

See Also

For more posts about Security on this blog, please click here.

[Update June 16th, 2020]: Good news! Dropbox also released its password manager!
Posted by
Labels: , , , , , ,

Monday, February 19, 2018

About the Freedom Mobile Hack

It seems that everyday some company is hacked (for the same reasons). Let's see why.
Mobile syrup reported in 2018 that an anonymous hacker posted a very detailed post on Freedom Mobile's subreddit about how they managed to access customer sensitive data on FreedomMobile.ca. While this wasn't confirmed, let's stop and evaluate certain aspects of the hack from different sources.

The Code

According to the report, the hacker mentioned it only took them 23 lines of code.. While anyone can guarantee this source is reliable, depending on how it was implemented, it indeed may have been possible to build a simple python script to perform username enumeration and password bruteforcing if the necessary prevention mechanism isn't in place.

The Login Widget

I inspected the code as soon as the news was out and collected some data. On Feb 15, 2018, the login screen just after the news offered that apart from username/password, we can also login using Phone number / PIN. If you were the hacker, which login you think would be easier to guess? A password (that can be anything) or a PIN composed of 4 numeric chars? 😉

Reviewing the Phone Number widget

I'm interested about this Phone number / PIN thing because PINs are usually simple and often are used to access your device from the phone. So, they should be numerical. Let's see what the source tells us:

From the screenshot we see that:
  • they're using Angular which has its flaws. Are they running the latest version?
  • some validations happen in the front-end (I hope they revalidate in the the web server);
  • that specific validation is done using Regex (pinRegEx).
  • the min/max length: 4 chars (see the red box on the right there);
  • the "PIN not valid" on the left shows up for non-numeric chars;

Estimating the Complexity

So, a mobile number and 4 numeric chars. How complex can that be?
  • mobile numbers are public.
  • PIN requires 4 numeric characters = 10 ^ 4 or 10,000 combinations

Brute Force

So, knowing your phone number, it takes the hacker, on the worst case, only 10,000 guesses. And it can get better. For example, if your pin were 1220 (Dec, 20) it would have taken me 10% of the time to guess your password.

Username Enumeration

The above has nothing of fancy, complex or undocumented. In fact, username enumeration and password bruteforcing are present in OWASP's CSRF Prevention guide and are part of OWASP's top 10 web application risks.

The hacker confirms it:
Source: https://mobilesyrup.com/2018/02/12/freedom-mobile-security-breach/

No brute force prevention

Sight. No brute force prevention. No account lockout? No MFA? No alerts. Probably not. Worse, the company ignores the issue, states the corporate jargon and returns the responsibility to users (as if a system based on 4 digit numeric PINs, no bruteforce or password enumeration prevention were secure enough):
“We continue to strongly encourage our customers to use unique PIN numbers that are not easy to guess, and to change their PINs frequently to best protect their personal account information. (...) meeting customer demands for a resonable login process.”

Shared Responsibility

Before we wrap up, there are two more things about this hack that are worth questioning:
  • who's responsible the decision to simplify the login by using the phone/PIN widget?
  • who's responsible for not preventing brute force without any lockout mechanism or alert on the login operation?
While I don't want to discuss who's responsible for what, I don't see the developers deciding how people should perform the login on the company's website. Certainly the ability to brute force such a crucial aspect of the application was missed or ignored by the business. It's definitely a shared responsibility.

Conclusion

So, even if we assume that the hack didn't happen, 10k combinations without any prevention against CSRF, username enumeration and/or password bruteforcing is not acceptable. Everyone loses when companies try to simplify security aspects for its users but do it wrong ignoring the most critical web application security risks. In time, if you haven't read yet, check OWASP's CSRF Prevention guide.

References

See Also

For more posts about Security on this blog, please click here.
Posted by
Labels: , , , , , , , ,

Monday, January 8, 2018

Web Development best practices: 9 tips for stronger passwords

Stronger passwords are a good practice to make our own systems secure. Let's see 9 tips to keep safe.
We already discussed how to secure our front-end and how to create stronger passwords for ourselves. On this post, I will approach how we, developers, can make integrate those concepts in our applications to reduce the risks of our users' accounts being hacked due to weak passwords.

Tip 1 - Expect stronger passwords

It is time applications start demanding stronger passwords from their users and inform them on how secure is their password (more on that later). So, when accepting user-entered passwords, if you don't mind, I will repeat what was written before on this blog removing what's not applicable:
  • Use passwords with at least 8 characters;
  • At least one number, 1 capital letter, 1 lowercase letter, 1 non-alpha character;
  • Use complex passwords that include numbers, symbols, and punctuation;
  • Use a variety of passwords for different accounts or roles;
  • Do not allow dictionary words as passwords, e.g. apple;
  • Do not allow sequences of characters, e.g. 3333, abcdabcd;
  • Do not allow personal information in passwords, e.g. your birthdate;
  • Do not allow setting the password as the associated service, e.g. Gm@il or Dropbox123;
  • Combinations of those above;

Tip 2 - Have a password and confirm password box

This is somehow trival. We don't want users entering a password they don't remember. So, ideally, we should have a Password / Confirm password section when creating an account.

Tip 3 - Provide feedback on how strong the entered password is

Once all information entered, please provide a feedback to the user regarding how safe is her password. For example, KeePass provides us this input:
Source: KeePass

And Twitter:
Source: twitter.com

Tip 4 - Recycle passwords

Yes, ideally we want users to change passwords every X days. I don't see that feature on most of the sites but it would be good to start having that featured enabled by default on websites so that rists on data leaks is automatically reduced. Outlook.com has that nice feature:

Tip 5 - Enable MFA

Multi-factor authentication greatly helps securing accounts. We already discussed that on a previous post. Enabling something for your app may not be complicated and assuming you don't want / can't use SMS, you could use a secondary email address for example. For example, this is Gmail's MFA:
Source: gmail.com

Tip 6 - Avoid Leaking Information

This should be common sense already but unfortunately it isn't. Web applications are still leaking a lot of information. For example, password hints usually allow:
How strong is that hint?
In case you have to have this feature, prefer to present options to the user in a dropdown as opposed to allowing him intering his own. Users are not good at creativity and usually provide very easily guessable password hints as:

Other approaches should suffice in order to not have a password hint:
  • allow different recovery options, such as reset tokens sent to secondary e-mails;
  • avoid password hint and just provide a safe forgot password service;

Tip 7 - Validate if password has been exposed

Troy Hunt's Have I been pwned? service provides a very interesting functionality: a database with X records that you can check against to validate if a used password.

Tip 8 - If possible, generate a strong password for your users

I know, this is controversial but how else can we go to make our users create strong passwords? Will they have creativity to respect all those constraints? Will they even be able to remember those passwords? Why not have a password generation built into our site to allow the creation of strong passwords for them?

Tip 9 - Test how secure is a password is

We can always use tools to inform us how secure our password ares. When online, we have how secure is my password. Or even better, why not integrate our application with such a service?

Conclusion

Posted by
Labels: , , , , , ,

Monday, November 20, 2017

How and why use stronger passwords

The number of online attacks increases and weak passwords is one of the main reasons. Learn how to create stronger passwords and be safer online.
Passwords are probably the most sensible aspect of our lives today. With more and more leaks happening every day, it's strongly recommended to start thinking about stronger passwords for our personal online accounts and our applications. So how can we leverage existing tools in a non-complex way to enhance our online protection?

Let's take a look.

What you should do

Let's start with simple basic tips for everyone. For starters, this is what we should be doing:
  • Using passwords with at least 8 characters;
  • Using complex passwords that include numbers, symbols, and punctuation;
  • Using a variety of passwords for different accounts or roles;
  • Using a secure password tool;

What you should not do

It's also important to remember what we should not do. For example, below I list somethings we should not be doing:
  • using dictionary words as passwords, e.g. apple, cat, Raptors, etc;
  • use sequences of characters, e.g. 3333, abcdabcd;
  • use personal information in passwords, e.g. your birthdate;
  • reutilize passwords;
  • avoid setting the password as the associated service, e.g. Gm@il or Dropbox123;
  • combinations of those above;
Other interesting tips to increase our protection are:
  • Avoid storing passwords on devices that you take out of home;
  • Use a password manager to securely keep track of your passwords (see the section below);
  • Setup MFA/2FA when available (see the section below);
  • Use a secure password generator to generate stronger passwords (see the section below);
  • Never remember a password!

Use Password Managers

While the  above tips are good to start and have in mind, let's now see concrete examples in how we can increase the complexity of our passwords and how we can protect them from external access. Utilizing stronger password demands a better memory. In case you don't have one as me, I  strongly recommend the utilization of a password manager like 1password, KeePass and it's forks KeePassX and KeePassXC. That's why I never remember my passwords! =)

And because I need to access my passwords on Linux and Windows machines, I'm currently using KeePassXC. I also advocate for files on disk instead of services like LastPass because you cannot trust anyone else nowadays =). How safe is LastPass data for example? Well, they were hacked before...

Using KeePass

Since KeePass is one of the most familiar out there, let's provide a very quick introduction on it. The rest, I'm pretty sure you can figure out. Also, if you're using one of its forks, should be the same, just varying the visual look and feel.

Step 1 - Create your password database

The first step is to create your password database. Launch KeePass, 

Step 2 - Start adding your passwords


See? KeePass not only manages our passwords but also helps us generating a very complex passwords for us.

Step 3 - Keep using it!

Yes, keep using it! Add all your accounts to this file and keep it safe on your disk, doing periodical backups. And sice KeePass is remembering your passwords for you, you have no excuses for sharing passwords or using simple passwords. Plus, backing up this file online is safer as the file is encrypted and assuming you didn't choose a very simple password for the file, it should take a long time for someone to crack it.

Which takes us to the next tip...

Recycle Passwords

Another relevant tip is recycling passwords. You may have already figured out that it's a technical term for not reusing the same passwords. But why? Yes, you should recycle your passwords every 3 months or so. It helps against data leaks. Or, if your service has something like a password expiration policy, even better:
Source: Outlook.com

How to create stronger Passwords

Most password managers have a very useful tool to generate passwords. After getting familiar with KeePass, I suggest getting acquainted with the Password generation tool.  To access it, do:
Tools -> Password Generator:

As we can there there are lots of intresting options here:
  • You can set the length of the generated passwords;
  • You can set/unset multiple options (I would recommend checking at least 4 of them);
  • You can provide patterns, certain characters;
  • You can strengthen entropy by clicking on the "Advanced" button
And, by clicking on the "Generate" button, KeePass will generate a password for you. It will even tell you how strong your password is (92 bits in this case). Remember to keep an eye on the bar. It will tip you how strong your password is. In theory, we should have the tool generate passwords for us as their algorithm handles better the complexity required.

Enable multiple-factor authentication

Multiple-Factor Authentication (MFA) and it's simpler form Two-Factor Authentication (2FA) is a way of logging in that requires more then a password. Example: a text message or a verification e-mail with a random code on a different email account are sent and the user will only be allowed access if she enters the right code..

MFA adds a very strong security component to our online accounts since it reduces dramatically the chances an unauthorized user can access our accounts. Many recent hacks such as the celebrity hack could have been avoided if MFA was enabled. But Apple have learned from the episode and now advise users to protect themselves using 2FA:
To protect against this type of attack, we advise all users to always use a strong password and enable two-step verification. Both of these are addressed on our website at http://support.apple.com/kb/ht4232.

Example 1 - Enabling MFA for an Apple ID

The majority of the most used websites currently offer MFA. As an example, here's what you need to do to enable MFA on you Apple ID.

Source: https://support.apple.com/en-ca/HT204915

Example 2 - Enabling MFA on GitHub

In GitHub, go to your profile -> security, and click:

Then you choose one of the options below to get your code:

How Secure is your Password?

Speaking of strong passwords, how secure is a  92 bits password compared to my own password? According to howsecureismypassword.net:
  • your simple password like "Apple123" is broken instantly;
  • a complex password as that one generated above would be broken in 52 quadrillion years;

Just access that type and enter your password to get a quick feedback on how long it would take for someone to crack your passwords:
Source: https://howsecureismypassword.net/
Spot the difference? Few hours x 52 quarillion years. But wait! There are techniques to speed up this process but we will not cover them now. The objective of that was to illustrate the importance of creating and using stronger passwords.

Conclusion

On this post I presented many suggestions on how to create strong passwords, store, transport and additional protection layers such as MFA. Please, start use them all and make your information safer. As a final note, consider using stronger passwords and enabling MFA on all your accounts.

See Also

Posted by
Labels: , , , , , , , , ,

Monday, October 16, 2017

Securing your front-end

How secure is your front-end and how much could it be? Let's discuss it on this post.

An extremely common and dangerous flaw in web apps security is relying solely in client side security as we already discussed on this blog here and here. On this post we’ll examine the most frequent mistakes developers make and how to protect from them. But before we proceed, check our previous discussions on web application security. For all the topics on security, please click here.

Law of Security #4

We already reviewed the 10 laws of security on this blog. So, you may recall our Law #4:
If you allow a bad guy to upload programs to your Web site, it’s not your website any more.
That's probably, the main (but not the only) reason why web applications are so insecure: users are constantly submitting data to your application and changing data state. So what should we do? 
Should you trust all data being submitted to you?
No.

Can you trust data from cookies sent to you?
No.

Can you trust everything that you are getting in your web application layer?
Of course not.

You cannot trust client side security

Because you don’t have control of what runs on your client or how that information is being submitted - if it was manipulated or came from a different source than you expect - you should never trust the data you are getting in a request. That's why you should always re-validate in your server data sent to you. The only actual info you should trust is the session, stored on the server.

So what are the most common mistakes?

In the context of web applications, the most common mistakes web developers make are:
  • Hiding info in hidden fields
  • Relying on Http cookies
  • Relying on Url parameters
  • Using Form action urls for backend logic
  • Using the Referer header for backend logic
  • Trying to be cryptic or to obfuscate info
  • Rely purely on the ASP.Net Viewstate
  • Rely only on html form attributes
  • Only run Javascript validation

Mistake #1 - Hiding info in hidden fields

In the past, developers used to hide essential information in hidden form fields as:
<input type=”hidden” name=”price” value=”45”>
So when a post was submitted to the server, something like the below would be sent:
POST /page.aspx HTTP/1.1
Host: mysite.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
quantity=1&price=449
Hacking this application is as simple as:
  1. changing the price value using devtools and resubmitting the form;
  2. issuing a post from a different tool to the server.
Luckily, this anti-pattern is no longer common anymore.

Solution

The solution here is simlpy not use hidden fields to pass sensitive information to the client. Use the Id of the product or some other type of identifier instead.

Mistake #2 - Relying on HTTP cookies

This one is less common but is still being used. Developers are still saving sensitive information in cookies, which are stored in the client side and can be easily manipulated. Consider this response from the server:
HTTP/1.1 200 OK
Set-Cookie: Discount=20
Content-Length: 100
Assuming that the Discount value set in the cookie was used to perform some calculation in the server, a malicious user could easily change that information to 100 for example, and get the product for free. Not what we want.
POST /store.aspx HTTP/1.1 
Cookie: Discount=100
Content-Length: 10

Solution

The solution here is simlpy not use cookies fields to exchange/store sensitive information to the client. If you need to save, save it on the session, on the server. Upon each request, get the session value and process it from there.

Mistake #3 - Relying on Url parameters

Often, urls are very easily hackeable:
 somesite.com/store/view?prod=3&price=100
Anyone using a web browser or curl for example could alter that url and, if that property was used to provide the price to the server, alter it and benefit from your security issue. Others can be more obscure but also open to attacks:
 somesite.com/store/view?prod=3&price=100&price_tkn=VJ58k6UxCFdUHiVj
 Remember that security trough obscurity does not work flawlessly.

Solution

Avoid using the query string to pass sensitive information. Even if some urls are meant to be hackeable, that's not the objective here.

Mistake #4 - Using Form action urls for backend logic

Similar to mistake #3, hidden but still modifiable, form actions can also be used to pass information :
<form action="/store/submit?discount=10">
...
</form>
Remember, this approach could be easily manipulated.

Solution

Avoid using the query string to pass sensitive information. Even if some urls are meant to be hackeable, that's not the objective here.

Mistake #5 - Using the Referer header for backend logic

Less common, the Http Referer header can be used to simulated authentication logic in the server. For example, a request like:
GET /auth/CreateUser.aspx HTTP/1.1
Host: mdsec.net
Referer: https://mysite.com/auth/admin.aspx
Could be interpreted in the server that the user indeed came from the admin page. While this could be true for non-malicious requests, it could also be manipulated.

Solution

Avoid using the Referer for authentication as can be easily manipulated in the client side.

Mistake #6 - Trying to be cryptic or to obfuscate info

We already provided an example in mistake #3. Trying to be cryptic or obfuscating information is not a 100% reliable solution. Yes, it could be used as part of a solution but should not be the sole solution.

Solution

Be creative securing your services and avoid security trough obscurity.

Mistake #7 - Rely only on html form attributes

Html form attributes like maxlength and disabled are nice but can be easily circumvented by simply removing them in developer tools or by submitting. Example:

Solution

Keep using those components to provide more friendlier applications but never rely only on them to validate your data. Always have similar validation in the server and in the backend if necessary.

Mistake #8 - Only run Javascript validation

As in mistake #8, relying solely on javascript is highly insecure as javascript can be disable or be easily removed, altered or manipulated in the client machine.

Solution

Make use of javascript to serve more friendlier applications but never rely only on it to validate your data. Always have similar validation in the server and in the backend if necessary.

Conclusion

So there you are, hope this post has helped you identifying the threats your app may be facing and how you could protect against them. But only for your front end. Remember, security is complicated. Securing your frontend is just another piece in the complex effort towards a good security framework.

See Also

  For more posts about ASP.NET on this blog, please click here.
Posted by
Labels: , , , , , , , , , , ,

Monday, September 18, 2017

Security is only as strong as your weakest node

If someone said to you that security is only as strong as the weakest link, would you know what that means?
When we talk security, there are certain patterns that as developers, we should know about. The "Security is only as strong as your weakest node" is one of them. Bruce Schneier explained that on his excellent Secrets and Lies book as:
Security is also like a chain. It is composed of many links, and each one of them is essential to the strength of the chain. And like a chain, security is only as strong as the weakest link. In this part, we look at the different security technologies that make up a chain, looking from the inside of the onion to the outside
Let's review with a concrete example what that means.

A simple multi-layered Architecture

Suppose we have the following simple architecture, common in most IT shops:
As seen, the above architecture is composed of:
  • a firewall;
  • one web server;
  • one database server;
  • one backend server;
  • storage accounts;
  • a messaging system used to communicate between the servers;
  • probably a build server;
  • probably a deploying mechanism;
  • probably multiple workstations with developers working on it
  • probably multiple 3rd-party packages and dependencies used in development projetcts
  • probably making use of multiple SaaS, PaaS, IaaS.

And what's necessary to secure this architecture? Let's review a security checklist.

A security checklist

In my company for example, this is the minimum that I could expect:
  • on the firewall: inbound and outbound rules are safe, the firewall software is kept up to date, the accounts to access the service have strong passwords, the server is kept up to date, etc;
  • on the web server: ensuring only necessary ports are open, services are not leaking any information, the server is patched, the webserver software itself is patched, the services utilized are secure (such as ssh, sftp, etc) and up to date, accounts to access the service have strong, rotating passwords, the code is reasonably resilient against attacks, has anti-virus software running, etc;
  • on the database server: ensuring not open to sql injection attacks, server is patched, database software is patched, no horizontal/vertical escalation can happen, accounts to access the service have strong, rotating passwords, has anti-virus software running, etc;
  • in the backend: code is somehow safe against attacks, OS is kept up to date, all 3rd-party libraries are kept up to date, accounts to access the service have strong, rotating passwords, has anti-virus software running, etc;
  • on the storage accounts: have strong passwords, have some sort of rotation mechanisms
  • the build server: the build is safe against external code injection, the build service is kept up to date, the OS is kept up to date, has anti-virus software running, etc.
  • the deployment process: is done automatically with little option to interference, has the source OS patched, guaranteed that the build is intact, communicates to secure channels, etc;
  • users have a clear understanding of how spam, phishing, smishing, vishing, malicious links can affect the internal network
  • developers are aware of the vulnerabilities in 3rd-party packages utilized in their projects and are constantly upgrading their dependencies to the latest available stable version
So just on the infrastructure we have at least 40 very important policies for our development architecture of 6 nodes! How complicated is to maintain all of that? Well, considering that the CVE Database is dynamic and considering the complexity of the above systems, I'd say, it's very, very complicated.

What about Development?

And what about on the user/development side? If we factor the # of accounts, # of developers, # of 3rd-party software used and multiple attack types, that list escalates very quickly!

May it be clear that, of course, on the list above some items are more critical than others but you get the point. Why would an attacker spend time trying to crack your super-secure session encryption algorithm if your unsecured instance of MongoDB is running openly on the internet or if you're using admin/admin as username password, or if you're not aware of the vulnerabilities your tools, or ... provide-your-example-here. That's why security is only as strong as the weakest link.

Conclusion

It won't matter if it's on a jQuery, on a poorly implemented code, a Sql Injection or on a printer. The attacker will always seek the easiest route to get his job done. And it's our job to try to be as safe as we can.

References

See Also

Posted by
Labels: , , , ,

About the Author

Bruno Hildenbrand