\nAuthors

My goal is to write an anthology.\nContributions from experts in their fields are welcome. Everyone contributing a\nchapter gets half a page of biography.

I just do not want to start asking for contributions now. Not until the book\nhas a well tested and established structure. I would hate to force external\nauthors to re-write their chapter several times just because the structures is\nstill developing….

",{"_643":644,"_43":44,"_47":48,"_45":46,"_65":66,"_645":646,"_814":641},"previewContent","

\n Preface\n
- \n This book\n
  - \n Goals\n
  - \n Release early, release often\n
  - \n 80/20 or Pareto Principle\n
  - \n Form follows function\n
  - \n All this said…\n
  \n
- \n Structure of this book\n
  - \n Project phases and audience\n
  \n
- \n Content\n
  - \n Background\n
  - \n Planning\n
  - \n Programming\n
  - \n Testing\n
  - \n Tools\n
  - \n Bolt-on security\n
  - \n Offense\n
  - \n Appendix\n
  \n
\n
\n Background\n
- \n Intro\n
- \n Principles\n
  - \n Bolt-on-security vs security-by-design\n
  - \n Threat modelling\n
  - \n Reduce Attack Surface\n
  - \n Compartmentalisation / Segmentation\n
  - \n Principle of “Least privilege”\n
  - \n Updates\n
  - \n Flexibility\n
  - \n Do not make mistakes\n
  - \n De-centralisation\n
  - \n Fail gracefully\n
  - \n Monitor / Incident Response\n
  - \n Educate users\n
  - \n Defense in Depth\n
  - \n Filter at the endpoint\n
  - \n Tripwires\n
  - \n Slow down the attacker\n
  - \n Security by Obscurity\n
  - \n Security Theater\n
  - \n Hollywood threats\n
  - \n Further reading\n
  \n
\n
\n Planning\n
- \n Intro\n
- \n Updates\n
  - \n Things that a good update strategy covers\n
  - \n Things to avoid\n
  - \n Response Time\n
  - \n Update strategy details\n
  - \n Verify version - only upgrade\n
  - \n Track distribution\n
  - \n Be able to stop updates\n
  - \n Distributing the updates\n
  - \n Compress updates\n
  - \n Diff updates\n
  - \n Incentives\n
  - \n Plan for several channels\n
  - \n Automatic updates\n
  - \n Control the update infrastructure\n
  - \n Details for things to avoid\n
  - \n Break the update chain\n
  \n
- \n Passwords\n
  - \n PINs\n
  - \n Passwords\n
  - \n Passphrases\n
  - \n Entropy matters\n
  - \n Password hints\n
  - \n Preventing copy & paste\n
  - \n Forgot password\n
  - \n TTL for passwords\n
  - \n Autofill trap\n
  - \n Stolen passwords\n
  - \n Cracking passwords\n
  - \n Web site scraping for wordlists\n
  - \n Keyloggers\n
  - \n IoT: Initial passwords\n
  - \n Salting\n
  - \n Pepper\n
  - \n Beyond passwords: “Two-factor authentication”\n
  \n
- \n Censorship\n
  - \n Mapping censorship\n
  - \n Censorship countermeasures\n
  - \n Further reading\n
  \n
- \n Crypto algorithms\n
  - \n Hash functions\n
  - \n HMAC or MAC\n
  - \n Password hash functions\n
  - \n Stream Ciphers\n
  - \n Block Ciphers\n
  - \n Authenticated Encryption\n
  - \n Asymmetric Ciphers\n
  - \n Key exchange\n
  - \n Elliptic Curve Cryptography (ECC)\n
  - \n Key length\n
  - \n Best practice\n
  - \n Further reading\n
  \n
\n
\n Programming\n
- \n Intro\n
- \n Requirements for code analysis tools\n
  - \n Some background\n
  \n
\n
\n Testing\n
- \n Intro\n
- \n Flawfinder\n
  - \n Finding issues\n
  - \n Finding inputs\n
  \n
\n
\n Tools\n
- \n Intro\n
\n
\n Bolt on\n
- \n Intro\n
- \n Anti Virus tests\n
  - \n Abstract\n
  - \n Methods\n
  - \n Eicar\n
  - \n Windows Defender\n
  \n
\n
\n Appendix\n
- \n External references and resources\n
  - \n Books\n
  - \n Conferences\n
  - \n Blogs\n
  - \n News\n
  - \n Podcasts\n
  - \n Magazines\n
  - \n Videos\n
  - \n Workshops and Training\n
  - \n CTF\n
  - \n Lists and bookmarks\n
  \n
- \n Glossary\n
- \n The author\n
  - \n The origin story: External brain\n
  \n
- \n Authors\n
- \n Credits\n
- \n Changelog\n
  - \n Aug 2025\n
  - \n April 2023\n
  - \n December 2022\n
  - \n November 2022\n
  - \n July 2022\n
  - \n October 2021\n
  - \n June 2021\n
  - \n April 2021\n
  - \n February 2021\n
  - \n October 2020\n
  - \n August 2020\n
  - \n May 2020\n
  - \n April 2020\n
  - \n March 2020\n
  - \n February 2020\n
  - \n January 2020\n
  - \n December 2019\n
  - \n November\n
  - \n August/September/October 2019\n
  - \n July 2019\n
  - \n June 2019\n
  - \n May 2019\n
  - \n April 2019\n
  - \n March 2019\n
  - \n February 2019\n
  - \n January 2019\n
  - \n December 2018\n
  - \n November 2018\n
  - \n October 2018\n
  - \n September 2018\n
  - \n August 2018\n
  - \n July 2018\n
  - \n June 2018\n
  - \n May 2018, initial release\n
  \n
- \n License\n
\n
\n Notes\n

\nPreface

\n\n\n

\nThis book

\n\n

\nGoals

\n\n

Your next project will be more secure than your last project. And this will be almost hassle-free. This is the mission of this book.

\n\n

This is why I wrote it.

\n\n

As an experienced engineer, software developer and security guy I want to help you getting started with security features in your projects.

\n\n

My observation is that there are many specific books for security topics. But almost no “getting started” books.

\n\n

This is the itch this book wants to scratch.

\n\n

\nRelease early, release often

\n\n

One of the reasons I dare to write a book is leanpub’s feature to release early and often. That way I can see progress and get feedback.

\n\n

Please visit the forum and\nhelp me improve the book. Or contact me:

\n\n

On Twitter: @ThorstenSick
On Mastodon: @thorsi@chaos.social

\n\n

As I have been spending lots of time with security focused engineers, the most important things I want to learn first from you:

\n\n

What causes trouble ?
What kind of technology is currently introduced in normal engineering ?\n
- Where does it cause issues ?
\n
What kind of normal technology (cloud, micro services, IoT) are you using ?

\n\n

Boiling down to: What do you need from this book ?

\n\n

\n80/20 or Pareto Principle

\n\n

Following the Pareto principle\nI will focus on finding the important 80 percent of security tips first and later filling in the missing 20 percent.

\n\n

This will result in:

\n\n

I start a new topic before I squished the last drop out of an older topic
Instead of spending hours to fine tune the language and optics of an existing chapter I start a new chapter with dozens of new tips

\n\n

This does not mean I will not do that sooner or later. But I want to get the low hanging fruit first.\nI also feel like you expect a book containing lots of good tricks instead of poetry.

\n\n

\nForm follows function

\n\n

With every iteration of the book I will tune the optics, improve the layout and maybe add images.

\n\n

But adding new chapters is more important.

\n\n

\nAll this said…

\n\n

Adding security features to a project can be fun and quite rewarding. Cherry-pick ideas from this book and get started.

\n\n\n

\nStructure of this book

\n\n

This book is meant to be read twice. First by cherry picking interesting topics and a second time as toolbox when implementing a feature.

\n\n

For this reason the book is split. The first few chapters offer an introduction to the security landscape. The second part contains chapters helping to solve specific problems.

\n\n

Do not feel bad if you directly skip to something interesting. Or to a chapter that is currently relevant for your project.

\n\n

\nProject phases and audience

\n\n

A project has different phases. Depending on your institution different people could be responsible for each phase. Everyone can contribute to security.\nAnd security will break at the weakest link.

\n\n\n

Stages in development are:

\n\n

Management
Architecture/Design/Project Management
Development
Testing
Support
Analysis (analysis of attacks)

\n\n\n

\nContent

\n\n

\nBackground

\n\n

\nKnow your enemies

\n\n

Describes the types of adversaries your project can face. And their high-level goals, resources, technologies and tactics. You should know your enemies

\n\n

\nAttacker’s goals

\n\n

An in depth list of goals and sub-goals the attackers have - things you will want to prevent happening. Block the attack, protect your system.

\n\n

\nPrinciples

\n\n

High level principles you can use to design a secure system. These principles are abstract - and you will be able to combine several of them in designing your project.

\n\n

\nPlanning

\n\n

\nThreat modelling

\n\n

A mixed group of people (engineers, architects, managers) meets for a threat modelling session. Understanding the strengths and weaknesses of the product and the planned new features. “What would an attacker want ?”,\n“How would he get that ?”. Identifying that is the first step to protect the valuable assets.\nIt can sound intimidating. But there are so many different approaches to make it simple and even fun. I collected a range of “best of” approaches in\nthis chapter.

\n\n

\nSoftware Design

\n\n

Software design - also known as architecture - is the bigger picture of the technological part of the project.\nA good design can speed up development, simplify testing, and increase security. This chapter covers the security basics of software design. Followed by specific topics in other chapters.

\n\n

\nVulnerabilities

\n\n

Your software - and maybe even your hardware will have bugs that turn into vulnerabilities. Ready to be exploited by an attacker. The chapter Vulnerabilities will cover the essence and taxonomy of vulnerabilities. Understanding that will make decisions based on vulnerabilities simpler.

\n\n

\nSecurity process

\n\n

Internal set up of a project will decide if a external vulnerability report is a disaster for the project release cycle or can be handled in a relaxed\nand simple way. Being prepared for the inevitable is central in this chapter.

\n\n

\nSoftware Design Checklist

\n\n

The Software Design Checklist introduces you to a source to learn about typical software design flaws. It also starts to create an (incomplete) list of typical flaws encountered it real world failed projects.

\n\n

\nUX

\n\n

How to create a user interface in a secure way - preventing the user from becoming the weakest link.

\n\n

\nUpdates

\n\n

As soon as a software reaches a certain complexity you need updates to ship patches. This chapter guides you through the challenge of shipping updates in a secure way.

\n\n

\nPasswords

\n\n

Passwords are the main way the user authenticates himself. Handling that in a secure fashion can turn out to be quite complex - but at the same time there is enough experience around.

\n\n

\nBrowser

\n\n

The browser is the main software running on most computers. And the interface for a lot of other technologies. As browsers are complex they are vulnerable.\nSome things can be done to improve browser security - or the security of connected web admin platforms (router config page).

\n\n

\nCensorship

\n\n

This chapter should be named Resilience. But Censorship attracts more attention. Our computer systems are very complex. And many do not have enough redundancy to recover from a single failure (accidental or intentional). But they can be built that way. This is covered in this chapter. It currently focuses on personal redundancy. Later it will be extended to also cover how to build resilient systems.

\n\n

\nIoT

\n\n

Things are getting more smart. Embedded Micro-controllers are cheap. Security is very often not existing. This chapter helps to improve that.

\n\n

\nCAN

\n\n

The CAN bus connects micro-controllers in many embedded systems - especially in vehicles. Securing it is a challenge - as it was not designed for security. This chapter will give you some tools - and basics for fuzzing CAN.

\n\n

\nBluetooth LE

\n\n

Low Energy Bluetooth can be integrated in many systems. Security is hard\nto implement. But possible. This chapter will give you the tools and basics to improve security.

\n\n

\nTLS

\n\n

TLS is a basic technology to secure data in transit. Some may know it as SSL or HTTPS. And many projects use it.

\n\n

\nCrypto algorithms

\n\n

Which algorithm to use ? In which mode ? Best key length ? This book is basic, so this chapter will be more of a cheat sheet for those essential things.\nFor the curious people: there are resources to dig much deeper.

\n\n

\nProgramming

\n\n

\nCode analysis tools table

\n\n

There are several tools that will assist you during the coding process. This\ntable will help you to pick the proper ones.

\n\n

\nDefensive programming

\n\n

Some coding techniques will harden your code against attackers. Positive side effects like making your code simpler to debug and more robust and stable are take always that balance the extra effort invested. If you do not yet practice defensive programming you should consider starting it.

\n\n

\nAssert

\n\n

A very powerful tool for debugging and preventing bugs are asserts. They are even more powerful when combined with fuzzing. When coding, you should start using asserts right now.

\n\n

\nCompiling

\n\n

Modern compilers have lots of less known features to find vulnerabilities\nduring compile or run time. Or even mitigate - making vulnerabilities harder\nto abuse by the attacker. Covered in this chapter.

\n\n

\nClang LLVM

\n\n

Clang is a compiler in the GCC league. It adds some more features for static and dynamic testing of your code. Those features are cool enough that you\nshould consider compiling at least the test version using Clang and those settings.

\n\n

\nJavaScript security

\n\n

I am a big fan of automated security tests. And JavaScript has its own pitfalls.\nBut those can be fixed by tools you can integrate seamlessly into your workflow. The JavaScript security will show you the low hanging fruit.

\n\n

\nTesting

\n\n

\nTesting compiled binaries

\n\n

To verify that the compiler properly hardened your executable the way you wanted you (or your testers) will want to use some tools. This is described here.

\n\n

\nFlawfinder

\n\n

In addition to your compiler the tool Flawfinder gets you more verification of your code. With zero effort.

\n\n

\nCPPCheck

\n\n

CPPCheck is Flawfinder enhanced. With the small drawback that you will have to invest some time in configuration. This chapter will help you there.

\n\n

\nTesting

Is it still testing or already hacking our own product ? There are many tricks to make software testing more aggressive and which will shine some light on vulnerabilities in this chapter.

\n\n

\nFuzzing

\n\n

Fuzzing is a technology to find unexpected bugs - most of them potential vulnerabilities. Pre-existing tools and DIY scripts can do the fuzzing for you. How to get started is described here.

\n\n

\nTools

\n\n

Several tools are essential to build secure software. This covers version control systems, SSH and many others that “just” support you in getting\nyour tasks done. Those are covered in this part of the book.

\n\n

\nSSH

\n\n

A very powerful tool that goes way beyond just replacing Telnet. Know it and simplify your work while being more secure. Or - if you build embedded\nsystems - integrate it in there.

\n\n

\nGit

\n\n

Git as a version control system is the core of your development workflow. It is also a perfect spot to add automated code quality tools. You learned\nabout those tools in the other chapters. And this chapter gives you some hints where to get started integrating them into Git.

\n\n\n\n\n

\nBolt-on security

\n\n

Bolt-on security is what is done of someone missed to do security-by-design.\nEspecially myths make it hard to find the right way to use it. These chapters will bust some myths.

\n\n

\nAntivirus tests

\n\n

