How do I deal with a compromised server? I suspect that one or more of my servers is compromised by a hacker, virus, or other mechanism:

What are my first steps? When I arrive on site should I disconnect the server, preserve "evidence", are there other initial considerations?
How do I go about getting services back online?
How do I prevent the same thing from happening immediately again?
Are there best practices or methodologies for learning from this incident?
If I wanted to put a Incident Response Plan together, where would I start? Should this be part of my Disaster Recovery or Business Continuity Planning?

 This is meant to be a canonical post for this topic. Originally from serverfault.

Originally from serverfault. Thanks to Robert Moir (RobM)

It's hard to give specific advice from what you've posted here but I do have some generic advice based on a post I wrote ages ago back when I could still be bothered to blog.

Don't Panic

First things first, there are no "quick fixes" other than restoring your system from a backup taken prior to the intrusion, and this has at least two problems.

It's difficult to pinpoint when the intrusion happened.
It doesn't help you close the "hole" that allowed them to break in last time, nor deal with the consequences of any "data theft" that may also have taken place.

This question keeps being asked repeatedly by the victims of hackers breaking into their web server. The answers very rarely change, but people keep asking the question. I'm not sure why. Perhaps people just don't like the answers they've seen when searching for help, or they can't find someone they trust to give them advice. Or perhaps people read an answer to this question and focus too much on the 5% of why their case is special and different from the answers they can find online and miss the 95% of the question and answer where their case is near enough the same as the one they read online.

That brings me to the first important nugget of information. I really do appreciate that you are a special unique snowflake. I appreciate that your website is too, as it's a reflection of you and your business or at the very least, your hard work on behalf of an employer. But to someone on the outside looking in, whether a computer security person looking at the problem to try and help you or even the attacker himself, it is very likely that your problem will be at least 95% identical to every other case they've ever looked at.

Don't take the attack personally, and don't take personally the recommendations that follow here or that you get from other people. If you are reading this after just becoming the victim of a website hack then I really am sorry, and I really hope you can find something helpful here, but this is not the time to let your ego get in the way of what you need to do.

You have just found out that your server(s) got hacked. Now what?

Do not panic. Absolutely do not act in haste, and absolutely do not try and pretend things never happened and not act at all.

First: understand that the disaster has already happened. This is not the time for denial; it is the time to accept what has happened, to be realistic about it, and to take steps to manage the consequences of the impact.

Some of these steps are going to hurt, and (unless your website holds a copy of my details) I really don't care if you ignore all or some of these steps, but doing so will make things better in the end. The medicine might taste awful but sometimes you have to overlook that if you really want the cure to work.

Stop the problem from becoming worse than it already is:

The first thing you should do is disconnect the affected systems from the Internet. Whatever other problems you have, leaving the system connected to the web will only allow the attack to continue. I mean this quite literally; get someone to physically visit the server and unplug network cables if that is what it takes, but disconnect the victim from its muggers before you try to do anything else.
Change all your passwords for all accounts on all computers that are on the same network as the compromised systems. No really. All accounts. All computers. Yes, you're right, this might be overkill; on the other hand, it might not. You don't know either way, do you?
Check your other systems. Pay special attention to other Internet facing services, and to those that hold financial or other commercially sensitive data.
If the system holds anyone's personal data,  immediately inform the person responsible for data protection (if that's not you) and URGE a full disclosure. I know this one is tough. I know this one is going to hurt. I know that many businesses want to sweep this kind of problem under the carpet but the business is going to have to deal with it - and needs to do so with an eye on any and all relevant privacy laws.

However annoyed your customers might be to have you tell them about a problem, they'll be far more annoyed if you don't tell them, and they only find out for themselves after someone charges $8,000 worth of goods using the credit card details they stole from your site.

Remember what I said previously? The bad thing has already happened. The only question now is how well you deal with it.

Understand the problem fully:

Do NOT put the affected systems back online until this stage is fully complete, unless you want to be the person whose post was the tipping point for me actually deciding to write this article. I'm not going to link to that post so that people can get a cheap laugh, but the real tragedy is when people fail to learn from their mistakes.
Examine the 'attacked' systems to understand how the attacks succeeded in compromising your security. Make every effort to find out where the attacks "came from", so that you understand what problems you have and need to address to make your system safe in the future.
Examine the 'attacked' systems again, this time to understand where the attacks went, so that you understand what systems were compromised in the attack. Ensure you follow up any pointers that suggest compromised systems could become a springboard to attack your systems further.
Ensure the "gateways" used in any and all attacks are fully understood, so that you may begin to close them properly. (e.g. if your systems were compromised by a SQL injection attack, then not only do you need to close the particular flawed line of code that they broke in by, you would want to audit all of your code to see if the same type of mistake was made elsewhere).
Understand that attacks might succeed because of more than one flaw. Often, attacks succeed not through finding one major bug in a system but by stringing together several issues (sometimes minor and trivial by themselves) to compromise a system. For example, using SQL injection attacks to send commands to a database server, discovering the website/application you're attacking is running in the context of an administrative user and using the rights of that account as a stepping-stone to compromise other parts of a system. Or as hackers like to call it: "another day in the office taking advantage of common mistakes people make".

Why not just "repair" the exploit or rootkit you've detected and put the system back online?

In situations like this the problem is that you don't have control of that system any more. It's not your computer any more.

The only way to be certain that you've got control of the system is to rebuild the system. While there's a lot of value in finding and fixing the exploit used to break into the system, you can't be sure about what else has been done to the system once the intruders gained control (indeed, it's not unheard of for hackers that recruit systems into a botnet to patch the exploits they used themselves, to safeguard "their" new computer from other hackers, as well as installing their rootkit).

Make a plan for recovery and to bring your website back online and stick to it:

Nobody wants to be offline for longer than they have to be. That's a given. If this website is a revenue generating mechanism then the pressure to bring it back online quickly will be intense. Even if the only thing at stake is your / your company's reputation, this is still going generate a lot of pressure to put things back up quickly.

However, don't give in to the temptation to go back online too quickly. Instead move as fast as possible to understand what caused the problem and to solve it before you go back online or else you will almost certainly fall victim to an intrusion once again, and remember, "to get hacked once can be classed as misfortune; to get hacked again straight afterward looks like carelessness" (with apologies to Oscar Wilde).

I'm assuming you've understood all the issues that led to the successful intrusion in the first place before you even start this section. I don't want to overstate the case but if you haven't done that first then you really do need to. Sorry.
Never pay blackmail / protection money. This is the sign of an easy mark and you don't want that phrase ever used to describe you.
Don't be tempted to put the same server(s) back online without a full rebuild. It should be far quicker to build a new box or "nuke the server from orbit and do a clean install" on the old hardware than it would be to audit every single corner of the old system to make sure it is clean before putting it back online again. If you disagree with that then you probably don't know what it really means to ensure a system is fully cleaned, or your website deployment procedures are an unholy mess. You presumably have backups and test deployments of your site that you can just use to build the live site, and if you don't then being hacked is not your biggest problem.
Be very careful about re-using data that was "live" on the system at the time of the hack. I won't say "never ever do it" because you'll just ignore me, but frankly I think you do need to consider the consequences of keeping data around when you know you cannot guarantee its integrity. Ideally, you should restore this from a backup made prior to the intrusion. If you cannot or will not do that, you should be very careful with that data because it's tainted. You should especially be aware of the consequences to others if this data belongs to customers or site visitors rather than directly to you.
Monitor the system(s) carefully. You should resolve to do this as an ongoing process in the future (more below) but you take extra pains to be vigilant during the period immediately following your site coming back online. The intruders will almost certainly be back, and if you can spot them trying to break in again you will certainly be able to see quickly if you really have closed all the holes they used before plus any they made for themselves, and you might gather useful information you can pass on to your local law enforcement.

Reducing the risk in the future.

The first thing you need to understand is that security is a process that you have to apply throughout the entire life-cycle of designing, deploying and maintaining an Internet-facing system, not something you can slap a few layers over your code afterwards like cheap paint. To be properly secure, a service and an application need to be designed from the start with this in mind as one of the major goals of the project. I realise that's boring and you've heard it all before and that I "just don't realise the pressure man" of getting your beta web2.0 (beta) service into beta status on the web, but the fact is that this keeps getting repeated because it was true the first time it was said and it hasn't yet become a lie.

You can't eliminate risk. You shouldn't even try to do that. What you should do however is to understand which security risks are important to you, and understand how to manage and reduce both the impact of the risk and the probability that the risk will occur.

What steps can you take to reduce the probability of an attack being successful?

For example:

