When the webmaster uses eWebEditor, did he find that improper eWebEditor configuration will make it an invisible problem in the website? The first time I discovered this vulnerability was caused by an intrusion last year. I discovered eWebEditor at the end of my life, so I simply obtained WebShell. Later, I had several successful experiences of using eWebEditor for intrusions. Then I remembered that I should write an article to share with you. At the same time, I also asked the webmasters who have already used eWebEditor to quickly check their own site. Otherwise, you will be the next one to be hacked!
Vulnerability exploit
The steps to obtain WebShell using eWebEditor are roughly as follows:
1. Make sure the website uses eWebEditor. Generally speaking, we can make a rough judgment as long as we pay attention to whether the page where the post (article) has similar icons.
2. Check the source code and find the path to the eWebEditor. Click "View source code" to see if there is a statement similar to "<iframe ID=’eWebEditor1’ src=’/edit/?id=content&style=web’ frameborder=0 scrolling=no width=’550’ HEIGHT=’350’></iframe>” in the source code. In fact, only by discovering such a statement can you truly confirm that this website uses eWebEditor. Then note the "***" in src='***, which is the eWebEditor path.
3. Visit the eWebEditor's administrative login page. The default management page of eWebEditor is admin_login.asp, and is in the same directory. Take the above path as an example. The address we visited is: http://www.***.net/edit/admin_login.asp to see if the login page appears.
If you don’t see such a page, it means that the administrator has deleted the management login page. Haha, what are you waiting for? Leave, try a different place. But generally speaking, I rarely see any administrator deleted this page. Try the default username: admin and password: admin888. How about it? It's successful (if you are not the default account, please read the following article)!
4. Increase the upload file type. Click "Style Management" and select the "settings of a certain style under the list. Why choose the style under the list? Because the styles provided by eWebEditor are not allowed to be modified, of course you can also copy a new style to set them.
Then add the "asa" type to the uploaded file type.
5. Upload the ASP * and get WebShell. Next, modify the extension of the ASP * to asa, and you can simply upload your ASP *. Don’t ask me how to upload it, have you seen the “preview”? Click "Preview" and then select the "Insert Other Files" button.
The principle of vulnerability
The principle of exploiting vulnerabilities is very simple, please see the file:
Uploading asp script files under no circumstances is allowed.
sAllowExt = Replace(UCase(sAllowExt), "ASP", "")
Because eWebEditor only filters ASP files. I remember when I first used eWebEditor, I wondered: Since the author already knows that asp files need to be filtered, why not filter asa, cer and other files at the same time? Maybe this is a sign of irresponsibility to free users!
Advanced Application
There are some tricks to exploit the eWebEditor:
1. You cannot log in with the default username and password.
Please try to download the file in the db directory directly. The user name and password are in the eWebEditor_System table. After md5 encryption, if it cannot be downloaded or cracked, then you should be deemed to be unlucky.
2. After adding the Asa type, I found that it still cannot be uploaded.
It should be that the webmaster understands some code and has modified the file by himself, but it doesn't matter. According to ordinary people's thinking habits, they often modify it directly on the sentence sAllowExt = Replace(UCase(sAllowExt), "ASP", ""). I have seen a webmaster modify it like this:
sAllowExt = Replace(Replace(Replace(Replace(Replace(UCase(sAllowExt), "ASP", ""), "CER", ""), "ASA", ""), "CDX", ""), "HTR", "")
At a glance, everything has been filtered, but as long as we add "aaspsp" to the upload type, we can upload the asp file directly. Haha, is it a genius idea? After "aaspsp" filters out the "asp" character, it becomes "asp" instead! By the way, let me tell you a secret. In fact, similar methods can be used to bypass filtering extensions in Dynamic Network Forum 7.0 sp2.
3. After uploading the asp file, I found that the directory does not have permission to run the script.
Haha, it's so stupid. The upload type can be changed, but the upload path can also be modified? Take a closer look at Figure 4.
4. The method in point 2 has been used, but the asp type still cannot be uploaded.
It seems that the webmaster must be a master of writing Asp, but we have one last move to deal with him: Have you seen the "remote type" in Figure 3? eWebEditor can set the type of automatic save remote files, and we can add asp type. But how can remotely accessed asp files can be saved in source code? There are many ways, the easiest way is to delete the "asp" in "App File Map" in IIS.
Postscript
According to my own experience, almost as long as you can enter the background management of eWebEditor, you can basically obtain WebShell. Searching "?id=" on Google can see more than ten pages of relevant information. I roughly checked a few of them and found that the success rate was about 50%. Not bad, right? oblg The previous version of version 2.52 also used eWebEditor. You can search for a few to practice. The worst thing is that there are no security tips in this regard in the official website and help files of eWebEditor. Also, I found that the test system provided by the official does not have similar vulnerabilities. It seems that they do not know about it, but that they do not take the network security of free users to heart!
Vulnerability exploit
The steps to obtain WebShell using eWebEditor are roughly as follows:
1. Make sure the website uses eWebEditor. Generally speaking, we can make a rough judgment as long as we pay attention to whether the page where the post (article) has similar icons.
2. Check the source code and find the path to the eWebEditor. Click "View source code" to see if there is a statement similar to "<iframe ID=’eWebEditor1’ src=’/edit/?id=content&style=web’ frameborder=0 scrolling=no width=’550’ HEIGHT=’350’></iframe>” in the source code. In fact, only by discovering such a statement can you truly confirm that this website uses eWebEditor. Then note the "***" in src='***, which is the eWebEditor path.
3. Visit the eWebEditor's administrative login page. The default management page of eWebEditor is admin_login.asp, and is in the same directory. Take the above path as an example. The address we visited is: http://www.***.net/edit/admin_login.asp to see if the login page appears.
If you don’t see such a page, it means that the administrator has deleted the management login page. Haha, what are you waiting for? Leave, try a different place. But generally speaking, I rarely see any administrator deleted this page. Try the default username: admin and password: admin888. How about it? It's successful (if you are not the default account, please read the following article)!
4. Increase the upload file type. Click "Style Management" and select the "settings of a certain style under the list. Why choose the style under the list? Because the styles provided by eWebEditor are not allowed to be modified, of course you can also copy a new style to set them.
Then add the "asa" type to the uploaded file type.
5. Upload the ASP * and get WebShell. Next, modify the extension of the ASP * to asa, and you can simply upload your ASP *. Don’t ask me how to upload it, have you seen the “preview”? Click "Preview" and then select the "Insert Other Files" button.
The principle of vulnerability
The principle of exploiting vulnerabilities is very simple, please see the file:
Uploading asp script files under no circumstances is allowed.
sAllowExt = Replace(UCase(sAllowExt), "ASP", "")
Because eWebEditor only filters ASP files. I remember when I first used eWebEditor, I wondered: Since the author already knows that asp files need to be filtered, why not filter asa, cer and other files at the same time? Maybe this is a sign of irresponsibility to free users!
Advanced Application
There are some tricks to exploit the eWebEditor:
1. You cannot log in with the default username and password.
Please try to download the file in the db directory directly. The user name and password are in the eWebEditor_System table. After md5 encryption, if it cannot be downloaded or cracked, then you should be deemed to be unlucky.
2. After adding the Asa type, I found that it still cannot be uploaded.
It should be that the webmaster understands some code and has modified the file by himself, but it doesn't matter. According to ordinary people's thinking habits, they often modify it directly on the sentence sAllowExt = Replace(UCase(sAllowExt), "ASP", ""). I have seen a webmaster modify it like this:
sAllowExt = Replace(Replace(Replace(Replace(Replace(UCase(sAllowExt), "ASP", ""), "CER", ""), "ASA", ""), "CDX", ""), "HTR", "")
At a glance, everything has been filtered, but as long as we add "aaspsp" to the upload type, we can upload the asp file directly. Haha, is it a genius idea? After "aaspsp" filters out the "asp" character, it becomes "asp" instead! By the way, let me tell you a secret. In fact, similar methods can be used to bypass filtering extensions in Dynamic Network Forum 7.0 sp2.
3. After uploading the asp file, I found that the directory does not have permission to run the script.
Haha, it's so stupid. The upload type can be changed, but the upload path can also be modified? Take a closer look at Figure 4.
4. The method in point 2 has been used, but the asp type still cannot be uploaded.
It seems that the webmaster must be a master of writing Asp, but we have one last move to deal with him: Have you seen the "remote type" in Figure 3? eWebEditor can set the type of automatic save remote files, and we can add asp type. But how can remotely accessed asp files can be saved in source code? There are many ways, the easiest way is to delete the "asp" in "App File Map" in IIS.
Postscript
According to my own experience, almost as long as you can enter the background management of eWebEditor, you can basically obtain WebShell. Searching "?id=" on Google can see more than ten pages of relevant information. I roughly checked a few of them and found that the success rate was about 50%. Not bad, right? oblg The previous version of version 2.52 also used eWebEditor. You can search for a few to practice. The worst thing is that there are no security tips in this regard in the official website and help files of eWebEditor. Also, I found that the test system provided by the official does not have similar vulnerabilities. It seems that they do not know about it, but that they do not take the network security of free users to heart!