Our valued sponsor

What tool can encrypt a laptop's data instantly when it's closed, and how do you set it up?

Register now
You must login or register to view hidden content on this page.
You have not described what the "hack" was :cool: so all of this is educated guess.

only ports for SFTP and HTTPS were opened.
firewall was activated and was restricting everything

it was a VPS(virtual machine on famous hosting provider's server)
it was managed through browser interfaces like many otherd VPS/droplets
SSH was done on a standard way, i made random keys with putty, uploaded private key through browser intreface...

bad thing i didn't have any logging except the standard one enabled, since i was very confident that issues can't occur

what i did not do, is changing default ssh port to some other, but still by not doing this, it could be a cause for server being down due to ddos, and not for someone to gain access to files

all scripts had input sanitized, and it was not able to deliver a hack that way

I am pretty much clueless when it comes to networks, but I think i covered most of the bases

If you don't have a specific knowledge, you should deploy a solution proposed by @0xDEADBEEF - a Teleport.

It sounds like your web application might have been vulnerable in multiple ways, not just to injection attacks [1]. Exposed HTTP(S) services often provide attackers with a foothold to infiltrate a server and escalate privileges to cause more damage. For the SSH part, I recommend setting up a jump server that is the only machine allowed to access your servers over port 22. You can then tunnel into this jump server and from there ‘jump’ to the rest of your infrastructure. Ensure that access to your jump server is tightly controlled with strict access policies. This approach significantly mitigates the risk of unauthorized access, brute forcing or password spraying.

A solution you can use is Teleport: Easiest, Most Secure Infrastructure Access (GitHub - gravitational/teleport: The easiest, and most secure way to access and protect all of your infrastructure.), which your IaaS provider can likely auto-deploy for you. ;)

Also a WAF like Cloudflare is the easiest to setup and will block threats on the application side. I don't want to go off topic too much, so if you want to go more in-depth about this, feel free to send me a message.


[1] OWASP Top Ten | OWASP Foundation

Ofc, never expose critical service or infrastructure to public. We don't know if you used that VPS for internal needs or were simply hosting a public facing website.

If you used Ubuntu as Linux O/S that means that you can filter traffic properly with default policy DROP - not REJECT (higher CPU usage and notification to adversary) - for all chains and allow only specific ports with both packet state and source and destination address filtering.
 
like i said, my network knowledge is far less competent than some other security aspects.
the https port has to be opened, since the web site has to be served to visitors (like on any other server)
the application was something fairly trivial using cgi, nothing complex, so i am sure any kind of injection was not possible

keep in mind server was set to communicate with SSH (RSA), and passphrase.
bruteforcing that is possible, but you and I would never try that, i am sure with a reason :)

jump server is a great idea, no question about.
cloudflare was something i implemented later to prevent them even knowing server's ip

anyhow, my point was that even as a above average user who pays attention a lot, things can go south.
below average or average people are better of using something secure out of the box like Apple does, and i am sure @0xDEADBEEF agrees with me
@mraleph i am not saying you are not right, but that type of security(IBM) is very hard to implement

****EDIT****
You have not described what the "hack" was :cool: so all of this is educated guess.
i wish i knew more. i just know files leaked. that is all.
it was my guess server got hacked, but did it actually happen, or not - it is just a speculation right now.
this example is far from ideal, i was just sharing my experience in a bar manner, none of this can't be used for a proper professional debate since a lot of things are missing (including the log of access).
sole purpose was to say that bad things can happen no matter what (but in fact we do not know if they actually happened on the way I think they did)
 
Last edited:
Back to OP's question; zero-day vulnerability may exist - even for cryptographic primitives and systems, CA and HA systems, network and system management services. It's up to architects and manager to identify risks and threats.

But, in our line of business - we already identified possible vectors for even those zero-days. There are no black swans - unknown unknowns - even regarding quantum computation and its impact on security of cryptographic systems. With properly segregated users, services and networks you can either limit damage or mitigate the risk completely, even for black swans.

Standard procedures starting with "update system on a regular basis", "implement security upgrades" and similar are for average users. We are facing polimorphic threats - for those, we don't have off the shelf solution. Just like a complex corporate and banking setup across jurisdictions :)

Rest assured that there are deployed and operational robust secure HA systems facing public network for which we didn't need z/OS and its ecosystem to have a leverage over adversaries.

Hell no, who would do a brute force. Some script kiddies maybe. Encrypted certificate is a good choice ;) Rainbows for RSA, perhaps :cool: ed25519 would be a better choice... Both will be degraded when QC is deployed so why not use faster solution?

Apple is a black box. For average user it's secure until it isn't. And, you should not be complacent - it isn't secure - not by IBM definition ;)

With @0xDEADBEEF an OPSEC thread will be written and possible about security of Apple and other declared-secure products and services.

I actually believe that you know a lot - Elbrus comment was very good, beside others - quite a lot and it is a pleasure discussing with you.
 
  • Like
Reactions: 0xDEADBEEF
get vera crypt its great and nobody can bypass that unless they know the password
there are multiple ways to bypass Veracrypt, for example bruteforcing the password or retrieving the encryption keys from computer's RAM.

yeah an you can setup 2 separate sessions with 2 different passwords. For instant you have session one with just trash and session two with the super secret stuff. Should one ak you for the password and put a gun to your head you can just give him the password for the session with trash and he will never find out there is another secret session with a different password!
imagine your hard drive is 1 TB, you decrypt the Veracrypt partition and it has 500 GB size. guess what the guy with a gun would ask you next?

