Sslstrip Ultimate - location hijacking

0x00 Preface

---

As I mentioned earlier  HTTPS Front end hijacking   The plan , It's fun though , However, the reality is not ideal . Its only 、 And the biggest flaw , It just can't stop the script from jumping . Without this defect , That would be perfect —— Of course, there is no need to write this article .

At the end of the day , Or because you can't rewrite  location  This object —— It is the only channel for script jumps . Although there are also some Hack Can barely achieve , But it is not reliable after all .

in fact , In the recently sealed HTML5 In the standard , It is very clear  location  The status of —— Unforgeable.

This is unfortunate news . But it's also a good thing , Let's get rid of all kinds of heresy , Looking for a new way out .

0x01 Replace plaintext URL

---

Last time I mentioned , You can refer to SSLStrip like that , Put... In the script HTTPS URL Replace all with HTTP edition , It can meet some occasions .

Of course , The defects are also obvious . as long as URL Not in clear text —— For example, it is formed by string splicing , It would be completely unrecognizable , Finally, there is no way to avoid jumping to HTTPS On the page .

This is not uncommon , So we need more advanced solutions .

0x02 Replace location

---

Although we cannot rewrite location, But we need to copy one and location Things with the same function , It's still very easy . We just need to define a few getter and setter, You can simulate a with exactly the same function  location2. But how to put the original location It is mapped ？

At this time , The role of the back end comes into play . Similar substitution HTTPS URL, This time we only focus on the script location character , Change them all to location2 —— So all the reading and writing related to the address bar , Will fall on our agent . What can be done later , Needless to say, everyone knows .

• Acting for all setter： If you jump to HTTPS Just stop it , Then downgrade to HTTP On the version .

• Acting for all getter： If you are currently in a degraded page , We will restore all the returned paths HTTPS character , You can cheat the protocol judgment script , Let those self checking functions completely fail ！

Compared with the previous URL Replace , This plan is too perfect —— URL Dynamic creation is very common , but location Not in clear text , Extremely rare .

Unless the script is encrypted , Otherwise, use Uglify Such a compression tool , And we won't confuse global variables . As for deliberately escaping it , Even more nonsense .

1 2 3 4 5

<code>#!js if (window['loc\ation'].protocol != 'https:') {     // ... } </code>

Here we are , Our goal is clear ：

• front end ： Achieve one location agent .

• Back end ： Will appear in the script location Replace with the proxy variable name .

0x03 Handle external chain scripts

---

Although it is not difficult to replace the contents of the page script , But for the outer chain script , That is not optimistic .

In reality , Many pages outside the chain  HTTPS Absolute path   Script for . At this time , Our middleman is powerless . To avoid that , We still need to replace the HTTPS URL, Let the middleman control more resources .

To replace URL It's not hard , A simple regularization can be implemented —— But since you use regular , We can only face the string .

But in fact , All received are the most original binary data , Not even all UTF-8 Of . In the last article , We want to be simple , Directly use binary injection . But now , This method is obviously not feasible .

Use binary , Not only difficult to control , And very lax . It's hard for us to know that the matching character is an independent character , It is also a partial byte of a wide character . therefore , We still have to deal with strings in the traditional and reliable way .

0x04 Process word set encoding

---

We have to use the word set conversion library , For example, famous iconv, To help accomplish this ：

• First convert the binary data into UTF-8 character string

• With the standard string , Our regularization can be executed smoothly

• String to be processed , Switch back to the previous code

Although I have to toss and turn twice this time , Performance costs a lot , But it is still necessary .

in fact , This process is not as smooth as expected . There are quite a few servers , Not in return  Content-Type  Specifies the codeword set in , So we can only try from the page  <meta>  In order to get .

But this label is compatible with many specifications , For example, in the past ：

1 2 3

<code>#!html <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=GBK"> </code>

And now popular ：

1 2 3

<code>#!html <meta charset="GBK" /> </code>

Although it's easy to get through regularization , But the premise of using regularity is that there must be a string first , So we got stuck .

But the good thing is that the label 、 attribute 、 Word set name , It's basically pure ASCII character , So you can convert binary to default UTF-8 character string , Extract the word set information from , Then transcode .

0x05 Process data chunking

---

Benefit from rich third-party extensions , None of the above problems is difficult to solve .

However , As mentioned before 『 Front end hijacking 』 A huge advantage of —— You don't have to process all the data , Just in the first chunk Just inject code into the . But now , This advantage is facing a severe test .

