Applications are no longer working in an isolated environment governed by synchronous behavior involving communication with the target (self) only. Instead, applications are well integrated with various different sources and channels in the era of Web 2.0, Mobile and HTML5. Also, SOA (Service Oriented Architecture) with third party API integration has added new communication channels to the application layer. As shown in the figure below, there are few side channels for communication for applications. They serve several different purposes like two factor authentication, password reset, information validations, third party data integration, sync option for mobile apps etc.
This new set of channels opens up integration challenges both at architecture and implementation stages. Hence, it ends up adding weaknesses and vulnerabilities at the application layer and possible opportunities to exploit.
Also, it is important to note that simple automated scanners or tools do not detect these vulnerabilities. It needs meticulously crafted observation, behavior analysis, access to side channels etc. to discover this set of vulnerabilities. Doing manual observation and assessment only can expose and reveal some of these vulnerabilities.
This new set of channels opens up integration challenges both at architecture and implementation stages. Hence, it ends up adding weaknesses and vulnerabilities at the application layer and possible opportunities to exploit.
Also, it is important to note that simple automated scanners or tools do not detect these vulnerabilities. It needs meticulously crafted observation, behavior analysis, access to side channels etc. to discover this set of vulnerabilities. Doing manual observation and assessment only can expose and reveal some of these vulnerabilities.
Figure 1 – Side Channels for Web
Applications
Let’s see some of these issues, which we have discovered during our recent manual assessments across application verticals with examples.
Email Channel
Consider an application using email as a channel to communicate with users in asynchronous off-line mode. Hence, certain features and functionalities would send emails to the user with some information. This information goes over a side channel and it is not a typical synchronous scenario. Hence, if the scanner is not accessing the content of mail and acting on it, then a vulnerability may get missed in that part.
An example of this is an application having “forgot password” functionality. When a user clicks on it, at that point the application sends a link for the user over email and that particular link is vulnerable and can be used to access or reset other user’s passwords with tampering a parameter (say “id” – sequential).
There are several other use cases across verticals like financial, health care etc. using the email channel to communicate with the application user and they can be vulnerable to this set of attacks. One needs to access the content of email and evaluate its impact from a security standpoint.
SMS/Text-Message Channel
Text-messaging is another interesting side channel for application communication and access. Applications are using various tokens for second factor authentication and validating over web applications. For example, banks are using One Time Password (OTP) for transactions or portals are using tokens for authenticating users on the portal and so on.
These tokens are integrated into the web application workflow and in certain cases open up vulnerabilities. For example, consider an application running on 3 step authentication processing for clearing a transaction and validating tokens. One can analyze the work flow and when a token is passed in the second step and sends a response back to the browser, one can trap the response and modify “FAIL” to “SUCCESS”. Now this will go to step three and at this step there is no other validation in place. Hence, a user can actually get access and force a transaction even not having the right token. This is clearly an asynchronous and manual leveraged attack. Automated testing where testing is synchronous by nature can’t perform these attacks.
Mobile/APIs Apps
Mobile applications are using different API based interfaces to access web applications. It is possible that there is a single application which gets accessed by different interfaces like web, android, and iOS based mobile applications. For example, a “todo” application often allows the application to be accessed by a browser through mobile, plug-ins created for Chrome/Firefox as well as an iOs/Android mobile application. This particular application keeps doing “sync” between all these different application components. Mobile applications are using APIs to do constant syncing of tasks. Now this channel becomes side channel communication for the application layer and there could be interesting vulnerabilities in using push or pull for sync function. The token used can be tampered and can allow access to other user’s todo tasks.
Conclusion:
Side channel communication attacks are going to be a reality and it is imperative to have these communication channels along with their integration to the main web applications analyzed thoroughly. This area, in many ways, is untouched and under-assessed during pen-testing. Automated scanners and tools cannot co-ordinate with asynchronous and side channels. The vulnerabilities involved can be of traditional types like SQL injection or abuse of business logic.
Email Channel
Consider an application using email as a channel to communicate with users in asynchronous off-line mode. Hence, certain features and functionalities would send emails to the user with some information. This information goes over a side channel and it is not a typical synchronous scenario. Hence, if the scanner is not accessing the content of mail and acting on it, then a vulnerability may get missed in that part.
An example of this is an application having “forgot password” functionality. When a user clicks on it, at that point the application sends a link for the user over email and that particular link is vulnerable and can be used to access or reset other user’s passwords with tampering a parameter (say “id” – sequential).
There are several other use cases across verticals like financial, health care etc. using the email channel to communicate with the application user and they can be vulnerable to this set of attacks. One needs to access the content of email and evaluate its impact from a security standpoint.
SMS/Text-Message Channel
Text-messaging is another interesting side channel for application communication and access. Applications are using various tokens for second factor authentication and validating over web applications. For example, banks are using One Time Password (OTP) for transactions or portals are using tokens for authenticating users on the portal and so on.
These tokens are integrated into the web application workflow and in certain cases open up vulnerabilities. For example, consider an application running on 3 step authentication processing for clearing a transaction and validating tokens. One can analyze the work flow and when a token is passed in the second step and sends a response back to the browser, one can trap the response and modify “FAIL” to “SUCCESS”. Now this will go to step three and at this step there is no other validation in place. Hence, a user can actually get access and force a transaction even not having the right token. This is clearly an asynchronous and manual leveraged attack. Automated testing where testing is synchronous by nature can’t perform these attacks.
Mobile/APIs Apps
Mobile applications are using different API based interfaces to access web applications. It is possible that there is a single application which gets accessed by different interfaces like web, android, and iOS based mobile applications. For example, a “todo” application often allows the application to be accessed by a browser through mobile, plug-ins created for Chrome/Firefox as well as an iOs/Android mobile application. This particular application keeps doing “sync” between all these different application components. Mobile applications are using APIs to do constant syncing of tasks. Now this channel becomes side channel communication for the application layer and there could be interesting vulnerabilities in using push or pull for sync function. The token used can be tampered and can allow access to other user’s todo tasks.
Conclusion:
Side channel communication attacks are going to be a reality and it is imperative to have these communication channels along with their integration to the main web applications analyzed thoroughly. This area, in many ways, is untouched and under-assessed during pen-testing. Automated scanners and tools cannot co-ordinate with asynchronous and side channels. The vulnerabilities involved can be of traditional types like SQL injection or abuse of business logic.
Article by Amish Shah & Shreeraj Shah