How to properly read antivirus tests. As antivirus is neither a silver bullet nor useless a proper estimation of its power should be done first.

\n\n

\nAntivirus integration

\n\n

Antivirus can only scan files it gets access to. Many projects could benefit from an interface between the project and an already installed antivirus. And Microsoft is offering one.

\n\n\n\n

There are several reasons to contact an antivirus vendor

\n\n

They have a False Positive on your software
You found undetected malware (files or URLs)

\n\n

This chapter will help you getting started and give you some internals - the people working in an antivirus lab are on your side and will love to cooperate.

\n\n

\nAntivirus: VirusTotal

\n\n

VirusTotal is the go-to way of quick scanning potential malware and false positives. But has an own tricky personality. Knowing that will prevent you from coming to the wrong conclusions.

\n\n

\nAntivirus: Behaviour based classification

\n\n

Unknown samples must be classified before detection can be created. A quite reliable way to achieve that is behaviour based classification. Especially it is quite simple to interpret the resulting log for malicious behaviour. The basics are covered in this chapter

\n\n

\nIOC sources

\n\n

IOC sources is a collection of lists of so called Indicator Of Compromise Sources. Those are Malware executables, hashes, URLs, registry key, …

\n\n

The lists can be used for training, learning or (if they are curated) event directly blocklisting.

\n\n

\nOffense

\n\n

Even if you are playing Defense - it is very important to know the tools, tricks and tactics of Offense. The basics are covered here.

\n\n

\nKill chain

\n\n

A kill chain is a typical structure of an attack. With different steps happening in between “the attacker decided to attack” and “the attack succeeded and is spending the stolen money”.\nA kill chain can be interrupted at any stage. Knowing kill chains will help the defender.

\n\n

\nRecon NG

\n\n

An early part of manual attacks is reconnaissance of the target. There are several tools helping the attacker doing that. The same tools help defenders estimate their attack surface. One of those is Recon-NG.

\n\n

\nGoogle Dorks

\n\n

Google Dorks are simple reconnaissance tricks abusing Google. Using them it is possible to learn about vulnerabilities in\nweb pages without event connecting to them once.

\n\n

\nBeEF

\n\n

BeEF - Browser exploitation Framework helps you exploiting browsers. And those are very often the most central application in a person’s life.

\n\n

\nBurp Suite

\n\n

Burp suite is attacking the other way: Connecting to a web page and while crawling it enumerating the vulnerabilities.

\n\n

\nMitmproxy

\n\n

Mitmproxy is a python proxy to intercept especially HTTP communication. Valuable for development of network communication, testing and pen testing.

\n\n\n\n\n

\nAppendix

\n\n

The appendix contains handy things that will make the reading of the book more enjoyable.\nEspecially:

\n\n

\nExternal References

\n\n

A list of external references (books, talks and homepages).

\n\n

\nGlossary

\n\n

There are so many new acronyms in the security field. And even there they are territorial - Web security being totally different from Assembler hacking. Have a glossary ready. Here it is.

\n\n

\nThe author

\n\n

Who wrote this book and: Why ?

\n\n

\nAuthors

\n\n

As the security field is so large I want to have other authors contribute to their field of expertise. This chapter is ready to introduce them. Even if I just slowly started to invite people.

\n\n

\nChangelog

\n\n

Read this first after you got an updated book

\n\n

\nLicense

\n\n

If you want to do anything else with this book besides reading it - this chapter is for you.

\n\n\n

\nBackground

\n\n\n

\nIntro

\n\n

This book is written for the experienced engineer, manager, tester. And not for experienced security experts. Security knowledge has not been very\naccessible. There are films - and most are horribly wrong. And there are complex books covering a specific topic in depth.

\n\n

If you not hyper-focused on security is is quite easy to either get lost in myths or complexity.

\n\n

I want to get you the foundations to contribute to the security of your product.

\n\n

The takeaway of this chapter will be:

\n\n

You know who could attack your technology
You know why\n
You will learn the basic principles of protection
You will also learn about the technology available to the attacker

\n\n\n

\nPrinciples

\n\n\n\n

There is a list of the most basic principles you can build security on. These principles are very abstract, but are the basics for building more specific tools. This is not a complete list.

\n\n

\nBolt-on-security vs security-by-design

\n\n

Detecting attacks is a typical bolt-on way of security. Anti-Virus, Network intrusion detection, behaviour detection, …\nThese kind of things are bolt-on-security. The other big security philosophy is security-by-design.

\n\n

If you are responsible for building a system use security-by-design. In many cases you are not free to do it the perfect way - for example a manager needs an old Internet Explorer to use am esoteric web based application installed on his PC.\nIn this case bolt-on-security (filtering files and URLs) is a valid approach.

\n\n

Disadvantages of Bolt-on-security is: It adds complexity (file parsing, for example).

\n\n

This can turn the bolt-on-security into a new infection vector.

\n\n

To protect against it, isolate it from other systems (segmentation):\nSandboxing and an own machine for the file processing are options.

\n\n

Two tactics with bolt-on-security:

\n\n

Add it to the outer perimeter of your network to reduce the normal\n“internet noise” of attacks. This will reduce your important monitor-log reports.
Add it to the innermost perimeter to detect attacks that bypassed your protection.

\n\n

A whole part of this book covers bolt-on security. If your are stuck with a given design bolt-on will be a good way to go.

\n\n\n

The next principles are part of the security-by-design philosophy

\n\n

\nThreat modelling

\n\n

Threat modelling is a process organized by the designer of the software but including a multi-skill team of people involved in the project.\nGoal is to identify potential threats to the developed tool as early as possible and to find fixes and mitigations.

\n\n

It is not complex but can turn out to produce lots of documentation.

\n\n

There are four basic steps that need to be done to model threats:

\n\n

Create overview
Brainstorm potential attacks
Rate severity
Define fixes and create priority to implement them

\n\n

For those steps there are many tools (methodologies/checklists) to guide your team through.

\n\n

Which one to pick will depend on mood, team, and especially your project.

\n\n

An improvised one would be:

\n\n

Who will attack your technology ?
What is the goal of this person (data, money, …)
Which resources can this person gather ?

\n\n

There will be a specific chapter on threat modelling

\n\n\n\n\n\n\n

\nReduce Attack Surface

\n\n

Attack surface is everything that can be reached from the outside.\nThese are servers, interfaces, network connections. You can reduce this surface by asking yourself some simple questions:

\n\n

Which features do you really need ?\n
- Remove unnecessary programs and features
\n
How to put steel plates on the technologies I have to keep ?\n
- Reduce features, reduce privileges, ….
\n
How to reduce the potential impact ?
Who do you (have to) trust ?\n
- Best case: You do not have to trust anyone
\n

\n\n\n

\nCompartmentalisation / Segmentation

\n\n

Segment your system into small partitions. Define narrow communication channels. Maybe they can be one-way (data-diodes). Possible segments can be:

\n\n

Multiple isolated VMs on a machine
Multiple isolated processes on an OS
Multiple isolated network segments
Sandbox the processes
Isolated servers
Split a big application into smaller compartments\n
- Example: Browsers have separate processes for tabs, extensions, …
\n

\n\n

Dropping privileges is a part of that.

\n\n

\nPrinciple of “Least privilege”

\n\n

Reducing available privileges\nreduces the impact of a hacked process or account. This reduction can be done on account level (special web server accounts, for example) or on process level (where the process drops privileges during startup - as soon as it does not require them anymore).

\n\n

Dropping process privileges is possible on Linux. Not on Windows.

\n\n

At least you can terminate the program if is run by root (as long as it is a potentially vulnerable program).

\n\n

\nLandlock

\n\n

Newer Linux kernels are shipped with the landlock module. Ths allows code to manage the own privileges. Your program should drop all privileges it does not need at startup.Many programming languages do support that:

\n\n

C: https://en.ittrip.xyz/c-language/c-sandbox-security
Rust: https://docs.rs/landlock/latest/landlock/
Golang: https://github.com/landlock-lsm/go-landlock
Python: https://github.com/Edward-Knight/landlock

\n\n

For command line execution use the cmdline tool “landrun”

\n\n\n

\nUpdates

\n\n

After a vendor created a patch it takes the bad guys a few hours to reverse engineer the patch and find the vulnerability which has just been patched. Within days there are attacks. Update everything ASAP.\nEspecially if it is network connected.

\n\n

\nFlexibility

\n\n

Whatever you do: Be flexible. You did threat modelling during the design phase, you fixed all vulnerabilities you found. But there will be a hack.

\n\n

Expect the attacker to find a trick against your tools in the following weeks.\nHave a plan ready to handle that situation. Expect the attacker to do something unexpected. Plan for flexibility.

\n\n

\nDo not make mistakes

\n\n

“Bitte immer alles richtig machen” in German. This is the core principle especially in Design and Coding. It kind of sounds obvious and boring.\nBut there are ways to engineer fault-reduction with tools and processes.

\n\n

Those are for example:

\n\n

\nDe-centralisation

\n\n

De-centralise everything. Centralised components (servers) can be DDOS-ed.\nWill your IoT device still work when the server is down ? Which functionality is available in offline mode ?\nCould you add fallback servers to the plan ?\nCould the user override the server for a short time ?

\n\n

\nFail gracefully

\n\n

Do you want your system to fail-close or fail-open ? What does the car’s door lock do when there is a power outage ? Lock or Open ? Plan these failures and the consequences. How can these failures be triggered and by whom ?

\n\n

\nMonitor / Incident Response

\n\n

Expect a hack to happen. But many hacked companies do not notice the breach - or do, hundreds of days later and by accident (server misbehaves or similar).

\n\n

You do not want to be one of those. You could monitor the devices you own or the devices you sold to customers (IoT, for example) for security incidents.\nFor “monitoring sold devices” scenario: respect privacy !

\n\n

There is SIEM (Security Information and Event Management) software for that. Connect your technology to a SIEM.

\n\n

This enables you to respond (“incident response”) when something happens.\nThis has several benefits:

\n\n

You can respond (updates, isolate infected devices, ….)
Learn from this incident for the next projects

\n\n\n\n\n\n

\nEducate users

\n\n

Users want the option to know what their technology is doing. Having two layers (simple and detailed) of information will very likely be embraced\n¹.

\n\n

Your security plan should not depend on users reading, understanding and acting upon this information. But having smart users will add new “sensors” for unexpected attacks to your environment. Especially attacks containing\nsocial engineering. Those users would need a fast channel to contact the person in charge for reports on attacks.

\n\n\n

\nDefense in Depth

\n\n

As protection mechanism will fail - the attackers will find holes - it is better to layer defenses.\nTo protect an asset it is essential to layer different kinds of defenses to make attacking more complicated to request different skills.

\n\n

As for a castle example:

\n\n

A castle on a hill has a moat, walls and archers.

\n\n

Attackers will have to be:

\n\n

Good runners
Swimmers
Climbers
Lucky

\n\n

To reach their goal alive.

\n\n

This will narrow down the number of successful survivors/attackers quite well.

\n\n

The same is true for your computer system. Combine different technologies to protect an asset. Even if you think the one specific layer you just designed\noffers 100 % protection.

\n\n

\nFilter at the endpoint

\n\n

Thanks to efforts by the EFF, Google and many more the connections between client and server are now end-to-end encrypted (HTTPS). Which is an incredible\nsecurity improvement.\nMany bolt-on security solutions offer a feature to scan the content of those connections with MITM proxies. This is only possible if you sabotage the alert system at the endpoints. Because they detect the attack a MITM is.\nSystems having a sabotaged alert have trouble detecting malicious attacks. Scanning as MITM is a very bad idea.

\n\n

The solution is: Filter at the endpoints. In the browser, When files are written to the endpoint system, …

\n\n

The user (or the admin - for larger installations) should also have full control about what is filtered.

\n\n\n

\nTripwires

\n\n

Add tripwires to your design. One example is to fill your database with some fake customers with made up mail addresses. As soon as those mail addresses start receiving mails (SPAM), you know the db has been compromised.

\n\n

The same for fake “password.txt” files in your system. They get accessed ? You got hacked.

\n\n

Tripwires are useless if you do not have a monitoring system and a plan how to react.

\n\n

\nSlow down the attacker

\n\n

Bank safes have a timed lock. Only after a certain time they open. Thieves will be slowed down. With an alarm system and a police unit to respond this is powerful.\nWithout those to additional ingredients it is useless. Maybe you can build something similar into your systems. Slow down, alerts and response.

\n\n

\nSecurity by Obscurity

\n\n

A bad idea. There are disassembler tools that help to reverse engineer executables. If any security depends on secrecy it will break as soon as an experienced person attacks it. You are an\nexperienced engineer but not an experienced attacker. The guys you face have the skill set switched: experienced attacker, OK-ish engineer.\nThis is why they became attackers.

\n\n

Long story short: if your defense depends on “as long as the attacker does not know X” it already failed.

\n\n

And just in case you think these disassembler tools are out of some fairy tales:

\n\n

\nIDA, paid and free test version. For Mac/Win/Linux
\nHopper, Mac/Linux. Test version available
\nRadare2, Mac/Windows/Linux/…

\n\n

\nSecurity Theater

\n\n

A big show towards the customer faking security features. Most often has an intended negative effect on usability - you want it to be noticed. It is also not necessarily cheap.

\n\n

One typical example is the water bottle ban at airports.

\n\n

Please double check if what you are implementing is just smoke and mirrors or some proper solution. And go for the proper solution.

\n\n

\nHollywood threats

\n\n

Also on the negative side: Thanks to Hollywood movies everyone seems to know how an attack looks like - with lots of show effects and world shattering scale.\nWhen discussing security with security-beginners there will be a tendency for the discussion towards those Hollywood threats. Explain to everyone this concept.\nHave some real-world hacker stories ready and try to steer the discussion towards a productive region. Even if it is less exciting.

\n\n

\nFurther reading

\n\n

\nGhost in The Wires

\n\n

Ghost in The Wires by Kevin Mitnick. Life story from Kevin Mitnick. Famous hacker and pen tester. Many described exploits are on the social engineering level. Simple to read. Most of the technology described here does not exist anymore.

\n\n

\nBeyond Fear

\n\n

Beyond Fear by Bruce Schneier is a book where a computer security guy analyses common physical world security practices like airport security. Teaches thinking and critical thinking about security and security promises. Can be read by\nnon-technical people.

\n\n

\nFuture Crimes

\n\n

Future Crimes by Marc Goodman is a book covering the experience of a cyber crime police officer. Every chapter is a noteworthy and often entertaining example of a real crime. Entertaining and does not require technical knowledge. Good for\ntraining critical thinking and security thinking.

\n\n\n

\nPlanning

\n\n\n

\nIntro

\n\n

Design flaws are as bad as programming bugs: Both are vulnerabilities an attacker can abuse.

\n\n

A software or hardware design well done can simplify programming and strongly improve security.

\n\n

Many specific technologies require domain knowledge to be used in a secure fashion. For example a crypto library offers an API to be used by programmers without having them understand the maths. This API can be simple and fool-proof or built-for-experts with lots of ways to make horrible mistakes. In the last case you will require lots of domain knowledge to build a secure application.