But, TPM should be disabled and not be used in the first place.
TPM is your friend if set up correctly.
you should use TPM to calculate the firmware/bootloader/kernel checksums, to make sure your system was not tampered with. check this for more info: Heads Threat model
you must not use TPM to store your encryption keys.

We internally deprecated AES
this is a good idea. AES is a global standard and hardware AES acceleration exists in every single CPU and even inside microcontrollers like STM32 or ESP32, and that could potentially mean that 3-letter guys have "very accelerated" devices capable of brute-forcing AES...

it was managed through browser interfaces like many otherd VPS/droplets
the VPS control panel could have had vulnerabilities, I don't know which one you was using but for example you could google for "vesta RCE" or "webmin RCE" to get an idea.
 
there are multiple ways to bypass Veracrypt, for example bruteforcing the password or retrieving the encryption keys from computer's RAM.


imagine your hard drive is 1 TB, you decrypt the Veracrypt partition and it has 500 GB size. guess what the guy with a gun would ask you next?


TPM is your friend if set up correctly.
you should use TPM to calculate the firmware/bootloader/kernel checksums, to make sure your system was not tampered with. check this for more info: Heads Threat model
you must not use TPM to store your encryption keys.


this is a good idea. AES is a global standard and hardware AES acceleration exists in every single CPU and even inside microcontrollers like STM32 or ESP32, and that could potentially mean that 3-letter guys have "very accelerated" devices capable of brute-forcing AES...


the VPS control panel could have had vulnerabilities, I don't know which one you was using but for example you could google for "vesta RCE" or "webmin RCE" to get an idea.

Any O/S CDE/FDE solution has its intrinsic vulnerabilities. Depending on a threat model, some may be mitigated, but there are certain that can't be - at least in every case. Retrieving the encryption keys from RAM is one those intrinsic implementation vulnerabilities. There is a TRESOR which is a kernel patch but it relies on AES. Beside TRESOR, both Intel and AMD implemented SME (Secure memory encryption).

For any O/S CDE/FDE, AES should not be used as a single algorithm - Serpent or Twofish are far superior. In a (VeraCrypt) cascade, AES should be used in a middle.

Brute-forcing may be mitigated by using passphrase with minimum 16 chars from whole ASCII chars printable scope in a (pseudo)random pattern

Bash:
genpasswd() {
        local l=$1
        [ "$l" == "" ] && l=16
        tr -dc '~!@#$%^&*()_+[]{}:"|;\,./<>?1234567890qwertyuiopQWERTYUIOPasdfgHJKLASDFGHJKLzxcvbNMZXCVBNM' < /dev/random | head -c ${l} | xargs -0
}

TPM is a black-box. I may agree - there are historical parallels - that using enemy's tools may lead to higher security. Calculating the checksums may be one of those cases.

Using decoy or hidden volumes in any case - abduction, criminal proceedings or similar high stress environments - may lead to loss of higher values and not only data when adversary has elementary understanding of the storage and arithmetic.
 
imagine your hard drive is 1 TB, you decrypt the Veracrypt partition and it has 500 GB size. guess what the guy with a gun would ask you next?
So you need to learn how Veracrypt works, so you would not ask such questions which have no relvance!
 
So you need to learn how Veracrypt works, so you would not ask such questions which have no relvance!
imagine your hard drive is 1 TB, you decrypt the Veracrypt partition and it has 500 GB size. guess what the guy with a gun would ask you next?
I understand both of your points, but for this, as irrelevant as it may seem to the regular Joe, it happens more often than you can imagine, and it is NOT done by "criminals" (the way some of us have been brainwashed to what criminals are).

The solution to this is:

  1. Security Risks
  2. Private Military Companies: Blackwater
It works like a charm! If you are unfamiliar with this, start learning or pay one of them to teach you or give you classes.

I "inherited" this from my mentors over +40 years ago!
These X-Men are NO joke!
They have NO filters!
They do NOT mince words, and your trespassers WILL meet their makers! dev56"""
These X-Men take preemptive strikes to a whole new level! coo-:!y
 
So you need to learn how Veracrypt works, so you would not ask such questions which have no relvance!
you are right, my question was not really relevant because Veracrypt does not work as I've thought.
I've thought that it creates two separate partitions that would be easy to distinguish because each partitions's size would be smaller than the total container size, or because the hidden partition's header would be visible among the zero's in the free space after the end of the data written to the main partition.
but in reality there is only one, single partition in either "normal" or in a "double bottom" container, and it fills the whole size of the Veracrypt encrypted file (or encrypted hard drive), and also Veracrypt does not have "free space" as we know it - every single empty sector of the file/drive is filled with random data not with zeros.
I have just created a Veracrypt "double bottom" container and compared it to a normal drive:

scr.webp

on a normal drive there are zeroes after my text file filled with "A"s, showing that it is a free space, but on a Veracrypt container there is random data after my file filled with "A"s, so it will be very hard to determine if it is just a free space or there is another encrypted container.

I've never bothered to learn how that "double bottom" stuff works because it does not fit my treat model: in the country I'm from (and highly likely in the country I reside in too) you just will be tortured until you tell all passwords to all containers, both visible and hidden :D
and as such I don't believe in any hidden containers and simply do not keep any sensitive information on a permanent storage in my computer.
 
Last edited:
For any O/S CDE/FDE, AES should not be used as a single algorithm - Serpent or Twofish are far superior. In a (VeraCrypt) cascade, AES should be used in a middle.
Good to know ,thanks for the info, it's easy to setup with veracrypt.
 
  • Like
Reactions: mraleph and jafo
Register now
You must login or register to view hidden content on this page.