What exploit are these user agents trying to use?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







48















I just looked at my user agent tracking page on my site (archived on Yandex) and I noticed these user agents. I believe they are an attempt to exploit my server (Nginx with PHP). The 1 in front of it is just how many times the user agent was seen in the Nginx log. These are also shortened user agents and not long ones like Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36. I no longer have access to the logs as I presume this occurred sometime in January or February (my oldest logs are in March and I created the site in January).



1 Mozilla/5.9}print(238947899389478923-34567343546345);{
1 Mozilla/5.9{${print(238947899389478923-34567343546345)}}
1 Mozilla/5.9x22{${print(238947899389478923-34567343546345)}}x22
1 Mozilla/5.9x22];print(238947899389478923-34567343546345);//
1 Mozilla/5.9x22


What exploit was attempted and how can I test to ensure these exploits are not usable?










share|improve this question




















  • 2





    Does the user agent start with ()? If yes, its probably the ShellShock exploit

    – Ferrybig
    Apr 3 at 8:46






  • 1





    @Ferrybig The shellshock exploit has a very particular syntax: (){:;}; is what triggers it.

    – Nzall
    Apr 3 at 11:22






  • 1





    A related question is security.stackexchange.com/questions/184115 .

    – JdeBP
    Apr 4 at 12:38











  • Anecdotally, I appreciate that the numbers used are "pretty big." I used to get false-positive results from a vulnerability scanner that would add two 3-digit numbers in its math-problem tests. It would then "match" the sum in a substring of the Content-Length header.

    – Michael
    Apr 4 at 13:29











  • In Plesk there used to be a vulnerability that allowed to execute php code that was within logs. This doesn't seem like it, but the vector of attack looks similar

    – eithed
    2 days ago


















48















I just looked at my user agent tracking page on my site (archived on Yandex) and I noticed these user agents. I believe they are an attempt to exploit my server (Nginx with PHP). The 1 in front of it is just how many times the user agent was seen in the Nginx log. These are also shortened user agents and not long ones like Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36. I no longer have access to the logs as I presume this occurred sometime in January or February (my oldest logs are in March and I created the site in January).



1 Mozilla/5.9}print(238947899389478923-34567343546345);{
1 Mozilla/5.9{${print(238947899389478923-34567343546345)}}
1 Mozilla/5.9x22{${print(238947899389478923-34567343546345)}}x22
1 Mozilla/5.9x22];print(238947899389478923-34567343546345);//
1 Mozilla/5.9x22


What exploit was attempted and how can I test to ensure these exploits are not usable?










share|improve this question




















  • 2





    Does the user agent start with ()? If yes, its probably the ShellShock exploit

    – Ferrybig
    Apr 3 at 8:46






  • 1





    @Ferrybig The shellshock exploit has a very particular syntax: (){:;}; is what triggers it.

    – Nzall
    Apr 3 at 11:22






  • 1





    A related question is security.stackexchange.com/questions/184115 .

    – JdeBP
    Apr 4 at 12:38











  • Anecdotally, I appreciate that the numbers used are "pretty big." I used to get false-positive results from a vulnerability scanner that would add two 3-digit numbers in its math-problem tests. It would then "match" the sum in a substring of the Content-Length header.

    – Michael
    Apr 4 at 13:29











  • In Plesk there used to be a vulnerability that allowed to execute php code that was within logs. This doesn't seem like it, but the vector of attack looks similar

    – eithed
    2 days ago














48












48








48


8






I just looked at my user agent tracking page on my site (archived on Yandex) and I noticed these user agents. I believe they are an attempt to exploit my server (Nginx with PHP). The 1 in front of it is just how many times the user agent was seen in the Nginx log. These are also shortened user agents and not long ones like Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36. I no longer have access to the logs as I presume this occurred sometime in January or February (my oldest logs are in March and I created the site in January).



