I am facing the following situation: for some reasons I have to run a linux binary provided by someone.
I can see (at least tcpdump can see it) that this binary is sending something over SSL when I run it - so I already know it's doing something it shouldn't be doing. My question: is it possible to find what it's doing ? I was thinking of going two routes:
Try to decompile it
Set up my SSL so it feeds me unencrypted traffic
I have already checked and it's statically linked, so the second option might not be possible.
I need to stress that this is a completely legitimate attempt at trying to find out what others want to find about me. Thank you for your time.
It's almost certainty linked with OpenSSL.
This procedure might work:
Create a new root certificate
Install the root certificate into your certificate store
Redirect its traffic to your receiver using host remapping or ipfw.
Capture the traffic from your endpoint, re-encrypt and send to the real one.
If it doesn't you need to find the encryption points in the binary and intercept those calls. Kind of hard, unfortunately.
strace it and see which files it opens.
Related
I don’t know if I asked my question correctly, but I wanted to know how it’s done. We have a website, and yesterday we noticed that the index.php file was deleted in the server, and instead added the index.html. We know for sure that the problem is not in the server, I mean that they didn't hack the server, and I would like to know with what attacks they could do this. I understand that there can be a lot of options, but I ask for help, can someone describe how this can be done, or give some kind of link where I could read about it. I apologize if I described the situation poorly, but I think someone will understand what I am asking for, and maybe help, thanks in advance.
The main attacks are most likely related to a rootkit, specific modification of a server is hard to do with an automated script, so your suspected hacker is likely accessing your server through a back door; you need to make sure that you are only keeping the needed ports open and have firewalls to detect scanners being used on your server. Another option, if you have the funds, is to store your files in a backend storage server, and allowing your frontend server to access those files, it's not foolproof, but it should effectively square the amount of time to detect an open port and pass through the firewall.
Look into these website(s) if you need more info: https://www.veracode.com/security/rootkit
https://en.wikipedia.org/wiki/Rootkit
I've proof read these, and they work well for some basic elaboration on the subject, as well as some prevention methods.
I'm trying to fix an old binary (sources unavailable of course...) that fails to connect now, probably because it's using outdated list of CAs.
However, when running through strace I don't see the binary attempting to read my CAs from /etc/ssl/certs.
Is it possible the list of CAs has been bundled into the binary itself ?
Thanks a lot,
Adam
To be clear, since you say source unavailable I assume you mean a custom program that uses OpenSSL library, since the source for the utility commandline-interface progam named openssl is still available for versions dating back to last century (and until 1.1.0 didn't change much, even when it probably should have).
Yes, definitely. A program using libssl (and libcrypto) can choose whether to use the standard file(s) for its truststore, or some other (custom) file(s) it specifies (often from configuration), or hardcoded data as you ask or data from some other source like a (secure, we hope!) database, or even no truststore at all if it uses ciphersuites that don't use certificate authentication -- anonymous, PSK or SRP -- which is rarely used but is supported by OpenSSL.
You might try strings on the program to see if they were basic enough to embed certs (and maybe other things) in PEM -- IINM that's how Lenovo Superfish was found. If they embedded binary 'DER', that still has enough redundancy you could find it, but not so easily.
Look at the network traffic with Wireshark or similar, or if you have access to the server check its logs, to see if the program is sending an alert in the range 41 to 49 in response to the server's first flight i.e. just after ServerHelloDone.
That would definitively indicate a certificate problem.
I have a server acting as a reverse-proxy connected directly to the internet. I access this computer through ssh on a non-standard port. It doesn't seem too secure. If someone found the ssh port they could brute-force it and gain access to the computer.
Is there a more secure way to configure this?
Brute forcing SSH is very slow and time consuming, by design. With OpenSSH (most implementations are similar) there is a couple second delay after submitting an incorrect password. After three failures the connection is dropped. This makes it unbelievably slow to brute force a password of even moderate entropy. Generally brute forcing of SSH is not a problem so long as your server doesn't have a ton of threads accepting connections and your passwords is sufficiently complex.
Nevertheless #demure's suggestion to use denyhosts or sshguard would not only put your mind at ease, but it would help you detect attacks and possibly take action if necessary. #Steve's suggestion to use public key authentication is also an excellent preventive measure. If you're truly paranoid, consider adding password and public key authentication to achieve two-factor authentication. Something you have and something you know.
I would recommend a tool like denyhosts or sshguard, which watch your logs for failed logins, and auto ban IPs based on the rules you set.
I use fail2ban and wrote a utility myself in C# using mono to add any IP that comes to attack my SSHD to add them to the /etc/hosts.deny as well. Now I see there are some persistent hackers whose IP addresses are kept getting refused. They always come back the next day, though. Digital Ocean has a good tutorial for setting up fail2ban here.
Edit: I changed my logging from username password to Certificate based authentication and that seemed to have reduced most of the attacks but some people even use brute force to crack the certificate. I changed my code now based on the new logs. That seems to be working fine.
Brute force SSH attacks that can suck the resources from a server. The problem can be especially exasperating on low powered servers with a minimal amount of processors (CPU) and memory (RAM).
We developed a solution that downloads IP address black lists of known SSH attackers and adds them to the /etc/hosts.deny file.
The solution is released as an open source project named am-deny-hosts on GitHub. The project consists of a set of shell scripts that does the job without taking up a lot of time, CPU, or memory.
I have a client who, printed 10,000 advertisements with a specific password for an FTP account written on it lets say: horses1, for many reasons I have had to migrate her over to a new host, she chose mediaTemple, and bought an account.
The Login is now horses1#HER-DOMAIN.com, which is a problem, becuase of all her print ads.
I'm thinking this can be fixed with mod_rewrite and htaccess, but I'm pretty sure apache2 and ftp are different programs... I'm really screwed if I cant fix this....
EDIT:
is there a way to create an FTP user alias?
Apache is just a HTTP server. But maybe mod_ftp and its StripHostname option can help you.
Apache is an HTTP server (which, due to being magic, can be made to act like pretty much any kind of TCP/IP server you like, but almost never is) so won't be responsible for the FTP.
The FTP will almost certainly be supplied by a different server, and you'll need to find out what that is and what level of configuration control you have on it before you can proceed any further.
FTP sites that need #domain are almost always shared hosts.
You will not be able to make configuration changes to make it work without.
What is the easiest free method of encrypting my web traffic? I'd like to be able to log in to sites on my web server without sending my password in plaintext.
Edit: My web server is running on the LAMP stack , although it is a shared host so I don't have root.
Get an X.509 certificate (for example, generating your own, or getting one free from StartSSL), and use it to set up SSL—a server-specific configuration task.
If you can't configure a new listener in your web server, there's not really a good option. In theory you could do a little hacking with some JavaScript crypto library, like JavaScrypt, and come up with something safe. I've toyed with several options but I don't know enough about it to come up with anything I feel confident about.
I don't know your circumstances, but if it were me, I'd consider another host.
https
Use a self-signed certificate.
Tell us your web server software for a detailed implementation description!
Since you don't have root your best bet is to contact your hosting provider and see what they can do for you. You may already have SSL access (try using https://yourdomain.com) using a self-certified key.
You should be able to talk them into installing a StartSSL key for you. This provides you with SSL encryption and browsers won't complain that it isn't signed by a valid Certificate Authority.
As stated above, publishing your own certification is free, however knowing more about your environment, may get you more specific answers. Are you running IIS? What will you be logging into that needs encryption? Are you using Windows Servers on the back end?
use Digest Authentication. Since you're on LAMP, you can configure it on Apache with mod_auth_digest.
Since you are trying to reduce costs, any ssl solutions will probably not be an option.
First it requires a signed certificate that cost a bit, the free ones is not always included in all web browsers.
Second to be able to utilize an ssl certificate your server ip must be dedicated to you. This is not the case in every cheap web hosting option. There are technologies that in the future will make it possible to host multiple ssl enabled sites on a single ip, but it's not here yet.
As mentioned before Digest Authentication is one option that doesn't require ssl certificate or dedicated ip.
It's a method of authentication that doesn't reveal your password even though everything else in the communication is unprotected.
In Apache this can be applied in individual directories by specific .htaccess files.
I'll repeat the previous link on mod_auth_digest.
This one is usually already installed on most servers so you won't have to ask you web hosting provider.
You don't always require root access to setup Apache to use SSL, but you will likely need to modify config files, which is either done thru your providers interface, or via files via a shell account. Either way you will need a server certificate; either self-signed, from a major company like Verisign, or one of the smaller free places like cacert.org. As noted by others, this does require a dedicated IP to your server or instance on the server.
I would recommend SSL first, but mod_auth_digest isn't a bad backup idea.