\n\n

This chapter will extend principles from the background chapter into technology specific knowledge.

\n\n\n

\nUpdates

\n\n

As soon as your system reaches a certain level of complexity, you will require updates. Reason for that are the inevitable bugs and feature requests.

\n\n

And as bugs can be vulnerabilities you will not be offering a secure solution without updates.

\n\n

The software offered today is highly complex. Caused by the foundation that is used: Operating Systems, libraries, frameworks, …

\n\n

Even CPU microcode can be updated.

\n\n

Updates are the solution. And they add more complexity.

\n\n

\nThings that a good update strategy covers

\n\n

Be able to rollback
Verify signature
Secure key handling
Verify version - only upgrade and no downgrades
Track distribution
Be able to stop update roll outs
Distributing the updates
Compress updates
Diff updates
Incentives to update
Automatic updates

\n\n

\nThings to avoid

\n\n

TOCTTOU Time of check to time of use - error
Break the update chain

\n\n

Especially breaking the update chain (for example by ruining the update on the client system) is one of the biggest fears.

\n\n

\nResponse Time

\n\n

This is the time you have to response to an incident. Normally it is the span between learning about an issue and successfully updating all your customers systems.

\n\n

If a vulnerability gets known to the bad guys, expect a time-to-exploit of a few days. Normal process is that someone identifies the vulnerability\nand writes an exploit (plus a blog post). The exploit is then stabilized and integrated into attack systems (metasploit for the more white hack side, exploit kits for the bad guys).

\n\n

If a vulnerability gets reported as “responsible disclosure” by a friendly hacker you will have about 90 days (standard) to release the fix to all customers. If you have good reasons (complex situation where it is hard to get all your users updated) you can maybe negotiate and get some\nmore days. But there is a very good reason for the 90 days: It is a reasonable time to get the fix released and a longer time frame would increase the risk that a bad guy finds the same vulnerability in parallel.\nThis happened more often than you think.

\n\n

Short: You will not be able to ship the fixes with the next regular update. Be ready to for quick response. Build your processes from support call to all-your-users update accordingly.

\n\n

One more thing: As soon as the first client gets an update, the bad guys could get it as well. Normally they do a binary diff (using disassembly tools).\nFrom that diff they can learn which vulnerability you just patched. The race is on between the bad guys creating a reliable exploit and you getting the update to your last customer.

\n\n

These disassembler tools may sound arcane, but are quite simple to find and sophisticated.

\n\n

\nIDA, paid and free test version. For Mac/Win/Linux
\nHopper, Mac/Linux. Test version available
\nRadare2, Mac/Windows/Linux/…\n%% TODO Add Ghidra

\n\n

\nUpdate strategy details

\n\n

\nBe able to rollback

\n\n

Be able to roll back your changes either automatically or by user interaction if the update breaks something. User interaction could be “press the reset button for 10 seconds”. Rollback could be to the factory system or last-know-good software state.\nThis will reduce your stress when doing emergency updates.

\n\n

\nVerify signature

\n\n

Cryptographically sign your binaries (public key cryptography is the keyword).

\n\n

One way of signing your binaries is to create at least a sha256 hash of your binaries (md5, CRC and sha1 are broken). Create a update config file containing all your files, their versions and their hashes. This update config file should also have a unique version number that is incremented only.

\n\n

Now sign this config file using public key signatures.

\n\n

This config file will be checked against the public key file on the end-system. If the key matches and the version is bigger than the current one the binaries can be downloaded and verified against the hashes.

\n\n

\nSecure key handling

\n\n

The secret key must be stored on an isolated system. Not a build machine and especially not the download server. You sign the update binary or config config\nprior to release with this key.

\n\n

You will want a second emergency key (its public part also distributed to the clients). This one is stored in a safe. If the first key is compromised you can can revoke it and do an emergency update now binding the emergency key to the clients.

\n\n

\nVerify version - only upgrade

\n\n

Only update to a newer version. No updates to older versions. If you ever want to roll back a change, release an old version of your programs with a higher version number.

\n\n

The reason for this is that an attacker could trick clients to install updates with older versions of your program that still contains known vulnerabilities. And hack the systems afterwards.

\n\n

\nTrack distribution

\n\n

You want to track your update roll out. And if systems are functional post-update. Especially that.

\n\n

\nBe able to stop updates

\n\n

If you roll out a broken update, you should be able to remove it from your update servers very quick. That way other users do not risk ruining their systems.\nAutomatic roll back (mentioned a few chapters above) will take care for the updated systems.

\n\n

Slowly increasing the percentage of client systems getting the update offered is also part of this. Start with a few percent, measure success, increase percentage.

\n\n

Result of these precautions is that everyone (including management) feels much more comfortable rolling out updates. And this will make it simpler to update clients with a new version that contains “only one security fix that is not even abused - as far as we know”.

\n\n

\nDistributing the updates

\n\n

If your updates are big your servers will not have enough bandwidth for to update all clients in time.\nYou could use a CDN for your updates. To further reduce load update in stages:

\n\n

Check first if there is a newer version than the one installed. This is a few bytes only
Download config file. Verify it.
Download binaries

\n\n

As you have your files signed, an option to be protected against DDOS-es vs. your update infrastructure would be to also have a fallback to a peer-to-peer network (BitTorrent). Some bigger software applications (games) use BitTorrent.\nDo not make that the only source ! BitTorrent could be blocked in some environments like companies. Also do not waste the users bandwidth without asking. It could be expensive for some of them if they are connected using a mobile network.

\n\n\n

\nCompress updates

\n\n

Compressing updates reduces stress on your update servers and makes them more resilient against DDOS attacks. Test common algorithms with your update files. The algorithms have different strengths and weaknesses. Also: De-compressing is very often much faster than compressing. And this is what your clients are doing.

\n\n

\nDiff updates

\n\n

If you are shipping large updates, you want to ship them as diffs to previous versions.\nDepending on your file types there can be different diff algorithms that are quite effective. Please test before using.\nFor PE files there is “courgette”.\nAlways verify after diffing if the created file is the proper one (by hash). If something went wrong, fall back to whole-file download.

\n\n

That way there is no additional risk.

\n\n

\nIncentives

\n\n

Some users care more about new Emojis than about vulnerability fixes. Maybe bundle some eye candy (new backgrounds, …) with the updates to get the users to update. Sad but true.

\n\n

\nPlan for several channels

\n\n

When creating an updater be ready to add new channels later. Valuable channels to have are for example an “internal” and a “beta” channel.

\n\n

\nAutomatic updates

\n\n

Do updates in the background. Without user interaction. Especially if you have corporate users offer an Opt-out hidden in some config. Companies want to test before they deploy to thousands of users.

\n\n

If the update requires a restart of the software think about waiting for the user to naturally restart it - with a timer. If the user does not restart it after X days nudge him.

\n\n

\nControl the update infrastructure

\n\n

It is essential that you control your update infrastructure. There are several things that can break given time:

\n\n

certificates run out
You lose ownership of your domain
server needs system updates

\n\n

Plan ahead and create scripts that test your current situation and warn you weeks ahead before your domain ownership runs out or before you should create a new certificate.

\n\n

Another thing to control is the certificate that signs the updates. It must not be on the update server. It also should not be on the build server (where lots of people from you company can access it) but on a dedicated system.

\n\n

\nDetails for things to avoid

\n\n

\nTOCTTOU Time of check to time of use - error

\n\n

Wikipedia on TOCTOU

\n\n

A possible issue when checking the signature of an update package: If the package is on an external medium and the updater is not copying it locally, the attacker can switch the (legit) package after verification with a malicious package.

\n\n

You verify the (clean) external data’s signature
Attacker replaces clean software with malicious software
Your tool now installs the malicious software from external medium

\n\n

Solution:\nCopy the package into a local storage before verification and installation.

\n\n

\nBreak the update chain

\n\n

Never break the update chain for your devices. As long as updates work you can fix anything. Focus of your testers should be to (automatically) test updates\nover several versions.

\n\n\n\n\n

\nPasswords

\n\n

Passwords are one of the most common authentication technologies.

\n\n

There are different kinds of passwords: Pins, Passwords and Passphrases.

\n\n

\nPINs

\n\n

Pins are short (4-10), contain most often only numbers and are insecure. To still make them a valid security feature add a short delay in between pins entered. After the 3rd wrong entry either lock the system and request a special PIN (like PUK for a Smartphone SIM cards) or add a massive penalty (1 minute) which increases during the next wrong entries. A negative side effect of this is that the system can be locked by a malicious actor…

\n\n

\nPasswords

\n\n

Passwords are longer than PINs. As with the current state of technology (cloud computing and GPUs) standard passwords have to be long to have a decent amount of security. To improve the situation you can push the user to create good passwords (high entropy thanks to a large character set, avoiding the top 100+ passwords, …)

\n\n

\nPassphrases

\n\n

Intentionally long passwords. If you create your product for a situation where a good keyboard is available or passwords are stored in password stores you should aim for that - or just do not artificially restrict password length and nudge users to use long passwords in a friendly way.

\n\n

\nEntropy matters

\n\n

Help the user to choose high-entropy passwords. Depending on the system the user is using there are several different approaches to generate high entropy passwords. Smartphone keyboards for example make it very difficult to enter special characters.\nMaybe go for long passphrases instead ?\nAlso: Avoid the most common top 100+ passwords (google for them). Have a list in your app and block list them. Notify the user not to use those. If you have international users you should also have international top 100+ lists.

\n\n

There is one exception where it is wise to use common passwords like “12345” or “password”: One time accounts without personal data attached.\nThings that can be stolen without pain to the user. But as a normal user will not be able to make this distinction - do not tell them that there is a\nsituation when weak passwords are OK…

\n\n

High entropy is based on length of the password and potential character set being used. This is why so many pages push people to have at least

\n\n

Lower case
Upper case
Special character
A Number

\n\n

In the password. As the code is simple to guarantee at least one of each is in the password it is done that way.

\n\n

One example of password entropy is the famous Correct horse battery staple

\n\n\n

\nPassword hints

\n\n

Don’t

\n\n

Users will use them and enter some easy to research data.

\n\n

\nPreventing copy & paste

\n\n

Some developers had the idea to prevent copy & paste. Hoping that can prevent malware from accessing the password in the clipboard.

\n\n

Maybe that was true. But current malware has many other tricks in addition. If malware is running on the system, it is game over.

\n\n

The side effect of preventing copy & paste is that people will use shorter and simple passwords because their password stores will not work properly with your password entry.

\n\n

And password cracking got a lot better thanks to improved computing power.

\n\n

TL;DR: Do not block copy and paste

\n\n

\nForgot password

\n\n

While creating an account enforce and verify a link to a mail address. This mail account is your “Trust Anchor” if the user forgets the password. Create a reset link and mail the user. Make sure not to spam the user. Do not revoke the old password until a new one is set.

\n\n

Do not send a random password by mail but a (randomly generated) link to a page you have to set a new password.

\n\n

\nTTL for passwords

\n\n

If you force the user to renew the password regularly, store a hash of the last 3 passwords the user used and make sure they are not recycled.

\n\n

\nAutofill trap

\n\n

If you create a web page with a password form:\nDo not allow autofill without user interaction on your web-page password pages.

\n\n

Malicious Ads are currently creating invisible forms to steal those passwords.

\n\n

Princeton research

\n\n

\nStolen passwords

\n\n

Malicious actors are hacking databases and extract the passwords from there. As users have the tendency to use the same password for different accounts this is troubling.

\n\n

The project HaveIBeenPwned is collecting those stolen databases from the dark web and makes it searchable for your own credentials.

\n\n

Hashes from there, cracked to 99%: Hash leaks

\n\n

Besides locking down your database server you should also “hash and salt” the passwords you store. That way you prevent damage in case of a stolen database..

\n\n

There are special passwords hashing algorithms that can be used.

\n\n

\nCracking passwords

\n\n

The technology to crack passwords is quite advanced. Besides Rainbow tables, GPU based passwords cracking and Cloud Computing an old tool is word lists:

\n\n

\nGPUs

\n\n

With powerful GPUs and usable APIs available people started to use a cluster of those GPUs to crack hashes (later they shifted to Bitcoins).

\n\n

This did beat the cracking capabilities of a CPU by a large factor. But people who invested into that had to specialize and offer hash cracking as a service to others. Reason for that is the investment into a bunch of the most powerful GPUs available (and re-investment a few GPU generations later).

\n\n

\nCloud

\n\n

Cloud computing offers processing power at a discount (especially when going for the compute-spot market). Using thousands of Amazon VMs in parallel to crack some hashes can be the fastest and cheapest way. Investment into GPUs declined and people switch to cloud way of hash cracking.

\n\n

\nRainbow tables

\n\n

Rainbow tables are attacker tools you should know about.

\n\n

To crack hashes (and passwords are stored as hashes) attackers use Rainbow Tables. These are large databases with pre-compiled string->hash pairs.\nThat way the attacker invests in storage, but reduces CPU power. If the attacker gets a large database dump with lots of Hashes, it is more efficient to match those two databases once and extract as many matching passwords as possible.

\n\n

And this is just the Rainbow Table basics. Some more optimization is available.

\n\n

Relevant for the defender:\nThe attacker just reduced required CPU power and swapped it for HDD space requirements. Common passwords will be in this table and are easy to crack. Non-common passwords or salted passwords are better protected.

\n\n

\nWord lists

\n\n

Attackers use word lists to brute force passwords. It is more effective to use existing words and permutes them than to generate all potential character combinations.

\n\n

Word lists are available online

\n\n

Hashpass
Imsky wordlists
berzerk0 wordlists
nerdlist
SecLists
If you installed Metasploit, word lists are in /usr/share/metasploit-framework/data/wordlists\n
Assetnote wordlist
Kali: /usr/share/wordlists

\n\n\n\n\n\n

\nCracking Archive files

\n\n

Multi threaded password brute forcing for archives: RARCrack\n%% rarcrack –threads 12 –type zip crypted.zip

\n\n

Cracking with wordlists:

\n\n

1 fcrackzip -u -D -p simple_wordlist.txt test_abc.zip\n

\n\n\n\n

\nWeb site scraping for wordlists

\n\n

CEWL

\n\n

Cewl example:

\n\n

1 sudo apt install cewl\n2 cewl -d 2 -m 5 -w docswords.txt https://example.com\n

\n\n\n\n

\nKeyloggers

\n\n

Keyloggers exist as hardware and as software variants. Hardware variants are USB dongles attached between keyboard and computer - external and internal. They record keystrokes and are later collected. Some even have WiFi - reducing the risk for the attacker. Those things are simple and can be deployed by cleaning staff.

\n\n

Software Keyloggers are drivers installed on the OS. Quite often by malware. They log keys and send their data to the mother ship.

\n\n

One way to defeat Keyloggers are on-screen keyboards. But at least for the software Keyloggers they fail. Those programs do screenshots as well as logging the physical keyboard.

\n\n