We want to replace the... In the page HTTPS resources 、location Variables, etc. , They will appear everywhere on the page . If we were to each chunk Separate filtration 、 forward , Is there any problem in this way ？

In reality , Not all of them are so ideal —— There is always a certain chance , The replaced keyword spans exactly two chunk：

Now , Incomplete heads and tails can't match , Then there will be omissions . The longer the keyword , The greater the probability of occurrence . about URL For such a long string , This is a potential hazard .

To solve this problem perfectly , It's more troublesome . But there is a simple way ： We can keep it chunk Characters at the end , Splice to next chunk Before , So as to reduce the possibility of omission .

Of course , If you don't consider the user experience , Or collect all the data , The last one-time treatment , It's the easiest .

In fact, there are better solutions ： The middleman opens a buffer , Temporarily cache the received data . When the data accumulated to a certain amount 、 Or when there is no data for more than a long time , Just started batch processing the cache queue .

This can be avoided   Frequent chunk Context processing , along with it   The response time of users will not be blocked for a long time , Nature is the best of both worlds .

Is this a bit similar TCP nagle What about your taste .

0x06 front end location agent

---

The back-end details are covered , Let's go back to the front end .

Achieve one location Your agent is simple , But there are a lot of details worth noting ：

• location Not only in  window, Actually  document  There is the same one in the .

• location The object itself can also be assigned , The effect is equivalent to location.href.（[PutForwards=href, ...] It has been well explained ）

• Empathy ,location Of  toString  And back again  href  attribute .

• If a location2 Your script is cached , Then the user is in the page without hijacking , Maybe it will report an error . So we have to leave a compatible way back .

• ......

As long as it is fully considered , Achieve one location It is relatively easy to cut the section of .

0x07 Dynamic script hijacking

---

We talked about the replacement page HTTPS URL, To ensure the clear text transmission of the outer chain script .

But in reality , Not all scripts are static . In this era of script flooding , Dynamic loading of modules is very common . If you introduce a HTTPS Script for , Then our middleman has no way to start .

But fortunately , Module interception is not like location That won't happen . In reality , There are many ways to intercept dynamic modules . I wrote it before 《XSS Front end firewall —— Suspicious module interception 》  In one article , Various methods and details have been discussed in detail , It comes in handy here .

in fact , In addition to the script , Frame pages also have this problem . In the last post , We use CSP To stop HTTPS Frame page of . But that's just shielding , It's not really interception . Only by adding the current hook system , It is a perfect interception system .

0x08 demonstration

---

Said so much , The real core is nothing more than changing the script location Variables , Everything else is just to help it .

Let's look for a few websites that failed before , Try this enhanced version of the hijacking tool .

The previous article mentioned JD login , Just jump through the script . Let's test it first ：

When the traffic passes through the intermediary agent , Pages and scripts location All become our variable names . So then everything related to the address bar , It's under our control ：

Notice that there is a in the address bar  zh_cn  The tag , That's exactly what it is. URL Identification code after downward transformation .

adopt  location2  Get all the attributes , It looks like HTTPS The page is exactly the same . Even if the script has a self-test function , Will also be cheated by our virtual environment .

Click login , Nature is successful .

After all ,HTTPS and HTTP Just the difference in transmission . On the application layer , The page is unknown —— Except for asking the script location, But it has been hijacked by us .

In addition to JD's script jump , TenPay website is through non mainstream  <meta http-equiv="refresh">  On going .

The good thing is that we are right about the HTTPS URL It's all replaced , So you can still jump to the degraded page ：

It is worth noting that , If from QQ Click in the icon , Then the page goes directly to HTTPS edition , Will not be hijacked . But if you come from a third party, you are resigned to fate .

Because of the thinking of the average developer , It is impossible to escape location Of this variable . Therefore, this scheme can kill almost all security sites .

Of course , Foreign websites are the same . As long as you haven't been  HSTS  The cache , Hijacking is still easy .

......

therefore , Just use endless imagination , Implement an engineering general hijacking scheme , It is still feasible .

0x09 Preventive measures

---

If you read this article carefully , I should have thought about how to deal with it .

in fact , because JS Superior flexibility , It is almost impossible to infer runtime behavior from static source code .

therefore , As long as... Will be involved  location  The relevant operation , Simple escape obfuscation , You can avoid being hijacked by the middleman . After all , While hijacking traffic , You also need to parse the script , The price is a little high .

This article comes from the dark cloud knowledge base , The copyright of this article belongs to Wuyun knowledge base ！