1 Mozilla/5.9}print(238947899389478923-34567343546345);{
1 Mozilla/5.9{${print(238947899389478923-34567343546345)}}
1 Mozilla/5.9x22{${print(238947899389478923-34567343546345)}}x22
1 Mozilla/5.9x22];print(238947899389478923-34567343546345);//
1 Mozilla/5.9x22


What exploit was attempted and how can I test to ensure these exploits are not usable?










share|improve this question
















I just looked at my user agent tracking page on my site (archived on Yandex) and I noticed these user agents. I believe they are an attempt to exploit my server (Nginx with PHP). The 1 in front of it is just how many times the user agent was seen in the Nginx log. These are also shortened user agents and not long ones like Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36. I no longer have access to the logs as I presume this occurred sometime in January or February (my oldest logs are in March and I created the site in January).



1 Mozilla/5.9}print(238947899389478923-34567343546345);{
1 Mozilla/5.9{${print(238947899389478923-34567343546345)}}
1 Mozilla/5.9x22{${print(238947899389478923-34567343546345)}}x22
1 Mozilla/5.9x22];print(238947899389478923-34567343546345);//
1 Mozilla/5.9x22


What exploit was attempted and how can I test to ensure these exploits are not usable?







exploit webserver web nginx






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 4 at 5:21









forest

39.5k18127140




39.5k18127140










asked Apr 2 at 18:44









SenorContentoSenorContento

358138




358138








  • 2





    Does the user agent start with ()? If yes, its probably the ShellShock exploit

    – Ferrybig
    Apr 3 at 8:46






  • 1





    @Ferrybig The shellshock exploit has a very particular syntax: (){:;}; is what triggers it.

    – Nzall
    Apr 3 at 11:22






  • 1





    A related question is security.stackexchange.com/questions/184115 .

    – JdeBP
    Apr 4 at 12:38











  • Anecdotally, I appreciate that the numbers used are "pretty big." I used to get false-positive results from a vulnerability scanner that would add two 3-digit numbers in its math-problem tests. It would then "match" the sum in a substring of the Content-Length header.

    – Michael
    Apr 4 at 13:29











  • In Plesk there used to be a vulnerability that allowed to execute php code that was within logs. This doesn't seem like it, but the vector of attack looks similar

    – eithed
    2 days ago














  • 2





    Does the user agent start with ()? If yes, its probably the ShellShock exploit

    – Ferrybig
    Apr 3 at 8:46






  • 1





    @Ferrybig The shellshock exploit has a very particular syntax: (){:;}; is what triggers it.

    – Nzall
    Apr 3 at 11:22






  • 1





    A related question is security.stackexchange.com/questions/184115 .

    – JdeBP
    Apr 4 at 12:38











  • Anecdotally, I appreciate that the numbers used are "pretty big." I used to get false-positive results from a vulnerability scanner that would add two 3-digit numbers in its math-problem tests. It would then "match" the sum in a substring of the Content-Length header.

    – Michael
    Apr 4 at 13:29











  • In Plesk there used to be a vulnerability that allowed to execute php code that was within logs. This doesn't seem like it, but the vector of attack looks similar

    – eithed
    2 days ago








2




2





Does the user agent start with ()? If yes, its probably the ShellShock exploit

– Ferrybig
Apr 3 at 8:46





Does the user agent start with ()? If yes, its probably the ShellShock exploit

– Ferrybig
Apr 3 at 8:46




1




1





@Ferrybig The shellshock exploit has a very particular syntax: (){:;}; is what triggers it.

– Nzall
Apr 3 at 11:22





@Ferrybig The shellshock exploit has a very particular syntax: (){:;}; is what triggers it.

– Nzall
Apr 3 at 11:22




1




1





A related question is security.stackexchange.com/questions/184115 .

– JdeBP
Apr 4 at 12:38





A related question is security.stackexchange.com/questions/184115 .

– JdeBP
Apr 4 at 12:38













Anecdotally, I appreciate that the numbers used are "pretty big." I used to get false-positive results from a vulnerability scanner that would add two 3-digit numbers in its math-problem tests. It would then "match" the sum in a substring of the Content-Length header.

