Shall we play a game?
- 1. Maciej Lasyk OWASP Poland, 2013-10-17
- 2. Recruitment process @OWASP? ● Because this system is web application (partially) ● Because we based (100%) on FOSS (open-source) ● Because security matters ● Because OWASP people cares about security and can affect recruitment processes (hopefully) ;)
- 3. Recruitment ● Lot of recruitment agencies / services ● Huge number of potential candidates ● Whole team is involved in recruitment ● Candidate evaluation takes really lot of time
- 4. SysAdmin / Operations ● He is sysop, developer, QA and network specialist ● Also great for performance tuning ● Responsible for critical data (all data) ● Easy handles moving UPSes between racks ;) ● Anytime day / night understands what you’re talking to him ● Everything he does respects high security standards ● Loves playing games (do you know sysop that doesn’t play)? ;)
- 5. Let’s play then ● Any idea? Not Quake / Diablo / Warcraft ;) ● pythonchallenge.com, wechall.net – CTFs are great! ● trueability.com – event for sysops ● So maybe CTF / challenge? ● Such system would have to fulfill some requirements: ● Optimization of recruitment process time ● Minimisation of the risk of rejecting good candidate ● Draw attention as very interesting (you like mindfscks?)
- 6. Let's start the ball rolling Stage 1 – simple task Stage 2 – call/social.eng. Stage 3 – challenge Application Problem: huge candidates number (>100) Target: reject not suitable cands (>80% rejections!) Target: recognition, manipulation Global Thermonuclear War ;)
- 7. Stage 1 – telnet / SMTP RFC-821/1869: HELO/EHLO ??.....?? GPG us ur CV using http://..../gpg.asc Lack of GPG knowledge :( RTFM!
- 8. Stage 1 – telnet / SMTP RFC-821/1869: HELO/EHLO my.hostname 1 trap – not server’s hostname but client’s (90% catched) GPG us ur CV using http://..../gpg.asc Lack of GPG knowledge :( RTFM!
- 9. Stage 1 – node.js ● At the beginning – pure C server. After 3am.. Node.js (simplicity) ;) ● What’s wrong with node.js? ● http://seclists.org/bugtraq/ - 0 hits ● http://osvdb.org/ - 2 hits ● http://1337day.com/, http://www.exploit-db.com/ - 1 hit ● https://nodesecurity.io/advisories - 4 hits ● Does it mean that node.js is safe & secure?
- 10. Node.js – how it works? http://magnetik.github.io/ - Event driven - Event loop - Callbacks - SPA, async, REST, Json
- 11. Node.js - threats ● no logging ● No error handling - DoS ● No configuration – “+” or “-”? ● No filters checking user-input ● JS: function as a variable ● Evil eval(code). Server-side XSS ● setInterval(code,2), setTimeout(code,2), str = new Function(code) ● Moduły npm – who creates those? ............................................________ ....................................,.-'"...................``~., .............................,.-"..................................."-., .........................,/...............................................":, .....................,?......................................................, .................../...........................................................,} ................./......................................................,:`^`..} .............../...................................................,:"........./ ..............?.....__.........................................:`.........../ ............./__.(....."~-,_..............................,:`........../ .........../(_...."~,_........"~,_....................,:`........_/ ..........{.._$;_......"=,_......."-,_.......,.-~-,},.~";/....} ...........((.....*~_......."=-._......";,,./`..../"............../ ...,,,___.`~,......"~.,....................`.....}............../ ............(....`=-,,.......`........................(......;_,,-" ............/.`~,......`-...................................../ .............`~.*-,.....................................|,./.....,__ ,,_..........}.>-._...................................|..............`=~-, .....`=~-,__......`,................................. ...................`=~-,,.,............................... ................................`:,,...........................`..............__ .....................................`=-,...................,%`>--==`` ........................................_..........._,-%.......`
- 12. Node.js – evil eval()
- 13. This way we added new functionality to the server during runtime! http://node.js/myurl Node.js – evil eval()
- 14. Node.js - npm https://blog.nodejitsu.com/npm-innovation-through-modularity Amount of npm modules in the time Amount of npm-mods/day comparison to node.js and others
- 15. Node.js – how can? ● Use frameworks: https://npmjs.org/ - carefully ● Npm modules are not validated! Check those: https://nodesecurity.io ● Watch module dependencies! ● must have: your own error handling & logging ● This is server – we need proper server security solutions: ● Monitoring – think how to monitor your app ● Control-groups – set limits for resources ● SELinux sandbox
- 16. Node.js – SELinux sandbox ●'home_dir' and 'tmp_dir' ● App can r/w from std(in|out) + only defined FDs ● No network access ● No access to foreign processes / files ● We can easily connect sandbox with cgroups :) ● Helpful: semodule -DB (no dontaudit) ● grep XXX /var/log/audit/audit.log | audit2allow -M node.sandbox ● semodule -i node.sandbox.pp
- 17. Node.js – SELinux sandbox
- 18. Node.js – how can #2 ● Freeze node.js version per project? ● Let’s read & learn: ● https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf ● http://lab.cs.ttu.ee/dl91 ● https://github.com/toolness/security-adventure ● Pseudo–configuration – set limits in your code (e.g. POST size) ● try...catch ftw ● use strict; - helps even with eval case (partially) ● Bunyan / dtrace: https://npmjs.org/package/bunyan ● node.js OS? Oh and use / build node.js packages (fpm or whatever)
- 19. Stage 2 – social engineering ● Stage’s target is to verify & check candidate’s security awareness ● Christopher Hadnagy – SE framework (2k10): ● http://www.social-engineer.org/framework/Social_Engineering_Framework ● Everyone can act as recruiter and call anyone ● Building network / connections on Linkedin is very easy ● Trust (lingo, easiness in some env: research) ● Sysop knows really much about env – he’s good target ● So one has to only get sysop’s trust and decrease his carefulness
- 20. Stage 3 - virtualization ● Our needs? ● Boot process supervision ● Console access ● Resource management ● Redundant storage ● Rescue mode for VMs ● Security by default > AWS > KVM/libvirt > XEN/libvirt > LXC
- 21. Stage 3 - virtualization boot console resources mgmt. redundant storage rescue VM security
- 22. Stage 3 - virtualization VS Performance XEN/HVM or KVM?
- 23. Stage 3 - virtualization VS We had great performance issues with XEN/HVM The winner is „hat in the red” and its PV (but with the cgroups help – under heavy load KVM is not that stable) Performance XEN/HVM or KVM?
- 24. Stage 3 – network security DMZ (Demilitarized Zone) – logical or physical partition https://en.wikipedia.org
- 25. Stage 3 – network security https://en.wikipedia.org DMZ (Demilitarized Zone) – logical or physical partition
- 26. Stage 3 – network security ● Separated, dedicated DMZ (VLAN?) for host ● No routing / communication from this DMZ with other segments ● Low – cost solutions? ● OpenWRT / DDWRT way || Pure Linux server ● 802.1Q – VLANs
- 27. Stage 3 – network security ● Network isolation on KVM host: ● Host/network bridge: L2 switch ● netfilter / nwfilter (IBM) ● By default there’s no packets isolation in the bridged network - ebtables null, no filtering ● ebtables – filtering l2– so we gain isolation ● Or virsh nwfilter-list ● allow-arp,dhcp,dhcp-server,clean-traffic, no- arp-ip-spoofing, no-arp-mac-spoofing, no- arp-spoofing, no-ip-multicast, no-ip-spoofing, no-mac-broadcast, no-mac-spoofing, no- other-l2-traffic ● L2 filtering? /proc/sys/net/bridge https://www.redhat.com/archives/libvir-list/2010-June/msg00762.html http://pic.dhe.ibm.com/infocenter/lnxinfo/v3r0m0/topic/liaat/liaatsecurity_pdf.pdf
- 28. Stage 3 –boot process, VNC ● Accessing boot process – VNC ● VNC security? SSL? Complications.. ● Maybe VNC over SSH tunnel? ● Encryption ● No certificates issues ● Every admin can easily use VNC
- 29. Stage 3 – restricted shells ● SSH tunneling requires SSH access (thank You Captain Obvious!) ● SSH access is a threat per se ● Let’s limit this SSH / shell access – use restricted shells Restricted shells by. Google ;) =>
- 30. Stage 3 – restricted shells ● Restricted shells are threat by default – unless we know how to use those! ● Under some circumstances one could escape the rshell: https://en.wikipedia.org/wiki/Rbash
- 31. Stage 3 – restricted shells ● Rbash: ● CentOSie / RHEL approved / friendly / legit ;) ● Protects from directory traversal ● Prohibits access to files via direct path ● Prohibits setting PATH or other shell env variables ● No commands output redirection ● PATH=$HOME/bin – and reconsider 2x what to put into this „bin” https://en.wikipedia.org/wiki/Rbash
- 32. Stage 3 – SSH tunnel / VNC ● We must go deeper! Candidate VM-Proxy screen / ssh tunnel VM host rshell / ibsh rshell / rbash VNC server
- 33. Stage 3 – restricted shells ● Other restricted shells: ● rssh – allows scp, sftp, rsync ● sudosh - http://sourceforge.net/projects/sudosh ● Allows saving whole user session and replay it ● One can define allowed operations for user ● Little outdated – better use sudosh3 ● Ibsh (small, fast, secure): http://sourceforge.net/projects/ibsh/
- 34. Stage 3 – control groups ● resource management in a simple way (ulimits, nice, limits.conf).. but.. ● Could you set 50 IOPS for defined process? ● What about 100Kbp/s limit for particular user? ● issues with memory–leaks in Java?
- 35. Stage 3 – control groups https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html ● Debian & RHEL friendly ● Running apps in cgroup context ● Setting cgroup context for process during runtime
- 36. Stage 3 – web application ● OpenStack? „Couple” of compliations ;) “Out of the box” – yup – I’ve heard about that ;) Could you deploy it in a few hours – securely?
- 37. Stage 3 – web application Commodore OS ???
- 38. Stage 3 – web application Commodore OS Vision FTW!
- 39. Stage 3 – web application ● Apache + mod_security ● mod_security + OWASP rules ● PHP & Python :) ● Simplicity! ● VM management with simple daemon + screen: ● while(1) do: manage_VMs(); ● And this just works!
- 40. Stage 3 – recording SSH sessions ● We have to record all sessions – also those under „screen” ● Real time recording ● sudosh3 (sudosh fork) – kinda proxy shell – great ;) ● auditd – lov-lewel tool for recording syscalls ● Asciinema (ascii.io, Marcin Kulik) – great one, but not for audit purposes ● Ttyrec – outdated: http://0xcc.net/ttyrec/index.html.en ● Ssh logging patch - outdated: http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html
- 41. Stage 3 – data security ● What if we loose any of the VMs...? Brrr.... ● Risk assesement – what would be enough for us? ● RAID1 / Mirror – “usually” is enough for a 3 – month time ● Backups – useful ;) RAID / replication are not backups... ● GlusterFS / DRBD – if you have enough resources – try it :) LVM Gluster brick KVM active host LVM Gluster brick KVM passive host replication
- 42. Podsumowanie