Security.txt Magento module

With the recent release of Magento 2.4.0 open source and commerce, you can find a brand new module under vendor/magento/ directory named module-securitytxt. You may find it a small module, but you will amaze to know the importance of that module in terms of the security. Two years ago, I was reading the blog post from Troy Hunt and other reputed people in the security industry about this new file called Security.txt which allows security researchers to report security vulnerabilities to the right people in the organization. I am amazed by this, because of my personal experience in not getting hold of right people in the organization whenever I find any security vulnerability on any website. I found security issues on numerous websites before reading about security.txt, and tried many ways to reach out to the people in the organization in an effort to get a hold of someone who is responsible to fix this. I sent messages to the people working in that organizations via LinkedIn, Twitter DM, tech email addresses I could find from whois, customer service, etc.. But, zero replies!! Of course, who would want to reply to such scary messages about their website right?!

Security.txt to the rescue

As soon as I learned about security.txt, I read many articles and checked its official website https://securitytxt.org/ to understand how it works. I really liked the concept, and thought to make it available to everyone in the very platform I love, Magento. I built Magento 2 module to allow administrators to input and store all the security contact details and signature in the database, which can be then easily viewed at the standard locations https://website.com/.well-known/security.txt and https://website.com/.well-known/security.txt.sig

Security.txt files have been adopted by many big players in the industry like Google, GitHub, LinkedIn and Facebook.

Listen to the community

Right after building the module and pushing it to my Github securitytxt repo, I was gathering feedbacks about this new security standard from the Magento community. I asked many well known people in the community, at various events and Dev Exchange, to understand its pros/cons from other people’s perspective. Unsurprisingly, many were in favor of this. There were some people against having a dedicated module for this, because Magento already has many modules that not every merchants need but they still have to keep it because… it comes out of the box. Totally valid point. However, this is a security module and Magento 2 was already infested with security bugs in the early days and not to mention security bugs that gets introduced via third-party extensions. With the modular approach of the securitytxt, it is very convenient for any merchant to enable and input security contact details and save right from the admin, which hardly takes 2 minutes! I do not know why anyone would want to disable any security module tbh. Before the module, there were hardly any merchants who had uploaded security.txt file on their server, even though the argument was it is the easiest approach so why to introduce a module for that. Ultimately, reward outweighed the risk and it was decided to ship this module in the core bundle.

I presented security.txt’s importance in various meetups last year and gathered feedbacks from the event attendees as well.

Continue reading »

#MagentoImagine2019 Dev Exchange Recap – Make Magento more secure

Magento Imagine 2019 Dev Exchange

This year Magento Imagine conference was amazing, around 3,500 people from around the world attended the event which was held at Wynn, Las Vegas. I met many people whom I already knew, and many more whom I never met before in real life but interacted on social media and forums.

I hosted a table at Dev Exchange around Magento security, which was co-hosted by Pablo Benitez from eBizmarts. Piotr Kaminski and Steven Zurek participated from Magento/Adobe’s side. Talesh Seeparsan took all the notes and contributed to the discussion during the talk. Other people that joined the table from Magento and community were Igor Miniailo, Igor Gorin, Georgiy Slobodenyuk, Lee Saferite, Manish Mittal, Jeanne, Scott N and Shilpa M. Everyone participated in the discussion and gave their valuable feedback on the topics we discussed, overall it was very productive.

There were 4 main topics we discussed at the table:

1. Extension developers write secure code

With the proactive and nimble approach Magento has taken to core security, many time agencies and merchants find external 3rd party extension makers have not put in as much effort. How can we encourage their developers to take a more secure coding approach? Can Magento community maintain secure coding practices document like technical guidelines, security? Validate code using a tool like PHP CodeSniffer? What solutions already exist that we can rely on? What processes already exist that we can implement?

Static Scanners / RIPS:

Third party code checking and code scanning is a complex process. RIPS work for some paths, they are also working on improving the support. We can add Regular Expressions to the old open source versions as well. However, we have to do lot of work to deal with the false positives because they don’t directly support Magento.

Dynamic Scanners:

Probably Dynamic Scanning is the better idea. Example, using OWASP Zap to test input fields of extensions. There are current efforts to get an easy to set up OWASP Zap fuzzer for Magento Extension makers.

There is a danger of reporting error in extensions without understanding the value of the error or making it easy to act on the error. Example, using tools that just dump a PDF of all the errors versus categorizing and ranking problems and putting them into bug tracker. We should have documentation of recommended fixes for the types of errors dynamic scanning provides.

Vulnerabilities in extensions:

A lot of extension providers are not prepared for a vulnerability in their extension. There are a few common problems with their approach. The problems we find with them, they are:

• Not fixing vulnerabilities and ignoring input from developer community, or
• Fixing vulnerabilities silently and not notifying their customers, or
• No way of notifying their customers of a new version with a fix.

There should be a process for responding to security vulnerabilities if extension makers want their extensions to be on the Marketplace. There should be consequences instead of enforcement when dealing with extension makers with vulnerabilities.

Marketplace vs non-marketplace extensions:

Unfortunately, most of the problems that we see are in extensions that are not from Marketplace, therefore enforcement of security policies may have the unintended consequence of reducing the number of extensions on the Magento Marketplace. One possible solution to extensions not on marketplace is that there may be a warning in Magento if it is code matched to an extension that is on the marketplace. This works for vendors that sell the same extension on Marketplace and on their own site.

One of the driving reasons for buying extensions from outside the marketplace is because updates from the Marketplace are too slow. The process is improving though.

It would be good if the marketplace extensions page would show the version that is on the Marketplace and show which past versions may be vulnerable.  Continue reading »

Magento Imagine Dev Exchange 2019

Magento Imagine 2019 is just 2 weeks away, I cannot wait any longer now! This year would be crazy for me, as I am participating in Contribution Days as a Maintainer that happens on Saturday and Sunday before the conference, and also hosting a Dev Exchange table after the conference on Wednesday. Also, this would be my first Imagine from agency side, so things would be different.

As many of you know, I have advocated Magento Security for quite a while now. From submitting core security bugs to adding an entire Security topic in the Magento 2 Professional Developer Plus certification, I realized there is many more things to do. This year I am going to host Dev Exchange where I will share my security ideas and also get ideas and feedback from the community. One very important thing that we would address this year is third-party extensions security. Pablo Benitez, CTO at eBizmarts, will join me bringing in business perspective when talking about third-party extension security. Talesh Seeparsan will bring his past Dev Exchange experiences on security and help us in guiding and noting down all the ideas and feedback that we would discuss with all the participants.

If you are coming to Magento Imagine and would stay little late on Wednesday, please stop by our Dev Exchange table and join the conversation. Here is the topic and details we submitted for Magento Imagine Dev Exchange 2019:

Do you have ideas to make #Magento more secure? Are you interested in participating on security-related discussion at #MagentoImagine? Then please vote/comment here (deadline 4/26) and stop by our DevExchange table https://t.co/ZNoLSwScrH. cc/ @_Talesh @centerax @foomanNZ @ext_dn pic.twitter.com/eGS0vF8P6R

— Kalpesh Mehta (@kalpmehta) April 25, 2019

Continue reading »

Magento: Multiple security vulnerabilities in Aheadworks Follow up Email extension

IMPORTANT: If you are using this extension in any of the Magento store, please patch or upgrade it immediately if you have not done it yet. You can find more details on the affected versions and patches here:
https://blog.aheadworks.com/2016/10/security-issue-follow-up-email-vulnerability/
https://blog.aheadworks.com/2016/10/follow-email-security-patch/

While modifying Aheadworks follow up extension on our store to meet our specific requirements, I discovered multiple security vulnerabilities in the extension. As the vulnerabilities were pretty serious, I immediately sent my discoveries to Magento team which they promptly sent to Aheadworks team. Aheadworks was quick enough to fix the vulnerabilities and rolled out the patches.

Link of the extension in Magento Marketplace:
https://marketplace.magento.com/aheadworks-follow-up-email.html
It allows store owners to send automated emails to customers who had abandoned their cart.

All the below vulnerabilities were found in the extension.

1. SQL injection
2. Directory Traversal vulnerability
Attacker can traverse to any directory on the server. In earlier PHP versions (prior to 5.3.4), attacker can read any file on server including /etc/passwd
3. Unrestricted Directories creation
Attacker can create any number of directories and subdirectories with their desired name wherever web server has permissions

I will not disclose any technical details and PoC of the vulnerabilties here to prevent wild exploits on Magento websites having this extension installed.

Timeline:
Oct 6, 2016 – Discovered the SQL injection vulnerability
Oct 6, 2016 – Emailed the vulnerability to Magento security and marketplace team
Oct 7, 2016 – Emailed the vulnerability to Magento team
Oct 7, 2016 – Magento forwarded my discoveries to Aheadworks team
Oct 11, 2016 – Aheadworks released new version 3.6.6 and patch for older versions of the extension
Oct 25, 2016 – Found further vulnerabilities on the same controller action, this time Directory Traversal and Unrestricted Directories creation vulnerabilities
Oct 25, 2016 – Emailed the details to Magento team, they promptly notified to Aheadworks team
Oct 27, 2016 – Fixed the vulnerabilities in new version 3.6.7 and released the patch for older versions