For the last couple of years I have been participating in various public and private bug bounty programmes including United Airlines, ING, RBS, EU or Synack. Usually these programmes are run by security-mature companies which take a lot of effort to make sure that their applications are secure. So how is that even possible that they are still vulnerable to well-known issues like XSS or IDOR which should not exist in 2019 anymore? Presentation will share information about common “inter-application” vulnerabilities encountered during testing process and emphasize the need of appropriate security testing at each stage of system life cycle. During 45 minutes long talk I will present several real-life examples of "inter-application" vulnerabilities, explain the root causes of these issues and propose steps which could be taken to avoid these vulnerabilities in the future.

1. Inter-application vulnerabilities
hunting for bugs in secure applications
CONFIDENCE 2019
@securityksl
Marcin
Szydłowski

2. TABLE
OF
CONTENTS
Introduction
Presentation background – why I’m even here?
1
3
Real life examples
Several examples of these inter-application vulnerabilities
and their root causes.
Inter-application
vulnerabilities
So what actualy are we going to talk about?
2
4 What can I do now!?
Where can I find these vulnerabilities or how can I avoid
them?
5
Q&A
In case you want to know something more

3. #whoami
• Marcin Szydlowski (@securityksl)
• Worked as a cybersecurity consultant (pentests, red team, etc.)
• Currently responsible for secure system deployment in a global
company
• Bug bounty hunter & member of Synack Red Team (rank 0x03)
• Participated in programmes such as Hack the Pentagon, United Airlines
and number of private programmes via Synack and HackerOne

4. Hunting for bugs in secure applications
• Changed company, started to participate in Bug Bounty programmes regularly
• Regularly does not mean full-time (nor part-time)
• Dark side of bug bounty programmes exists

5. Presentation background – problem
statement
How to find unique vulnerabilities in web
applications of security-mature companies in a
limited time?

6. How your pentest environment looks like?
HTTPS
test.example.comUser

7. How the production environment looks like?
HTTPS
example.comUser
mail.example.com
user.example.com
legacy.example.com

8. How the production environment looks like in
2019?
HTTPS
api.example.com
example.comUser
mail.example.com
user.example.com
legacy.example.com
Caching server/LB/WAF
OAUTH
other.example.com
S3 example.com
HTTPSHTTPS

9. Who covers the delta?
„Integration with other systems will be performed once we know our application is secure”
„Other components have already been tested by other independent companies”
„Test environment is isolated from the Internet for security reasons”
„XYZ functionality is out of scope as it is not ready yet”
„E-mail sending is disabled not to flood our helpdesk with e-mails”
„Only ZYX functionalities are in scope”
Integration testing to the rescue?

10. What is in scope of integration testing?
Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase in software testing in
which individual software modules are combined and tested as a group. Integration testing is conducted to evaluate
the compliance of a system or component with specified functional requirements.

11. Integration testing presented on a Venn
diagram
People who
understand
system A
People who
understand
system B
Pentesters
(security people)
People involved in
integration testing

12. Integration testing – reality kicks in
People who
understand
system A
People who
understand
system B
Pentesters
(security people)
People involved
in integration
testing

13. Am I exploiting the technology or the
process?
• Web application security testing covers only specific components of the system as it is
often performed on isolated or non-fully developed environment
• Pentesters often do not understand the business process behind the application
• Various applications (system components) are tested by various teams (or even
companies)
• Responsibility for integration testing is often blurred
• Security is not the first priority of integration testing
???
PROFIT!!!
Acceptance rate - 44%
27 unique vulnerabilities reported in 11 months
Probably testing for less then 5 hours/week on average

14. Inter-application vulnerabilities – the
definition
Vulnerabilities, which require playing with at least two
different systems (or system components) to be exploited
successfully.

15. Case #1 - Story of a desktop application
• Major international company
• Set of web applications in scope
• No vulnerabilities identified in the last couple of months
• Google recon identified that users e-mail addresses are disclosed via Google searches as they
are transmitted in GET parameter
• It was not possible to identify that particular endpoint during application walkthrough
Some other application component must exist

16. Money for nothing and XSSes for free
• Desktop application of that vendor publicly available for download after registration
• Most of the functionalities were not resulting in any requests being sent to the web server,
but...
• License renewal and forgot password functionalities resulted in HTTP requests with the
parameters never encountered before.
• Two XSSes with <script>alert(1)</script> payload right away (Bounty! X2).
• Forgot password mechanism - root cause of e-mail address disclosure identified (Bounty!)
• More was yet to come...

17. Fun part begins
• So how this license renewal mechanism actualy works?
POST /license.aspx
Host: renewal.example.com
ID=123456
renewal.example.comUser
Here is your license number!
AVX123ZSAJ1213124
I’m redirecting you to
buy.example.com
And by the way here you also have license
numbers of other users as this is clearly
vulnerable to IDOR...
This is my license number
and I’m authenticated as
Marcin I want to renew my
license.
buy.example.com
Redirecting you to payment
page where you have info on
subscribtion days left

