Understanding Amazon Web Services Security

First is to highlight the security issues that AWS occasionally have:

https://alas.aws.amazon.com/alas2.html

https://alas.aws.amazon.com

https://aws.amazon.com/security/security-bulletins/

In particular is the ROBOT attack:

https://security.stackexchange.com/questions/177337/what-makes-servers-vulnerable-to-return-of-bleichenbachers-oracle-threat-robot

https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-bock.pdf

https://www.usenix.org/conference/usenixsecurity18/presentation/bock

https://robotattack.org/

Amazon Web Services: Overview of Security Processes:

https://d0.awsstatic.com/whitepapers/Security/Intro_Security_Practices.pdf

https://cloudacademy.com/blog/amazon-web-services-security/

https://d36cz9buwru1tt.cloudfront.net/aws-gov-summit-2011/Security_Keynote_CJ_Moses.pdf

https://i.crn.com/sites/default/files/ckfinderimages/userfiles/images/crn/custom/2018/AlienVault_360_Q418_AWS_security_monitoring_for_beginners.pdf

https://1xt03y2cptxl2pmtse29x65s-wpengine.netdna-ssl.com/wp-content/uploads/2018/05/08-AWS-Security-State-of-the-Union_final.pdf

https://d1.awsstatic.com/whitepapers/aws-security-best-practices.pdf

https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Checklist.pdf

https://www.fortinet.com/content/dam/fortinet/assets/white-papers/wp-why-your-aws-cloud-environments-need-advanced-security.pdf

https://www.isc2denver.org/sites/default/files/AWS_Security_Best_Practices.pdf

https://www.owasp.org/images/3/33/Aws_security_joel_leino.pdf

https://www.threatstack.com/blog/what-you-need-to-know-about-the-top-7-aws-security-issues

https://aws.amazon.com/security/

Tips for AWS firewall:

https://aws.amazon.com/blogs/compute/automating-security-group-updates-with-aws-lambda/

https://blog.trendmicro.com/top-10-aws-security-tips-5-create-restrictive-firewall-policies/

AWS IoT Security:

Application Development How to:

https://medium.com/@CharlesBordet/how-to-deploy-a-shiny-app-on-aws-part-1-4893d0a7432f

https://medium.com/capgemini-norway/hosting-your-react-application-with-aws-in-30-minutes-623f6539d92d

https://towardsdatascience.com/deploying-a-python-web-app-on-aws-57ed772b2319

https://www.thinxtream.com/whitepapers/thinxtream-iot-security-wp-005.pdf

https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/index.html

Development APIs and setup:

https://aws.amazon.com/tools/

https://aws.amazon.com/sdk-for-node-js/

https://github.com/aws/aws-sdk-js

https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/getting-started-nodejs.html

https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/index.html

Fuzzer:

https://github.com/MozillaSecurity/octo

https://github.com/MozillaSecurity/funfuzz

https://github.com/MozillaSecurity

https://nth10sd.github.io/js-fuzzing-in-mozilla/

Characteristics of eBPF

a. it never can modify or read aribitrary parts of kernel memory, but only through known channels or mechanism.

b. if it uses FTRACE for tracing, then the dynamic instrumentation is delayed as long as possible – only when the code execution path is encountered. So if the user requested ebpf tracing of kernel APIs, many times it will not be instrumented until the point it is executed.

c. instead of directly running binary codes, it run a virtual machine to interpret binary codes. since this intermediate language must not have loops, it is verified so, and so is many other characteristics verified as well.

d. whenever it read parts of kernel memory, the data are only snapshots, and constantly changing. data-misses may happen, and this statistical by nature. memory buffer may be too small and reused quickly (ring buffer) – especially for network packet collections.

e. eBPF ==> no userspace dependencies, like FTRACE, and unlike SYSTEMTAP, so python, go, RUST, and so many other variations of usage of eBPF have been spawned. (and so similarly you have FTRACE + python, FTRACE + go and so on)

f. what is seccomp bpf?

https://lwn.net/Articles/740157/

"BPF does not define itself by only providing its instruction set, but also by offering further infrastructure around it such as maps which act as efficient key / value stores, helper functions to interact with and leverage kernel functionality, tail calls for calling into other BPF programs, security hardening primitives, a pseudo file system for pinning objects (maps, programs), and infrastructure for allowing BPF to be offloaded, for example, to a network card.

LLVM provides a BPF back end, so that tools like clang can be used to compile C into a BPF object file, which can then be loaded into the kernel. BPF is deeply tied to the Linux kernel and allows for full programmability without sacrificing native kernel performance.

Last but not least, also the kernel subsystems making use of BPF are part of BPF’s infrastructure. The two main subsystems discussed throughout this document are tc and XDP where BPF programs can be attached to. XDP BPF programs are attached at the earliest networking driver stage and trigger a run of the BPF program upon packet reception. By definition, this achieves the best possible packet processing performance since packets cannot get processed at an even earlier point in software. However, since this processing occurs so early in the networking stack, the stack has not yet extracted metadata out of the packet. On the other hand, tc BPF programs are executed later in the kernel stack, so they have access to more metadata and core kernel functionality. Apart from tc and XDP programs, there are various other kernel subsystems as well which use BPF such as tracing (kprobes, uprobes, tracepoints, etc)."

How can eBPF be compromised by vulnerabilities?

What are the security risks for allowing any runtimes codes to be executed in the kernel?

According to:

https://hardenedlinux.github.io/system-security/2016/12/13/kernel_mitigation_checklist.html

We can have:

1. Privilege escalation
2. Buffer overflow (You can see how spender tried to protect all the buffer for BPF processing here: https://grsecurity.net/~spender/jit_prot.diff, for example by using MACROS instead of some haphazard numbers like 64). Another to overflow the buffer is via “JIT spraying”: (https://lwn.net/Articles/525609/)
3. Information leakage

Actual bug history:

https://www.openwall.com/lists/oss-security/2018/10/17/9

https://tools.cisco.com/security/center/viewAlert.x?alertId=56415 (information leakage from kernel to userland)

https://blog.aquasec.com/ebpf-vulnerability-cve-2017-16995-when-the-doorman-becomes-the-backdoor

https://secuniaresearch.flexerasoftware.com/advisories/68979/

But BPF is a double edged sword:

http://www.brendangregg.com/Slides/BSidesSF2017_BPF_security_monitoring.pdf

https://www.openwall.com/lists/oss-security/2017/12/24/1

https://lwn.net/Articles/742170/

https://www.exploit-db.com/exploits/42048

https://ricklarabee.blogspot.com/2018/07/ebpf-and-analysis-of-get-rekt-linux.html

https://lkml.org/lkml/2018/1/3/895