– Michael
Apr 4 at 13:29





Anecdotally, I appreciate that the numbers used are "pretty big." I used to get false-positive results from a vulnerability scanner that would add two 3-digit numbers in its math-problem tests. It would then "match" the sum in a substring of the Content-Length header.

– Michael
Apr 4 at 13:29













In Plesk there used to be a vulnerability that allowed to execute php code that was within logs. This doesn't seem like it, but the vector of attack looks similar

– eithed
2 days ago





In Plesk there used to be a vulnerability that allowed to execute php code that was within logs. This doesn't seem like it, but the vector of attack looks similar

– eithed
2 days ago










5 Answers
5






active

oldest

votes


















59














It looks to be trying to exploit some form of command injection. As DarkMatter mentioned in his answer, this was likely a broad attempt to find any vulnerable servers, rather than targeting you specifically. The payload itself just appears to just be testing to see if the server is vulnerable to command injection. It does not appear to have any additional purpose.



In order to test if you would be affected by these specific payloads, the easiest way would be to send them to your own server, and see how they respond. Note, that I only say this because the payloads themselves are benign; I do not recommend doing this with all payloads.



My bet is that your server is not vulnerable, because I would have expected to see follow up request to actually exploit your server.






share|improve this answer



















  • 5





    Note that when re-testing a payload in this way, you don't check that you weren't vulnerable at the time it occurred (when maybe some updates were not yet made): just that you are not vulnerable anymore. Your server could still have been compromised - though I don't say it necessary is the case here.

    – Mic
    Apr 4 at 12:59






  • 1





    That there are these particular (apparently unsuccessful) attempts in the log doesn't mean there hasn't been a successful one, which didn't get logged. Notice how some of these potential commands do have ${...}, others don't, yet others have x22 which is quotation mark " etc. ­— the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.

    – Ruslan
    2 days ago





















22














It is probably nothing. It seems like the broad spam of a scanner looking across the web for any website that evaluates and returns that subtraction when it shouldn't. It is a pretty common thing to see.