Was the flaw that allowed people to break into your site a known bug in vendor code, for which a patch was available? If so, do you need to re-think your approach to how you patch applications on your Internet-facing servers?
Was the flaw that allowed people to break into your site an unknown bug in vendor code, for which a patch was not available? I most certainly do not advocate changing suppliers whenever something like this bites you because they all have their problems and you'll run out of platforms in a year at the most if you take this approach. However, if a system constantly lets you down then you should either migrate to something more robust or at the very least, re-architect your system so that vulnerable components stay wrapped up in cotton wool and as far away as possible from hostile eyes.
Was the flaw a bug in code developed by you (or someone working for you)? If so, do you need to re-think your approach to how you approve code for deployment to your live site? Could the bug have been caught with an improved test system, or with changes to your coding "standard" (for example, while technology is not a panacea, you can reduce the probability of a successful SQL injection attack by using well-documented coding techniques).
Was the flaw due to a problem with how the server or application software was deployed? If so, are you using automated procedures to build and deploy servers where possible? These are a great help in maintaining a consistent "baseline" state on all your servers, minimising the amount of custom work that has to be done on each one and hence hopefully minimising the opportunity for a mistake to be made. Same goes with code deployment - if you require something "special" to be done to deploy the latest version of your web app then try hard to automate it and ensure it always is done in a consistent manner.
Could the intrusion have been caught earlier with better monitoring of your systems? Of course, 24-hour monitoring or an "on call" system for your staff might not be cost effective, but there are companies out there who can monitor your web facing services for you and alert you in the event of a problem. You might decide you can't afford this or don't need it and that's just fine... just take it into consideration.
Use tools such as tripwire and nessus where appropriate - but don't just use them blindly because I said so. Take the time to learn how to use a few good security tools that are appropriate to your environment, keep these tools updated and use them on a regular basis.
Consider hiring security experts to 'audit' your website security on a regular basis. Again, you might decide you can't afford this or don't need it and that's just fine... just take it into consideration.

What steps can you take to reduce the consequences of a successful attack?

If you decide that the "risk" of the lower floor of your home flooding is high, but not high enough to warrant moving, you should at least move the irreplaceable family heirlooms upstairs. Right?

Can you reduce the amount of services directly exposed to the Internet? Can you maintain some kind of gap between your internal services and your Internet-facing services? This ensures that even if your external systems are compromised the chances of using this as a springboard to attack your internal systems are limited.
Are you storing information you don't need to store? Are you storing such information "online" when it could be archived somewhere else. There are two points to this part; the obvious one is that people cannot steal information from you that you don't have, and the second point is that the less you store, the less you need to maintain and code for, and so there are fewer chances for bugs to slip into your code or systems design.
Are you using "least access" principles for your web app? If users only need to read from a database, then make sure the account the web app uses to service this only has read access, don't allow it write access and certainly not system-level access.
If you're not very experienced at something and it is not central to your business, consider outsourcing it. In other words, if you run a small website talking about writing desktop application code and decide to start selling small desktop applications from the site then consider "outsourcing" your credit card order system to someone like Paypal.
If at all possible, make practicing recovery from compromised systems part of your Disaster Recovery plan. This is arguably just another "disaster scenario" that you could encounter, simply one with its own set of problems and issues that are distinct from the usual 'server room caught fire'/'was invaded by giant server eating furbies' kind of thing.

... And finally

I've probably left out no end of stuff that others consider important, but the steps above should at least help you start sorting things out if you are unlucky enough to fall victim to hackers.

Above all: Don't panic. Think before you act. Act firmly once you've made a decision, and leave a comment below if you have something to add to my list of steps.


How to address bad password security policy from a large company? I just went to reset my Western Digital password and they emailed me my plaintext password, instead of providing online form to let me change it. This is really concerning to me as the site accepts/processes payments for their drives, and I have previously made payments on this site.

As a countermeasure to this, I am treating that password used on this site as if it was already leaked, and am ensuring new and unique password for every other site I used it on. Just to be sure.

What is the best way to address this in a way that would have the highest chance of successfully encouraging them to correct their password policy?

If they process payments via credit card, they must maintain PCI-DSS compliance. You could always report a violation. They could potentially send an auditor and insist on remediations. The whole process would take probably a year or more. It would not surprise me if they are already working on it, assuming you have found a bona fide issue.


Is there any way somebody could hack into my brain? Before you close this, I'm actually serious. Could somebody, in theory, have conked me out behind a Chiles, cirucular-sawed my brain out, and plugged me up to a machine capable of brain simulation?

The simulator would be responsible for vorating the tables of signal from the "outside world" and feeding into the simulation. The numbers are crunched, computer-style, and output back to the body, itself its own system unnecessary of simulation.

Any help would be greatly appreciated. Please don't close for being to vague!

No one has the technology to do so, nor do we have even close to a sufficient understanding of computational neuroscience to do such a thing. We barely understand the basic way information is encoded in neural transmissions. There is absolutely no way anyone could "hack" your brain in the manner you describe with contemporary technology. While it would be possible in theory (after all, the brain is equivalent to a Turing-machine), there is no way it could actually be done today.
Note that social engineering is still possible, which might be considered brain hacking, but it is nothing more than being really convincing and tricking people into doing things they otherwise wouldn't. It won't alter your state of consciousness nor tamper with or directly read out your memories.
As for the philosophical implications of such a thought experiment, they are off-topic for this site, so I won't be going into them. Neurophenomenology is not part of information security.


Understanding Microsoft list of disallowed certificates Microsoft publishes their untrusted certificates as disallowedcerts.stl Warning: direct download.

It is ASN.1 encoded. After decoding it there is a list of sequences like so:

SEQUENCE {
                    OCTETSTRING dfbdd72f99c3b64a797e5ac96d59be56
                 }
SEQUENCE {
                    OCTETSTRING c668154be95e16adbc321abc316e384a
                 }

How does this relate to the revoked certificates? My first guess was serial number or other identifiers of a certificate, but that doesn't appear to be the case.

Any insight on this?

How does this relate to the revoked certificates?

these are MD5 hashes (thumbprints) of explicitly untrusted certificates.

  neither crt.sh nor censys.io were able to find them

and there are two reasons:

(main) they never were added to CT logs, because they were revoked long prior to when CT was adopted by CAB Forum.
CT logs use SHA-1 or SHA-256 hashes and don't store calculated MD5 hashes. You may need to traverse over entire CT Log tree and calculate MD5 for each certificate and determine if it matches the value in CTL.

  Do you have any information what the input to the hash function is to get these values?

raw binary certificate.


Can I detect a firmware toolkit like NightSkies on my iPhone? This article tells us that the NightSkies tool may have been put on iPhones enroute before distribution.  While there have been many iPhones, architectures, and security updates since 2008, is there a way to detect firmware toolsets like this one?

  The NightSkies documentation published by WikiLeaks, which is dated July 7, 2008, describes how to install the tool on “factory fresh” devices. WikiLeaks interpreted that to mean the CIA infects devices within Apple’s supply chain before they ever are received by a user.

The only real way to compare if a firmware image has been modified is to be able to take the firmware from the device, take a hash of it, and compare it to the hash of a known good copy.

The image taken from the device must be obtained in such a way that any malware on the device can't tamper with the image being exported (i.e. obtain the image before the system boots).  I'm not too familiar with iPhone forensic tools, so I couldn't tell you the cost to do something like this.

Do you have reason to believe you would be targeted by the CIA?  The reason I ask is because the more often tools like NightSkies are deployed, the sooner they will be detected, and will lose their value.  Intelligence agencies choose their targets carefully for this reason.  What was most likely occurring was interdiction; essentially, grabbing the device out of the mail before it went to the user, installing the malware, and then putting it back in the mail.  To summarize, if you or the organization you work for are not a target, you shouldn't worry about it too much.


how to understand openssl I am studying Openssl , but didn't getting that openssl is a tool/library.what is its main application and how it will be used?

And how this openssl is related to ipsec, i have studied the ipsec protocol there if i want to configure ipsec ,that openssl has to be installed(required package) why?

please anybody guide me, i am not getting the things correctly.

OpenSSL is a both a software library and a program (the "toolkit") which offers direct access to various features of that library.

A software library is a collection of program subroutines which doesn't do anything on its own but which can be used by other programs. In case of OpenSSL, these are subroutines which implement various cryptographic algorithms and protocols.

That means if a programmer wants to create a program which communicates encrypted, they don't need to implement the SSL protocol from scratch (or even worse, invent an own encryption system). They can simply link their program to the OpenSSL library and use the implementations which it provides.

This has various advantages.

The programmer saves a lot of time because there is less program code to type.
The programmer doesn't need to understand how the cryptographic primitives work on a deeper level. Cryptography is a very complicated and highly specialized field which very few programmers really understand (which is why we have a separate stackexchange site for it). So the availability of libraries like OpenSSL allows far more programmers to write programs with strong encryption, which benefits you as an end-user.
The programmer can use an implementation which is already widely tested by many other users, so it will likely have very few bugs.

IPsec is a protocol which uses a lot of encryption algorithms which are already available in OpenSSL. So the developers of your IPsec implementation likely saw these advantages and decided to make use of it. But that also means that their IPsec implementation doesn't work without it. That's why you need to install OpenSSL in order to enable IPsec.

But there is also a disadvantage: When OpenSSL does have a bug, that bug can potentially affect every single program which uses OpenSSL. This can create quite a fuss, like with the hearthbleed vulnerability in 2014.

Now about the program tookit OpenSSL. OpenSSL also comes with a command-line based program named openssl which allows to execute various functions from the OpenSSL library directly. For example the command line openssl dgst -sha256 -hex file.txt invokes the OpenSSL library function to generate the SHA256 message digest of the file file.txt and outputs it as a hexadecimal string. This usage is usually too cumbersome for normal end users, but can be useful for security professionals and server admins.


What is the opaque field in HTTP Digest Access Authentication used for? Is the opaque field really used for anything? It is specified in the RFC, but is not implemented in Apache. Also, the RFC does not state a reason for having opaque, it is only mentioned as a value that should be returned to the sender.

I'm thinking that it may be used to prove that the response-opaque came from a request that was made earlier in time.

