" External Authentication Injection Attack - (EAIA) | TGHC

External Authentication Injection Attack – (EAIA)

Alright, .. it sounds sexier than it is…


From Wikipedia, the free encyclopedia

Hotlinking is a term used on the Internet that refers to the practice of displaying an image on a website by linking to the same image on another website, rather than saving a copy of it on the website on which the image will be shown. So, instead of loading picture.gif on to their own website, a website owner uses a link to the picture as http://example.com/picture.jpg. When the hotlinking website is loaded, the image is loaded from the other website, which uses its bandwidth, costing the hotlinked website’s owners money. For this reason many website owners use .htaccess files to prevent hotlinking. In some cases website owners use the .htaccess file to replace any hotlinked images with an offensive image to deter any other website owners from hotlinking.

Hotlinking can also be used for file types other than images, including documents and videos.

We have all seen it, done it, used it. What can we do with it?

Recently used this against galleryproject.org  and some other places (pending bounty feedback), and Google Blogger – they didn’t want to know !? … anyway,it’s a risk, I think quite overlooked until now ? recently? whatever.

i’m writing this so you can add this check to your existing methodology and to acknowledge that anything calling an ‘untrusted’ external resource is at fault.

The Attack:

hotlinking has a specific file type that it can link to in most cases. usually it’s jpg or image / movie formats supported by browsers, and the app will look at the url see that it ends in .jpg or .whatever and say yeahuuup that’ll do me.

but if we position a basic auth or an ntlm over http prompt we can position these in the path to the image, so when the image is called the authentication challenge kicks in (before it reaches the image).


the webapp will allow the url because it satisfies it’s requirements. but it wont know that on the root folder ‘/’ or on ‘/images/’ there is an authentication.

so if a trusted domain is allowing hotlinks usually to profile /header/company logo images this is a nice way to position an attack.

it will simply challenge the user for a username and password, some users may think ‘well, I’m on bigdomain.com, and it’s asking me for my username and password, … I’ll give it them’ and if your using old versions of IE or new versions with modified configurations (for sharepoint and stuff) you might automatically send your ntlm credentials to the attacker if he uses http ntlm as apposed to basic auth.

Basic Auth offers an attacker to leave a message that may aid in social engineering / convincing the victim it’s a legitimate prompt – the NTLM Prompt is richer in value if you succeed ( from my experience).

worth mentioning that in some instances you may need to turn the authentication on after you have applied it to a target, I haven’t done this or needed to …but suspect it may be handy to consider.

an interesting one, thought it was worth sharing.

Screen Shot 2013-06-21 at 11.39.47



Screen Shot 2013-06-21 at 11.04.35

Screen Shot 2013-06-21 at 11.40.54

What I See (Attack view)

[*] http_ntlm – Request ‘/googleAPI/derp2.jpg’…
[*] http_ntlm – Request ‘/googleAPI/derp.jpg’…
[*] http_ntlm – Request ‘/googleAPI/derp2.jpg’…
[*] http_ntlm – 2013-06-21 11:40:17 +0100
NTLMv1 Response Captured from 7.local

[*] http_ntlm – Request ‘/googleAPI/derp.jpg’…
[*] http_ntlm – Request ‘/googleAPI/derp.jpg’…
[*] http_ntlm – Request ‘/googleAPI/derp2.jpg’…


Thats it really, maybe something to consider when all the XSS has been fixed yet your still able to reference images <img src> or when asked for a url to an image of your choice .

So watch out for sites that handle external URL’s and don’t check for folder level authentication.

 go see  for yourself but you will get those prompts.


Some cases you may have to host an image first, then apply authentication after it has been accepted by the app.





Email from google re- blogger:



Thanks for the report. I don’t seen any vulnerability in Google’s systems or applications here — Blogspot allows pretty much arbitrary content. Of course, this sort of thing does violate the terms of service so if discovered would be taken down.



I wasn’t expecting that – maybe I’m making a bigger deal over this than I should… we’ll see what happens with other companies.

– I recently submitted a EAIA flaw into a the recent Bugcrowd #Beta021 program, and was denied a reward due to the caveats – CSP and SOP  - nothing for creativity.  you could argue that the path to a file isn’t  content, and the content that the path is leading to is what the CSP provides support for, I think it’s relative but doesn’t have it’s own place, I mean.. how are you going to check for dangerous paths to files when thats all the internet is made up of, you have trusted locations not trusted filetypes. as for SOP that’s the very reason SOP Should be implimented but we’ll move on and see what paypal say, see how they interpret the issue, … they unlike bugcrowd are dragging there heels !.


You can see my little video rant here :