The positive effect of on-screen keyboards is limited. Please think twice if it is the proper solution for your specific security problem or if it is just security theater.

\n\n

\nIoT: Initial passwords

\n\n

Especially IoT devices and Routers have initial passwords. Some important wisdom:

\n\n

Force the user to change that on first use
Do never derive it from MAC address or other system specific number\n
- No fancy maths will protect you if you do. And MAC is broadcasted on WiFi
\n
Do not use a increment in the factory to initialise the first password\n
- Add proper randomness instead
\n

\n\n

\nSalting

\n\n

A salt is a random string/number.

\n\n

This is added to the password, before it is hashed. The salt is stored together with the username and password-hash in the database - plain text.

\n\n

By adding a random string/number to the password the user entered before it is hashed, we force the attacker to create a rainbow table for each of these salts.

\n\n

Create a new random salt for every user. That way even if two users use the same standard password, the resulting hashes will be different.

\n\n

Make the salt big.

\n\n

\nPepper

\n\n

Pepper is similar to salt. But pepper is either stored in a different database or in a different configuration file - both the password database and the configuration file have to be hacked.

\n\n

Or even not stored at all but is small. And then you brute force them when matching passwords to the database.\nWhen comparing the hash the computer will have to generate lots of hashes with password + all possible peppers.

\n\n

You can afford the extra computing power - while the attacker trying to hack millions of your accounts can not.

\n\n

\nBeyond passwords: “Two-factor authentication”

\n\n

Technology that extends passwords is already a part of many products. In addition to passwords so called “two-factor authentication” is implemented.

\n\n

A second factor - and a second communication channel - is required. This improves security.

\n\n

The second factor is very often based on a hardware device.

\n\n

Two major concepts are existing.

\n\n

\nTime-based One-Time Password (TOTP)

\n\n

The user has a device that shared an initial secret with the server. Based on this secret and the current time a short lived number is generated. The user enters this number in addition to the normal password to access the server.\nTo verify the server just calculates the same data using the current time and the shared secret.

\n\n

For the user it looks like an App on the smartphone that generates a 6 digit code. A countdown shows its validity (30 seconds are recommended in the RFC).

\n\n

The best known app for that is the Google Authenticator

\n\n

RFC 6238

\n\n

\nUniversal Two-Factor (U2F)

\n\n

U2F uses a device with a asymmetric crypto implementation. It can export the public key and sign challenges with the private key - which is sealed inside of the device.

\n\n

The public key is registered at the server. The best known device for U2F is the Yubikey which looks like a USB memory stick. But it can also offer NFC to be used with mobile phones.

\n\n

FIDO U2F

\n\n

Yubikey

\n\n

\nBackup codes

\n\n

As mobile phones tend to fall into a toilette or get lost somewhere else your backend will have to offer backup codes as well. Those are generated when the device is paired and can either be stored by the user or printed and locked away.

\n\n

Those codes should be valid one time only and maybe you also want to offer several codes for download.

\n\n

Plan a user experience to link a new device to the server using one of those codes. Also better plan a “refresh” button to invalidate the old codes and create new ones in case the printed codes get stolen.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\nCensorship

\n\n

The original internet was planned with lots of resilience. Even if parts of the internet have issues, the rest will route around it.

\n\n

Centralisation has added dependencies on a few companies. This results in accidental outages or planned censorship.

\n\n

Both are totally contrary to the spirit of the internet. By engineering resilience into the software you can protect from outages.

\n\n

If you are not building a system but administrating one, there are several tools that add redundancy to your current tool set. Especially by disconnecting from centralized services.

\n\n

The tricky thing: You have to install those programs before the internet fails. And regularly use them to be sure they are operational in case of an emergency.

\n\n

The programs you currently use will not have to be replaced. Just have those additional programs installed as well.

\n\n

\nMapping censorship

\n\n

There are several projects mapping internet failures. This can be censorship (Turkey) or power outages causing internet downtime (Venezuela).

\n\n

\nOONI by the Tor project

\n\n

Oooni has globally distributed sensors measuring the reach ability of services. Data can be accessed on a map, by a\nlist of “best of censorship” events and by an API.

\n\n

The project is Open Source and there is a description how to set up a sensor on a Raspberry Pi.

\n\n

The whole project is part of the Tor project.

\n\n

\nNetblocks

\n\n

Netblocks is run by a civil society group. Focus is more on written reports based on special internet outage events.

\n\n

\nBlocked.org.uk

\n\n

Censored pages in UK. UK has a voluntary filter for <18 content. This is over-blocking.

\n\n

This site tests and monitors specific sites.

\n\n

\nCensorship countermeasures

\n\n

Basic countermeasures are based on “have a plan B”. Redundancy.

\n\n

\nMessenger

\n\n

\nJabber + OMEMO

\n\n

Jabber is a chat software. Jabber (aka XMPP) is like E-Mail: You can have an address at any\nJabber server, use any kind of Jabber client to access it and contact everyone with a Jabber account.

\n\n

OMEMO is the encryption technology for Jabber. Just activate it in your client and done.

\n\n

There a different Jabber clients for example:

\n\n

Conversations for Android
Gajim for Linux and Windows

\n\n

Jabber is de-centralized and this makes it very resilient.

\n\n

There is also no central directory of user names. Pro: No one is tracking you or your network. Con: You have to give your friends your Jabber address.

\n\n

\nSignal

\n\n

Signal is a free client for mobile phones with a very good encryption. The Con: There is a central directory. Pro: As soon as you register on\nSignal, all your address book contacts that also use Signal will be in your Signal-connections-list.

\n\n

Similar to WhatsApp. But without Facebook.

\n\n

\nThreema

\n\n

Threema is a mobile phone communication app. It is cheap but not free. Also: It is closed source - but is getting security reviews. The encryption and the feature set are good and it is a very good messenger\nand simple to use. I especially like the (optional) key verification that forces people to meet\nin person and confirm their identity by scanning a QR code. Intuitive and secure.

\n\n

\nTelegram

\n\n

I am not using Telegram. It has several security issues. But on the other hand: Many people are already using it and it “survived” several censorship attempts already.

\n\n

Use it but be aware: It is less secure to spying attempts than the other messengers listed here. But the widespread adoption has its own benefits.

\n\n\n

\nBrowser replacement

\n\n

\nTor browser

\n\n

The Tor browser is hiding your tracks on the internet. Just install it. It will look like a Firefox browser with a few extra options. You can ignore them - the defaults are OK.

\n\n

The Tor trick: Your data is sent encrypted over three “Tor nodes” to hide you from the internet.

\n\n

Some very restrictive states limit the Tor browser. For those there are extra modes to exit their internet.

\n\n

The Tor browser can access special “.onion” URLs. That is the Dark part of the web.

\n\n

This may sound spooky. But even Facebook has a an entry door on the Dark side of the web. Facebook on Tor\nIt is is not as big a thing as you may think.

\n\n

Install the Tor browser and give it a try. You may not need it now. But maybe later.

\n\n\n

\nNetwork infrastructure

\n\n

In some regions the web coverage is under-developed. For some political reasons that is quite common in Germany. The Freifunk\nproject is offering free WiFi under the SSID “Freifunk”. Just connect and use the internet.

\n\n

This project is a good alternative to company owned infrastructure and adds resilience.

\n\n

If you are responsible for an area where people gather (restaurant, library, …) think about contacting this project and running an own Freifunk router. Which is basically an AP with special configuration.

\n\n

\nDNS

\n\n

Domain Name System is the phone book of the internet. It converts URLs into server IP numbers (IPv4 or IPv6). Ripping entries out of the DNS pre-configured by your ISP is a simple way to censor specific services.

\n\n

If it looks like that happened to you:

\n\n

DNS settings are in your Operating System. Some big companies run their own DNS. Try changing the old DNS entries for one of those:

\n\n

Google: 8.8.8.8
Cloudflare: 1.1.1.1
Quad9: 9.9.9.9

\n\n

(Yes, all of them were able to get iconic IPv4 addresses).

\n\n

Blocking on DNS level happened at the “Censorship in Turkey” event.

\n\n\n\n

Using OnionShare it is possible to share files. Just drag some files into the box, click the “start sharing” button and send\nthe generated URL to your communication partner.\nAs long as the server is running the partner can download it by simply using the Tor browser.

\n\n\n

\nFurther reading

\n\n

A large collection of alternative to centralised and surveilled services can be found on prism-break.org

\n\n\n\n\n\n\n\n\n\n

\nCrypto algorithms

\n\n

Crypto Algorithms are the basic building blocks of encryption. Above them are protocols (“how do we glue algorithms together to achieve our goal ?”). And above the protocols are libraries offering an easy programming interface to use a protocol.

\n\n

In many cases the user of the library still has to pick the algorithm to slot into the protocol. A basic knowledge of the algorithms will prevent many bugs.

\n\n

I will skip the mathematics and try to build simple “Good vs Bad” tables. If you want to dig deeper, please read the books in the links.

\n\n

A good crypto algorithm is created and tested in challenges. It will get a good peer review by other crypto experts. When mathematics improves (and computers get faster as well) the estimated time to crack it will shrink. Moore’s law predicts a increase of processing power by factor 2 every 18 months. GPUs, ASICs and Clouds (lots of cheap computers from Amazon Cloud, for example) can\nalso bring down the attack time.

\n\n

Normally experts will warn months or even years before a realistic attack on an algorithm is possible. That’s the time to move on to use a better algorithm.

\n\n

Be prepared to swap the algorithm used in your products and services

\n\n

If you rely on a crypto book on your desk, check out the date it was published. During the last years new attacks have been invented and some algorithms and protocols did not age well. If your decisions still are based on a book from 1995 they will be wrong - even if the book was great at that time.

\n\n

Be aware: This chapter is an extreme simplification. If crypto security is an essential part of your project dig deeper and use the further reading section.

\n\n

\nHash functions

\n\n

Hash functions are one way functions that generate a value of a fixed size from any length of input. One input always generates the same Hash. On the\nother hand: One Hash can be the same for different inputs.

\n\n

For security reasons it must be impossible:

\n\n

To revert the process and calculate the input from the Hash
To generate two inputs with the same Hash

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Name	Output Length (Byte)	Quality
CRC	*	Broken
MD5	16	Broken
SHA-1	20	Broken
SHA256	32	Good
SHA512	64	Good
SHA-3	variable	Good
BLAKE2	variable	Good

\n\n

A CRC is not a Crypto Hash function. It is good for validating bit flips in data. But not to prevent or detect human attacks. Still some people use it\nthat way…

\n\n

shattered.io on breaking SHA-1

\n\n

SHA256 and SHA512 are SHA-2 hashes. Where the number indicates the bit length.

\n\n

SHA-3 aka Keccak: Is developed as fallback for SHA-2. SHA-2 is still good. But if something should happen to it, there is SHA-3 with is based on a totally different internal principle.

\n\n

BLAKE2 was in the SHA-3 contest. Its main feature is speed. There are different variants optimized for different architectures. The core ones are:

\n\n

BLAKE2b: for 64 bit platforms
BLAKE2s: For 8 to 32 bit platforms

\n\n

If you need speed, give it a chance.

\n\n\n

\nHMAC or MAC

\n\n

MAC allows Integrity and Authentication. Simplified: It is a Hash with a shared key involved. That way the parties can authenticate the origin.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Name	Quality
Poly1305	Good
SipHash	Good

\n\n\n\n

\nPassword hash functions

\n\n

While other hash functions are efficient, for password hashes we want inefficient hash functions. On a normal server it does not matter that much if\n1 or 500 milliseconds are wasted on calculating the Hash. But the attacker wanting to break a database dump with hundreds of thousands Hashes gets into lots of trouble thanks to the in-efficient hash.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Name	Comments
Argon2d	GPU attack resistance
Argon2i	side channel attack resistance
bcrypt	Vulnerable to FPGA, ASIC attacks
scrypt	Vulnerable to GPU attacks
PBKDF2	Vulnerable to FPGA, ASIC and GPU attacks

\n\n

Links:

\n\n

Argon
BCrypt
PBKDF2

\n\n\n\n

\nStream Ciphers

\n\n

Stream ciphers are used especially in telecommunication to encrypt a data stream (mobile phone voice channel).

\n\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Name	Quality
A5/1	Broken
A5/2	Broken
RC4	Broken
Salsa20	Good

\n\n

\nBlock Ciphers

\n\n

Block Ciphers are the work horse to encrypt large data. Besides selecting the Algorithm and the key length it is also important to use it in the\nproper mode. There will be an own table for that.

\n\n

\nAlgorithms

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Name	Quality
DES	Broken
3DES	Mediocre
AES	Good

\n\n

3DES is rated mediocre because AES offers a better key-length to protection ratio. You should be using that.

\n\n

\nModes

\n\n

Block ciphers are encrypting the data block-by-block. The mode defines if and how the encryption of one block influences the encryption of the other blocks.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Name	Quality
Electronic Codebook (ECB)	Broken
Cipher Block Chaining (CBC)	OK
Counter Mode (CTR)	Good
Authenticated Enc. .. (AEAD)	Perfect

\n\n\n

If possible use AEAD.

\n\n

Some of those modes need more data in addition to the password to initialize the encryption: a number named IV (initialisation vector) or nonce (number used only once). This number can be public. But it has an important requirement: Do not recycle it ! This number must be used once only. For the next data you encrypt use a different one. With that requirement: A counter would do the job pretty well.

\n\n\n

\nAuthenticated Encryption

\n\n

Combining a MAC and an encryption results in Authenticated Encryption.

\n\n

The most common AE technology is AES Galois Counter Mode (AES-GCM)

\n\n

One important differentiation is if to do MAC first or encryption. It seems during the years - as experience grew - the shift was towards “Encrypt-then-MAC” as best practice.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Name	Quality
Encrypt-and-MAC	Bad
MAC-then-encrypt	Better
Encrypt-then-MAC	Best

\n\n

MAC and cipher must use distinct keys.\nBut there are foot guns and alternatives to this whole AE complex.

\n\n

If you go down that road, please check out “further reading” and at least 2 more books. Implementing this is lots of work (months-for experts). Invest your time into smartening up first.

\n\n

Or use libraries implementing this technology ready-to-use (which I would do).

\n\n\n

\nAsymmetric Ciphers

\n\n\n

RSA: you should use 2048-4096 bit key length (security levels of 90 to 128 bits)

\n\n

Encryption: Cipher text should be padded. RSA-OAEP does this (Optimal Asymmetric Encryption Padding)

\n\n

For signatures with RSA use RSA-PSS(Probabilistic Signature Scheme)

\n\n

\nKey exchange

\n\n

To do a key agreement/key exchange the state of the art is DH: Diffie-Hellman protocol. It can be used in different flavours.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Name	Quality
Anonymous Diffie–Hellman	Broken
Authenticated Diffie–Hellman	Weak
Menezes–Qu–Vanstone (MQV)	Best but complex

\n\n

Anonymous DH is breakable by man-in-the-middle attacks
Authenticated Diffie–Hellman: breakable by replay attacks
MQV is best but complex