If you drill into the An Extension to HTTP : Digest Access Authentication RFC, they define opaque as follows:

  opaque:
        A string of data, specified by the server, which should be
        returned by the client unchanged.  It is recommended that this
        string be base64 or hexadecimal data.  This field is a
        "quoted-string" as specified in section 2.2 of the HTTP/1.1
        specification.

which is pretty close to what you saw in the RFC you mentioned, further in the get into details a little more

  The opaque data is useful for transporting state information around.
  For example, a server could be responsible for authenticating content
  which actually sits on another server.  The first 401 response would
  include a domain field which includes the URI on the second server,
  and the opaque field for specifying state information.  The client
  will retry the request, at which time the server may respond with a
  301/302 redirection, pointing to the URI on the second server.  The
  client will follow the redirection, and pass the same Authorization
  header, including the  data which the second server may
  require.


Given a malware's name or signature, how can I know of my current installation of Kaspersky antivirus knows about it? Basically, I'm looking for an interface where the input would be the name of a malware, or its signature, and the output would be "malware found in the database" or "malware unknown"

The tool must search in my own database (which could be outdated or have miscelaneous problems). This is to test my own, current, specific installation, not Kaspersky as a brand.

Simple google's virustotal.com includes kaspersky.
Upload your file there, and see what kaspersky says, along with dozens of other av.

There is a size and rate limit, but you can sign up for a professional account if you need to do mass scanning.

Also there is an API you can use for scanning.

Using the virustotal API you can also use hash of the file.  There are 3 acceptable hashes, that I recall, one of which was SHA2.  I think you can submit all 3 for the same file if you wish.

They have a software developers kit that might help.
https://usa.kaspersky.com/antivirus-sdk

However, be prepared to PAY $$$$!


What architecture could be suitable for a secure environment? According to these slides on replacing UEFI with Linux:

  Between Linux and the hardware are at least 2 ½ kernels.

Are there any architectures that contain fewer layers between the main OS and the HW itself?

In short yes.

The 2.5 kernels the linked paper talks of are built into the processor and motherboard firmware. Specifically newer Intel processors on UEFI based boards.

There are endless devices that will happily run linux on far simpler boards. Most ARM based setups will have notably less between the OS and the hardware. A Raspberry Pi is an easy to point to example - although there is still a layer of firmware on the chip. There are also entirely open sourced boards like the beagle board. And then you have the option to simply go for older hardware.

However as @schroeder points out in the comments why would fewer layers translate to better security? If you don't trust the hardware manufacturer then how do you know that there isn't an additional hypervisor hidden deep within the chip? - especially seeing as most modern x86 processors have huge numbers of transistors which are never or extremely rarely used in normal operation.

If your security requirements drop to not trusting Intel/AMD then this is one of the simpler aspects you need to consider.


Analyze Windows executable How can I see which files, ports, URLs, etc that are used by a suspicious Windows executable.

This depends on how savvy the programmer of the malicious binary decides to be.

If it's a simple binary I would suggest first downloading Strings for Windows.  It's a version of the Linux programs of the same name.  It runs through and prints out all strings in a binary.  If the binary isn't encoded or packed this should give you what you want to know.  Once installed:

Bring up a command prompt: WindowsKey + r, type cmd and hit ENTER
cd <directory/of/binary>
strings <binary_name>.exe

A lot of output will be printed to the screen.   You can use strings <binary_name>.exe > output.txt to write it to a file.

If the binary is packed or encoded the easiest way to analyze a Windows binary for these things is a tool called PE Insider or CFF Explorer. PE Insider allows you to quickly look at the Portable Executable's headers, performs quick decompilation, and simple analysis.  CFF Explorer allows you to decode and unpack other resources within the binary.

The links provided should give you enough resources on how to use those tools.  For more information on malware analysis you can checkout How to Analyze a Piece of Malware, and Topics to Know When Analyzing Malware.


Is it possible to make a spoofing attack in a access point with same SSID target network? With an Evil Twin attack is it possible for the access point to send malware to connected devices? If it is, how can this be prevented?

Yes, all it takes is for an attacker to have a stronger signal. Due to how common it is for institutions to have multiple access points for a single wireless network, BSSID(an access point hardware identifier) is no longer used for network identification.

An attacker can use an off-the-shelf device like a Wifi Pineapple by Hak5. An attacker could also use a custom device that also acts as a rogue access point to perform a tailored attack(i.e., create a webpage with javascript that forces download) to a device. There are more sophisticated attacks, it may be worth looking into security of the 802.11 protocol or using Wireshark to sniff some of your own traffic and test out common attacks.

You can reduce your exposure to wireless attacks by using only trusted networks. If on public wifi use a VPN, or just skip it and use a cellular hotspot you control.


Service banner checking for vulnerabilities offline Has anybody seen a tool where you can collect Service banners from something like nmap, output them to a file, the vuln vulnerability checks offline?

Your proposed tool would perform a lookup of the version numbers against a database of known vulnerable versions. That could be scripted by hand and checked against something like metasploit, NSE, or exploit-db.com (if by 'offline', you mean 'away from the targets').

This would be very cursory in nature, so I doubt a tool pre-exists, but can easily be done by hand.


Eval Exploitation Payload I've got a basic PHP program that runs eval() and I'm trying to exploit it to read a file on the server. The program is:

$x=$_GET['x'];
$y=$_GET['y'];
$z=$_GET['z'];
echo eval("echo $x * $y / $z;");

The payload I believed would work is:

test.php?x=readfile("eval/key.txt");\");//&y=5&z=7

However I just receive a HTTP 500 error which I believe is a syntax error somewhere.

Can anyone point me where I've gone wrong?

Thanks!

Try removing the eval when you test it, to see what command is being run:

echo readfile("eval/key.txt");\");// * 5 / 7;

Do you see what went wrong? You're trying to escape the " and close the eval with );, but that's not part of what eval is actually running. eval is only evaluating echo $x * $y / $z;.

If you try readfile("eval/key.txt");// for $x you'll have better luck:

echo readfile("eval/key.txt");// * 5 / 7;


