Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Viewers also liked
Viewers also liked (16)
Similar to Magento Security and Us
Similar to Magento Security and Us (20)
Recently uploaded
Recently uploaded (20)
Magento Security and Us
- 1. Magento Security and Us Lee Saferite
- 3. Introduction • Started programming in the 80s (Yikes!) • I have been: • Unix Admin • DB Admin • Network Engineer • Ecommerce developer since 2004 • Magento developer since 2008 • Senior Developer at AOE since July 2013
- 4. Historic Exploits on Magento • Failed access control restriction • Remote code execution • File disclosure • Flawed cryptography • Session hijacking • Trojans • Bastian Ike (@b_ike) – AOE’s resident expert
- 5. Base Server Security • Limit the attack surface – Do NOT run other software on ecommerce server – Only open ports needed for server operation – Use a bastion host to restrict SSH access • External log file storage • Chroot and privilege dropping • Backup security
- 6. Server users and permissions • Web server should run as a user with very limited permissions • Web server user should not have a login shell • Deployments should run under a different user • Site code should be read-only • /var and /media – only writable by web server user – should not allow running scripts
- 7. Users and Roles • Defined granular permissions for modules • Principle of Least Privilege (POLP) • No shared accounts • Strong passwords and password rotation rules • Admin action audit logs • Employee exit procedures
- 8. Code Security Audits • Never trust a third party module without a security review • Be very wary of encrypted and obfuscated code • Never allow a module to include a remote self-update • Watch out for information leakage via phone-home features • Module installation from Magento Connect via admin downloader is evil • Code repositories and commit hashes (or signed revisions) are your friends
- 9. Very Bad Things™ • Magento Connect via Admin • Remote update capabilities • Composer without commit hashes • Encoded files • Obfuscated files
- 10. Incident Response Plan • You will be compromised. • Advance persistent threat – You are a high value target as a financial transaction processor – They want in and will keep trying until they finally find a flaw • Written action plans for major compromise situations – Code modifications – Stolen data – Site lockout
- 11. Demonstration • Simple remote file dump on 1.7.0.0
- 12. Recap • Website security is multi-layer • Secure your server • Review all code you run on your site • Don’t share a server with other services that could provide an entry point • Plan and document your incident response
- 13. Questions No meme for you!
- 14. I in the USA AOE Inc. 700 Airport Blvd, Suite 280 Burlingame, CA 94010 USA Phone: +1 415-230-0697 E-Mail: lee.saferite@aoe.com Twitter: @LeeSaferite
Editor's Notes
- Magento security is an often overlooked and critical issue to any online store. Improper server configuration, insecure modules, and obfuscated code are just a few of the issues. We as developers, agencies, and merchants, have an obligation to the customers to secure our systems and personal data. I’ll cover a few of the basics of a secure Magento deployment and recommend some best practices that can help prevent and mitigate the inevitable attacks you will encounter.
- Open Source web development agency focusing on Magento and Typo3 development. Primary office in Weisbaden Germany Satellite offices in Zürich Switzerland and Burlingame California
- I used to be very active on the Magento forums and IRC so some of you may know me from there. I’ve also be very vocal about several issues in Magento over the years, one being security. Honestly I hope every one of you walk away from this thinking to yourself that I didn’t tell you anything you don’t already know and do. If that happens, I’ll be happy. This is a very light topic as I’m mostly interested in raising awareness of the subject and encourage you to do a deep dive yourselves.
- Magento historically has not been very transparent about security issues, but they have gotten better over time. Security patches are not back-ported to old releases leaving many older stores vulnerable. Bastian is scary good at finding vulnerabilities. We’re all lucky he’s on the right team.
- Using WordPress on the same server you use for Magento is a tragedy in planning. You should only have 80 and 443 visible to the outside world on your web server. Accessing your e-commerce server via SSH should bounce through a bastion host on a different IP and preferably different subnet. Real-time delivery of log entries is best. Be aware of sensitive information in your logs and act accordingly. Docker is a nice tool for limiting the attack surface.
- The Apache/nginx/PHP-FPM server should have very restricted permissions This user should not have a login shell that would allow a remote login Automated deployments should be done using another limited user The site code should be read-only to prevent malicious code modifications The only writable parts of the site should be /var and /media and both of those should prevent scripts from running. This will mitigate any exploit that allows writing random files to those two locations.
- Every module should have defined ACL permissions and they should be granular enough to follow the Principle of Least Privilege . The Principle of Least Privilege protects you from bad actors inside the company or even just accidents. Roles are cheap to create and should be used to model the permissions of every job position on the site. Never let your admin users share accounts. This is circumventing POLP and makes any admin action logging useless. Either use EE and the built-in admin action logging or a third party module that provides the same information. This information is invaluable when tracking down the source of an exploit. Have written employee exit procedures that revoke their access to all systems and changes all shared secrets.
- Don’t trust third party code. Ever. I trust Boris, but I would still review his code. A module doesn’t even have to be intentionally bad, but could just have a bug that exposes your system to attack. If you cannot read the source code on your store, how do you know what it’s doing? How can you debug it? How can you be sure the vendor isn’t silently collecting CC details and exfiltrating them via bogus DNS queries? Allowing a module to update itself via the admin backend or automatically is a giant security hole. You’ve just extended your security perimeter to include the vendors systems. If they update and introduce a critical bug then you have no formal review and no idea it has happened. Modules that phone home send a variety of information to their server some of which could be deemed sensitive. This just adds more ammunition to an attacker if the vendor is compromised. Using the admin module installer is evil. You have no ability to formally review the code first. You also, in many cases, have no way to uninstall the module. When depending on external code, using commit hashes or signed releases will protect you from hidden code changes.
- Every site is a target. E-commerce sites are even bigger targets. You are under an advanced persistent threat. Attackers never sleep and run automated attacks that poke at your site constantly. You MUST plan ahead. Knowing that you are a target you need to have plans in place for the different scenarios.