18. What confidential actualy means?
• So we have a huge number of license IDs – potentially all of them.
• Do not mix license IDs with license keys.
• Who really knows if some data is confidential? What makes it confidential?
• License numbers allows you to get more info on product type and number subscribtion days
left
• Not really confidential data :(
• But...

19. Inter-application dependency kicks in!
• There is one more web application of the same vendor, which allows (surprise surprise) to
renew licenses ☺
• So you are authenticated in the application, you provide your license ID and you are
redirected to the very same payment page.
• But what happens when you are not authenticated?
POST /license.aspx
Host: renewal2.example.com
LicenseID=AVX123ZSAJ1213124
renewal2.example.comUser
You need to authenticate. Let
me redirect you to the login
web page. I will provide the
e-mail address associated with
this LicenseID to speed up
authentication process.
• Insecure direct object reference leads to disclosure of e-mail addresses of all customers
(Bounty!)

20. We are not done yet.
• So we are redirected to authentication web page and our e-mail is automatically submitted.
How does it work?
renewal2.example.com
User
You need to authenticate. Let
me redirect you to the SSO
web page. I will provide e-
mail address associated with
this LicenseID automatically.
GET
/redirect.aspx?email=ksl@test.
com&otherparameters...
Host: renewal2.example.com
302 – let me redirect you to
sso.example.com?code=base64st
ring (not decryptable)
sso.example.com
Login page with your email

21. We are not done yet.
• So we are redirected to authentication web page and our e-mail is automatically submitted.
How does it work?
renewal2.example.com
User
You need to authenticate. Let
me redirect you to the SSO
web page. I will provide e-
mail address associated with
this LicenseID automatically.
GET
/redirect.aspx?email=”><script
>alert(1)</script>&otherparame
ters...
Host: renewal2.example.com
302 – let me redirect you to
sso.example.com?code=base64st
ring (not decryptable)
sso.example.com
Login page with your email.
XSS in e-mail field! Reflected XSS on login page (Bounty!)

22. Summing up
• 3 Reflected Cross-Site Scriptings on critical subdomains
• One IDOR vulnerability leading to complete disclosure of customer database (e-mails)
• Incorrectly set indexing protection leading to disclosure of user e-mails in Google
5 bounties for 5 vulnerabilities identified only by downloading a single desktop
application
Identified XSSes were exploitable with basic XSS payload - <script>alert(1)</script>
4 out of 5 were well-known vulnerabilities - listed in last 3 editions of OWASP TOP
10...

23. Case #2 - Single-sign on, multiple XSSes
• Major web page
• Set of web applications used for different purposes (subscriptions, estore, auctions, etc.)
• Payouts were offered only for high/critical vulnerabilities (SQLi, RCE, Persistent XSS)
• WAF in place for certain subdomains

24. That tricky registration mechanism
• Number of applications in scope of program allowed to create account in the application
• Account created in any of these web apps was valid for all the other applications in scope
• User e-mail address was published in each of these web applications – in most cases it was
encoded
• Filtering mechanism existed during registration, emails address needs to be provided in a valid
format
• But what actualy is a valid format for e-mail addresses?

25. What actualy is a valid e-mail format?
• E-mail address format is defined in RFC 5321 and RFC 5322
• Better explained in Wikipedia
• This makes ”<script>alert(1)</script>”@gmail.com address completely fine from the RFC perspective
• Most of the web pages does not allow to register yourself with these addresses.... But some do ☺

26. Let the persistent XSSes begin!
• One of these web pages in scope allowed to register yourself with
”<script>alert(1)</script>”@gmail.com address, however it encoded malicious characters
properly
• However, some other web page in scope did not allow funny e-mail addresses, but output
encoding mechanism was not there
• Remember that tricky registration mechanism?
???
• Most likely the only impacted person would be the account owner...
• ... but you never know - Persistent XSS in Profile Overview section (Bounty!) ☺
PROFIT!!!

27. Moar XSSes!!!
• Seems that certain well-known applications which are often integrated with web pages also
allow to use „quoted” e-mail addresses
• Application in scope supported PayPal payments
• And PayPal supported „quoted” e-mail addresses ☺
Let me purchases that item
store.example.comUser
How do you want to pay?
PayPal.
And here is my PayPal account which is
”<script>alert(1)</script>”@gmail.com
OK, mail address seems valid,
I’m redirecting you to PayPal web page

28. Moar XSSes!!!
paypal.comUser
I can see that you are
”<script>alert(1)</script>”@gmail.com
and you are coming from store.example.com.
Authenticate yourself to pay with PayPal.
Changed my mind, I’m cancelling the payment.
No worries, let me redirect you back to store.example.com

29. Noone expected the scope change!
• store.example.com has a full list of successful/unsuccessful transactions with details about
success/failure
• PayPal e-mail address used during transaction is presented in transaction details and is not
encoded
???
• Bug Bounty programme rules changed in the meantime (probably after i got paid for the
1st XSS)
• Persistent XSSes which have no clear impact on other users were excluded from program
scope 
NO PROFIT!!!

30. Case #2 – Summary
• 2 persistent XSS identified and 1 bounty received for simple vulnerability
• Excellent example why input filtering might not be enough to secure your web application
• It also seems that this company does not rely on pre-approved code snippets for e-mail
verification, as mechanism worked differently between applications
• Update [May 2019] – 3 persistent XSSes in e-mail address identified on 3 well-known web
pages for travelers – total bounty 2130 $

31. Case #3 – E-mails, e-mails everywhere
• It is more series of cases related to e-mail sending functionalities
• Web applications in scope? Pretty much everything – ecommerce, airlines, FMCG,
cybersecurity
• Thing in common? All of them were sending emails from the application to the end user

32. Case #3.1 – Me, myself and I
ecommerce.com
Bob
I want to Chat with Alan! POST
Msg=Chat message:Hello World!
Alan
Message from: Bob
<gasr23basd1axne@
ecommerce.com>
Hello World!
Reply to: Bob
<gasr23basd1axne@
ecommerce.com>
Hello Bob!
Chat with Alan
Bob: Hello World!
Alan: Hello Bob!
Just by knowing Bob’s temporary e-mail address i can spoof Alan’s messages.
Bob’s temporary e-mail address is not visible in the web browser, but it is visible in JSON
responses...
I can negotiate prices and contract terms with myself, non-repudiation is being affected
• Well-known international web page
• Couple of months without vulnerability reported

33. Case #3.2 – Mail content spoofing
ebanking.com
Harry
I want to steal Bob’s password!
POST /reset.php HTTP/1.1
Host: evilebanking.com
email=bob@test.pl
This is a password reset e-mail. To
reset your password please access:
https://evilebanking.com/newpasswo
rd?Token=H81nasj3as73jmd
Bob
Hey! That is an e-mail from my bank!
evilebanking.com
User: Bob
Password:Secret12#

34. Insecure HTTP headers
• This is not just about e-mails. Spoofing text message (SMS) content via host header
modification was identified.
• It is not just about Host header. Other cases of spoofing were identified (e.g. X-Forwarded-
Host header, or X-Akamai-Original-Url header)
• Summing up, I reported these 5 times, but 3 times they were duplicates
• The more fancy header, the less chance it has already been reported by someone

35. Case #3.3 – Spidering does not work
anymore
• Applications send multiple e-mails (newsletters, password reset, account activation,
notifications)
• URLs (functionalities) which are embeded in these e-mails are often vulnerable to numerous
attacks
• „Unsubscribe” functionality – vulnerable to reflected XSS (Bounty!)
• IDOR in „Newsletter settings” functionality leads to unauthorized data modification
(Duplicate)
• „Welcome” e-mail contains URLs with parameters never encountered before (Bounty!)
• Hyperlink included in e-mail vulnerable to IDOR and ultimately leads to account takeover
(Bounty!)
• Password reset e-mails contain URLs. User e-mail address is sent in GET parameters.
Google indexes these URLs and e-mail values (Bounty! X2)

36. Bug Bounty Hunter/Pentester – Quick wins
• Register an account in your application with ”<script>alert(1)</script>”@gmail.com
• Go to „My profile” section or equivalent
• PROFIT!!!
• Subscribe to all newsletters, notifications, promotions, gift cards.
• Create new account, forget password, restore password, unsubscribe, delete account.
• Check received e-mails for hyperlinks with fancy parameters. Look for XSSes, IDORs.
• PROFIT!!!
• Register an account
• Initiate password reset request
• Substitute Host header value with some other domain name.
• Add X-Forwarded-Host and X-Original-URL headers with some other domain name.
• Check received e-mails for spoofed hyperlinks
• PROFIT!!!

37. How to avoid these issues? - Basics
• During testing process analyze all the application interfaces and non-standard way of
inputting data
• Make sure that your integration tests cover security aspects such as input validation
• Make sure to follow defense-in-depth principle (e.g. by implementing both input filtering
and output encoding whenever possible)
• Make sure that your TEST environment is as similar to PROD environment as possible and
that scope of your security tests include all of the system components and functionalities.
Pay special attention to:
• Email sending functionalities and email messages
• Account creation and password reset process
• Authentication using 3rd party services (Google, Facebook, etc.)

38. How to avoid these issues? - Advanced
• Ensure that you security testing team:
• understands the business processes supported by the application
• is aware of all interfaces with the other applications and has a sufficient support to
perform security scenarios during integration tests
• has a good understanding of the entire tested ecosystem
• Regularly perform Google dorking to identify any cases of unintentional public access to
sensitive data or functions
• Analyze any cases of cross-system data dependencies which may lead to obtaining
sensitive information by unauthorized individual. Implement cross-system segregation of
duties wherever possible.

39. More thoughts on that?

40. Q&A
Inter-application
vulnerabilities
hunting for bugs in secure
applications
@securityksl
Marcin
Szydlowski