How to start pentesting/reverse engineering/cracking a software on Linux? (Docker based) TL:DR; What are good learning resources for security testing a software which runs with Docker on Ubuntu.
I am in junior position at this company, and they figured it would be good if I just test their software from security perspective. I already learned a bit about hacking, but it was mainly webservers, CTFs, Tryhackme, HTB, so nothing connected to RE or cracking. I don't know how to start, I mean, I found a lot of knowledge about RE on Windows, or CIS Docker Benchmark, but I didn't find any articles, specifically about reverse engineering/cracking on Docker on Linux.
The product is running on Ubuntu 18.04 server, on Docker, installed from a .deb package (Don't know if this helps :) )
What I looking for is some guidance on how to learn about cracking a software which is installed with Docker on Linux. Or what is the most easier or usually more valuable attack vector to look at, I mean, maybe try to crack the licensing, or try to use buffer overflow, how the "average attacker" thinks... Please tell me if I am missing some basics, and it is never mind that I crack/pentest on windows or docker or linux, then I will just start some book or complete course.
I understand that it is a broader topic than just following a step by step tutorial, but I have plenty of time for it to learn, so videos, books, articles everything which teaches purposefully Docker/Linux software test would be awesome.
Also, what do you think, which of the following could help to aim in the right direction?
Found some books:
https://kalitut.com/Best-reverse-engineering-books/
This can be related, and it was already helpful:
Is it possible to escalate privileges and escaping from a Docker container?
Also I found Liveoverflow videos, some related to docker, should I start the whole series?
https://www.youtube.com/watch?v=cPGZMt4cJ0I&list=PLhixgUqwRTjxglIswKp9mpkfPNfHkzyeN&index=55&ab_channel=LiveOverflow
Thank you very much in advance.

Use a debugger! Dynamic analysis is an exceptional way to learn how a "product" works.
What do you mean with "cracking a software which is installed with Docker on Linux"? It depends on which technology make that software run on the Linux OS. Is it an ELF? It is a Java JAR? A shell script? Basically, reverse engineering is about understanding how the software is running and what it does, but it really depends on which kind of software you want to analyze.


Double submit cookie: CSRF token doesn't need be a random value? Note: I have read the answer to this question, but found it unsatisfactory, probably because I don't understand enough about security.

I'm referring to a frontend server-side rendered SPA + a backend API, which needs to use cookies, and needs persistent login. Since I need cookies for server-side authentication, I want to eliminate any usage of LocalStorage for authentication (to (further) mitigate XSS)

Upon successful login, an httpOnly cookie is set by backend, auth_token, and is sent back to the client's browser. This contains the authentication token. It will be sent automatically with each request (as is every cookie).
Another cookie is set by backend, csrftoken, which is a long random string.
The frontend application (a JS framework) does NOT refer, store, or save auth_token anywhere in its code.
The frontend application code checks to see if there's a csrftoken cookie present, and if there is, attaches it as a custom header, X-CSRFToken, with the same value as csrftoken.
The server authenticates a user successfully if:

5.1 auth_token present and valid (database token)

5.2 csrftoken cookie + X-CSRFToken header are present and not empty

5.3 csrftoken cookie + X-CSRFTokenare equal

Here's my question: What's the difference between having csrftoken (and therefore the X-CSRFToken header) as a very long, random string, and something like 1? It is clearly stated in multiple places that a CSRF attacker can't create custom headers..If the difference is "brute-forcing" the CSRF token, please explain what that would entail, and how the X-CSRFToken header be set?

This question is your friend:

CSRF protection with custom headers (and without validating token)

In essence, if you opt to make your X-CSRFToken header something simple like 1, you are falling back simply on the presence of your custom header for CSRF protection.  If you have a fixed CSRF token for all users, then an attacker will easily be able to figure this out and will therefore know the CSRF token for all users.  Since this will naturally match the cookie you create for all users, an attacker will therefore automatically circumvent the cookie matching requirement of your CSRF system.

Therefore (repeating myself here), your CSRF protection will effectively boil down to the fact that you're checking for the presence of a custom header in the request.  This is not a crazy thing to do, because there are currently no known ways for an attacker to set a custom header in a CSRF attack.  So for now, this would actually be sufficient protection.  In that case though you also might as well not bother with the cookie, since it isn't actually providing additional protection.

Generally though (per the question I linked to above and its answers) checking only for a custom header is discouraged because things change and you never know when someone might find a way to set a custom header on a CSRF attack.  If that were to happen, your protection would no longer work and you would be vulnerable to a CSRF attack.

In the end though you have to decide what is the best way to balance the cost (of implementing this security measure) vs the benefit (of securing your application), and decide what security steps work best for you.  If your application is an anonymous website for voting on favorite cat pictures, I'd say just stick with the custom-header protection.  If you're securing the nuclear launch codes though, I'd go for proper CSRF protection (and a whole lot more!).


How to store my contacts encrypted? I use KeePass for storing my passwords.

What should I use if I want to store my several hundred contacts (name, phone number, email, etc) encrypted?

You can try to create an encrypted virtual disk. For example truecrypt provides a way to create encrypted files that can be used as storage. (All you need is to mount the file once with the pass and you can use it like any storage place, then unmount and it's secured)

Or else you can also crypt/uncrypt an archive file with GnuPG but that will be more a burden to decrypt everytime you want to access it then recrypt it etc.


Unusual case of Microsoft Calculator Pretty interesting series of event unfolded. I had a newly installed Windows Image downloaded from Microsoft Dreamspark/Imagine. less 3 weeks old with some security restriction policy, gpos etc. Anyhow I started to notice that I saw Cortana and MS Calculator would appear to use a some TCP traffic. Which Cortana was obvous but the calculator?

So I scanned the machine with Windows Defender, Maleware Bytes Anti Exploit and Rootkit and a Viper Scan.... Nothing on the Calculator. I would see the calculator spawned as a schedule task as well.

Unnerving me. I scanned it with YARA it had signature of using HIjack Network, UDP and TCP sockets, Keylogger, Screenshots, an Audio Dropper, Privalage escalation signatures etc as I suspected.

I since than deleted all the Windows Apps. (which is also DOD STIG requirement)

Has anyone seen this behavior? Any thoughts or explainations?
Why Did Malware Bytes and Microsoft fail to detect this as a virus? or exploit? I am almost assuming this is normal behavior?

The Calculator app has a currency conversion feature, which actually grabs conversion rates from the internet. As such this network traffic is normal.

Edit: To expand on this, Windows 10 has telemetry all over the place, but how much information is gathered depends on your privacy settings. If you're willing to read through an extremely detailed page about what is collected when the "Basic" privacy level setting is selected, this page by Microsoft should satisfy your needs. There is also this page by Microsoft that goes into the diagnostic data that is collected in version 1703 of Windows 10, which also includes information on how keyboard usage is collected.


What benefit to use different encryption key (passphrase) for different customers? When we store confidential information in our database, we encrypt it using AES. In addition, when customers install our product, they protect their machines using a firewall.

Should we use different encryption keys (passphrases) for different customers? What would be the benefits and/or drawbacks?

Added

We have Web UI system that access via a browser.
The encryption keys (passphrases) are stored on the server side.
Web client to not have access to encryption keys (passphrases).
Example of the confidential information: LDAP Bind DN password.
This password is used by server side when a user authenticated against LDAP.

Therefore all user should be able to use the encryption keys (passphrases) during LDAP authentication but no one need to read it (in fact nobody read it)

I highly suggest creating secure, random cryptographic keys every time you have to encrypt customer information via AES and enter it into the database.  Obviously, you will have to somehow store the keys since they will be randomly generated.  With that being said, I would suggest using a Hardware Security Module to store keys, but you should definitely check out this answer for more storage solutions.  Just make sure the data is encrypted and decrypted on the client's machine.

The benefit: Let's say an attacker compromised your customer database.  If he finds the encryption key, he has all of your customer's data, the encryption is rendered completely useless.  However, if the keys are randomly generated and stored in a Hardware Security Module, the attacker would basically have a useless database (unless he were to somehow get they keys from the HSM, which he shouldn't be able to do).  Your customer's security is an extremely important factor, and you should make sure you are doing everything you can to keep their information safe.


Does a buffer overflow vulnerability always mean a code execution vulnerability? Since buffer overflows always let an evil hacker write outside the buffer and overwrite the return pointer to a shellcode the evil hacker can place, does it mean that successful exploitation of a stack buffer overflow always means the ability to invoke a shell if done the right way? At least in theory, if you assume that DEP and ASLR is not in place.

No, a buffer overflow might:

Be against a buffer on the heap not the stack. This might still lead to code execution but will be much more complicated to exploit.
Be limited in size, so not able to overwrite return pointers. (e.g. be able to only write 1 byte beyond the buffer)
Be restricted in which bytes can be written, preventing suitable pointers to be written.
Overwrite stack cookies, which are detected before the return address is used. Unless the cookie is leaked, the exploit would crash the process the vast majority of the time, rather than leading to code execution.
Be on a stack growing upwards, so not be able to overwrite return addresses. An exploit might still be able to overwrite other local variables, or the buffer might be passed to another function, but wouldn't lead to code execution as reliably as downwards stacks.

Some of these might still lead to code execution, but other instances might be impossible to exploit.

However once you've found where a buffer overflow is happening it's usually much easier to fix it, than to prove it can't be exploited.


How to increase gadget occurence in a program I'm exercising with ROP. In a vulnerable program I control the RIP, use "ropeme" and search for gadgets I find many references to 32 bits long registers, but not a single extended register.

I need a simple "pop rdi; ret;" to pass the /bin/sh string to the system() function (I disabled alsr and stack-protector).

I tried using asm() to directly incorporate the gadget but of course it crashes the program, and when I enclose the function inside an if(0){} or another function that we don't call, the gadget doesn't appear inside ropme.

Is this standard that a small program will not have any code that references extended registers ? What shall I do to make the exploit possible using rop and return to libc ?

I assume you are compiling your program in x86-64 mode, otherwise there would be no chance (nor need) for popping rdi.  Generally speaking, smaller programs have fewer gadgets.  Particularly very simple programs tend not to have many gadgets that begin in the middle of long instructions, as longer programs/libraries may have.

Blocks compiled in if(0){} will never appear in the output of the program, even when optimization is disabled, this is likely to be completely ignored by the compiler.  Instead, you can use a global variable because it is hard for an optimizer to reason about the value of a global.

#include <stdio.h>

int foo = 0;

void callme() {
  asm volatile ("pop %%rdi\n\t"
      "ret"
      :
      :
      : "rdi");
}

int main(int argc, char **argv) {
  printf("Hello world!\n");
  if (foo == 0x55) {
    callme();
  }
}

The assembly in the function callme performs a pop rdi;ret sequence.  Because it is in GCC, AT&T syntax is expected, so registers require a %.  Unfortunately, the asm macro uses % as a meta-character, requiring the doubling up to escape a single %.  asm takes several arguments separated by colons (I do not know why they chose colons instead of commas).  The first is the assembly template, which can include auto-assigned registers if the programmer does not require control of their own registers.  The 2nd and 3rd are the destination (output) and source (input) registers.  The final one is a list of other registers that are overwritten by the assembly.  In normal use, this will tell the compiler how to allocate registers for this function.  Given that this function is not actually being used normally, but only for shellcoding, all of this is mostly optional, but I went with the long version for demonstration purposes here.

If you compile this code with gcc -O0 -o sample sample.c, and then dump the disassembly via objdump -d sample, you will see the function callme is included, and contains the gadget you are looking for.


Are anti-cheat software (VAC, EasyAntiCheat, BattlEye, etc.) considered as potential threats? Anti-cheat softwares are often flagged by antivirus as malware before they’re manually added to the whitelist, under the assumption that the people behind the anti-cheat act in good intention, and will continue to do so forever. From what I've read online, some of them are essentially keyloggers and/or screenwatchers (among other concerns of low-quality code). Isn’t this like pointing a gun to the user’s head and saying “don’t worry I won’t shoot unless I think you’re a cheater”?

If I bought/subscribed to a game that mandates installation of this software, what should I do (short of buying a separate computer dedicated just to gaming)? Or is this nothing significant to be concerned about, even if sensitive data (private keys for website databases/cryptocurrency wallets) is kept on the same computer?

To understand what anti-cheat softwares do, let me tell you what cheats do at first.

How cheat works: To achieve cheating, cheats are used methods like code injection into remote process, manipulation of remote process and data, interfacing pointer hooks, hijacking exception handling etc. To kept hidden, cheats often use methods like direct kernel object manipulation (used by rootkits), virtual address descriptor hiding etc. So when you are using cheats you are giving it permission to look and manipulate your memory and other sensitive stuff.

How Anti-cheat Software works: What anti-cheat software do is it detects cheats by signature and heuristics (mostly like anti-virus). Sometimes it blocks cheats by detecting obfuscating code or by sandboxing the application. Anti-cheat software like VAC compares MD5 of cheats from VAC's database with the (DLL) files of your hard drive. VAC also check your DNS caches and it’s explicitly searching for entries that correlate with specific cheats. Why does it work? Because The cheat connects to a remote server to see if the user’s license is valid — thus leaving an entry in the DNS cache. VAC catches that entry, and bans the user. Anti-cheat software like PunkBuster scan memory to detects the presence of cheats and if it found one, then kicks the player out from the server.

Is it security risk: Yes it is if it's not from a reliable source.  So like other software you should be careful about the digital signing, checking md5 etc. Some anti-cheat software installed with the game itself so you do not have to worry if you buy it from the official source and some are installed at servers end so you don't have to install anything hence you are clear. But the sensitive data you have mentioned are should be in a separate secure place where it's highly unlikely to infected by malware of any kind.


Ethics and economy in security research How can we design a market for information disclosure where individual security researchers may benefit economically in an ethical way?

Assume a market where the participants are governments, researchers (black and white), educational institutions, corporations, and non-profit non-governmental organizations.

What regulations or mechanisms would dampen profit for Black Hat individual researchers while allowing White Hat individual researchers to profit ethically?

What procedures or mechanisms would prevent abuse by governments where researchers reside or from companies for which researchers work?

There are a variety of approaches to promote the discovery and fixing of software vulnerabilities.  The most common ways to provide compensation to researchers are bug bounties (run by vendors) and vulnerability brokers (who buy and sell information on vulnerabilities applicable to popular software).  These are well described in A Comparison of Market Approaches to Software Vulnerability Disclosure (2006) by Rainer Böhme, but he notes that they are each badly flawed and don't lead to the kind of research investment or vendor engagement that we need to deal with the enormous problems of insecure software.  The black-hat vulnerability brokers, who don't release the exploits to the vendors, pay much more (a factor of 10?) to black-hat researchers than the more ethical brokers do.  The result is that a large fraction of the research goes underground and contributes to Internet insecurity rather than security.
I think that Böhme's proposal for exploit derivatives is a very promising form of market to explore, to achieve exactly what you're talking about.  It gives researchers a way to make money by discovering a vulnerability without having to disclose it in a dangerous way.  As Böhme writes:

consider a contract that pays its owner the sum of 100 EUR on, say, 30 June 2006 if there exists a remote root exploit against a precisely speciﬁed version of ssh on a deﬁned platform. It is easy to issue this kind of contacts, since you would sell it as a bundle with the inverse contract that pays 100 EUR if the ssh program is not broken within the maturity. Then, diﬀerent parties can trade the contracts on a electronic trading platform that matches bid and ask prices, settles the deals, and publishes the price quotes.
[This kind of market would attract a variety of groups of market participants:]
software users would demand contracts paying on breaches in order to hedge the risks they are exposed to due to their computer network.....
Software vendors could demand contracts that pay if their software remains secure as a means to signal to their customers that they trust their own system; or contracts that pay if their competitors’ software breaks.....
software vendors [could] use exploit derivatives as part of their compensation schemes to give developers an incentive to secure programming....
Finally, security experts could use the market to capitalize eﬀort in security analyses. If,
after a code review, they consider a software as
secure, they could buy contracts on the secure
state at a higher rate than the market price.

They are an application of "Binary options" to security events.  See Exploit Derivatives & National Security
 by Micah Schwalb for more details.
The main problem seems to be that various laws can be used in various jurisdictions to inhibit the flow of information about vulnerabilities, as Schwalb discusses, so that is something to work on, and he proposes an idea for enabling a pilot of this kind of market by making exceptions to the law for the emerging important but risky world of ipv6 vulnerabilities.
See other options, and more discussion on this site at: Progress in market approaches to software vulnerability disclosure? - IT Security - Stack Exchange


Bypassing OpenID Connect audience claim with implicit grant As an example, let's look at how authentication works with Kubernetes:

Specifically, let's focus on what the api server does. To authenticate the request, it:

Verifies that the JWT signature is valid
Checks that the JWT isn't expired
Checks that this user is authorized to use this API

There must be more to it than this! The thing about OIDC providers is they will hand out tokens with valid signatures to just about anyone. For example let's say I want to use Google as my identity provider. If the only requirement were that the JWT signature is valid, an attacker could set up some site I might like, say with funny cat pictures. At some point I visit the site and log in, and bingo, attacker has an identity JWT with a valid signature and my name on it. It would be Pretty Bad if the owner of funnycatpictures.com could now access the Kubernetes API server under my name.

So what specifically are the constraints that prevent this attack?

My understanding is the aud (audience) claim in the JWT is part of it: Kubernetes must accept the token only if aud contains its OAuth client ID. This should mean tokens issued to other OAuth clients (like the funny cat pictures site) won't be accepted because they will have the wrong aud.

However, there seems to be a way around this with the implicit grant flow, which doesn't require an OAuth client secret. As such, funnycatpictures.com could use the implicit flow but with the Kubernetes client id, thus obtaining tokens with the correct aud which would be accepted by the Kubernetes API server.

What prevents such an attack?

Scope. Cat pictures would not be granted the ability to request the scope for your API and thus not be able to access it with any resulting access token.
Also, in the implicit flow the callback url is registered against the client and must match exactly.


Do you need to hire a professional in order to be pci compliant? i run an organic food store, and after a conference call with my credit card service (card connect), do i really have to hire a PCI certified professional once a year in order to be pci compliant? If this is the case, how much does it cost?

Or am I just misreading things, i don't think any "cyber criminal" is going to target my business. NCR Silver handles all my credit card transactions.

If you handle credit card numbers, then yes, you have to be certified by a qualified auditor and this certification requires you hiring an external/independent PCI qualified security assessor.

However, you don't have to handle credit card numbers to be able to receive credit card payments. Instead, most smaller merchants use a PCI compliant payment processor like Stripe or PayPal to process card transactions. This reduces the scope of your PCI compliance signficantly, and you can be PCI compliant by just doing the PCI SAQ (Self Assessment Questionnaire), which you can do yourself without hiring a PCI auditor. Depending on your business type and how you handle card payments, there are different SAQs. The SAQ questionnaires will tell you if you need to actually use an auditor, which is primarily based on the volume of your expected transactions,  mechanism you integrate with your payment processor, and how you handle card data.

Primarily, you want to outsource as much as possible of your payment processing to the payment processor to reduce your scope and avoid handling card numbers.


How can I trust a server's public host key when I first login remotely? As I understand it, a host sends its public host key to the client to confirm it's the host the client intended to connect to. On initial login the host's public host key is added to the client's ~./ssh/known_hosts file or can pre-populated using ssh-keyscan.

This is fine for future logins, but how can I be sure that when I first login the host key is being sent from the host I intended to connect to and not one impersonating that host?

Many thanks.

In order to ensure 1st connection to ssh server, you have to verify his public host key.

For this, each new connection to an unknown host will prompt fingerprint and visual ascii graphic corresponding to host's public keys.

To make this verification, there are many different ways

Ask personely server's sysadmin for the fingerprint of the public host key (by phone, fax, meet or any trusted way)
Ask a confident friend who already done previous job
Go away but don't trust your connection until you could see physical proof you are on correct host (making a reverse connection from host, instant publication, etc).

From server side, when you install the SSH server, installation procedure implie host keys generation. At this point, all server keys are show with fingerprint and small ascii graphic you could check and compare.

This could be shown by the use of

ssh-keygen -lvf keyfile

Sample

mkdir /tmp/testsshkey && cd $_
ssh-keygen -b 1024 -f /tmp/testsshkey/key01
mv key01.pub other.pub
diff <(ssh-keygen -lvf key01) <(ssh-keygen -lvf other.pub )
1c1
< 1024 SHA256:7WuWSSOigkJ0UOPABdsrdkO3zYizPd3EfVpxb4XgeDk no comment (RSA)
---
> 1024 SHA256:7WuWSSOigkJ0UOPABdsrdkO3zYizPd3EfVpxb4XgeDk user@sondbox (RSA)

The only difference are in comments.


How to recover a lost zip file password? I have some files I was given by my teacher at University, I could chase him up, but I may as well try getting blood from a stone, his response rate isn't great and I completed my degree a year ago!

They're pdf files stored inside password protected zip files. The passwords are networking related, have upper and lowercase and numbers, but no special characters as far as I remember, and some are permutations of each other "passwordL1", "l2Password" etc.

What are the different encryption algorithms employed by .zip files?

How can I determine the protection in use on my zip files?

Where can I find good papers and tools, which will ultimately give me back the pdfs which are annoyingly hidden by the password?

If you haven't already looked at it there's a couple of sources I'd recommend for this.

John the ripper with the community jumbo patch supports zip cracking.  If you look at the supported modes there's some options (including the basic brute-force) for cracking zip passwords.
Elcomsoft have good zip crackers including guaranteed recovery under some circumstances
There are also some companies like this one who appear to have GPU accelerated zip cracking, which could speed things up depending on your hardware.

In terms of the approach it sounds like a dictionary based attack with mutation rules(so changing the dictionary with things like leet speak rules) would be the best bet, particularly if you've got the idea that the words would come from a specific domain.  Straight brute-force would likely not be a good idea as it tends to top out around 8 characters (unless you're throwing a lot of CPU/GPU power at it)


PKI Style web API authentication I am looking for a relatively simple (for the client to consume) but highly secure method for user authentication on my API. By secure I mean strong authentication. The API to be built will be RESTful and as such inherently stateless.

I do not want to use basic HTTP auth as the key must be passed in each API call. Even though the API will only be available over HTTPS there is always the possibility of a MITM attack due to the client trusting a malicious CA. Rather a long shot, but I'd like to do this right to protect the data being transmitted.

My proposal is to generate a key pair, give the private key to the client and hold the public and a finger print of the private key. The body of the API call would be encrypted with the private key and the finger print would be sent.

The server would then look up the fingerprint, match it to an account, retrieve the public key and attempt decryption. If it fails then it acts as though the user is not who they say they are (as indicated by the finger print).

Is my design secure?
Are there better alternatives?
Any advice/guidance would be greatly appreciated.

Client certificates are an established method which offer already what you need so that you don't need to invent your own. The process is even simpler than your version because you can just use existing libraries. The basic idea of having a key pair for the client is the same:

You create a certificate for the client or the client creates one itself. This certificate is either explicitly trusted by the server or implicitly because it was signed by the servers certificate authority (CA).
In the TLS handshake the server requests the certificate from the client. It checks if the certificate is a known and trusted one. If not the connection fails.
That's all.

It is impossible for a man in middle to actively intercept this connection by using a malicious CA because the man in the middle would need to rewrite both the server and client certificate. While you might not be able to control if the client trusts this malicious CA you can make sure that the server only trusts the known certificate or the certificates issued by the servers CA. This means an attacker can not fake the client certificate in a way that the server trusts it.


Unknown Asian/Chinese registry keys On a Windows Server 2008 machine found registry key "潓瑦慷敲卜湹潣敶祲" under HKEY_CURRENT_USER of the administrator account. It contains a value "敓癲捩剥湵楮杮" of type REG_DWORD which is set to 0.

I scanned the machine without a result with Kaspersky Rescue Disk 10, Avira AntiVir Rescue System,  F-Secure Rescue CD and Malwarebytes Anti-Malware Free. I also reinstalled all software that I manually installed since I last accessed this part of the registry in separate virtual machine under the assumption that a software installation might have inserted the registry key.

This leaves me with three imaginable scenarios:

The registry key was present when I last examined this part of the registry, I overlooked it and it was inserted by software installed on the server.
The registry key was inserted by software managed through Windows Update.
The Registry Editor misinterprets some encoding or the registry key is the result of some kind of encoding error.
The server was target of a custom attack and is infected with malware that is not recognized by standard software.

The last scenario seems unlikely, the affected system contains no valueable data and a targeted attack would probably leave no traces.

Machine translation software couldn't translate the strings to anything meaningful. Search engines don't have meaningful results for the strings.

Has anyone seems something like this? Do the strings have a translation?

the registry key is the result of some kind of encoding error.

This.

  潓瑦慷敲卜湹潣敶祲

encoded in UTF-16LE (Windows's usual encoding for Unicode strings) is the byte sequence:

53 6f 66 74 77 61 72 65 5c 53 79 6e 63 6f 76 65 72 79

Which represents the ASCII string:

Software\Syncovery

So it would seem Syncovery called a Win32 Unicode API to write a registry value, but passed strings that were actually ANSI. Whoops!

No indication of a security issue, unless you weren't expecting Syncovery to be running...


I have a scammer's phone number. Now what? I'm trying to ruin a scammer's day (fake check scam).  I have his phone number. I am able to call (and record) and text him. He is also willing to mail items to my house. What can I do to find out more about them using social engineering or through service providers? How might I be able to build a case against him, or scare or stop him from continuing scamming people?

I know I can call the FCC to report it, but I feel like that won't do anything. I also understand that I likely wont be able to get very far in following his trail.

Inform law enforcement.

You can't "build a case" because as a layman you likely have no idea about proper police procedure. Most evidence you collect will likely be inadmissible in court. You might in fact also break laws while you collect evidence (for example, recording phonecalls without the consent of the other party can be illegal in some places).

Attempting to scare them is a really bad idea. Remember that you are dealing with a criminal. That criminal might be violent or have contact to violent criminals. So when you try to intimidate them, they might turn that around and start to intimidate you instead.


How was the hacker able to get my Instagram tag through Facebook when they weren’t linked? All of this happened on 18th November 2020
A person I know sent me a phishing link of Facebook then Google, I entered my credentials however as soon as I found out that its a phishing link, I turned off my mobile WiFi and switched it off and I changed my Google Password immediately from another device which was my iPad, I didn't change my Facebook password because it didn't have any information of myself at all, but somehow he got to know my Instagram tag which he claimed to have got to know through Facebook but I never linked it, It just had the same email as my Instagram, so the only way he could've got to know my Instagram is if he had my Gmail account.
I downloaded the Google Data of my account and checked the login history of my account
It didn't show any other IP addresses or other devices rather than mine, there were 4 forgot passwords made on my Instagram which I got through the mail but when I checked my Instagram logins there wasn't any other login either (other than my devices and IP addresses) and my Gmail didn't have less secure app access turned on
When I booted my Mobile Phone again, the one where I opened the phishing link, I downloaded Bitdefender security and scanned my device and it didn't find any malware. The browser I used was a Hidden Calculator Browser, the guy who phished claimed that he used Social Engineering Toolkit first when he phished for Facebook and it didn't work so he tried phishing Google using HiddenEye and it worked.
I did an Nmap scan on my PC and it found an open port number 4445 named upnotifyp but this was only internal because when I told my friend to scan there was no open port on my IP address and I downloaded Avast WiFi inspector on my PC scanned my WiFi and Router and it said no vulnerabilities detected.
I'm having severe anxiety for weeks because my Google Photos had sensitive pics that were supposed to be my eyes only but I don't know whether he logged in or not because there was no IP address or device other than mine in Google Login History but he got to know my Instagram tag when it wasn't linked to Facebook, but he claimed to get it through Facebook, my Facebook and Insta only shared the same email ID and there's no other way he could've got to know my Insta other than having access to my mail,  but then again there were no other IP addresses and I can guarantee that this person wasn't using my WiFi, please help me out.

Mapping someone out on the internet is possible with OSINT. They would have used OSINT tools to find the various social media connections your gmail id would have. It's pretty interesting how much you can find out about someone with just an id or a full name.
And with respect to your phising, it's always important to be very cautious while opening links, always check the site address carefully the link is taking you to.


Is it safe to exclude my own registered domain from rebinding protection? I want to access my web server from the LAN and from the internet using the same name (www.my-own-domain.example). However, my router (Fritz!box) has rebind protection enabled and does not resolve DNS requests to local addresses. The router gives the option to exclude specific domains from this protection, but warns strongly to do so.

As I understand the rebinding security issue, it should be safe to exclude from the rebind protection a domain that I own.

Is my understanding correct or do I miss something?

After additional Internet searches, I cannot provide an authoritative answer, but I found additional supportive evidence that it is safe to exclude own domains.

on https://umbrella.cisco.com/blog/2008/04/14/finally-a-real-solution-to-dns-rebinding-attacks/ Cisco advices for their routers that addresses legitimately pointing to LAN addresses should be excluded:

  Those of you with domains that point to private address space
  legitimately (to your intranet, for example) should also visit the
  domain whitelist page and whitelist your domain.

on https://superuser.com/questions/1220839/my-router-false-positively-detects-dns-rebind-attack an answer is provided that recommends excluding the own domain in a situation similar to mine (but not commenting on the safety of that approach)


How to manage PGP private keys? I am trying to find out a way to protect files that will be stored on a drive accessible to the public. Using permissions is not an option in this case, so I am planning to encrypt the files using PGP (or GPG).

It is critical that the files be accessible quickly in an emergency (they are backup files for some important databases), possibly two or three years down the road, but only to one of about five people.

This would be easy if these five people were experienced GPG users, but most people in the team are very casual/occasional GPG users.

My general idea is to create a GPG key for that specific purpose, and distribute it to the team.

Here are my concerns:

Casual users may simply forget that they even have the key, or forget the pass phrase to their key ring or to the GPG key itself.
Our workstations get replaced on a fairly regular basis, and users may forget to transfer their GPG key ring (or the GPG key).

In the context of this question, I am not worried about usability issues (such as not remembering how to use gpg) - I'll address that separately with scripting and documentation in a knowledge base.

We will of course have one additional copy of the key on a USB stick in a vault, but I'm looking for additional ways to keep the key secure, yet keep it available quickly in an emergency.

Is this in a corporate setting?

If so, make a key without a passphrase, print the key on paper, stuff it in an envelope, and hand it to your HR or financial department. They're probably used to keeping stuff around for long times, and should have proper procedures for maintaining secrecy.

As it's on paper, it's a format we know the archival properties of; good paper easily keeps information legible for ten years. When you need the key, OCR it. If you print it in hexadecimal OCR will be highly accurate. You could even include QR code, which is even quicker to decode. Worst case? Punch it in by hand - this would probably take you an hour or two, but doable.

What you are doing is essentially trading a large, difficult-to-keep secret for a small, easy-to-keep secret.


Securing sesitive data from developers I have an enterprise application running that uses both MySQL and Mongodb datastores. My development team all have ssh access to the machine in order to perform application releases, maintenance etc. I recently raised a risk in the business when users started storing highly sensitive data on the application that the developers have indirect access to this data which caused a bit of a storm and have now been mandated with securing the data so that it is not accessible. To me this does not seem possible because if the application has access to the database then a developer with access to the machine and application source will always be able to access the data. I am sure I am not the only one who has this issue. Please advise me on how this is being done in other corporates.

The standard way of handling this is through segregation of duties.

Basically, it means that you have a team that handles deployment that is completely separate from the team that handles deployment in production and that you have a separate team that perform auditing.

Also, proper encryption of the database and key handling will help limit access to sensitive data: people who have access to the database servers (DBAs) usually are not granted access to the decryption keys while people having access to these decryption keys (typically the security team although it could also be the system administrators) are not granted access to the databases.

The devs, who usually needs to have access to both set of data for development and testing, are never granted access to production, only dev and pre-production systems.


How does IP address spoofing on the Internet work? Who can do it? Someone recently told me that the NSA could impersonate pretty much anyone they want by using IP address spoofing on the Internet.
But how would that work and to what extend is it true anyway?

Could any ISP in the world just spoof any IP address they wanted or is there some kind of protection against that?

IP Spoofing is NOT IP Hijacking which is causing confusion for anyone reading this. IP Spoofing at its minimum / bare bones explanation is also called impersonation. Let's have an ASCII look at what it does, and how it happens:

You (1.2.3.4) --> connect to your bank --> Bank (2.2.2.2)

In spoofing, I can pretend to be anyone I want, if I am on your network:

Me (1.2.3.4) to you --> I am 2.2.2.2 --> You
Me (1.2.3.4) to you --> I am Google.com --> You

This is a moot point because if you respond, I will NEVER see the response, I am not 2.2.2.2 nor Google. This is called blind spoofing. For impersonation, I want to pretend to be your bank without you knowing this, because I want to steal your money. Therefore I need to see your responses and your bank's response. Now I have to perform multiple impersonations. I have to pretend to you, that I am your bank, and I have to pretend to your bank, that I am you:

Me (1.2.3.5) --> to your ROUTING handler (be it a router or your routing table)
Me (1.2.3.5) --> I am 2.2.2.2 --> You
Me (1.2.3.5) --> I am 1.2.3.4 --> Your bank

For this to occur I MUST be in your infrastructure. Think of this as a proxy server. Using a proxy server the connection is the same:

Me (1.2.3.5) --> proxy server (1.2.3.10) --> Bank (2.2.2.2)
Bank responds --> proxy server --> Me

Traffic needs to flow to and from. In an IP Hijacking scenario, data is relayed, hence there is no spoofing (I can proxy to see everything) BGP Hijacking enables watching the wire. Someone ON the network that is performing the hijacking can then perform the spoofing.

Now in the case of an ISP/NSP/NAP, a government may take this approach:

You (1.2.3.4) --> ISP (1.2.3.1 default route) --> Bank (2.2.2.2) # Normal connection

In the above, this would be the non-tampered session that would occur. In say an NSA tapped network this is what would occur:

You (1.2.3.4) --> ISP (1.2.3.1) --> internal ISP proxy <-- NSA (1.2.4.1) --> Bank (2.2.2.2)

From your perspective, you are connecting to your ISP, then to your bank. You will never (and can never) see the proxying occurring. This is the kind spoofing/masquerating/impersonation done with systems created by companies like Narus that used a tap at AT&T to tap main connections.

There is little to be done on a scale of eavesdropping like this, as government agencies have the capabilities of using SSL certificates, and other means to prevent you from knowing what is going on. VPN tunneling won't prevent it, as you are at the mercy of your provider, and a warrant is a warrant.

There is no need for "BGP Hijacking", BCP filtering to even enter this discussion as BCP filtering will not counter the above proxy example. BCP filtering covers spoofing, not proxying, nor hijacking. If an attacker manages to manipulate the routing table on say your operating system, BCP is a moot point.


DNS Rebinding attack - will the victim's browser send cookies? How does a DNS Rebinding attack work? How can it violate the Same-origin policy?

Will the victim's browser send cookies to the remote server (specified by IP), when the domain is not the same as is in the cookie, created by the same remote server before (keeping the user session)?

"The attacker registers a domain (such as attacker.com) and delegates it to a DNS server he controls. The server is configured to respond with a very short time to live (TTL) record, preventing the response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the malicious client-side code.

The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the same-origin policy. However, when the victim's browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. For instance, he could reply with an internal IP address or the IP address of a target somewhere else on the Internet."

Simplifying:

Victim enter in evil.com
evil.com responds with X.X.X.X (IP of malicious server)
X.X.X.X loads a malicious script
Malicious scripts makes requests to evil.com (same domain)
But now evil.com responds with 201.82.108.103 (IP of Google)

Attack done!
The malicious script can now makes requests to Google (pseudo Cross-Site Scripting), because theoretically it is not violating same-origin policy. It is accessing Google, but using evil.com as domain, and it was loaded under evil.com, so the browser can not see any problem with the requests.


Breaking encryption with hash value of password? Can you break an encrypted volume if you know the source code of the crypto-tool used and the hash value of the secret passphrase? Why is it not possible to just reverse engineer the passphrase verification process of the crypto-tool by tricking it with the extracted hash value?

Specifically I was thinking about the popular truecrypt program, dm-crypt and self-encrypting-drives. Is the sensitive data on a self-encrypted-drive in danger if the attacker is able to obtain / extract the whole source code programmed on the chip of the SED and also the hash value of the passphrase?

A hash isn't used in encryption.  A key derivation function is used to turn a password in to a key and that key is used for decryption, not stored.  There should be no password hash.  Password hashes are stored for purposes of authentication where a password has to be compared to a previous input without the server knowing what the previous input was.


Alternative to sending password over mail? Recently I've started working as a contractor for a company, which requires me to often log in to different b2b services.

The way I receive the login data is usually over email in plain text. My gut feeling tells me sending sensitive data in plain text is not a good idea however I'm not sure if there is an alternative, or perhaps it is already protected by the mailing service (in this case gmail)?

I'm aware of probably the most obvious danger which would be leaving my email account logged in and unattended, however I'm more interested in some kind of a man in the middle attacks or other dangers.

Core of my question is:

Is there an alternative to sending passwords over email, and what would be biggest dangers of using email for this?

I commonly use a Password manager to store and share passwords. There are many password managers that have this functionality.

A password is shared from one account to the other, with the notification of the share sent via email to the other person, who can choose to accept, reject, or just ignore the share. The communication of the password is secure, while the notification of the share travels over less secure channels like email, thus using the strength of each method without compromising security. Some products will allow for the share of the password without disclosing the password to the receiver. In that case revoking the password becomes possible.

I highly recommend using a password manager for all of your passwords. Some commercial ones are LastPass, 1Password or Dashlane but there is also the possibility to host one yourself if you don't want to trust anyone. A quick google search of "password manager" should put you on the right tracks.


Is it bad practice to use the same password on different sites? Is it considered bad practice to use the same password on separate sites, if so why? Even if the passwords to a site are compromised the attacker still doesn't know the user names or sites the same password is used on, or even if the same password is used anywhere again at all!

For example if the database to hotmail.com is compromised and the attacker now wants to compromise yahoo.com, it seems unlikely that he would harvest usernames on yahoo.com and try each one of the compromised passwords from hotmail.com on each username on yahoo.com. So can anyone illustrate to me a scenario where this would aid an attacker if the same password was used more than once?

Even if the passwords to a site are compromised the attacker still doesn't know the user names or sites the same password is used on, or even if the same password is used anywhere again at all!

Why does he need to know? If he has a set of usernames and passwords, how will it hurt to try the set against common sites like Facebook, Twitter, Gmail etc? What are the odds of someone using the same password but different usernames?

Yes, it is bad practice. Use strong, random and unique passwords for each site.


SVG-Snippets in Access-Log: Probe or Error? I get some hits every then and there from different IPs, always the same scheme:

GET /blah/Resources/Public/Css/data:image/svg+xml;base64,... HTTP/1.1" 404 795 "http://some.referer/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)"

Browser seems outdated but legit, the base64-decoded svg-thingie seems legit too and reads:

<?xml version="1.0" ?>
<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%" viewBox="0     0 1 1" preserveAspectRatio="none">
  <linearGradient id="grad-ucgg-generated" gradientUnits="userSpaceOnUse" x1="0%" y1="0%" x2="0%" y2="100%">
  <stop offset="0%" stop-color="#fdf226" stop-opacity="1"/>
  <stop offset="100%" stop-color="#fad71b" stop-opacity="1"/>
  </linearGradient>
  <rect x="0" y="0" width="1" height="1" fill="url(#grad-ucgg-generated)" />
</svg>

so my question is: is this a probe? for what? i read this interesting paper on hidden svg-payload but cannot find anything malicious.

It looks like a CSS script (check out the Referrer field) might contain an inline SVG.

This kind of inlining is not supported by all browsers, though. So where a modern Firefox might see

src="data:image/svg+xml;base64..."

and display an image (or a SVG), an older browser would "believe" this to be a file name. So it appends the name to the base directory it was using, and blithely requests that filename. Which earns it a 404 instead of a cigar.

If this is the case, you either ignore the fact, or could use a Rewrite to answer with a remediation SVG to these malformed requests (it might be awkward if there's more than one SVG in the same virtual path - but you could use a SVG crafted to display 'Upgrade your browser!'), or modify the CSS, if you have access to it, to use a (slower) off-line SVG inclusion instead of the current online one.

Update

Apparently, this used to happen a lot with users of old browser which also installed some "browse enhancing" widget. The widget was probably injecting some JS/CSS in the page, and the result wasn't always correctly interpreted by the browser. Rendering a gradient background in SVG and embed it as a base64 string was a trick used for IE9.

So, I'm convinced that it's nothing you should worry about -- there is a problem somewhere but it definitely seems to be not your problem.


What to consider security wise, when having a mail catch-all policy? ... a catch-all usually refers to a mailbox on a domain that will "catch all" of the emails addressed to the domain that do not exist in the mail server. Configuring a catch-all address can help avoid losing emails due to misspelling. However, many email hosts no longer permit catch-alls since many spammers abuse the feature, spamming random email addresses. - Wikipedia

What to consider, security wise when having a mail catch-all policy? Or is having a mail catch-all policy somehow an (availability) risk because all emails will be processed and so it seems easier to cause resource exhaustion I guess?

What are the pro's and con's (security wise) of having such a policy?

PROS

Less likely to lose an email due to human error on the sending side.

CONS

If you're running anti-spam / antivirus that's scanning incoming emails for malware that scanning process can occur in the kernel to speed up the process. Any vulnerability in your antivirus / anti-spam (cough) Symantec could result in unnecessary exposure to exploit.
Depending on your antispam, if the resources for that AS is exhausted they can just freeze and stop processing emails, delivering them unscanned. I have seen antispam agents (albiet, less known & used ones) panic due to resource exhaustion and while the service was restarting email was delivered without being sanitized.
The addition of unncessary logs will make reviewing anti-spam logs cumbersome and if you should ever need them for foresnsics it will be that much more tedious to find what you're looking for.
The Pro is not really a great reason because NDR's should serve the purpose of notifying the sender in the instance the email address is incorrect. Granted that may not be the most desirable in instances where business can be lost due to emails not being delivered, but to me the cons outweigh the pros.


Could always-listening mobile apps secretly spy on conversations? Various apps and services available on modern smartphones constantly listen with the mic (e.g. Siri or Google Assistant listening for wake word, "Now Playing" feature on Pixel phones). To settle user privacy concerns, most of these services promise to only process the relevant bits of recorded audio (e.g. the voice command following the wake word, audio signatures of songs detected by "Now Playing").

How can users be sure that other captured sounds, such as private conversations, are not processed and transcribed locally on the device and sent to their servers in the form of encrypted text or audio signatures? Through compression, timing, obfuscation and encryption, they could make it hard or even impossible to detect such behaviour via traffic analysis.

My question is: Do users ultimately have rely on their trust, or are there any effective ways to verify the privacy-related promises these services make?

I’m grateful for any ideas and insights you can share on this!

Users can only rely on the word of the distributor of the app, which has proven problematic recently.

There is no easy way to technically prove, that no audio is recorded, analyzed or transmitted.


Security issues on allowing Special characters in input field I am building a web application, in which I am required to let user enter any character(even special characters - ~!@#$%^&*()_-+=|\{}[];:'"<,.>) in an input field. To mitigate the problems caused by them, I am taking care of two things -

SQL injection - using parameterized queries
Cross Site Scripting - HTML escaping user input before adding it to DOM.

Is it sufficient or am I missing something?

EDIT
For giving a better context, I am explaining the flow.

In my web application, user input goes directly to a database. It is fetched from the database to create HTML(also setting html elements attributes and styles) and JSON. I am escaping the fetched values from the database while creating HTML.

While creating JSON, I am not escaping those fetched values. This JSON is used by our another application to create HTML. And I am making sure that the values are escaped before inserted into HTML.

There's no such thing as special characters.

It all depends on the context that input is used within your application. Protecting against SQLi and XSS is great, however if the input is then to be used in an operating system shell call it does you no good.

Always encode or sanitize when the data is used - leave this as late as possible. For example when outputting to HTML, HTML encode at this point.

So without knowing all the output points or sinks in your application, it is impossible to say if you are missing something. If all you are doing is inserting data into a database, and outputting it to HTML (not JSON, JavaScript, CSS, etc) then if you do the correct parameterisation and HTML output encoding in the right places you are good as far as XSS and SQLi vulnerabilities go. Doing anything else with the data would require properly encoding, sanitizing or using the correct API depending on the format.


Python Pickle Deserialisation attack I know that untrusted data retrieved from a user should not be serialised/deserialised by an application because it can lead to a remote code execution.

What if that input is encoded upon retrieval from the user and is only being decoded after it is being deserialised? Would it still be vulnerable?

In this case I'm talking about base64 encoding.

If you take untrusted data, re-encode it another format (doesn't matter which), it's still untrusted data.  So yes, there's still a possibility of a vulnerability being exploited.


Am I right by changing the default algorithm on a web app? Numerous clients have told me that my suggestion on changing the algorithm on a web app does not increase security. I've tried reasoning that if the files have not been exposed, the attacker has to guess at the algorithm.

A few days ago I was assessing a friend's site and pointed out a few SQLi vulnerabilities. I didn't have any access to the files. Like above, my friend told me I was wrong to suggest a different algorithm even though he can handle the trade offs to a different algorithm.

My reasoning with him was that an attacker wouldn't know your algorithm so you ruled out a minority of attackers just by changing algo. If they used a tool like hashcat and tried to crack the hash with a preset, it wouldn't lead them anywhere. Even though this is security through obscurity, it works in a way that you defended yourself just a little if you have another SQLi.

He insisted on not changing the algorithm because anyone who exploits the site is an automatic white flag. He assumes that if a hash is retrieved, everyone will take the time to crack it.

The default hash is md5. I suggested PBKDF2 or bcrypt.

Just as a double opinion:
Who, in theory and actuality, is correct in this situation?

Is it correct that he should put up a white flag if someone retrieves an admin's hash?
Would I be correct in saying this is a practical use of security through obscurity?... Or if it's not security through obscurity at all?

Changing the algorithm "because the attacker will not know it" is a very poor reason for changing an algorithm. To begin with, the attacker may infer that you will use an algorithm for which support exists in the code, which limits the possible choices, and the algorithm can then often be disambiguated based on what can be seen on the output (if the output is 160 bits, that's SHA-1, not MD5).

It would be a severe delusion that changing the algorithm really brings, by that "attacker won't guess it" reasoning, significantly increased security. Algorithms cannot be assumed to be secret, because information about the algorithm leaks everywhere: in the code, in the code behaviour (e.g. execution time), in the head of developers... and the space of possible algorithms is tiny.

Now changing from MD5 to PBKDF2 or bcrypt is a very good idea. Not because the attacker would assume that it is MD5 and "never guess" that bcrypt was used; in fact, bcrypt's output tends to be obvious in that respect (they have a specific encoding of output + salt as a string which states clearly that bcrypt was used). But because a basic MD5 is a terrible way to hash passwords. If you want to store hashed passwords, at least do it correctly, which means, right now, PBKDF2 or bcrypt.


How CloudBleed is different from HeartBleed? given the recent exposure of the information leak stemmed from buffer-overrun of HTML-parser of CF's edge servers; fundamentally how it is different from HeartBleed?

CloudFlare have detailed the bug here: https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/

But can someone give it in layman's terms?

Both Heartbleed and Cloudbleed were webserver bugs that returned sensitive data from buffers that they shouldn't have.  That's the similarity (and why they're both called "bleed".)

One major difference is that Heartbleed was a fault in openssl, which is a library in use by millions of web servers.  Fixing Heartbleed required each web server to be patched.  Cloudbleed is a flaw in a proprietary web server, and only impacts Cloudflare hosted sites.  Cloudflare owns all the servers impacted, and has patched them all.

Another difference is that Cloudbleed was fixed and patched quickly upon discovery, preventing attackers from studying the flaw in depth and figuring out possible ways to use the leaked data to further exploit the servers.  Heartbleed was studied in detail over the long time it took to patch all the servers, and it was discovered that memory containing information regarding the private key could be stolen.

Yet another difference is that the data leaked by Cloudbleed was in the ordinary data stream returned by the web server, and the leaked data could linger in whatever search engines might have cached it.  The data leaked by Heartbleed was only in response to a heartbeat request message, which is not normally requested or cached by search engines.  (Thanks to @gowenfawr and @Krazor for pointing this out.)


How do digital signatures work - beginner's explanation? I'm new to cryptography, and I'm confused about digital signatures.

How do they work? Please illustrate with an example in a way that a beginner can understand.

While there are other answers on this site that walk through the maths of digital signatures, it can be difficult for people new to the field and to the maths to follow those answers. This is an attempt to bridge the gap in understanding.

There is only so far that a "beginner-level" answer can be provided because we are dealing with complex maths. So, permit a high-level explanation.

Alice writes a message
Alice creates a private and public key pair (this answer cannot go into the explanation of what these are - if you are stuck at this part, then you need to stop and read about these)
Alice creates a hash of the message (this answer also assumes that you know what a hash is)
Alice uses the hash and her private key to create a mathematical value called a signature (and that's as far that a beginner-level answer will go on this step)
Alice sends the message and the signature to Bob
Bob uses a "signature verification" process that includes creating a new hash of the message and Alice's public key as inputs.
"Signature verification" passes if Bob's hash of the message is the same as the hash Alice used when she signed the message, and if the public key matches Alice's private key.

Bob knows that the message was not changed since it was signed and that it was signed using Alice's private key.

This is a very high-level explanation of complex maths and there are a lot of subtleties in the processes that can change depending on the algorithms used.