Nov 1, 2018

Oct 1, 2018

Subdomain Takeover via Shopify Vendor ( blog.exchangemarketplace.com ) with Steps





Subdomain Takeover via Shopify Vendor ( blog.exchangemarketplace.com )


Program : Shopify

Domain : exchangemarketplace.com
in Scope : yes it belong to shopify 

exchange.shopify.com = exchangemarketplace.com
Bounty : Not eligible for bounty!
*****************************************
I was using aquatone but it show me the subdomain and didn't show me that vulnerable to subdomain Takeover vulnerability !!
when I go directly to 
blog.exchangemarketplace.com
I found it asking me to connect the domain to my shopify Store !
Shopify team was fast response triaged and fixed the report in 15 min from triage 


****************************
Takeover steps 
1) create your free trial account of shopify store 
2) now you have a free account you just need to add your vulnerable subdomain from here 
https://your-shop.myshopify.com/admin/settings/domains
and click on ( Connect existing domain )
3) Add your vulnerable subdomain and click on verify ( connect )
it will be like this poc
4) wait minute and now when you enter your shopify store url 
it will redirect to vulnerable subdomain
*********************************
My disclosed report on Hackerone

Sep 11, 2018

Subdomain Takeover via campaignmonitor








Subdomain Takeover via Campaignmonitor.com
was in Private Program on BugCrowd

what is createsend.com dns ?
its a dns service Belong to campaignmonitor.com
if you create an account on campaignmonitor 
this will give you a subdomain on createsend.com

companies count on Campaign Monitor for email campaigns
So campaignmonitor is only for emails 

*****************************************************************
Steps to subdomain Takeover example 
*****************************************************************
When I go to 
example.site.com 
i found the site like this pic


I notice that subdomain 
example.site.com 
is alias to 
testexample.createsend.com


This mean the domain plan is expired on campaignmonitor
and ready to reactive on another email 

1) So I created an account on campaignmonitor.com
and choose any name
name here i mean an  example.createsend.com

2) After this you need only to add the subdomain of takeover
By going to 
example.createsend.com/account
then 
example.createsend.com/account/customize

Then Just Choose a Custom domain 

example.createsend.com/account/customize/customdomain/manage

3) add your vulnerable subdomain example.site.com
Then Click next 
wait 1 min and the setup will be verified

Congrats 😉
 4) Now when you go to  example.site.com
its will show your example.createsend.com

Takeover Steps is now finished
****************************************************************
Now when anyone go to example.site.com 
it ask him to login to Campaign Monitor
yes as I said at first Campaign Monitor is only to manage emails and Subscribes 

Now if you need to create a small Page Show 
you will only create a Subscribes Page 

Go to this Path

https://example.site.com/templates/create

You can Upload your subscribe page or choose from the templates on the site

example like mine 



***********************************************************************
Reward was 900$
fixed in 10 min from report 
*****************************************************

Aug 29, 2018

Reflected XSS in Django REST Framework Api at MapBox Subdomain








Reflected XSS in  
Django REST framework API at
 MapBox Subdomain 


Bounty : 500 $
Program : Mapbox
subdomain : osmcha.mapbox.com

******************************************************************

