Also acceptable: Not common but happens reasonably often and exposes large vulnerabilities.
Seriously, you wouldn't believe the number of companies/people who don't even try. I'm talking "db.run(request.body)" levels of not-trying, "the shared admin password is 'turtle'" levels of not-trying; "the medical records are protected because they're on a hidden share" levels of not-trying.
These are all things that I've seen.
Second to that is thinking that you're trying because every once in a while you have a vague sense of paranoia.
"Let's use MongoDB so we're safe from SQL injection." "We need to proxy the API because that's what other people do." "The WiFi password is secure because it's 26 characters long -- even though we're still using WEP."
Also things I've seen.
I know I'm not any better either. Given the opportunity, I would always hire a professional to audit my stuff.
"No one but the customer is even going to know this machine exists, so why would anyone try to access it?" levels of ignorance are the cause of most of the IoT security issues we face today.
Forget ransomware and other exotic attacks, what happens if after 7 years your hard drive decides to die on you?
I don't know. The backup is the first thing that needs to be setup and tested when you buy a computer. Windows and Mac have build-in systems for point-in-time backups and linux offers more than a few solutions.
Backup, backup and backup again :-)
Which isn't fair of me. I think people do realize it. Just making the time to regularly repeat something you have done before is tough.
I am very sympathetic to the idea that you can automate this. However, this seems to typically fall afoul of the idea that you now just have more that can and will fail. So now you need something to monitor that....
Specifically, the axes of security are integrity, authentication, and availability. Backups give the illusion of helping both integrity and availability. However, without practiced and verified recovery plans, they do neither.
I don't think current operating systems go anywhere near far enough in helping users to get this right. When I buy a computer, the computer should be in charge of ensuring that catastrophic data loss cannot easily occur. 9 times out of 10, the user simply doesn't know how to set things up that way.
Test your restore process periodically!
But how does one test restoring personal data? I'm guessing that most people, like me, don't buy duplicate laptops just to be a platform for testing their data restoration protocols.
Truer words were seldom written!!
its 2017 and yet still the biggest vulnerability of them all is willful ignorance.
People have agendas to fulfill. Can't let the truth get in the way. Haven't found a budget to fit in the truth looks like we will have to do without it for now.
What is the truth?
Well nobody cares about security.
Who knows about the truth?
Mostly everybody
Why doesn't anyone do anything about it?
Trying hard just doesn't cut it anymore as we can see those with influence would rather destroy the entire internet for mass surveillance.
Also don't forget about 2FA
ShittyPassword1 ShittyPassword2 ShittyPassword3 ... ShittyPassword8 ShittyPassword1
NIST came out recently against this, so hopefully, hopefully companies will start to listen.
• Using the same short passwords over and over again.
• Using short passwords <8 characters
• Using very commonly used passwords (password123)
• Security questions
Just use a password manager. Choose one strong 10+ character password that you can remember. Choose the first letter of every word from song lyrics you like if you have to.
Example: lwbeiycwlmdrgag (loving would be easy if your colors were like my dreams red gold and green).
It would take the standard web hack billions of years to figure out that password. Even if someone had massive computing resources behind the crack (not typical, and very expensive) it would take over a week. Password123 or Fido16 might take a minute.
It's not protection from idiocy, but if you're a Microsoft shop, default long passwords avoid stuff that Microsoft is rather coy about (e.g., LANMAN hash attacks against passwords < 14 characters long are still a thing, sigh).
I'm not sure that's a strong password. A web crawler could generate a list of n-grams from the first word of every word on every web page
i pick a random order of a 52 card deck as my password. is that a strong password? you could just iterate over all of them. might take a whole though.
now my password is EITHER the song thing or a random order of a 52 card deck, you dont know which one. am i having a strong password yet?
"a web crawler could just read every page on the internet and then construct all the potential n-grams of every word of every page on the internet and then easily figure out your password" sounds slightly optimistic.
youd only have to clone half the google operation to crack some random weirdos password.
As for a single, common mistake for iot/apps/firmware altogether, that's an overly broad question. I think the best answer I can give is not updating things when updates are available. That's the easiest way to get compromised without even writing a single line of vulnerable code.
Bad secret management (hardcoded in Git, shared secrets not changed after an employee left ...)
Dev and live not properly separated/dev not properly secured.
Services exposed to the internet that shouldn't be.
Old and forgotten software / appliances.
Don't forget about the dev/sysadmin workstations!
Can you get me most or all of the following in an hour or so?
- List of people with production API credentials and which ones per person
- List of accounts with weak passwords or lacking 2FA
- Who has SSH access to each of your servers?
- All portal logins per employee
- Show me the last 3 production data sources this specific employee accessed
- Per data source, list people and services that can read/write
- Network diagrams and policies
A lot of organizations can't. It's boring bookkeeping, but systems have to be put in place to keep this information correct and up to date. Otherwise, there's nothing to manage or secure!
Talking about history of :
1. Slack channels ( lot's of private stuff / links go to #general )
2. VCS ( lot's of passwords / tokens are in the commit history )
3. JIRA ( lot's of private information / company secrets are there )
Usually only one of those three can cost the company a big lawsuit if some employee/freelancer is deliberately being hired to make damage.
JIRA is typically secured. As are VCS. As are Slack channels.
What is not secured are the developer machines...
A lot of people have the mindset "oh, who would ever hack me? my app is just small potatoes". And this is how you end up with things like the mirai botnet.
I've only had it happen to me about 4 or 5 times in the past 15 years or so. But it makes me so disappointed each time that I literally want to find that developer and knock him/her out with the ugliest hammer I can find.
Mistake websites make: only letting you have one user account.
People opening untrusted web content and email attachments in Acrobat Reader and Office.
Reliance on antivirus products.
- User tries to edit something sensitive, UI has profile data so disallows the action if the user is not an admin
- User pokes around the browser console to see what request would have been sent had the user been an admin and the UI allowed it
- User manually sends malicious admin request to API
- API fails to check whether admin request came from a user with admin rights and blindly executes the malicious action
I found this on a mapping site (now defunct) that let you printout sections of maps for a change. However, you could get small sample maps for free. And so by altering the width and height parameters in the page source ...
This wasn't mean't as a dig at frontend devs. After all the backend used the values as passed, and there should be some archtectural oversight to ensure this sort of sloppiness doesn't pass review. It's really a case of incompetent all round.
As dev I see a push to put more and more functionality into the client. It makes for a better user experience, but the downside is that security gets overlooked.
I can provide email filtering, DNS filtering, firewalls and all sorts of technical solutions to security.
It all goes to pot if someone gets click-happy on weird websites or email attachments or falls for the "Your $Company_President need to transfer some funds" email.
Our ticketting system is written in-house and is a diabolical mess of Teach Yourself PHP In 24 Hours - every trope of poor PHP development is in there. Certain sensitive pages are so badly written they're IP-restricted to our office to reduce the chance of them being exploited.
And a major one - passwords as a 1337 spelling of the username. We use this A LOT.
- Default config.
- But the machine isn't a website, it doesn't have a name, just an IP address. Who would find it?
- Just execute user SQL query / eval user code, what could possibly go wrong? I'm sure all the docs telling you no string substitution, not even with a gun on your head, is just exaggeration..
- Password is domain name.
- Password comparison in JavaScript, rendered, readable (a special place in hell for this one).
- And of course, clear text passwords. Gotta love that one.
One malicious package could completely compromise a significant amount of our infrastructure.
<p>Hello, <?= $username ?>.</p>
$sql = "update tbl set x = '{$_POST['x']}' where id = {$_POST['id']}";
For SQL, use parametric queries. (Most people call them parameterized queries, but with so many suffixes in English, why not choose the more musical one?)
2. In Ruby code, I see a surprising amount of `eval`; mostly `class_eval`
- Trying to remove/escape "bad" characters on input or thinking that only "user" input needs escaping. This means anything that slips past the filtering can do unlimited damage. Any "special" characters get lost or mangled in uncontrollable ways. The right way is to escape data on output.
- Thinking "escaping" is one universal thing that can be done in advance. This leads to HTML-escaped text in email subjects, SQL-escaped strings in HTML, etc.
- Forgetting that nested contexts require multiple levels of escaping (e.g. an URL argument in string in JS in an HTML script tag requires URL-escaping followed by JS string escaping followed by HTML-script escaping).
- Voodoo escaping such as `sprintf(buf, "cmd '%s'", arg)`
Escaping on output also makes text processing easier and more reliable. For example, if you cut a string, you don't have to worry you'll cut it in a middle of an HTML entity or just after a backslash.
Passing in user info for a query, instead of using session or token encoded data (Impersonation just waiting to happen).
Bad passwords/keys, and bad management of those secrets.
No plan for backups, or not having a way to restore backups.
Just look at WannaCry. The Patch was released March 14th and the worm was released May 12th.
That shows everybody who was compromised simply didn't have a regularly scheduled Patch Management Process in place.
From WannaCry Wikipedia page:
>A "critical" patch had been issued by Microsoft on 14 March 2017 to remove the underlying vulnerability for supported systems, nearly two months before the attack, but many organizations had not yet applied it.
>Almost all victims are running Windows 7 or newer.
Same with web apps, have a regularly scheduled Patch Management Policy in place for the Libraries, Gems, Modules, Packages, etc you use.
There are lots of words written about security, so it's hard to pick a single thing. But my vote would be for "enumerating badness", and "default permit", which are kinda related.
Bugs leading to memory corruption vulnerabilities are the most common mistake I see. So things like, not doing proper bounds checks before accessing an array, using memory after it's been freed, not initializing memory properly before using it, type confusions causing values to be treated as pointers, etc.
* Private SSH/AWS API Keys in Github
* Shared Prod Passwords
Not applying updates to infrastructure regularly
The most common security mistake I see is API authorization errors, in the abstract. More specifically, I see this manifest itself reliably as insecure direct object references. Nearly every security assessment I have ever been on has had an API where you can slightly alter a parameter value and bypass authorization controls altogether to access another user's account (or whatever other state-changing action you can think of in the context of their session).
In an era where just about everyone knows what SQLi and XSS are, actual logic errors fly right under the radar and authorization controls are not implemented universally.
To be even more specific - do you have a microservice architecture? Have you tested that every backend service has the same authorization controls in place? When was the last time you tested this?
Put your backend services behind a common access policy (you can use something like Kong for this), and make sure that you parameterize all calls between services, because someone can and will access your privileged services through a less privileged service using an unexpected or undocumented call. For that matter, use internal access policies to discriminate between more and less privileged services. It doesn't matter if you have a DMZ and firewall open IP traffic if you give a user-facing service access to a more privileged service - users can hop between them.
And when you deprecate an internal legacy API, actually remove it from being accessible by other services. This is probably still the number one way that people find really serious vulnerabilities in Facebook. I've seen cases where user input was used by Service A to directly query Database B using fallback API C, giving the user de facto arbitrary read access to the entire table. Database B is always firewalled to outside internet traffic in these scenarios, but Service A gets a free pass to access internal resources and voila.
It's fairly straightforward to classify specific technical issues, but if your APIs for various backend services are not properly set up with authorization controls you open the door to remote code execution, command injection, server-side request forgery...it's pretty bad. And it's largely unknown by developers because they are hyper-focused on common web vulnerabilities, which frankly are mostly solved by using the right libraries these days.
The most common one for this is login systems. I've custom written ones with bugs so bad that a blank password worked for every login.
The result? All our sysadmins marching around as root all day because it's the only way they can get any work done.
Seems to be the default on several Linux distros these days.
Servers, computers, software, (people), everything. Many exploits have been published on exploit-db.com targeting software that has already been patched. My fortune top-100 company is the type of company that will decide to update to Windows 10 when Windows 15 comes out.
People eventually quit or are fired, are hired by a competitor, and still know about the hack. Its BAD.
default/dev/test/guest accounts+passwords with easy to guess credentials
exposing servers and services to the internet when not needed (memcached, hadoop, mongo, etc)
Insecure Direct Object Reference
Not blocking known hostile entities (known bad ASNs, known bad netblocks)
It is appalling how many old school places do this.
Also, if you open up the top drawer of someone's desk, you are pretty likely going to find passwords there too.
If you do not have documentation explaining how the system works, its dependencies, diagrams, etc, you will have a hard time fixing security errors.
What happens if the guy that built the system leaves?
* Those without memory management (I'm not talking about garbage collection, though there seems to be a correlation). Buffer overflows/overruns and its cousins have caused many security flaws, including heartbeat and even flaws in java, where it interops with C programs for performance's sake.
* Syntactical leniency wrt. scope can lead to errors like apple's infamous "goto fail"