\n\n

Most often used is Authenticated DH

\n\n

\nElliptic Curve Cryptography (ECC)

\n\n

Elliptic curve based cryptography is an upgrade on many crypto protocols. It offers more security for less key length. And thanks to the smaller keys it\nis often faster.

\n\n

If possible replace your RSA and DH with ECC.

\n\n

EC crypto depends on one special parameter: the curve it runs on. The curve has to be special. You can not make up your own. Instead use one of the standard curves:

\n\n

NIST curves
Curve25519 (which is very common)

\n\n

\nKey length

\n\n

Depending on your computing power, lifetime of your product and adversary this may vary. But sane best-practice key lengths are:

\n\n

Asymmetric: >= 3248 bit
Elliptic Curve to replace classical asymmetric crypto: >= 256 bit
Symmetric: >= 128 bit

\n\n

A source for a more specific evaluation of your required key length is here.

\n\n

\nBest practice

\n\n

Never encrypt without authentication: The cryptographic doom principle\n

\n\n\n

\nFurther reading

\n\n

\nSerious Cryptography by Jean-Philippe Aumasson

\n\n

Serious Cryptography is Mathematics paired with some hands-on. It contains lots of common mistakes being made when using those algorithms and protocols. It should be on your desk when building something with cryptography.

\n\n

\nThe Mozilla TLS guide

\n\n

Mozilla TLS guide is a collection of TLS server settings for different situations. A good cheat sheet ranking the current quality of algorithms in a pragmatic (“don’t break the web”) environment.

\n\n

\nBetterCrypto.org

\n\n

BetterCrypto is a project aimed at helping admins. They offer a free manual with lots of specific crypto settings for different applications. It also contains basic algorithm overviews.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\nProgramming

\n\n\n

\nIntro

\n\n

Programming bugs turned into vulnerabilities since…it feels like forever.\nWith the hacker paper Smashing The Stack For Fun And Profit\n - which was release somewhere in the 90s - game got more tricky.

\n\n

As C and C++ are very close to hardware and can mess with memory by design the issue has never been solved properly. And those languages are still\naround (for good reasons).

\n\n

The good news: This kind of bugs and similar ones can be avoided, detected, prevented and mitigated. There are tools for that. This chapter covers them.

\n\n\n

\nRequirements for code analysis tools

\n\n

There is a long list of tools supporting you during the development cycle. Some have specific requirements - and you will not be able to use them in your situation.

\n\n

Some of my projects are embedded projects - the requirement “compiles on Linux” is quite hard when the release target is a micro controller\nwithout an OS.

\n\n

An option here is to at least test the part of the code that are not hardware depended on Linux.

\n\n

\nFlawfinder: static code analysis\n
- Pro: No code modification required
- Pro: No Linux compilation required
- Pro: No execution on Linux required
- Con: No detailed analysis
\n
\nAssert: debugging tool\n
- Pro: No Linux compilation required
- Pro: No execution on Linux required
- Pro: Force multiplier for other technologies
- Con: Code modification required - debug build only
\n
\nFuzzing: Finding unexpected bugs\n
- Pro: No code modification required
- Con: Linux compilation strongly suggested
- Con: Linux execution strongly suggested
\n
Unit tests\n
- Pro: Linux or Windows for execution
- Pro: Compilation for Linux and Windows
- Con: Code modification required (modular design of code plus writing of unit tests)
\n
\nCppCheck: static code analysis\n
- Pro: No code modification required
- Pro: No execution required
- Pro: More detailed analysis than flawfinder
- Con: Special build target required
\n
\nClang, static: static code analysis using Clang\n
- Pro: Does not require code modification
- Pro: Does not require execution on Linux
- Con: Requires special build
- Pro: Very detailed static code analysis using compiler internal features
\n
Valgrind: dynamic code analysis (memory as a speciality)\n
- Pro: Does not require code modification
- Pro: Does not require re-compilation
- Con: Linux execution only
- Con: Focus is on memory issues
- Pro: Can run the release binary !
\n
\nClang, dynamic: dynamic code analysis using Clang\n
- Pro: Does not require code modification
- Con: Requires re-compilation
- Con: Linux execution only
- Pro: Very powerful dynamic code analysis
\n

\n\n\n

\nSome background

\n\n

There is a large number of fuzzing and dynamic code analysis tools for Linux.\nBeing able to compile at least core parts of the code and execute them on Linux will make your life much simpler.

\n\n

The two things that require code modification only modify special debug code. This way you will not mess up your release build.

\n\n

Unit tests can be run on Linux or Windows. They will even run on embedded systems.\nBut there you will have to handle memory space issues (the binary will be huge)\nand redirect the report to UART. I would define that as a bonus goal after the unit tests run on Linux or Windows.

\n\n\n\n\n\n\n

\nTesting

\n\n\n

\nIntro

\n\n

Testing is the last line of defense before your product is shipped to the customers. Having the ability to find the vulnerabilities here has serious benefits:

\n\n

Reduces emergency updates
Lets everyone sleep better
Creates a more relaxed development cycle

\n\n

Testing for vulnerabilities is part automation (=engineering) and part hacking.\nAs it is using existing tools and not looking for new ways to hack systems it does not require 1337 hacking skillz but still kicks the door open to the\ninteresting world of hacking.

\n\n\n

\nFlawfinder

\n\n

Flawfinder

\n\n

Flawfinder is a simple static code analysis tool. One of the “grep on speed” kind. It is simple - it should be one of the first tools to use to verify\nyour code. One nice thing: It puts the important messages first. Start checking the code from top to bottom.

\n\n

As it is simple it will not find all vulnerabilities. You should continue with\nother tools and code-reviews even if flawfinder gives you green lights.

\n\n

But it will guide you to areas of your code that are smelly.

\n\n

Flawfinder has two important modes:

\n\n

Finding smelly code that could have vulnerabilities
Finding code that handles inputs

\n\n

\nFinding issues

\n\n

Fuzzgoat is a vulnerable C program to test your fuzzer.

\n\n

Running flawfinder on Fuzzgoat results in this kind of log:

\n\n

 1 flawfinder .\n 2 Flawfinder version 1.31, (C) 2001-2014 David A. Wheeler.\n 3 Number of rules (primarily dangerous function names) in C/C++ rule set: 169\n 4 Examining ./main.c\n 5 Examining ./fuzzgoatNoVulns.c\n 6 Examining ./fuzzgoat.c\n 7 Warning: Skipping directory with initial dot ./.git\n 8 Examining ./fuzzgoat.h\n 9 \n10 FINAL RESULTS:\n11 \n12 ./fuzzgoat.c:1049:  [4] (buffer) strcpy:\n13   Does not check for buffer overflows when copying to destination (CWE-120).\n14   Consider using strcpy_s, strncpy, or strlcpy (warning, strncpy is easily\n15   misused).\n16 ./fuzzgoatNoVulns.c:928:  [4] (buffer) strcpy:\n17   Does not check for buffer overflows when copying to destination (CWE-120).\n18   Consider using strcpy_s, strncpy, or strlcpy (warning, strncpy is easily\n19   misused).\n20 ./fuzzgoat.c:368:  [2] (buffer) memcpy:\n21   Does not check for buffer overflows when copying to destination (CWE-120).\n22   Make sure destination can always hold the source data.\n23 ./fuzzgoat.c:401:  [2] (buffer) sprintf:\n24   Does not check for buffer overflows (CWE-120). Use sprintf_s, snprintf, or\n25   vsnprintf. Risk is low because the source has a constant maximum length.\n26 ./fuzzgoat.c:427:  [2] (buffer) sprintf:\n27   Does not check for buffer overflows (CWE-120). Use sprintf_s, snprintf, or\n28   vsnprintf. Risk is low because the source has a constant maximum length.\n29 ./fuzzgoat.c:444:  [2] (buffer) sprintf:\n30   Does not check for buffer overflows (CWE-120). Use sprintf_s, snprintf, or\n31   vsnprintf. Risk is low because the source has a constant maximum length.\n32 ...shortened...\n33 ./main.c:135:  [2] (misc) fopen:\n34   Check when opening files - can an attacker redirect it (via symlinks),\n35   force the opening of special file type (e.g., device files), move things\n36   around to create a race condition, control its ancestors, or change its\n37   contents? (CWE-362).\n38 \n39 ANALYSIS SUMMARY:\n40 \n41 Hits = 49\n42 Lines analyzed = 2545 in approximately 0.04 seconds (69403 lines/second)\n43 Physical Source Lines of Code (SLOC) = 1817\n44 Hits@level = [0]   0 [1]   0 [2]  47 [3]   0 [4]   2 [5]   0\n45 Hits@level+ = [0+]  49 [1+]  49 [2+]  49 [3+]   2 [4+]   2 [5+]   0\n46 Hits/KSLOC@level+ = [0+] 26.9675 [1+] 26.9675 [2+] 26.9675 [3+] 1.10072 [4+] 1.10\\\n47 072 [5+]   0\n48 Dot directories skipped = 1 (--followdotdir overrides)\n49 Minimum risk level = 1\n50 Not every hit is necessarily a security vulnerability.\n51 There may be other security vulnerabilities; review your code!\n52 See ([http://www.dwheeler.com/secure-programs](http://www.dwheeler.com/secure-pro\\\n53 grams)) for more information.\n

\n\n\n\n

\nFinding inputs

\n\n

As inputs into a program must be verified, filtered and sanitized it is a handy feature of flawfinder to search for code offering inputs.

\n\n

Use that tool and spend some time writing code to verify the input data.

\n\n

 1 flawfinder -I .\n 2 Flawfinder version 1.31, (C) 2001-2014 David A. Wheeler.\n 3 Number of rules (primarily dangerous function names) in C/C++ ruleset: 169\n 4 Examining ./main.c\n 5 Examining ./fuzzgoatNoVulns.c\n 6 Examining ./fuzzgoat.c\n 7 Warning: Skipping directory with initial dot ./.git\n 8 Examining ./fuzzgoat.h\n 9 \n10 FINAL RESULTS:\n11 \n12 ./main.c:142:  [0] (input) fread:\n13   Function accepts input from outside program (CWE-20). Make sure input data\n14   is filtered, especially if an attacker could manipulate it.\n15 \n16 ANALYSIS SUMMARY:\n17 \n18 Hits = 1\n19 Lines analyzed = 2545 in approximately 0.04 seconds (70448 lines/second)\n20 Physical Source Lines of Code (SLOC) = 1817\n21 Hits@level = [0]   1 [1]   0 [2]   0 [3]   0 [4]   0 [5]   0\n22 Hits@level+ = [0+]   1 [1+]   0 [2+]   0 [3+]   0 [4+]   0 [5+]   0\n23 Hits/KSLOC@level+ = [0+] 0.550358 [1+]   0 [2+]   0 [3+]   0 [4+]   0 [5+]   0\n24 Dot directories skipped = 1 (--followdotdir overrides)\n25 Minimum risk level = 0\n26 Not every hit is necessarily a security vulnerability.\n27 There may be other security vulnerabilities; review your code!\n28 See 'Secure Programming for Linux and Unix HOWTO'\n29 ([http://www.dwheeler.com/secure-programs](http://www.dwheeler.com/secure-program\\\n30 s)) for more information.\n

\n\n\n\n\n

\nTools

\n\n\n

\nIntro

\n\n

Using tools is one of the things that is typical for the human species [^wrong].\nTools make us doe more things. In a more reliable way. Have “old” stuff automated away and open us to do new things. They reduce human error.

\n\n

Many tools did not fit in other chapters. But they are part of our daily work with computers. And they contribute to the daily workflow of building software.

\n\n

Those tools are covered in this part of the book.

\n\n

[^wrong:] This is wrong. Even birds can do remarkable things and even build their own tools…just follow the biological and cognitive science there. This does not invalidate my point. Be smarter than the chicken wings on your plate.

\n\n\n

\nBolt on

\n\n\n

\nIntro

\n\n

There is a rift between security engineer. Those who can plan and build a system despise what they call “snalá¸±e oil”. It adds complexity (which is bad)\nand has no perfect guarantee for security\n(protection is statistics with a detection rate of 99.89%).

\n\n

Some security engineers are not so fortunate and have to deal with a system that is flawed and buggy and they can not change. For technical or political reasons (manager want to use an outdated internal web based tool that is not supported\nanymore and only works with and IE from last century). Their only hope is bolt-on security tools to manage a deprecated system which is already\nway to complex.

\n\n

This chapter deals with the bolt-on side - which commonly uses detection of attacks.

\n\n

As security can be a stressfull job, this intro closes with “Be excellent to each other”

\n\n\n

\nAnti Virus tests

\n\n

\nAbstract

\n\n

Modern anti-virus tools are a combination of hash databases, pattern matching, behaviour blocking, cloud technology and sandboxes. At least.

\n\n

Testing them is tricky.

\n\n

Malware has a short life span. New malware is generated every few minutes\n(this is called server side polymorphic).

\n\n

Testing malware is tricky as well.

\n\n

A testing lab needs access to large heaps of current malware, lots of virtual\nmachines, verification tools to identify if the malware is a dud or dangerous, verified clean samples, …

\n\n

This is the reason it requires teams, racks of computers, terabytes of malware and cleanstuff (for FP tests) and years of experience.

\n\n

Computer magazines normally let external experts test the AV software for detection and protection and add their own usability and speed tests on top.

\n\n

External experts are

\n\n

av-test
av-comparatives
\nvirus bulletin\n
- Which is a AV industry internal organisation
\n

\n\n

You can get some (not very detailed) raw data from those pages directly.\nObserve how the different tools develop over time, how they currently achieve, how their detection relates to their False Positives.

\n\n

Also check out who is not participating in those tests…. this could be a red flag.

\n\n

\nMethods

\n\n

Basically there are two kinds of tests.

\n\n

\nClassic scan

\n\n

A large folder containing historic and current malware is scanned. The percentage of detected malware and maybe the speed of the scan are the output.

\n\n

The results will be biased because the focus is on historic malware. The dangerous - current - malware is under-represented.

\n\n

The tested AV products can not use some of their protection tools like URL block lists, behaviour detection, cloud technology, …

\n\n

This is not used that often anymore.

\n\n

For that reason this kind of tests is replaced by:

\n\n

\nReal-world protection tests

\n\n

Current malware is used to “infect” machines where a full AV product is running.\nThe antivirus can use all its features to protect the machine.

\n\n

URL block list
Static file scanning
Cloud scanning
Behaviour analysis
Sandbox

\n\n

The results of this test are much more significant but the test is harder to run and the malware sample set will be smaller.

\n\n

This kind of tests is the future.

\n\n

\nDIY malware tests

\n\n

Some people do malware tests (by modifying malware, finding some stuff on the internet, …) and do their own testing. Especially patching malware samples to test with “new and unique” samples is a critical thing. Please do not do\nthat. Patching the malware sample could have broken it: it is not running properly and is causing no harm. Not detecting them is the right thing.

\n\n

Be careful when you see DIY malware tests and always verify with other sources.

\n\n

\nEicar

\n\n

What you can and should tests is if you antivirus is properly attached to your system.

\n\n

Basic questions should be:

\n\n

Is the proxy intercepting web traffic to scan it ?
Is the proxy scanning mails when I fetch them with the mail client ?
Is the AV scanning files when they are stored on hard-disk (called: On-access scanning)
Is it scanning when I execute a file ?
Is it scanning when I copy a file to a USB stick ?

\n\n

Exactly for these kind of tests there is the EICAR test file. Every AV should detect it. And it is easy to detect. It was created for testing exact this kind of situations mentioned above.

\n\n

EICAR test file

\n\n

It is just a few bytes long and you can copy & paste it.

\n\n

Move it around your system and test which entry points are not protected by your antivirus scanner.

\n\n\n

\nWindows Defender

\n\n

Windows Defender - pre-installed on Windows - is a kind of fallback if no other AV is installed. It improved its detection rate over the last years and already offers a decent baseline. There are still good reasons to install 3rd party scanner. But from an engineering perspective you can expect:

\n\n

A current Windows with Defender has a decent scanner already installed

\n\n

There are many drawbacks of having only the Defender as protection: Malware could start to hide from Defender as priority number one. As it is becoming the most common AV product. And this in turn can weaken the real protection Defender is offering. A typical mono culture effect.\nIt is better not to build a mono culture on your systems.

\n\n\n

\nAppendix

\n\n\n

\nExternal references and resources

\n\n

In addition to the references spread in the chapters - most often as “Further reading” - here is an extended list of hacking and security resources.

\n\n

It is important that you rate those resources for yourself. I have my personal categories.

\n\n

ALERT: Resources being fast on alerting. But I do not expect in depth coverage
DEEP: Slow (months after the incident) but incredibly deep coverage
SIMPLE: Resources to share with non-tech people
KNOWLEDGE: General knowledge covering specific technology. Not a source for threat intelligence

\n\n

All of them have their benefits and you should always use the proper source for the task at hand.

\n\n

\nBooks

\n\n

\nBook: Practical Internet of Things Security

\n\n

Practical Internet of Things Security by Drew Van Duren, Brian Russell

\n\n

A very methodical book covering

\n\n

Threat modelling
Design
Life cycle
Basic Cryptography
Authentication/Authorization
Compliance monitoring
IoT Incidence Response

\n\n

A good overview.

\n\n

Potential improvement: Go deeper into details and specific technology. For example: Crypto chapter is a good start but really using crypto will\nrequire more books to be read. Says the one writing a “security overview book”…I know….

\n\n

\nBook: “Test driven development for embedded C”

\n\n

Test Driven Development for Embedded C by James W. Grenning

\n\n

A pragmatic and step-by-step approach how to develop for embedded systems in C and still benefit from unit tests.

\n\n

This book will improve your software quality and security.

\n\n\n

\nThe Browser Hacker’s Handbook

\n\n

The Browser Hacker’s Handbook by Michele Orru , Christian Frichot , Wade Alcorn.\nEssential knowledge how to hack and secure a browser. Lots of focus on Beef\ntechnology.

\n\n\n\n\n\n\n

\nBook: IoT Penetration Cookbook

\n\n

IoT Penetration Cookbook by Aaron Guzman, Aditya Gupta

\n\n

Wide spectrum of offensive technologies. Good to create a checklist what to protect. Be prepared to read more in-depth books for the technologies you are interested in.

\n\n

\nBook: Pragmatic Thinking and Learning

\n\n

Pragmatic Thinking and Learning, by Andy Hunt

\n\n

Explains your most important tool as a computer expert: Your brain. How to use it, how to learn. A very important book for me. Written for the engineer.

\n\n

\nDriving Technical Change

\n\n

Driving Technical Change, by Terrence Ryan

\n\n

A book explaining how to introduce new technologies in a team or company. Simple to read but with very essential tricks for the tech guy how to get mental\nboulders blocking change out of the way.

\n\n

\nAnti Patterns

\n\n

Anti Patterns, Refactoring Software, Architectures, and Projects in Crisis by William H. Brown Raphael C. Malveau, Hays W. “Skip” McCormick III, Thomas J. Mowbray

\n\n

A book showing typical anti-patterns that just happen in larger (software)\nprojects. Your project will also suffer from some of those. Read this to\nunderstand those patterns and learn how to eliminate them.

\n\n

\nConferences

\n\n

An important criterion for conferences added here is online publication of talks and papers.

\n\n

When you know where to look you will find lots of awesome conferences with different priorities and a different focus.

\n\n

\nCCC

\n\n

The Chaos Computer Club has several conferences in Germany. Those have different focus and size. If you are interested in computer security, the MRMCD and the Congress are the most valuable ones for you. Talks are recorded and can be found on media.ccc.de

\n\n

\nUsenix (scientific security conference)

\n\n

Usenix is a high tech security and academic conference. Bleeding edge technology but a bit harder to get it into a product than with other conferences.

\n\n

\n\n

\n\n

\n\n

\n\n

\n\n

\nHack.lu

\n\n

Hack.lu is a security conference in Luxembourg. Talks are recorded, but it seems there is no central storage besides YouTube where you can find them.

\n\n

\nOWASP

\n\n

German OWASP Day 2019

\n\n

\nBlackhat

\n\n

Blackhat is a security conference with events in US, Europa and Asia (so don’t get confused).

\n\n

\nShmoocon 2006 - 2020

\n\n

Shmoocon

\n\n

2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020

\n\n

\nDefcon

\n\n\n

Defcon 26
\nDefcon 28\n
- Main stage on youtube
\n
Defcon 29

\n\n

\nBSides

\n\n

BSides

\n\n

BsidesSF 2021

\n\n

[BSides TLV 2021] (https://www.youtube.com/playlist?list=PLkNlAwTF5yEvS0IDS8zRanqUfTWxadcV4)

\n\n

\nRadare Con

\n\n

2020:

\n\n

https://github.com/radareorg/r2con2020

\n\n\n

\nPurdue University seminar

\n\n

Purdue

\n\n

\nVirus Bulletin

\n\n

Virus Bulletin is an Anti-Virus community magazine, tester and conference.

\n\n

Especially the conference has in-depth talks covering malware and malware actors. Some of those talks can be found on YouTube.

\n\n

Virus Bulletin videos

\n\n

\nBlogs

\n\n

Blogs are a good resource for in-depth malware analysis or content of almost any complexity.\nI suggest you check out which ones cover topics you are interested in and then start monitoring them for changes.

\n\n

Security perspective from a bank, check out articles, blogs, handbooks, white-papers: Bank indosecurity

\n\n

Deep analysis and IOCs: Cylance

\n\n

Team Cymru blog covers threat intelligence.

\n\n

Malware must die blog contains malware information

\n\n

Malware don’t need coffee focuses on Exploit kits and their distribution.

\n\n

Cyber crime Magazine focuses more on the crime aspect.

\n\n

Internet Storm Center

\n\n

Cloudflare

\n\n

HITBSecNews

\n\n

Citizen lab - big game hunting

\n\n

Also Brian Krebs is very well known for his investigations into the crime part of the topic.

\n\n

To stay in the world of crime: Europol will also cover it. But not focused on computer security.

\n\n

The Anti Virus companies also have blogs. Sometimes several blogs. With a focus on end-users or tech nerds. Those can vary in depth.

\n\n

Just to name a few.

\n\n

\nNews

\n\n

Hacker news portals:

\n\n

\nPodcasts

\n\n

Security Now
The Silver Bullet
Darknet Diaries

\n\n

\nMagazines

\n\n

Magazines (called Zines) are a part of the hacker culture. And they still exist.

\n\n

Pagedout magazine
\nPOC or GTFO Also available on other mirrors and as books
Spuz.me pen testing

\n\n

\nVideos

\n\n

“Administraitor” talks
Hak5

\n\n

\nWorkshops and Training

\n\n

Open Security Training
Reverse Engineering for Beginners

\n\n

\nCTF

\n\n

Capture the flags (CTF) are challenges to test your own skills in hacking.\nA good way to do that without committing any crimes.

\n\n

Background and some help:

\n\n

Awesome CTF

\n\n

There are also CTF competitions:

\n\n

https://ctftime.org/

\n\n\n

\nLists and bookmarks

\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\nGlossary

\n\n

0-day: An exploit used by the attackers before the vulnerability is known to the defender. They are expensive on the black market. Typical malware does not need 0-days. As many users do not patch their systems.

\n\n

ABAC: Attribute based access control. A logic decides based on attributes of different objects (subject, resource, action, environment) if access is permitted.

\n\n

Adware: Malware that shows Ads. As the Ad ecosystem generates money for viewed Ads this is how attackers convert infections to money

\n\n

Amplification attacks: Are attacks where a 3rd party is used to attack the target with amplified bandwidth. Services emitting more data than they receive are vulnerable. Often uses stateless protocols like UDP because the initiator is different from the victim.

\n\n

Anycast: Servers share the same IP address. The client connects to the closest one. Relevant if only one of them is hacked and serves malware…

\n\n

Approved List: A list of url/hashes/… that got approved as being harmless

\n\n

APT: Advanced Persistent Threat. Advanced malware. Often government backed. Or just very advanced malware.

\n\n

ASLR: Mitigation strategy to load code into random areas of the memory. Makes writing of exploits harder

\n\n

ASVS: Application Security Verification Standard: This OWASP project lists different ways to verify the security of an application.

\n\n

Backdoor: A constructed way for an attacker to connect to a vulnerable system and execute code

\n\n

Beacon: The C2 server on the public internet which is contacted by the implants on the victims local network. Connection is usually done in a regular interval. Depending on the malware this can be from minuets to months. Using this short beacon messages the implant fetches new instructions

\n\n

Blacklist: Deprecated, see “Block List”

\n\n

Block List: A list of items like URLs, hashes, … that trigger a blocking

\n\n

BLE: Bluetooth Low Energy

\n\n

BLE Characteristic: Value + Descriptor

\n\n

BLE GAP: Advertisements, connection handling, defining device roles in communication

\n\n

BLE GATT: Organizes the data offered by the device

\n\n

BLE L2CAP: Encapsulating data into packets

\n\n

BLE Service: Several Characteristics combined create a service. A default service for BLE would contain device information

\n\n

BLE Profile: Profiles combine several services. They standardize specific device classes

\n\n

Bot: An infected machine that can be remote controlled by the attacker

\n\n

Botnet: Infected machines centrally controlled by the attacker using a C&C

\n\n

Bug: Error made in the programming phase. Not all bugs are vulnerabilities

\n\n

Campaign: Malware campaigns are events where a malware actor spreads malware by phishing, infected sites, … As malware is a business with division of work, one malware type can be spread by different actors in separate campaigns in parallel

\n\n

Canary: A trigger that will alert in an intrusion attempt. Code canaries for example are values in the code that trigger when being overwritten

\n\n

CAPEC / Common Attack Pattern Enumeration and Classification: A MITRE taxonomy for attack patterns. https://capec.mitre.org/

\n\n

C&C aka C2: Command and Control server. Central control over a botnet

\n\n

Class break: A Class break is a vulnerability that breaks the whole device class. Instead of just one single device. Example: Same master key on all devices leaks

\n\n

CORS/ Cross-origin-resource-sharing: Mechanism to define exceptions for the SOP (Same-origin-policy) in the HTTP header

\n\n

CERT: Computer Emergency Response Team. Handles security breaches in organisations or nations.

\n\n

Command injection: If the attacker is able to inject a command to the system shell (and the data is not sanitized) this is a command (line) injection. See OWASP

\n\n

Common Platform Enumeration: A unique ID for software products, can be used to query vulnerability databases and software asset management

\n\n

CRITs / Collaborative Research Into Threats Threat intelligence sharing platform by MITRE. See TIP. https://crits.github.io/

\n\n

CSRF aka XSRF - Cross site request forgery: The attacker tricks the user to issue a HTTP requests on a site where the user has an open session. This HTTP request triggers an action on the server on behalf of the user.

\n\n

Dark Web: Intentionally hidden parts of the web. Most common TOR pages

\n\n

DAST: Dynamic Application Security Testing. Testing by executing the program in a special test harness. Maybe compiler flags like ASan

\n\n

Deep Packet Inspection: A filter looks into the deeper layers of packets. Complex, and causes issues with encrypted data. Better don’t do it.

\n\n

Deep Web: Parts of the web, that is not indexed by search engines (intranets, everything behind a login, ….)

\n\n

Dedik: Stolen RDP access to a windows server. Used as first step for Ransomware attacks (2020: 70% of Ransomware attacks started that way). Dedik = Dedicated server

\n\n

DEP: Data execution prevention. Parts of the memory are marked as non-execute (=NX)

\n\n

DFIR: Digital forensics and incident response

\n\n

DGA / Domain generation Algorithm: An malware algorithm generating domain names based on a counter/time to connect to.

\n\n

Differential privacy: Is a way to collect statistical data on clients/users without compromising the privacy of specific users

\n\n

Domain Flux: Way to hide C&C servers. A domain name generator creates changing domain names

\n\n

DOS: Denial Of Service - Attack that exhausts resources of the target (CPU, memory, network, storage)

\n\n

DDOS: Distributes DOS - Attack is done by many systems in parallel

\n\n

DNG / Domain Name Generator: Part of a malicious script generating possible URLs for C&C servers by time. By registering some of them the attacker can reduce take downs and still get connecting bots.

\n\n

DTLS: Datagram TLS - TLS for short UDP messages (see: IoT)

\n\n

DVA / Damn Vulnerable Application (Also: Damn Vulnerable Web application): A insecure application to train hacking on or test tools

\n\n

Dynamite phishing: Automated spear phishing. The malware silently collects mail communication to later fake new phishing mails for new victims

\n\n

EDR /Endpoint Detection and Response: Endpoint protection with a deeper analysis system and an array of potential responses to attacks

\n\n

ELF: Linux executable file format

\n\n

EMET: Enhanced Mitigation Experience Toolkit for Windows hardening. Now integrated into Windows Defender Exploit Guard

\n\n

EPP / End Point Protection: Passive Endpoint protection

\n\n

Evercookies: Are snippets stored in the browser like cookies. Storage is JavaScript Local storage, Flash storage, … hard to delete those data snippets. AKA Zombie Cookies

\n\n

Exploit: Attack on a vulnerability

\n\n

Exploit Kit: A ready to run malware spreading tool. Normally uses infected web pages to spread the exploit.

\n\n

Fast Flux: Using Round-Robin DNS to hide a C&C server. One URL gets multiple IPs that way.

\n\n

Flaw: Error made in the design phase. Not all flaws are vulnerabilities

\n\n

FP: False Positive. A harmless URL or file is detected as malicious

\n\n

Firewall: Network filter. Can reduce allowed traffic on a network connection. Smarter firewalls can maintain some state and decided based on who initiated a connection - internal or external computer ?

\n\n

Heap Spraying: Loading the exploit code several times into different memory areas. Also uses NOP slides

\n\n

Honeypot: A Honeypot is a simulated vulnerable system to attract attackers. The attacks will then be analysed to learn about the attackers.

\n\n

HVCI: Hypervisor Protected Code Integrity, aka “memory integrity”, a Windows feature HVCI

\n\n

IDS / Intrusion Detection System: Monitor in a network to analyse that for malicious activity. Using rules it can notify admins if anomalies are detected

\n\n

IPS / Intrusion Prevention System: IDS with the ability to automatically stop potential attacks (firewall up, terminate processes, …)

\n\n

Implant: A tool used by the attacker to maintain access to an exploited system. Normally has some form of connection to the attacker’s infrastructure to be controlled

\n\n

IOC: Indicator of Compromise. A file-hash, URL, registry key or similar feature left by the malware when a system is infected.

\n\n

JWT: JSON web token. A “cookie” for authentication with added data. Stored on the client. The JWT is signed by the server.

\n\n

Kerckhoffâ€™s Principle: A cryptosystem should be secure, even if everything about the system, except the key, is public knowledge.

\n\n

Key rotation: Periodically change the encryption key

\n\n

Kill chain: Phases of an attack

\n\n

Living off the land: A tactics where the attacker uses pre-installed software for the attack. This reduces detectable malware on the system

\n\n

MAEC5: Malware sample description language. Covers static features like hashes and behaviour. MAEC5

\n\n

MBEC: mode-based execution control: Windows memory integrity feature, requires CPU support

\n\n

Malware: Malicious software

\n\n

MaaS / Malware as a service: Organised crime split malware creation and using malware against a target into different roles. Malware creators offer malware “as a service” to the second group

\n\n

MISP: Open standard for threat information sharing. Also a sharing platform. Focus on IOC. MISP. See also. TIP

\n\n

MISRA C: Guidelines for safe C programming. Tools (compiler and static code analyser) support it. Some of the safety issues are also security issues. Check it out. Low hanging fruit.

\n\n

MITM: Man/Monster in the Middle. Network connections are broken up in the middle by the attacker to spy or modify network packets

\n\n

MITRE: Non profit organisation doing security research

\n\n

MITRE Att@ck: A taxonomy for attacker TTPs. see: MITRE

\n\n

mutual TLS / mTLS: Both sides, client and server, authenticate to each other using certificates

\n\n

NOP slide: Increases the target the instruction pointer has to hit to get to the exploit code. Done by adding NO operation codes to the beginning.

\n\n

Open redirect: A vulnerability where a legitimate website can be tricked into HTTP redirecting a visitor to a url supplied by the attacker

\n\n

Patch gap: Gap between a security patch in a 3rd party library and a patched release of the main product using this library

\n\n

Patch Guard: Windows kernel patch protection, protects some memory structures from being modified

\n\n

PE: Portable Executable file. On Windows .exe and .dll (and some others). Starts wit a DOS Header (MZ)

\n\n

Persistence: Attackers can do a hit and run - stealing data - or try to maintain access to the target by running implants there or getting the credentials. That way the “attack survives a reboot”. This would be called “persistence”.

\n\n

Persistence(system): System level persistence can be gained by running code on a single system. Often done as a hidden rootkit in kernel mode

\n\n

Persistence(network): Persistence by controlling several systems by either stolen credentials or compromise of a core infrastructure in the network.

\n\n

Phishing: Attack using social engineering to get credentials. Can involve malware or exploits as well

\n\n

POLA / Principle Of Least Authortity see POLP

\n\n

POLP / Principle Of Least Privilege: Users are granted the smallest set of privileges they need to get their assigned tasks done

\n\n

POMP / Principle Of Minimal Privilege: see POLP

\n\n

QUIC: A Google protocol based on UDP to replace TCP. By adding TCP features to UDP

\n\n

RAT / Remote access trojan: An implant to gain persistence. Can remote control OS functionalities.

\n\n

RBAC / Role based Access Control: Every user has a role. Those roles come with permissions

\n\n

RBN / Russian Business Network: Rogue ISP offering bullet proof hosting (take downs by police not easy)

\n\n

RCE: Remote Code Execution. An attacker is able to execute code without physical access to the system. Very bad.

\n\n

Regular Expression DOS: Non optimized regular expressions can require lots of CPU. If the attacker is able to submit an own Regex, it is possible to DOS the target system OWASP

\n\n

Reproducible Build: The software build chain must create hash-identical software on different build systems. That way some supply chain attacks can be mitigated.

\n\n

Reverse shell: A command shell running on a hacked PC. To get out through NAT/Firewall it connects back from the infected PC to a server the attacker controls.

\n\n

ROI: Return on investment. A business metric. But as attackers want to make money, make them pay for it by detecting their tools, sharing this knowledge. And make it very expensive for them to attack.

\n\n

ROP / Return Oriented Programming: If an executable is compiled with DEP it is not possible to insert new shellcode to execute. ROP uses existing code from the victim-executable and chains those ROP gadgets into a new order to achieve the goal.

\n\n

Round-Robin DNS: Old system for load balancing that does not work with modern clients or IPv6. TTL is short lived.

\n\n

SafeSEH: A windows compiler feature to mitigate attacks abusing the Exception Handler. Attackers can modify the the exception table. The cause an exception. By that they then can control program flow. SafeSEH mitigates that.

\n\n

SAST: Static Application Security Testing. This can be compiler warnings or special tools

\n\n

SBOM Software Bill of Materials

\n\n

SCA: Software Component Analysis: Check external software components for vulnerabilities and license compliance issues

\n\n

Self guided malware: Malware for air-gapped systems. Does not need a connection to a control server. Has all the propagation/infection logic built in. Not a common thing. But Stuxnet was one of those.

\n\n

Session fixation: Vulnerability caused by not creating a new session on login but recycling an old one. The attacker injects his token into the victims browser. As soon as the victim logs in, the attacker has parallel access to the account.

\n\n

Session Hijacking: The login token of a session is stolen. While this is valid the attacker has access

\n\n

Shellcode: The payload in an exploit. Shellcode either pops a shell or establishes a connection to the attacker in the internet, … This is where malicious things happen.

\n\n

Side Channel: Using side effects to hack a system. For crypto a side channel can be timing differences between a right and a wrong password.

\n\n

SIEM / Security Information and Event Management: Collect and analyse different security relevant data into logs. Actions are triggered based on this data.

\n\n

Sigma rules: Sigma rules are for logs what Yara is for files https://github.com/Neo23x0/sigma

\n\n

SKF: Security Knowledge Framework: OWASP expert system to build and verify secure software https://owasp.org/www-project-security-knowledge-framework/

\n\n

SNI / Server Name Indicator: Part of the header to indicate which one of the hosted servers to contact. Could be encrypted if ESNI (Encrypted SNI) is used.

\n\n

SOC / Security Operations Center: The team running SIEMs in an organisation.

\n\n

SOP / Same-origin-policy: Web browser security principle: Elements of a web site must be from the same server

\n\n

Spam: Unwanted Advertising mails. Or similar messages on other channels. Often sent from hacked PCs to abuse their bandwidth.

\n\n

Spear Phishing: Targeted phishing. Learn about the target first to create better social engineering attack

\n\n

SQLI / SQL Injection: SQL commands can be sent through the user interface to the database backend. Instead of just values (which was the developer’s intention)

\n\n

Stack Clash: A vulnerability on Linux/BSD systems. Stack Guard Page should protect against Stack-Overflows. But it can be tricked into overwriting memory. A compiler switch can protect against Stack Clash.

\n\n

Static Code analysis: Analyse code without executing it. Compiler warnings are the best known example. Also linters.

\n\n

STIX2: A data format to exchange threat intel. More focused on Attack Groups/Identity/Threat actor/Campaign. STIX2

\n\n

StrongNaming: Authentication for .NET libraries. Signed binaries with version verification and pinned key.

\n\n

Sub domain hijacking aka sub domain takeover: The attacks is able to claim an abandoned web host with still existing DNS entries. Now it is compromised….

\n\n

Supply chain attack: The attacker manipulates a software, library or compiler used by the victim to attack the victim or the victims’s customer

\n\n

Suricata: Open Source IDS Suricata

\n\n

Threat intelligence: A service offered by security companies (or peer-to-peer). Can start with sharing IOCs and end with detailed reporters on attacks and threat actors. Focus is on Advanced attacks

\n\n

TIP / Threat intelligence platform: Threat intelligence sharing between organisations. See MISP or CRITs by MITRE

\n\n

TLP / Traffic Light Protocol by DHS: defines threat intelligence information sharing policy. From public to secret. Using 4 coloured levels

\n\n

TOR: The Onion Router. Overlay network over the internet to ensure anonymity of clients and servers

\n\n

Trust boundary: Who do you trust with what ? If your project integrated 3rd party compilers, tools, library, … you are already trusting someone. Knowing who you trust and how far is the trick.

\n\n

Trusted Computing Base (TCB): The part of a system that MUST work properly to ensure security. Keep this small.

\n\n

UAF / Use After Free vulnerability: Typical memory corruption bug

\n\n

VBS. Virtualization Based Security, a Windows feature to isolate parts of the memory from the OS. VBS

\n\n

Vulnerability: A bug or a flaw that has security implications

\n\n

Warning fatigue: A psychological aspect for secure UI design. If you display to many warning UIs your users will be trained to ignore them.

\n\n

Waterhole attack: Targeted phishing attack using a hacked/manufactured homepage the victim is known to visit and trust

\n\n

Weaponizing: Making an exploit easy and reliable to use.

\n\n

Whitelist: Deprecated term. See “Approved List”

\n\n

XSS, Persistent: An attacker can store a script on the web server that is for another user rendered. As it is a script it will execute in the context of the victim’s page.

\n\n

XSS, Reflected: The attacker can add a script to a url parameter which is part of the rendered page. This script will then run in page context

\n\n

XXE: XML External Entity injection: The attacker uses modified XML sent to the server to access internal data like files

\n\n

Zero Trust: All network requests must be authenticated. Even those originating from the own network

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\nThe author

\n\n

I have to tell you my origin story. Because you should know where we are going\nif you join me by reading this book. I hope it is not boring as no radioactive\nspiders are involved….

\n\n

Trouble shooter and one-man-team somehow happened to be my role. This and team expert for security.\nI am a software developer and engineer who also took the role of architect/project manager in security related projects. Which gave me a good and wide perspective on things in the IT world.

\n\n

After studying Computer Science (Dipl. Ing FH at University Ravensburg Weingarten, a German title) I went to Avira. An Anti-Virus/Endpoint bolt-on-security company. I handled core detection projects as part of teams. I was focused on the engineering/architect and developer roles. Amongst the things I did is:

\n\n

An AI SPAM filter in C: String processing in C….
A full Anti-Virus engine. Cross-compilable. For WinCE, Linux, PalmOS and Symbian. C
A generic module to detect malware in homepages. Building a kind of DOM. String processing. In C.
Management security consulting
Browser extension development - self learning phishing detection. JavaScript
A government founded research project:\n
- Split an OS into several virtual machines for segmentation
- Scan into these virtual machines without installing anything (Volatility)
- Classify malware based on behaviour (Cuckoo Sandbox)
\n
Create the architecture of a security/privacy focused Chromium based browser
Went to the Embedded and IoT world at Feo, another company
Mvoing to Avast I wrote a simulation environment to experiment with advanced attacks named PurpleDome\n

\n\n

Right in the middle of doing all those things I started to sort my knowledge\nand experience. Resulting in this book.

\n\n

Currently I am Lead Security expert at Primion where I can use all my knowledge.

\n\n

You can reach me

\n\n

On Twitter: @ThorstenSick
On Mastodon: @thorsi@chaos.social

\n\n

Thorsten Sick

\n\n

\nThe origin story: External brain

\n\n

This book was already written once. As my external brain. Just for me.\nI collect my knowledge in “external brains” a private wiki.\nMy security knowledge external-brain just grew to a stage where I thought “well, you just wrote a book”. And after finding leanpub which fits my style of tackling projects I decided I can transfer my external brain (written for me) into a book (written for tech people world wide).

\n\n

And this is currently happening.

\n\n\n

\nAuthors

\n\n

My goal is to write an anthology.\nContributions from experts in their fields are welcome. Everyone contributing a\nchapter gets half a page of biography.

\n\n

\nCredits

\n\n

Credits are for all the contributors.

\n\n\n

\nChangelog

\n\n

I want to “release early - release often”. For this reason I will add a\nchangelog to make it simpler for you to find the new sections.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\nAug 2025

\n\n

\nRSS feed space started
\nAV behaviour based classification extended
\nPrinciples extended
\nAnti Virus sharing samples extended
\nGoogle dork extended
\nBrowser security extended
\nCryptographic algorithms extended
\nPasswords extended
\nThreat modelling extended
\nTLS extended
\nSecret scanning extended

\n\n

\nApril 2023

\n\n

\nZAP updated
\nPasswords updated
\nVulnerabilities updated
\nPython updated
\nGit hardening updated

\n\n

\nDecember 2022

\n\n

Added Secret Scanning\n
Improved ZAP\n
Improved Git hardening\n

\n\n

\nNovember 2022

\n\n

Updating my Author-page
Update in Vulnerabilities\n
Updated Git hardening chapter\n
Adding ZAP\n

\n\n

\nJuly 2022

\n\n

Small extensions to video.txt, testing_compiling.txt, presentations.txt
Extended external references
Text cleanup based on vale
Improved behaviour classification
Added CAPEv2 chapter

\n\n

\nOctober 2021

\n\n

Fixed safari links (now learning.oreilly)
Cleaned up and extended glossary

\n\n

\nJune 2021

\n\n

New:

\n\n

Big additions:

\n\n

Added Nmap chapter\n

\n\n

Small additions:

\n\n

Extended Glossary
Behaviour based classification
Kill chain
Passwords
Vulnerabilities

\n\n

\nApril 2021

\n\n

Extended glossary
Extended “design”
Extended python\n%% TODO: Fix the whole book thing

\n\n

\nFebruary 2021

\n\n

Extended glossary
Updated python chapter

\n\n

\nOctober 2020

\n\n

Extended Behaviour based classification
Added Antivirus detection chapter
Extended glossary
Extended Kill chain
Extended External References
Extended SSH

\n\n

\nAugust 2020

\n\n

Extended External References

\n\n

\nMay 2020

\n\n

Extended Glossary
Extending Git hardening (turning it into CI/CD + Security)
Replacing whitelist/blacklist with approved list and block list\n

\n\n

\nApril 2020

\n\n

Reworked layout. Removed headers from chapters
Extended Glossary
Extended Glossary

\n\n

\nMarch 2020

\n\n

Extended passwords
Extended external references
Extended fuzzing
Extended Glossary

\n\n

\nFebruary 2020

\n\n

Glossary extended

\n\n

\nJanuary 2020

\n\n

Extended external references\n
Extended glossary\n
\nProgramming/compiling: visual studio added
\nTesting-compiling extended
Decission: I will remove the target audience from all chapters. Also the author as long as it is just me. 3rd party authors will get the credits.

\n\n

\nDecember 2019

\n\n

Thug chapter extended
TLS chapter extended

\n\n

\nNovember

\n\n

Spelling and quality improvements
fixed ../../images/tls_simple.png
Adding Recon-NG\n
Small fuzzing upgrade
Upgrade in vulnerabilities\n
The part planning got a proper review.

\n\n

\nAugust/September/October 2019

\n\n

Improved mitmproxy\n
Improved browser\n
Added kill chain\n
Added the practical parts to thug\n
Extended glossary\n

\n\n\n

\nJuly 2019

\n\n

Extended Glossary
Updated Thug
Extended Browser
Extended security process
Added mitmproxy
Extended “Threat modelling” with MITRE attack

\n\n

\nJune 2019

\n\n

Chapter for thug added - a honey client to investigate malicious web pages

\n\n

\nMay 2019

\n\n

Some cleanup
Extended “security process”
Added python security\n

\n\n

\nApril 2019

\n\n

Added “Threat modelling”
Extended Glossary
Added “git hardening”
Added “JavaScript security”

\n\n

\nMarch 2019

\n\n

Extending testing compiled binaries\n
Most readers read PDF ⇒ Focus on PDF layout now.
Old PDF setting: A5 (14.8cm x 21.0cm ) to get a book style size
New PDF setting: A4 (21.0cm x 29.7cm) for more table space and better screen readability
Tables set from default to wide
extended content\n
extended glossary\n
extended browser\n
extended security_process\n
Full quality check for “background” section
Added Censorship\n

\n\n

\nFebruary 2019

\n\n

Cleaning up the author page. Adding Mastodon and Twitter
Extended Attacker’s goals\n
Extended know your enemies\n
Small extensions to principles\n
Extending TLS\n
Extending browser\n
Starting vulnerabilities\n
Starting security process\n

\n\n

\nJanuary 2019

\n\n

Added Software design checklist (initial version)
Added Google Dorks\n
Added Glossary\n
Added part Appendix\n
Added basic beef chapter
Added basic burp suite chapter
Added IOC sources chapter
Extended TLS\n
Updated content\n
Intro for background added
Intro for planning added
Intro to programming added
Intro to testing added
Updated samples
Intro for tools
Reworking first chapters: re-write, remove or move to the end of parts. Reason: I want to get people to encounter the core book faster.\n
- Structure: removed unnecessary things
- The origin (moved to the author)
- stages of learning moved to part “psychology toolbox” (which is not active yet)
- random encounter removed
\n
More glossary entries

\n\n

\nDecember 2018

\n\n

Enhanced book list of defensive programming
\nSSH chapter added
Added Code Coverage chapter
Improved Fuzzing chapter
Added Vagrant to compiling chapter
Extended CppCheck\n
Small things in:\n
- Antivirus sharing samples
- clang
\n

\n\n

\nNovember 2018

\n\n

Enhanced defensive programming\n
Added design\n
Enhanced “attacker’s goals”
Enhanced passwords\n
Enhanced clang\n
Cleaning up the book, adding parts\n
- Chapters got moved around
\n
Enhanced This book\n
Enhanced The author\n
Enhanced structure\n
Clean up crypto algorithm tables
Enhanced antivirus testing\n
Added antivirus testing to the sample
unhooked external references
Kehrwoche: Aspell for all text parts in “sample”

\n\n

\nOctober 2018

\n\n

Added crypto algorithms\n
Re-worked Asserts\n
- It got an own chapter
- Python added
- JavaScript added
\n
Extended principles
Added testing chapter. Especially for unit testing and bug bounties (basics)
TLS got a diagram and minor improvements
\nClang chapter added
Added crypto algorithms to Sample

\n\n

\nSeptember 2018

\n\n

CAN bus hacking
Bluetooth LE (BLE)
Added code analysis tools requirements table for an overview
URLs now in footnotes
Content chapter added
Chapter Antivirus Behaviour classification added
added code analysis tools requirements to Sample

\n\n

\nAugust 2018

\n\n

This is the holiday release: Focus is on improving text quality\nof existing chapters.

\n\n

Extended “Principles”
Added new chapter “browser security” (not finished yet)
Added new chapter “IoT security” (not finished yet)
Quality improvements in\n
- defensive programming
- know your enemies
- principles
- structure
- this book
\n

\n\n

\nJuly 2018

\n\n

Added attacker’s goals\n
Added antivirus-tests\n
Added antivirus-integration\n
Changed PDF to A5 for a typical book-size PDF
Added basic fuzzing chapter
Extended “Defensive programming”
Extended “principles”
Extended “TLS chapter”
Extended “External references”
Added antivirus-sharing-samples\n
Added antivirus virustotal\n
Added Cppcheck chapter\n
Added Testing compiling chapter
Added kill chain chapter to offense

\n\n

\nJune 2018

\n\n

Added TLS chapter\n
Extended principles\n
Added passwords\n
Added basic compiling\n
Improved external references\n
Extended update\n
Added flawfinder chapter

\n\n\n

\nMay 2018, initial release

\n\n

Added principles chapter
Added updates chapter
Added Know your enemies chapter
Added UX chapter
Added structure chapter
Added external references chapter
Added “The Author” chapter
Added “This book” chapter
Added “Defensive programming chapter” for default defensive programming

\n\n\n

\nLicense

\n\n

This book is licensensed under CC-BY-SA 4.0

\n\n

The source of this book

\nNotes

Background

1Depends on your users↩

\n\n\n

\n\n

\n\n","tocStructure",[647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673,674,675,676,677,678,679,680,681,682,683,684,685,686,687,688,689,690,691,692,693,694,695,696,697,698,699,700,701,702,703,704,705,706,707,708,709,710,711,712,713,714,715,716,717,718,719,720,721,722,723,724,725,726,727,728,729,730,731,732,733,734,735,736,737,738,739,740,741,742,743,744,745,746,747,748,749,750,751,752,753,754,755,756,757,758,759,760,761,762,763,764,765,766,767,768,769,770,771,772,773,774,775,776,777,778,779,780,781,782,783,784,785,786,787,788,789,790,791,792,793,794,795,796,797,798,799,800,801,802,803,804,805,806,807,808,809,810,811,812,813],{"_80":74,"_43":70,"_71":-5,"_75":76,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":82,"_71":-5,"_75":83,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":88,"_71":-5,"_75":89,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":94,"_71":-5,"_75":95,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":97,"_71":-5,"_75":98,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":100,"_71":-5,"_75":101,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":103,"_71":-5,"_75":104,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":106,"_71":-5,"_75":107,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":110,"_71":-5,"_75":111,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":113,"_71":-5,"_75":114,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":117,"_71":-5,"_75":118,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":120,"_71":-5,"_75":121,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":123,"_71":-5,"_75":124,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":126,"_71":-5,"_75":127,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":129,"_71":-5,"_75":130,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":132,"_71":-5,"_75":133,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":135,"_71":-5,"_75":136,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":138,"_71":-5,"_75":139,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":74,"_43":117,"_71":-5,"_75":141,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":144,"_71":-5,"_75":145,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":148,"_71":-5,"_75":149,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":152,"_71":-5,"_75":153,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":155,"_71":-5,"_75":156,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":158,"_71":-5,"_75":159,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":161,"_71":-5,"_75":162,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":164,"_71":-5,"_75":165,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":167,"_71":-5,"_75":168,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":170,"_71":-5,"_75":171,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":173,"_71":-5,"_75":174,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":176,"_71":-5,"_75":177,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":179,"_71":-5,"_75":180,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":182,"_71":-5,"_75":183,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":185,"_71":-5,"_75":186,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":188,"_71":-5,"_75":189,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":191,"_71":-5,"_75":192,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":194,"_71":-5,"_75":195,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":197,"_71":-5,"_75":198,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":200,"_71":-5,"_75":201,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":203,"_71":-5,"_75":204,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":206,"_71":-5,"_75":207,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":209,"_71":-5,"_75":210,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":74,"_43":120,"_71":-5,"_75":212,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":144,"_71":-5,"_75":215,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":167,"_71":-5,"_75":218,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":221,"_71":-5,"_75":222,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":224,"_71":-5,"_75":225,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":227,"_71":-5,"_75":228,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":230,"_71":-5,"_75":231,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":233,"_71":-5,"_75":234,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":236,"_71":-5,"_75":237,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":239,"_71":-5,"_75":240,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":242,"_71":-5,"_75":243,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":245,"_71":-5,"_75":246,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":248,"_71":-5,"_75":249,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":251,"_71":-5,"_75":252,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":254,"_71":-5,"_75":255,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":257,"_71":-5,"_75":258,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":260,"_71":-5,"_75":261,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":263,"_71":-5,"_75":264,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":266,"_71":-5,"_75":267,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":269,"_71":-5,"_75":270,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":273,"_71":-5,"_75":274,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":269,"_71":-5,"_75":276,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":278,"_71":-5,"_75":279,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":281,"_71":-5,"_75":282,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":284,"_71":-5,"_75":285,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":287,"_71":-5,"_75":288,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":290,"_71":-5,"_75":291,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":293,"_71":-5,"_75":294,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":296,"_71":-5,"_75":297,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":299,"_71":-5,"_75":300,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":302,"_71":-5,"_75":303,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":305,"_71":-5,"_75":306,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":308,"_71":-5,"_75":309,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":311,"_71":-5,"_75":312,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":314,"_71":-5,"_75":315,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":317,"_71":-5,"_75":318,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":320,"_71":-5,"_75":321,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":323,"_71":-5,"_75":324,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":327,"_71":-5,"_75":328,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":330,"_71":-5,"_75":331,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":209,"_71":-5,"_75":333,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":335,"_71":-5,"_75":336,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":339,"_71":-5,"_75":340,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":342,"_71":-5,"_75":343,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":345,"_71":-5,"_75":346,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":348,"_71":-5,"_75":349,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":351,"_71":-5,"_75":352,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":354,"_71":-5,"_75":355,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":357,"_71":-5,"_75":358,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":360,"_71":-5,"_75":361,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":363,"_71":-5,"_75":364,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":366,"_71":-5,"_75":367,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":369,"_71":-5,"_75":370,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":209,"_71":-5,"_75":372,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":74,"_43":123,"_71":-5,"_75":374,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":144,"_71":-5,"_75":377,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":380,"_71":-5,"_75":381,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":384,"_71":-5,"_75":385,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":74,"_43":126,"_71":-5,"_75":387,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":144,"_71":-5,"_75":390,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":393,"_71":-5,"_75":394,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":397,"_71":-5,"_75":398,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":400,"_71":-5,"_75":401,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":74,"_43":129,"_71":-5,"_75":403,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":144,"_71":-5,"_75":406,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":74,"_43":409,"_71":-5,"_75":410,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":144,"_71":-5,"_75":413,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":416,"_71":-5,"_75":417,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":420,"_71":-5,"_75":421,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":423,"_71":-5,"_75":424,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":426,"_71":-5,"_75":427,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":429,"_71":-5,"_75":430,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":74,"_43":138,"_71":-5,"_75":432,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":435,"_71":-5,"_75":436,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":439,"_71":-5,"_75":440,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":442,"_71":-5,"_75":443,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":445,"_71":-5,"_75":446,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":448,"_71":-5,"_75":449,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":451,"_71":-5,"_75":452,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":454,"_71":-5,"_75":455,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":457,"_71":-5,"_75":458,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":460,"_71":-5,"_75":461,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":463,"_71":-5,"_75":464,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":466,"_71":-5,"_75":467,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":469,"_71":-5,"_75":470,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":473,"_71":-5,"_75":474,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":477,"_71":-5,"_75":478,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":480,"_71":-5,"_75":481,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":484,"_71":-5,"_75":485,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":488,"_71":-5,"_75":489,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":492,"_71":-5,"_75":493,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":495,"_71":-5,"_75":496,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":498,"_71":-5,"_75":499,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":501,"_71":-5,"_75":502,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":504,"_71":-5,"_75":505,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":507,"_71":-5,"_75":508,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":510,"_71":-5,"_75":511,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":513,"_71":-5,"_75":514,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":516,"_71":-5,"_75":517,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":519,"_71":-5,"_75":520,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":522,"_71":-5,"_75":523,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":525,"_71":-5,"_75":526,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":528,"_71":-5,"_75":529,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":531,"_71":-5,"_75":532,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":534,"_71":-5,"_75":535,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":537,"_71":-5,"_75":538,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":540,"_71":-5,"_75":541,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":543,"_71":-5,"_75":544,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":546,"_71":-5,"_75":547,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":549,"_71":-5,"_75":550,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":552,"_71":-5,"_75":553,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":555,"_71":-5,"_75":556,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":558,"_71":-5,"_75":559,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":561,"_71":-5,"_75":562,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":564,"_71":-5,"_75":565,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":567,"_71":-5,"_75":568,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":570,"_71":-5,"_75":571,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":573,"_71":-5,"_75":574,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":576,"_71":-5,"_75":577,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":579,"_71":-5,"_75":580,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":582,"_71":-5,"_75":583,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":585,"_71":-5,"_75":586,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":588,"_71":-5,"_75":589,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":87,"_43":591,"_71":-5,"_75":592,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":81,"_43":594,"_71":-5,"_75":595,"_73":74,"_90":-5,"_91":-5,"_92":-5},{"_80":74,"_43":598,"_71":-5,"_75":599,"_73":74,"_90":-5,"_91":-5,"_92":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

\nAuthors

Table of Contents

\nPreface

\nThis book

\nGoals

\nRelease early, release often

\n80/20 or Pareto Principle

\nForm follows function

\nAll this said…

\nStructure of this book

\nProject phases and audience

\nContent

\nBackground

\nKnow your enemies

\nAttacker’s goals

\nPrinciples

\nPlanning

\nThreat modelling

\nSoftware Design

\nVulnerabilities

\nSecurity process

\nSoftware Design Checklist

\nUX

\nUpdates

\nPasswords

\nBrowser

\nCensorship

\nIoT

\nCAN

\nBluetooth LE

\nTLS

\nCrypto algorithms

\nProgramming

\nCode analysis tools table

\nDefensive programming

\nAssert

\nCompiling

\nClang LLVM

\nJavaScript security

\nTesting

\nTesting compiled binaries

\nFlawfinder

\nCPPCheck

\nTesting

\nFuzzing

\nTools

\nSSH

\nGit

\nBolt-on security

\nAntivirus tests

\nAntivirus integration

\nAntivirus sharing samples

\nAntivirus: VirusTotal

\nAntivirus: Behaviour based classification

\nIOC sources

\nOffense

\nKill chain

\nRecon NG

\nGoogle Dorks

\nBeEF

\nBurp Suite

\nMitmproxy

\nAppendix

\nExternal References

\nGlossary

\nThe author

\nAuthors

\nChangelog

\nLicense

\nBackground

\nIntro

\nPrinciples

\nBolt-on-security vs security-by-design

\nThreat modelling

\nReduce Attack Surface

\nCompartmentalisation / Segmentation

\nPrinciple of “Least privilege”

\nLandlock

\nUpdates

\nFlexibility