0507 057 01 98 * Adana Klima Servisleri
Download as PPTX, PDF•1 like•201 views
The document discusses the recruitment process at OWASP, highlighting the importance of security and candidates' evaluations. It outlines three stages of the recruitment process: simple tasks, social engineering, and virtualization, while showcasing challenges and methods to enhance security awareness among potential candidates. Various security measures and technologies, particularly concerning Node.js and data management, are also elaborated upon to improve operational security practices.
0507 057 01 98 * Adana Klima Servisleri
- 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