What exploit are these user agents trying to use?What web servers are affected by this user agent exploit?What is SPL exploit?What kind of security injection are these traces of, SQL, javascript, or otherwise?Is it illegal to use Fake User-agents?Server attack attempts, what are they trying to achieve?Can I exploit Windows kernel from user-mode application?HTTP attack taking down PHP-FPMSegmentation fault trying to exploit printf vulnerabilityWhat web servers are affected by this user agent exploit?Which exploit and which payload use?Help on what to do with these suspicious logs
Why are electrically insulating heatsinks so rare? Is it just cost?
DC-DC converter from low voltage at high current, to high voltage at low current
What typically incentivizes a professor to change jobs to a lower ranking university?
Does object always see its latest internal state irrespective of thread?
High voltage LED indicator 40-1000 VDC without additional power supply
Is it inappropriate for a student to attend their mentor's dissertation defense?
Paid for article while in US on F-1 visa?
Did Shadowfax go to Valinor?
How can I prevent hyper evolved versions of regular creatures from wiping out their cousins?
Which country benefited the most from UN Security Council vetoes?
Client team has low performances and low technical skills: we always fix their work and now they stop collaborate with us. How to solve?
Are the number of citations and number of published articles the most important criteria for a tenure promotion?
Unable to deploy metadata from Partner Developer scratch org because of extra fields
What would happen to a modern skyscraper if it rains micro blackholes?
How much of data wrangling is a data scientist's job?
Today is the Center
What is a clear way to write a bar that has an extra beat?
Why "Having chlorophyll without photosynthesis is actually very dangerous" and "like living with a bomb"?
Has there ever been an airliner design involving reducing generator load by installing solar panels?
RSA: Danger of using p to create q
What defenses are there against being summoned by the Gate spell?
Is it possible to run Internet Explorer on OS X El Capitan?
Why can't I see bouncing of switch on oscilloscope screen?
Why doesn't Newton's third law mean a person bounces back to where they started when they hit the ground?
What exploit are these user agents trying to use?
What web servers are affected by this user agent exploit?What is SPL exploit?What kind of security injection are these traces of, SQL, javascript, or otherwise?Is it illegal to use Fake User-agents?Server attack attempts, what are they trying to achieve?Can I exploit Windows kernel from user-mode application?HTTP attack taking down PHP-FPMSegmentation fault trying to exploit printf vulnerabilityWhat web servers are affected by this user agent exploit?Which exploit and which payload use?Help on what to do with these suspicious logs
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
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);
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.9print(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
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.9print(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
exploit webserver web nginx
edited yesterday
forest
39.3k18127139
39.3k18127139
asked Apr 2 at 18:44
SenorContentoSenorContento
358138
358138
add a comment |
2
Does the user agent start with()? If yes, its probably the ShellShock exploit
– Ferrybig
2 days ago
1
@Ferrybig The shellshock exploit has a very particular syntax: ():;; is what triggers it.
– Nzall
2 days ago
1
A related question is security.stackexchange.com/questions/184115 .
– JdeBP
yesterday
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 theContent-Lengthheader.
– Michael
yesterday
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
10 hours ago
2
2
Does the user agent start with
()? If yes, its probably the ShellShock exploit– Ferrybig
2 days ago
Does the user agent start with
()? If yes, its probably the ShellShock exploit– Ferrybig
2 days ago
1
1
@Ferrybig The shellshock exploit has a very particular syntax: ():;; is what triggers it.
– Nzall
2 days ago
@Ferrybig The shellshock exploit has a very particular syntax: ():;; is what triggers it.
– Nzall
2 days ago
1
1
A related question is security.stackexchange.com/questions/184115 .
– JdeBP
yesterday
A related question is security.stackexchange.com/questions/184115 .
– JdeBP
yesterday
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
yesterday
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
yesterday
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
10 hours 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
10 hours ago
add a comment |
5 Answers
5
active
oldest
votes
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.
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
yesterday
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 havex22which is quotation mark"etc. — the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.
– Ruslan
13 hours ago
add a comment |
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.
add a comment |
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!
add a comment |
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.
add a comment |
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.
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.
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
yesterday
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 havex22which is quotation mark"etc. — the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.
– Ruslan
13 hours ago
add a comment |
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.
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
yesterday
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 havex22which is quotation mark"etc. — the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.
– Ruslan
13 hours ago
add a comment |
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.
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.
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
yesterday
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 havex22which is quotation mark"etc. — the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.
– Ruslan
13 hours ago
add a comment |
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
yesterday
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 havex22which is quotation mark"etc. — the server may have been immune to some combinations of quoting/evaluating while vulnerable to others.
– Ruslan
13 hours 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
yesterday
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
yesterday
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
13 hours 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
13 hours ago
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Apr 2 at 19:29
DarkMatterDarkMatter
2,3081121
2,3081121
add a comment |
add a comment |
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!
add a comment |
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!
add a comment |
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!
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!
edited yesterday
answered yesterday
The DThe D
1,1261920
1,1261920
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered yesterday
520520
51524
51524
add a comment |
add a comment |
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.
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.
add a comment |
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.
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.
add a comment |
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.
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.
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.
answered yesterday
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.
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
2
Does the user agent start with
()? If yes, its probably the ShellShock exploit– Ferrybig
2 days ago
1
@Ferrybig The shellshock exploit has a very particular syntax: ():;; is what triggers it.
– Nzall
2 days ago
1
A related question is security.stackexchange.com/questions/184115 .
– JdeBP
yesterday
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-Lengthheader.– Michael
yesterday
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
10 hours ago