While I was testing osmcha.mapbox.com 
I've found that Django REST framework API is Available for all Users 
( i don't mean admin panel I mean the normal paths )

So I start testing this /changesets/ path 
but i admit its hard to find a bug in Django Api
https://osmcha.mapbox.com/api/v1/changesets/


I notice that there is some Parameters 
https://osmcha.mapbox.com/api/v1/changesets/?page=1&page_size=75&date__gte=2017-07-01

so i Started to test it 
The affected Parameter was date__gte=
its accept any payload to make XSS 

Poc was 
https://osmcha.mapbox.com/api/v1/changesets/?date__gte=%27%22--%3E%3C/style%3E%3C/scRipt%3E%3CscRipt%3Ealert(1)%3C/scRipt%3E&format=json&page=2&page_size=75


**********************************************


Aug 28, 2018

Reflected Swf XSS at ( https://plugins.svn.wordpress.org )










Reflected Swf XSS at 
( https://plugins.svn.wordpress.org )

Program : Wordpress
Vulnerability    :   XSS
Bounty  : 350$ 

Affected files 
video-js.swf

moxieplayer.swf

Description 

https://plugins.svn.wordpress.org website is for downloading Plugins 
So all Swf files or PHP are not loaded on the websites
All files are Download not loaded
Except  
video-js.swf

moxieplayer.swf
Are loaded normal on the website !

Poc : 
https://plugins.svn.wordpress.org/1player/tags/1.3/players/video-js/video-js.swf?readyFunction=alert(%27Hello%27)
https://plugins.svn.wordpress.org/agile-video-player/trunk/js/plugins/media/moxieplayer.swf?url=hekimuso1973.xsl.pt/723.flv






Aug 9, 2018

My Disclosed Report about Basic auth Api details at Reverb.com












Program   : Reverb.com
Bug Type : Information Disclose
Bounty     : 100$
Disclosed report : https://hackerone.com/reports/367581 

Description 

The Bug was about an Api Key ( Username + Password )  was found in Open Source for Reverb in a Disclosed Report ( 351555 ) belong to Reverb Company and Hosted in cloudinary.com 


I give a try if the key was work So I reported it again 

Poc was

 1) goto 


2) It will ask to enter a Username and Password
Enter
username:pass
434762629765715:PQlkrSHPqqjhIBc0MmUkdjcqpps 


Learn more about cloudinary.com
Only need to goto Docs
example 

Poc Pic





Aug 1, 2018

Shipt Subdomain TakeOver via HeroKu ( test.shipt.com )















 ( test.shipt.com ) Subdomain Takeover via HeroKu

I notice that Shipt become Public Program

so I started scan for Subdomain TakeOver 
by Takeover tool edited by me

Then it detected  there is a possible Takeover on
test.shipt.com 
As it has a A record 
michael.shipt.com.herokudns.com 

tried to go directly to michael.shipt.com.herokudns.com 

The Page was not found 😀 

So I claimed it on HeroKu 


 Then I uploaded a Simple Node.js to Provide more POC only 




The Team was very fast 
Reported to  : Shipt Jul 28th

Triaged : 28th

Fixed  and rewarded in 10 min


Apr 12, 2018

ROBOT Attack (Strong Oracle)

ROBOT Attack (Strong Oracle)

Vulnerability Details 

The ROBOT (Return Of Bleichenbacher's Oracle Threat) vulnerability in the target web server. The ROBOT vulnerability allows anyone on the Internet to perform RSA decryption and signing operations with the private key of a TLS server. Expression, Strong Oracle, means that the attack is possible by collecting less than a million packets.

Impact
An attacker can passively record the traffic and later on decrypt it.  Even though forward secrecy is enabled, the risk depends on how fast an attacker is able to perform the attack. Also a server impersonation or a man-in-the-middle attack is possible.

Suggested Fix

Ensure you have no vulnerable applications on your SSL stack. If you do have any vulnerable applications, make sure that you applied the related fix released by the vendor (if any available).
RSA encryption modes are so risky that the only safe course of action is to disable them. These encyption modes also lack forward secrecy. Thus we strongly recommend, as a preventive measure, to disable all the TLS_RSA cipher suites on your SSL stack (except for the ones that have DHE or ECDHE in their name).


Site For TEST Attack 



***** More about Bug *****

The Vulnerability
ROBOT is the return of a 19-year-old vulnerability that allows performing RSA decryption and signing operations with the private key of a TLS server.
In 1998, Daniel Bleichenbacher discovered that the error messages given by SSL servers for errors in the PKCS #1 v1.5 padding allowed an adaptive-chosen ciphertext attack; this attack fully breaks the confidentiality of TLS when used with RSA encryption.
We discovered that by using some slight variations this vulnerability can still be used against many HTTPS hosts in today's Internet.

How bad is it?

For hosts that are vulnerable and only support RSA encryption key exchanges it's pretty bad. It means an attacker can passively record traffic and later decrypt it.
For hosts that usually use forward secrecy, but still support a vulnerable RSA encryption key exchange the risk depends on how fast an attacker is able to perform the attack. We believe that a server impersonation or man in the middle attack is possible, but it is more challenging.

Who is affected?

We have identifed vulnerable implementations from at least seven vendors including F5, Citrix, and Cisco. (Current patch status is listed below.)
Some of the most popular webpages on the Internet were affected, including Facebook and Paypal. In total, we found vulnerable subdomains on 27 of the top 100 domains as ranked by Alexa.
Several vendors have fixes pending and will not be named at this time. The following table will be kept up to date as patches become available.
F5BIG-IP SSL vulnerabilityCVE-2017-6168
CitrixTLS Padding Oracle Vulnerability in Citrix NetScaler Application Delivery Controller (ADC) and NetScaler GatewayCVE-2017-17382
RadwareSecurity Advisory: Adaptive chosen-ciphertext attack vulnerabilityCVE-2017-17427
Cisco ACEBleichenbacher Attack on TLS Affecting Cisco Products, End-of-Sale and End-of-LifeCVE-2017-17428
Cisco ASABleichenbacher Attack on TLS Affecting Cisco ProductsCVE-2017-12373
Bouncy CastleFix in 1.59 beta 9, Patch / CommitCVE-2017-13098
ErlangOTP 18.3.4.7, OTP 19.3.6.4, OTP 20.1.7CVE-2017-1000385
WolfSSLGithub PR / patchCVE-2017-13099
Palo Alto NetworksPAN-OS exposure to ROBOT attack, Advisory (fixed in PAN-OS 7.1.15, 8.0.7)CVE-2017-17841
IBM DominoTwitter source (Dirk Wetter) (unfixed)-
IBM WebSphere MQIBM Security BulletinCVE-2018-1388
MatrixSSLChanges in 3.8.3CVE-2016-6883
Java / JSSEOracle Critical Patch Update Advisory - October 2012CVE-2012-5081
MatrixSSL and JSSE are old vulnerabilities, but we added them as we still see vulnerable hosts.

I am affected, what shall I do?

If you use one of the products that provides a fix you should of course install the update. However, we recommend something else:

Disable RSA encryption!

ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. We believe RSA encryption modes are so risky that the only safe course of action is to disable them. Apart from being risky these modes also lack forward secrecy.
By disabling RSA encryption we mean all ciphers that start with TLS_RSA. It does not include the ciphers that use RSA signatures and include DHE or ECDHE in their name. These ciphers are not affected by our attack.
Based on some preliminary data we also believe the compatibility costs of disabling RSA encryption modes are relatively low. Cloudflare shared with us that around one percent of their connections use the RSA encryption modes. Disabling these modes on the HTTPS server operated by one of the authors caused no notable problems.

I have a Cisco ACE device.

Cisco informed us that the ACE product line was discontinued several years ago and that they won't provide an update. Still, we found plenty of vulnerable hosts that use these devices.
These devices don't support any other cipher suites, therefore disabling RSA is not an option. To our knowledge it is not possible to use these devices for TLS connections in a secure way.
However, if you use these products you're in good company: As far as we can tell Cisco is using them to serve the cisco.com domain.

My server is vulnerable. Do I need to revoke my certificate?

No. This attack does not recover the server's private key. It does only allow an attacker to decrypt ciphertexts or sign messages with the server's private key.

Do I need to update my browser?

No. This is an implementation bug in servers, there is nothing clients can do to prevent it.

Can you actually prove that Facebook was vulnerable?

We were able to sign a test message with Facebook's private key.
You don't have to take our word for it; we have cryptographic proof. Just use these commands:

echo 799e4353 5a4da709 80fada33 d0fbf51a e60d32c1 115c87ab 29b716b4 9ab06377 33f92fc9 85f280fa 569e41e2 847b09e8 d028c0c2 a42ce5be eb640c10 1d5cf486 cdffc5be 116a2d5b a36e52f4 195498a7 8427982d 50bb7d9d 938ab905 40756535 8b1637d4 6fbb60a9 f4f093fe 58dbd251 2cca70ce 842e74da 078550d8 4e6abc83 ef2d7e72 ec79d7cb 2014e7bd 8debbd1e 313188b6 3a2a6aec 55de6f56 ad49d32a 1201f180 82afe3b4 edf02ad2 a1bce2f5 7104f387 f3b8401c 5a7a8336 c80525b0 b83ec965 89c36768 5205623d 2dcdbe14 66701dff c6e768fb 8af1afdb e0a1a626 54f3fd08 175069b7 b198c471 95b63083 9c663321 dc5ca39a bfb45216 db7ef837 | xxd -r -p > sig
curl https://crt.sh/?d=F709E83727385F514321D9B2A64E26B1A195751BBCAB16BE2F2F34EBB084F6A9|openssl x509 -noout -pubkey > pubkey.key
openssl rsautl -verify -pubin -inkey pubkey.key -in sig

The first line will write the signature to a file using xxd (a tool that's part of vim). The second line will download Facebook's certificate as used at the time of the attack (we could also download it from Facebook, but then it won't work after they change it). The third line will verify it and tell you that it's a signature over the text:
We hacked Facebook with a Bleichenbacher Oracle (JS/HB).

How is it possible that a 19-year-old vulnerability is still present?

After Bleichenbacher's original attack the designers of TLS decided that the best course of action was to keep the vulnerable encryption modes and add countermeasures. Later research showed that these countermeasures were incomplete leading the TLS designers to add more complicated countermeasures.
The section on Bleichenbacher countermeasures in the latest TLS 1.2 standard (7.4.7.1) is incredibly complex. It is not surprising that these workarounds aren't implemented correctly.

If the test says I'm not vulnerable then everything is fine, right?

Not necessarily.

Further protocol flows and cipher suites

We discovered that with slight modifications, e.g. by changing the message flow or by using different cipher modes, we could find more vulnerable hosts. It is likely that further variations may reveal new oracles.

Cross-protocol and cross-server attacks

Even if your server is not directly vulnerable, the attack can be applied in two cases. First, your secure server can share the same public with a vulnerable server. As shown in DROWN, this is quite common that web servers share the same key. The attacker can then use the vulnerable server as an oracle to decrypt the confidential communication with your secure server.
Second, another vulnerable server can use a certificate with a domain name that matches your secure server. This would allow an attacker to perform impersonation attacks. We have actually observed such an example in the wild. The main WhatsApp web page www.whatsapp.com was not vulnerable, but we detected several vulnerable servers with a wildcart certificate issued to *.whatsapp.com.

Timing attacks

It is also important to note that our test does not consider timing variants of Bleichenbacher's vulnerability. However these tend to be very hard to exploit in practice.
You can find some info about potential timing issues in OpenSSL here and in NSS here.

What's this PKCS #1 v1.5 you're talking about?

The RSA algorithm cannot be used in its "pure" form. In order to be secure, messages need some kind of padding. PKCS #1 v1.5 is a widely used padding mode for RSA for both encryption and signatures.
There are more secure padding modes for RSA (PSS/OAEP), but they never gained widespread adoption. They're standardized in PKCS #1 v2.2.

What about PKCS #1 v1.5 signatures?

They're also problematic, but for different reasons that were not part of our research.

Is this only a problem for TLS?

Every protocol that uses RSA PKCS #1 v1.5 encryption is at risk of exposing similar vulnerabilities.

How is ROBOT different from Bleichenbacher's original attack?

Bleichenbacher's original work from 1998 used an oracle based on different TLS alerts. We changed it to allow various different signals to distinguish between error types like timeouts, connection resets, duplicate TLS alerts.
We also discovered that by using a shortened message flow where we send the ClientKeyExchange message without a ChangeCipherSpec and Finished message allows us to find more vulnerable hosts.

So... ROBOT doesn't add a whole lot, right?

That's correct. The surprising fact is that our research was very straightforward. We used minor variations of the original attack and were successful. This issue was hiding in plain sight.
This means neither the vendors of the affected products nor security researchers have investigated this before, although it's a very classic and well-known attack.

How is this related to previous research?

Originally this type of attack was discovered by Daniel Bleichenbacher in 1998.
In 2012 Romain Bardou and others developed a much more efficient Bleichenbacher attack algorithm that reduces the number of needed connections.
The DROWN attack is a protocol level Bleichenbacher vulnerability in SSL version 2. The DROWN research also contains further insights on cross-protocol scenarios.

Are there any tools that I can use to scan for this vulnerability?

We have reached out to the developers of various TLS testing tools before the publication of our research. The following tools have checks that will cover ROBOT:
We encourage developers of other security and TLS testing tools to add checks for ROBOT. You can use our code, it's under a CC0 (public domain) license.

Can this attack be used against Bitcoin?

Bitcoin does not use RSA, instead it uses elliptic curve cryptography based on the curve secp256k1. Our attack cannot be directly applied to that. However if you transform a quantum key exchange to a supersingular Isogeny you can attack post-quantum RSA and thus apply our attack indirectly to secp256k1.
We believe the only way Bitcoin can defend against this is to immediately switch to Quantum Blockchains.

Will you publish the proof of concept?

We have published a proof of concept as part of our robot-detect script.
We delayed publishing the poc after our initial announcement to give people time to patch and fix their servers and to play the CTF.

Play our Capture The Flag contests!

Update: The CTF is over!
We have a ROBOT CTF contest where you can test your crypotgraphic attack skills.
This will require the implementation of a practical Bleichenbacher attack. While we can't make any rules about what you publish we ask you to delay the publication of any tools you create during the contest until it is over.
We will probably run the contest for two months, but we may revisit the timeline.

Is this vuln really serious enough to deserve a name, a logo and a web page?

We had considerable disagreement in our team about this. Juraj agreed only under protest. All complaints about this issue need to go to Hanno.

Media, Blogs and more

Media reports



Blog posts



Other