share|improve this answer































    21














    The use of actual function names (e.g. print) suggests they're looking for websites that are using eval in some way (note that this could be PHP's eval(string $code), JavaScript's eval(string), and other scripting languages' equivalents).



    I note that the executable code appears immediately after the first version parameter after Mozilla/. This means the authors of this attack believe that enough websites in the wild are actually using eval as a (horrible) way of parsing a two-component (major.minor) version number.



    So I imagine vulnerable websites were doing something like this (pseudo-code):



    var userAgent = request.headers["User-Agent"];

    var indexOfVersion = userAgent.indexof( '/' );
    var indexOfVersionEnd = userAgent.indexof( indexOfVersion , ' ' );

    var versionText = userAgent.substring( indexOfVersion + 1, indexOfVersionEnd );
    var versionNumber = eval( versionText ); // <------- this is the vulnerability!





    share|improve this answer

































      2














      it looks like they are trying to inject PHP code into log files. The idea being that if the sysadmin is using a PHP app to parse the logs, some might view the logfile as trusted (after all, the user does not normally get to directly alter the logfile) and therefore forego any sanitisation processes.



      If you are looking at your log files through a desktop or CLI text editor, you will never be vulnerable to this attack. If you use a PHP app, make sure it treats the logs as untrusted and sanitise it just like you would a normal user input field.






      share|improve this answer































        1














        This is simple; they're trying PHP command injection. The process is to substitute a header (in this case the user agent field) with a mathematical expression, then to determine whether the code is being executed view the return value. If the code is executed, the return value will be the result of the expression, rather than the original expression. You'll notice the slightly spammy usage of open and close brackets, semicolons and other characters often used to fool interpreted languages into intepreting data as executable code. Nothing to worry about, automated vulnerability scans like this are par for the course nowadays.






        share|improve this answer








        New contributor




        Steve Gazzo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.





















          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "162"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          noCode: true, onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206649%2fwhat-exploit-are-these-user-agents-trying-to-use%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          5 Answers
          5






          active

          oldest

          votes








          5 Answers
          5






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          59














          It looks to be trying to exploit some form of command injection. As DarkMatter mentioned in his answer, this was likely a broad attempt to find any vulnerable servers, rather than targeting you specifically. The payload itself just appears to just be testing to see if the server is vulnerable to command injection. It does not appear to have any additional purpose.



          In order to test if you would be affected by these specific payloads, the easiest way would be to send them to your own server, and see how they respond. Note, that I only say this because the payloads themselves are benign; I do not recommend doing this with all payloads.



          My bet is that your server is not vulnerable, because I would have expected to see follow up request to actually exploit your server.






          share|improve this answer



















          • 5





            Note that when re-testing a payload in this way, you don't check that you weren't vulnerable at the time it occurred (when maybe some updates were not yet made): just that you are not vulnerable anymore. Your server could still have been compromised - though I don't say it necessary is the case here.

            – Mic
            Apr 4 at 12:59






          • 1





            That there are these particular (apparently unsuccessful) attempts in the log doesn't mean there hasn't been a successful one, which didn't get logged. Notice how some of these potential commands do have ${...}, others don't, yet others have x22 which is quotation mark " etc. ­— the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.

            – Ruslan
            2 days ago


















          59














          It looks to be trying to exploit some form of command injection. As DarkMatter mentioned in his answer, this was likely a broad attempt to find any vulnerable servers, rather than targeting you specifically. The payload itself just appears to just be testing to see if the server is vulnerable to command injection. It does not appear to have any additional purpose.



          In order to test if you would be affected by these specific payloads, the easiest way would be to send them to your own server, and see how they respond. Note, that I only say this because the payloads themselves are benign; I do not recommend doing this with all payloads.



          My bet is that your server is not vulnerable, because I would have expected to see follow up request to actually exploit your server.






          share|improve this answer



















          • 5





            Note that when re-testing a payload in this way, you don't check that you weren't vulnerable at the time it occurred (when maybe some updates were not yet made): just that you are not vulnerable anymore. Your server could still have been compromised - though I don't say it necessary is the case here.

            – Mic
            Apr 4 at 12:59






          • 1





            That there are these particular (apparently unsuccessful) attempts in the log doesn't mean there hasn't been a successful one, which didn't get logged. Notice how some of these potential commands do have ${...}, others don't, yet others have x22 which is quotation mark " etc. ­— the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.

            – Ruslan
            2 days ago
















          59












          59








          59







          It looks to be trying to exploit some form of command injection. As DarkMatter mentioned in his answer, this was likely a broad attempt to find any vulnerable servers, rather than targeting you specifically. The payload itself just appears to just be testing to see if the server is vulnerable to command injection. It does not appear to have any additional purpose.



          In order to test if you would be affected by these specific payloads, the easiest way would be to send them to your own server, and see how they respond. Note, that I only say this because the payloads themselves are benign; I do not recommend doing this with all payloads.



          My bet is that your server is not vulnerable, because I would have expected to see follow up request to actually exploit your server.






          share|improve this answer













          It looks to be trying to exploit some form of command injection. As DarkMatter mentioned in his answer, this was likely a broad attempt to find any vulnerable servers, rather than targeting you specifically. The payload itself just appears to just be testing to see if the server is vulnerable to command injection. It does not appear to have any additional purpose.



          In order to test if you would be affected by these specific payloads, the easiest way would be to send them to your own server, and see how they respond. Note, that I only say this because the payloads themselves are benign; I do not recommend doing this with all payloads.



          My bet is that your server is not vulnerable, because I would have expected to see follow up request to actually exploit your server.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Apr 2 at 20:12









          user52472user52472

          2,872816




          2,872816








          • 5





            Note that when re-testing a payload in this way, you don't check that you weren't vulnerable at the time it occurred (when maybe some updates were not yet made): just that you are not vulnerable anymore. Your server could still have been compromised - though I don't say it necessary is the case here.

            – Mic
            Apr 4 at 12:59






          • 1





            That there are these particular (apparently unsuccessful) attempts in the log doesn't mean there hasn't been a successful one, which didn't get logged. Notice how some of these potential commands do have ${...}, others don't, yet others have x22 which is quotation mark " etc. ­— the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.

            – Ruslan
            2 days ago
















          • 5





            Note that when re-testing a payload in this way, you don't check that you weren't vulnerable at the time it occurred (when maybe some updates were not yet made): just that you are not vulnerable anymore. Your server could still have been compromised - though I don't say it necessary is the case here.

            – Mic
            Apr 4 at 12:59






          • 1





            That there are these particular (apparently unsuccessful) attempts in the log doesn't mean there hasn't been a successful one, which didn't get logged. Notice how some of these potential commands do have ${...}, others don't, yet others have x22 which is quotation mark " etc. ­— the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.

            – Ruslan
            2 days ago










          5




          5





          Note that when re-testing a payload in this way, you don't check that you weren't vulnerable at the time it occurred (when maybe some updates were not yet made): just that you are not vulnerable anymore. Your server could still have been compromised - though I don't say it necessary is the case here.

          – Mic
          Apr 4 at 12:59





          Note that when re-testing a payload in this way, you don't check that you weren't vulnerable at the time it occurred (when maybe some updates were not yet made): just that you are not vulnerable anymore. Your server could still have been compromised - though I don't say it necessary is the case here.

          – Mic
          Apr 4 at 12:59




          1




          1





          That there are these particular (apparently unsuccessful) attempts in the log doesn't mean there hasn't been a successful one, which didn't get logged. Notice how some of these potential commands do have ${...}, others don't, yet others have x22 which is quotation mark " etc. ­— the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.

          – Ruslan
          2 days ago







          That there are these particular (apparently unsuccessful) attempts in the log doesn't mean there hasn't been a successful one, which didn't get logged. Notice how some of these potential commands do have ${...}, others don't, yet others have x22 which is quotation mark " etc. ­— the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.

          – Ruslan
          2 days ago















          22














          It is probably nothing. It seems like the broad spam of a scanner looking across the web for any website that evaluates and returns that subtraction when it shouldn't. It is a pretty common thing to see.






          share|improve this answer




























            22














            It is probably nothing. It seems like the broad spam of a scanner looking across the web for any website that evaluates and returns that subtraction when it shouldn't. It is a pretty common thing to see.






            share|improve this answer


























              22












              22








              22







              It is probably nothing. It seems like the broad spam of a scanner looking across the web for any website that evaluates and returns that subtraction when it shouldn't. It is a pretty common thing to see.






              share|improve this answer













              It is probably nothing. It seems like the broad spam of a scanner looking across the web for any website that evaluates and returns that subtraction when it shouldn't. It is a pretty common thing to see.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Apr 2 at 19:29









              DarkMatterDarkMatter

              2,3081121




              2,3081121























                  21














                  The use of actual function names (e.g. print) suggests they're looking for websites that are using eval in some way (note that this could be PHP's eval(string $code), JavaScript's eval(string), and other scripting languages' equivalents).



                  I note that the executable code appears immediately after the first version parameter after Mozilla/. This means the authors of this attack believe that enough websites in the wild are actually using eval as a (horrible) way of parsing a two-component (major.minor) version number.



                  So I imagine vulnerable websites were doing something like this (pseudo-code):



                  var userAgent = request.headers["User-Agent"];

                  var indexOfVersion = userAgent.indexof( '/' );
                  var indexOfVersionEnd = userAgent.indexof( indexOfVersion , ' ' );

                  var versionText = userAgent.substring( indexOfVersion + 1, indexOfVersionEnd );
                  var versionNumber = eval( versionText ); // <------- this is the vulnerability!





                  share|improve this answer






























                    21














                    The use of actual function names (e.g. print) suggests they're looking for websites that are using eval in some way (note that this could be PHP's eval(string $code), JavaScript's eval(string), and other scripting languages' equivalents).



                    I note that the executable code appears immediately after the first version parameter after Mozilla/. This means the authors of this attack believe that enough websites in the wild are actually using eval as a (horrible) way of parsing a two-component (major.minor) version number.



                    So I imagine vulnerable websites were doing something like this (pseudo-code):



                    var userAgent = request.headers["User-Agent"];

                    var indexOfVersion = userAgent.indexof( '/' );
                    var indexOfVersionEnd = userAgent.indexof( indexOfVersion , ' ' );

                    var versionText = userAgent.substring( indexOfVersion + 1, indexOfVersionEnd );
                    var versionNumber = eval( versionText ); // <------- this is the vulnerability!





                    share|improve this answer




























                      21












                      21








                      21







                      The use of actual function names (e.g. print) suggests they're looking for websites that are using eval in some way (note that this could be PHP's eval(string $code), JavaScript's eval(string), and other scripting languages' equivalents).



                      I note that the executable code appears immediately after the first version parameter after Mozilla/. This means the authors of this attack believe that enough websites in the wild are actually using eval as a (horrible) way of parsing a two-component (major.minor) version number.



                      So I imagine vulnerable websites were doing something like this (pseudo-code):



                      var userAgent = request.headers["User-Agent"];

                      var indexOfVersion = userAgent.indexof( '/' );
                      var indexOfVersionEnd = userAgent.indexof( indexOfVersion , ' ' );

                      var versionText = userAgent.substring( indexOfVersion + 1, indexOfVersionEnd );
                      var versionNumber = eval( versionText ); // <------- this is the vulnerability!





                      share|improve this answer















                      The use of actual function names (e.g. print) suggests they're looking for websites that are using eval in some way (note that this could be PHP's eval(string $code), JavaScript's eval(string), and other scripting languages' equivalents).



                      I note that the executable code appears immediately after the first version parameter after Mozilla/. This means the authors of this attack believe that enough websites in the wild are actually using eval as a (horrible) way of parsing a two-component (major.minor) version number.



                      So I imagine vulnerable websites were doing something like this (pseudo-code):



                      var userAgent = request.headers["User-Agent"];

                      var indexOfVersion = userAgent.indexof( '/' );
                      var indexOfVersionEnd = userAgent.indexof( indexOfVersion , ' ' );

                      var versionText = userAgent.substring( indexOfVersion + 1, indexOfVersionEnd );
                      var versionNumber = eval( versionText ); // <------- this is the vulnerability!






                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Apr 4 at 11:34

























                      answered Apr 4 at 11:20









                      The DThe D

                      1,1261920




                      1,1261920























                          2














                          it looks like they are trying to inject PHP code into log files. The idea being that if the sysadmin is using a PHP app to parse the logs, some might view the logfile as trusted (after all, the user does not normally get to directly alter the logfile) and therefore forego any sanitisation processes.



                          If you are looking at your log files through a desktop or CLI text editor, you will never be vulnerable to this attack. If you use a PHP app, make sure it treats the logs as untrusted and sanitise it just like you would a normal user input field.






                          share|improve this answer




























                            2














                            it looks like they are trying to inject PHP code into log files. The idea being that if the sysadmin is using a PHP app to parse the logs, some might view the logfile as trusted (after all, the user does not normally get to directly alter the logfile) and therefore forego any sanitisation processes.



                            If you are looking at your log files through a desktop or CLI text editor, you will never be vulnerable to this attack. If you use a PHP app, make sure it treats the logs as untrusted and sanitise it just like you would a normal user input field.






                            share|improve this answer


























                              2












                              2








                              2







                              it looks like they are trying to inject PHP code into log files. The idea being that if the sysadmin is using a PHP app to parse the logs, some might view the logfile as trusted (after all, the user does not normally get to directly alter the logfile) and therefore forego any sanitisation processes.



                              If you are looking at your log files through a desktop or CLI text editor, you will never be vulnerable to this attack. If you use a PHP app, make sure it treats the logs as untrusted and sanitise it just like you would a normal user input field.






                              share|improve this answer













                              it looks like they are trying to inject PHP code into log files. The idea being that if the sysadmin is using a PHP app to parse the logs, some might view the logfile as trusted (after all, the user does not normally get to directly alter the logfile) and therefore forego any sanitisation processes.



                              If you are looking at your log files through a desktop or CLI text editor, you will never be vulnerable to this attack. If you use a PHP app, make sure it treats the logs as untrusted and sanitise it just like you would a normal user input field.







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Apr 4 at 15:17









                              520520

                              51524




                              51524























                                  1














                                  This is simple; they're trying PHP command injection. The process is to substitute a header (in this case the user agent field) with a mathematical expression, then to determine whether the code is being executed view the return value. If the code is executed, the return value will be the result of the expression, rather than the original expression. You'll notice the slightly spammy usage of open and close brackets, semicolons and other characters often used to fool interpreted languages into intepreting data as executable code. Nothing to worry about, automated vulnerability scans like this are par for the course nowadays.






                                  share|improve this answer








                                  New contributor




                                  Steve Gazzo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                  Check out our Code of Conduct.

























                                    1














                                    This is simple; they're trying PHP command injection. The process is to substitute a header (in this case the user agent field) with a mathematical expression, then to determine whether the code is being executed view the return value. If the code is executed, the return value will be the result of the expression, rather than the original expression. You'll notice the slightly spammy usage of open and close brackets, semicolons and other characters often used to fool interpreted languages into intepreting data as executable code. Nothing to worry about, automated vulnerability scans like this are par for the course nowadays.






                                    share|improve this answer








                                    New contributor




                                    Steve Gazzo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                    Check out our Code of Conduct.























                                      1












                                      1








                                      1







                                      This is simple; they're trying PHP command injection. The process is to substitute a header (in this case the user agent field) with a mathematical expression, then to determine whether the code is being executed view the return value. If the code is executed, the return value will be the result of the expression, rather than the original expression. You'll notice the slightly spammy usage of open and close brackets, semicolons and other characters often used to fool interpreted languages into intepreting data as executable code. Nothing to worry about, automated vulnerability scans like this are par for the course nowadays.






                                      share|improve this answer








                                      New contributor




                                      Steve Gazzo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.










                                      This is simple; they're trying PHP command injection. The process is to substitute a header (in this case the user agent field) with a mathematical expression, then to determine whether the code is being executed view the return value. If the code is executed, the return value will be the result of the expression, rather than the original expression. You'll notice the slightly spammy usage of open and close brackets, semicolons and other characters often used to fool interpreted languages into intepreting data as executable code. Nothing to worry about, automated vulnerability scans like this are par for the course nowadays.







                                      share|improve this answer








                                      New contributor




                                      Steve Gazzo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.









                                      share|improve this answer



                                      share|improve this answer






                                      New contributor




                                      Steve Gazzo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.









                                      answered Apr 4 at 20:31









                                      Steve GazzoSteve Gazzo

                                      111




                                      111




                                      New contributor




                                      Steve Gazzo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.





                                      New contributor





                                      Steve Gazzo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.






                                      Steve Gazzo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.






























                                          draft saved

                                          draft discarded




















































                                          Thanks for contributing an answer to Information Security Stack Exchange!


                                          • Please be sure to answer the question. Provide details and share your research!

                                          But avoid



                                          • Asking for help, clarification, or responding to other answers.

                                          • Making statements based on opinion; back them up with references or personal experience.


                                          To learn more, see our tips on writing great answers.




                                          draft saved


                                          draft discarded














                                          StackExchange.ready(
                                          function () {
                                          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206649%2fwhat-exploit-are-these-user-agents-trying-to-use%23new-answer', 'question_page');
                                          }
                                          );

                                          Post as a guest















                                          Required, but never shown





















































                                          Required, but never shown














                                          Required, but never shown












                                          Required, but never shown







                                          Required, but never shown

































                                          Required, but never shown














                                          Required, but never shown












                                          Required, but never shown







                                          Required, but never shown







                                          Popular posts from this blog

                                          Masuk log Menu navigasi

                                          Identifying “long and narrow” polygons in with PostGISlength and width of polygonWhy postgis st_overlaps reports Qgis' “avoid intersections” generated polygon as overlapping with others?Adjusting polygons to boundary and filling holesDrawing polygons with fixed area?How to remove spikes in Polygons with PostGISDeleting sliver polygons after difference operation in QGIS?Snapping boundaries in PostGISSplit polygon into parts adding attributes based on underlying polygon in QGISSplitting overlap between polygons and assign to nearest polygon using PostGIS?Expanding polygons and clipping at midpoint?Removing Intersection of Buffers in Same Layers

                                          Старые Смолеговицы Содержание История | География | Демография | Достопримечательности | Примечания | НавигацияHGЯOLHGЯOL41 206 832 01641 606 406 141Административно-территориальное деление Ленинградской области«Переписная оброчная книга Водской пятины 1500 года», С. 793«Карта Ингерманландии: Ивангорода, Яма, Копорья, Нотеборга», по материалам 1676 г.«Генеральная карта провинции Ингерманландии» Э. Белинга и А. Андерсина, 1704 г., составлена по материалам 1678 г.«Географический чертёж над Ижорскою землей со своими городами» Адриана Шонбека 1705 г.Новая и достоверная всей Ингерманландии ланткарта. Грав. А. Ростовцев. СПб., 1727 г.Топографическая карта Санкт-Петербургской губернии. 5-и верстка. Шуберт. 1834 г.Описание Санкт-Петербургской губернии по уездам и станамСпецкарта западной части России Ф. Ф. Шуберта. 1844 г.Алфавитный список селений по уездам и станам С.-Петербургской губернииСписки населённых мест Российской Империи, составленные и издаваемые центральным статистическим комитетом министерства внутренних дел. XXXVII. Санкт-Петербургская губерния. По состоянию на 1862 год. СПб. 1864. С. 203Материалы по статистике народного хозяйства в С.-Петербургской губернии. Вып. IX. Частновладельческое хозяйство в Ямбургском уезде. СПб, 1888, С. 146, С. 2, 7, 54Положение о гербе муниципального образования Курское сельское поселениеСправочник истории административно-территориального деления Ленинградской области.Топографическая карта Ленинградской области, квадрат О-35-23-В (Хотыницы), 1930 г.АрхивированоАдминистративно-территориальное деление Ленинградской области. — Л., 1933, С. 27, 198АрхивированоАдминистративно-экономический справочник по Ленинградской области. — Л., 1936, с. 219АрхивированоАдминистративно-территориальное деление Ленинградской области. — Л., 1966, с. 175АрхивированоАдминистративно-территориальное деление Ленинградской области. — Лениздат, 1973, С. 180АрхивированоАдминистративно-территориальное деление Ленинградской области. — Лениздат, 1990, ISBN 5-289-00612-5, С. 38АрхивированоАдминистративно-территориальное деление Ленинградской области. — СПб., 2007, с. 60АрхивированоКоряков Юрий База данных «Этно-языковой состав населённых пунктов России». Ленинградская область.Административно-территориальное деление Ленинградской области. — СПб, 1997, ISBN 5-86153-055-6, С. 41АрхивированоКультовый комплекс Старые Смолеговицы // Электронная энциклопедия ЭрмитажаПроблемы выявления, изучения и сохранения культовых комплексов с каменными крестами: по материалам работ 2016-2017 гг. в Ленинградской области