Telegram Visibility Into Secret Chat VS Plaintext

how do they do it?

From here (http://telegram.wiki/tips:linkparsing) it is clear that the links themselves are sent to the server to be parsed.

Therefore, they probably parse locally your secret text on client side to find links (not that hard to isolate links from the rest of the text) and send only those to the server, as is done in any other (non secret) chat.

As far as I can understand from their docs, they do it on the senders side. After you hit send, it goes encrypted to the other side. Therefore, the server side will not be sure if you did sent that link to anyone, if it was on a secret or non secret chat or just fetched the preview and canceled the message sending.

  but even that means they are also able to simply set their client to
  send the client's Secret Chat log to anyone they so choose;

You are right, nothing stops them from doing this if you do not trust that the client does not have a backdoor for that. But that is not related to Link previews. Even without anything like this, the simple fact that they do need to parse the unencrypted messages for displaying it to you is already a point where they could capture and send anything to a third party. The encryption end-to-end is only until it leaves one phone and gets to the other. Not before and after that. You type unencrypted data and read unencrypted data.

What this could add is a possible point of failure, ex some specially crafted link could exploit a bug and leak more than the URL. But if it is well implemented, it just leaks the URL, that you should allow it to do for the sake of using this resource.

IMHO, they should simply not add this functionality to secret chats. I dont think most users will understand exactly how much is not secret anymore when using it.


Is disk wiping required for full disk encryption if that disk was encrypted before?

Random bits of data can make up fragments or even whole files. While that doesn't happen too often, it depends on the importance of the data and will-power of individuals wanting to gain access to it. If the HDD/SSD was not wiped completely, it could contain traces of previous files/fragments/encrypted data that can be obtained. Erasing the HDD completely will remove traces of any potential files and is not considered a bad practice.

Not an expert, but I would assume that partial/broken encryption is irrecoverable even with an encryption key.


PKI: why is leaked CA certificate a threat?

As marstato seems to have already said, by 'Leaked CA certificate', they seem to be implying the private key for the signing certificate as well. Which would enable anyone to sign their own certificates and hence the issue.


Security implications of storing email attachments on Centos Server

Technically, a filesystem stores files as opaque sequences of bytes. There is no harm that the said bytes can do to your server as long as you do not try to "interpret" these bytes. Unfortunately, some operating systems are quite eager to interpret file contents, triggering heavy processing without explicit user consent; and that processing could have security holes exploited by maliciously crafted file contents. See this answer for details. Usual countermeasures apply: if you use a maintained OS (like CentOS) and apply published security fixes on a daily basis, then you should be fine. I would still recommend avoiding exploring the directory with a graphical file explorer, so as to avoid automatic interpretation of picture files.

Legally, any act of storing data coming from external sources can put you in trouble, depending on what the file contains and the legal framework in which you operate. When you have a mail server, it is rather unavoidable that you may receive just about anything by email, and most law systems will recognize that, as a technical service provider, you are not responsible for the email contents. It may still be worth talking to a lawyer, though, in particular if you envision creative storage systems. There can be privacy issues, too; you'd better protect access to the storage system for attachments as well as you would protect mailboxes themselves.

Note that safe email handling is not easy; it is considered bad form to lose emails when a badly timed power shortage occurs. Email sending systems are supposed never to physically destroy email data until the receiving system has duly announced that it has committed the email to a physical medium (which, in a Unix filesystem context, entails at least an fsync() call). If you split emails into their main body and separate attachments, then such handling becomes more complex; this is probably easier to do with a database than with a filesystem. Thus, I would recommend the database, not for security, but for reliability.


XSS

If the chat is vulnerable to XSS or not depends on what exactly the chat software does with the string you put in the [img] tag. Presumably it put it in the src attribute of an img HTML tag. As far as I know full control of the src attribute does not give you the ability to execute scripts, but there might still be some things you could try:

If the URL is not propertly filtered or encoded, try something like www.doesnotexist.com" onerror="alert('XSS');" .com.
If the URL is not quoted, you might be able to get around a filter by just not using any quotes.
If the image is wrapped in an a tag to make it clickable, so the URL ends up in a href attribute as well, you could try javascript:alert('XSS');. No image will be loaded, but if the reciever clicks on it the script will be executed. (Edit: I just noticed the www.*.com requierment. I don't think you could make this point work under that rule.)

There are probably more things you can try as well. Inspect the output HTML of the chat, and try different inputs to try to figure out what is going on behind the curtains.

Other issues

I will only briefly mention these, since your question is about XSS:

Privacy. This could be used to get the IP of the person you are chatting with. (Just send them an URL to an image on a server you control, then check the logs.)
CSRF. See Rápli András' answer. Not sure I would care about this though, since it is not an issue with your chat.
Password theaft. Send a URL for an image protected by basic auth, and the reciever will get a password pop up. It can be used to fool people into entering their credentials for the chat.


What about a minimal UNIX VM somewhere on your network (e.g. an Ubuntu live on your workstation) and then use the mail command?

You might want to configure a basic mail transfer agent to correctly queue mail to your SMTP server. Ubuntu uses Postfix, but there are many more such as Qmail and if you're brave, Sendmail.

Configuring a mail server is not an easy task and it might break your company policy. Make sure you're not doing anything contrary to your company's policies here.

Your solution with Python is also a good one.

And for a very, very basic solution there's also telnet.


Can employer see which state you are in if logged into their VPN?

They would be able to see the IP address of the incoming VPN connection (where you're dialing in from) and can perform lookups to see where that IP is registered.

This won't give them an exact location, but a city usually. It should also be noted that the information stored within the databases that these whois services reference might contain stale information so they're nowhere near fool proof. In addition these whois services typically state the location of the IP address is the location of the ISP office so accuracy can be off by hundreds of kilometres.


How to find out the IP address of email sender in Gmail

There is no technical way to get the ip-address of someone sending an email via the gmail web interface. Google does not put it into the email headers. And there is no API to query gmail for it.

If you really need that IP address for valid reasons, you need to get a court order.


End to end security of HTTPS websites over VPN

No. One of the end is your computer, not the VPN provider, so the connection is encrypted between you and Gmail.

The VPN just acts as an intermediary at the IP level, but HTTPS is handled at the application level.


Host based code injection defense vs anti virus?

This is based on information found here 1, 2

Bee Master is a research project that describes a mechanism for determining if a host-based code injection attack has occurred. It does this by running "honeypot" processes that have well-known behavior and then monitoring those processes to see if their behavior pattern changes.

While Bee Master seems to do an excellent job (see page 17) of identifying that an attack has occurred, it has no mechanism whatsoever for responding to such an attack. As Bee Master only indirectly detects attacks due to a change in behavior in one of its honeypot processes, it cannot always (perhaps never) what the attack vector was; it just knows that a honeypot process was tampered with.

It is far from clear what the appropriate response should be when an injection is detected.

While Bee Master only focuses on this indirect detection of viruses, more typical anti-virus applications focus on direct detection of malicious code (eg: via code examination or suspicious process activity), terminating the errant processes, and sanitizing the computer.


As Lampport OTP's doesn't require a shared secret, it is extremely feasible to use them, particularly where services which require successive authentication.

Assume the following

A = Hash(B)
B = Hash(C)
.
.
.
Y = Hash(Z)

The entire hash chain above will be generated at the client and will be stored. The exchanges between client and server will be as follows.

[Client] -----------A-----------> [Server] Stores A
[Client] -----------B-----------> [Server] Verifies if Hash(B) == A; If yes, authenticates and discard A and stores B. If No, authentication failure.
[Client] -----------C-----------> [Server] Verifies if Hash(C) == B; If yes, authenticates and discard B and stores C. If No, authentication failure.

And coming to your question, here is an example on how Lamport OTPs are used for securing client service interactions.


Is it there any way to detect payloads generated by veil framework

Veil is actually not too good at creating payloads that evade AV. I've created numerous payloads and they're all detected upon upload to Virus Total.

You could try the following:

Write a script to create a hash checksum of every file on a fresh, untainted install of your OS
Run the same script on your machine (with the suspect Veil infected files)
Compare the hashes
Any hashes that don't match up, replace the files with the untainted versions

Alternatively and a more safer way to go would be to wipe your system and start from scratch.


What are the chances to generate the same ssh key?

The chance is very much lower than any of these events:

The computer spontaneously catches fire during the key generation process.
Great Britain is wiped out by a falling asteroid during the very same second.
A rogue gorilla escaped from a zoo enters your living room and mauls you.
You win millions of dollars at the lottery three times in a row.

So the basic conclusion is that you should not worry about getting twice the same SSH key: it really will not happen in your lifetime.

On a more theoretical point of view, there are about 28164 possible 8192-bit RSA keys (that's really a lot). However, ssh-keygen will use a pseudo-random number generator which works over a much more reduced internal seed, which depends on the operating system but will typically have size at least 160 bits. This reduces the number of possible keys to a much lower (but still huge) number, 2160. Even with tremendous computing power (I am not talking about a bored student with a few dozens of PC; rather, think "Google"), probability of finding the very same key after a few years of effort is less than 2-100. Comparatively, the events I list above can be estimated to occur with probabilities roughly equal to 2-45, 2-50, 2-60 and 2-71, respectively: these are billions of times more probable.

Of course, with a flawed PRNG, anything goes.


Can my online activity be detected with this set up?

It is not possible to tell with the information given. The real question becomes how that Aruba device works as Shroeder mentions. My instinct is that no, someone from your work network can not connect to anything on your home network that is not plugged in or logged into that Aruba device.

That said, run some tests:

Log into everything as you tend to use it. Reach out to a friend at work for help with this as you need someone on the work network.

1: Try to ping your friends computer. Can you see it on the corporate network? You can do this by running the command ipconfig on their computer to get the IP address and then typing "ping [ip address]" on your computer at home and seeing if it succeeds.

2: Try the same thing from the other direction. Can your friend ping your computer?

3: Find the IP address of your home computer that is not plugged into the Aruba. Can you ping it? If not, that's a good sign.

4: If you can ping it, can your work friend also ping it?

5:Find the IP of your home router (probably 192.168.0.1) and ping it from your work laptop. Can you reach it?

If you and your friend can't ping your home computer, you should be fine as far as a work "pipe" into your network. You probably have different subnets (work vs. home) and won't be able to route between them anyway unless Aruba is handling that somehow. If somehow your work friend can reach your home router (even if they can't reach anything else) they could probably exploit it and add a route to your network. Definitely make sure you are not using factory defaults on your home router and that "remote access from the internet" is disabled on your home router.


Between point to point connectivity and remote network access, which is riskier?

This is a very general question. You must start with a blank sheet of paper and draw what (application, service, ,...) needs to be accessed by whom (local or remote users, ...) and how (via which route).

With this in mind you must decide what is the most restrictive access you can afford, starting with having your service hosted on Internet without connectivity to your network (which will probably not work) and then slowly bringing it in through the network layers (DMZ, LAN, ...). At the same time look at how the third party will access the service (it does not have to be VPN, it could be SSL to an application, or a virtual desktop, ...).

This is to say that there is no definite answer to your question, it is entirely dependent on the service, on your network configuration, and the general architecture.

EDIT following comment (very broadly):

VPN: an extension of the network which bridges a computer to a computer, a computer to a network or a network to a network
virtual desktop: a service which provides a virtual environment (equivalent to a physical desktop) which is accessed via a browser or a specific client (RDP for instance).
Application: access to data is done via a web application, directly exposed to Internet, or limited to a set of IPs, to browsers which can provide a certificate, etc.


For remotely unlocking LUKS volumes via SSH, how can I verify integrity before sending passphrase?

You don't. You can't.

The best you can do is a trusted boot pathway using TPM which you make part of the partition unlocking process. But unless the hardware is locked to your personal signing key (which it probably isn't), then even that can be subverted.

Still, TPM is probably the closest you can get. This is non-trivial to implement, and it is unlikely that you'll find an off-the-shelf solution for this.


Is there a way to prevent comments from being abused for command and control?

If you allow content generated by others at your site there is no way to detect if the content contains hidden messages in all cases because there are simply many ways such content could be embedded. Any attempts to detect and block such content have the risk of overblocking and thus impacting innocent users. From the example of the Instagram comments you see that the attacker only needs to hide a message of a few bytes in a much larger message. Such small hidden content could be spread over multiple comments (like using the first character from each comment only), could be contained in the username, could be hidden in the timestamp, could be contained in images ... .

At most you could try to detect the bots which read this message in that they don't really look or behave like real users. But also in this case it would not be too hard for an attacker to fool such detection system or make it throw lots of false positives so that it impacts innocent users of the site.


Re-run nmap OS fingerprint match with existing subject fingerprint

There is not a public tool to do this, but you can cobble one together pretty easily with a few functions from osscan.cc:

Load the fingerprints from nmap-os-db with parse_fingerprint_file.
Parse the observed fingerprint you want to test with parse_single_fingerprint.
Check for a match with match_fingerprint.
Print the results.


There isn't really a security difference if both desktop app and browser app are properly built.  Yet, I would definitely lean towards the browser app because you get several features "for free" (e.g. PKI for HTTPS).

All security measures that are present in modern browsers can be built into a desktop app alright.  The problem is that that would likely require more development effort and allow for more places where mistakes can happen.

Let's have some fun with counterarguments now:

  Desktop is safer since it stops random people from manipulating our data if they don't have the program

LOL!  < sarcasm >Yeah, reverse engineering does not exist, and obscurity can prevent eavesdropping < / sarcasm >.

With the amount of computing power we have today security through obscurity is getting less and less possible.  A couple of megabytes of traffic dumped into a statistical model can construct a specification of how data is sent.  And, unless you will never repeat the same commands to the admin interface, you cannot escape from a statistical model by using obscurity only.

Your only option is encryption.  Which means you will need to implement full TLS.  And by full I mean TLS (you could use openssl for this part) and HSTS, and a revocation path for compromised certs, and a CSP would be good as well.  And all that carefully enough to not make mistakes.  Cryptography does not allow space for coding mistakes.

  Rival company is employing this method. Currently they are no.1 in the market

MasterCard still uses mainframes to process (some of their) Chipcard data.  And still send different clearing files in distinct EBCDIC flavours.  Shall we all use mainframes for payments?

You can still make mistakes in the web app and make it worse than a desktop app.  But there is a lot of documentation about securing web apps.

There are also good frameworks to build desktop apps that come bundled with TLS communication.  Using one of those (Python paramiko and Microsoft WIF come to my mind) is an option but see the next section:

Extra point

The Achilles heel (in terms of security) of desktop apps is their dependency tree.  A desktop app will require dozens of libraries, which may have security bugs.  You will need to keep an eye on the CVEs for all libraries.  And, if one of the libraries turns out to not be very popular, there will not be many bughunters looking at it.

(That's also true with unpopular JavaScript libraries though)

And finally come the desktop app updates.  You found that your desktop app is vulnerable to something and patched it.  Good!  But now you need to distribute the new version to everyone using it, including that guy who is working from home for the past two months.  OK, you may send him an email with the new installer.  But wait, can't the email be tampered with?  Or even in a more mundane point, can you be sure that he will update his app?

A web app is much easier to update.


SSH works exactly the same way when logging in to an EC2 instance in AWS and when logging in to a git repo on github.
cryptography mumbo-jumbo
SSH is an old protocol from the 90s. Like SSL/TLS and IPSec, it has evolved since the 90s and the default (and even "must-implement") cipher suites from the 90s are no longer a good idea and should not be supported.
Everyone has converged on X25519-Ed25519-ChaCha20-Poly1305 as the best default cipher suite, with the following options/fallbacks:

AES-GCM used instead of ChaPoly in case your device has hardware AES and CLMUL instructions and you care about the difference between 1.7GB/s and 4.8GB/s (per core)

ECDHE over NIST P-256 instead of X25519 if you don't support X25519

RSA-PSS (with 2048, 3072 or 4096 bits) instead of Ed25519 if you don't support Ed25519

RSA-PKCS#1v1.5 (with 2048, 3072 or 4096 bits) instead of RSA-PSS if you don't support RSA-PSS

TL;DR: If you use a recent (8.x) version of openssh on the server and on the client, you don't need to worry about any of this - the defaults are fine. The latest version (>=0.74) of putty is also ok.
SSH host keys
EC2 will generate new host key for a new VM and you will need to use TOFU with the ssh host key.
Github doesn't create a new server for you, so it has published long term SSH host keys which you should verify when first connecting to github.
SSH user keys
In both cases (EC2 and github) you should generate the user keypair yourself on your own computer using ssh-keygen (or puttygen or equivalent) and upload the public key to the server that will authenticate you, either in the openssh authorized_keys format or in the PEM format (they carry the same data).
In AWS EC2, the option to generate your own user SSH keypair is present ("choose an existing key pair" and then use a public key you have previously uploaded), but it also has the option to let AWS generate a new SSH keypair for you, let you download it as a PEM file, and then use it (puttygen can import it to convert to a putty--format private key, and openssh can decode it and let you see the private key values, if you want). AWS might say: if you don't trust AWS with that key, why do you trust them with the VM?
But there are risks:

You might be tempted to use the same keypair for other things (like github), and if so then AWS has access to your account at github.

AWS might leak the private key it generated for you, though they should delete it after you download it.

Well, you shouldn't use that option - there is no need. The risks are real, while the benefits are non-existent. Just generate a keypair on your laptop and upload the public key to AWS.


Impact analysis of CVE-2016-1000341 affecting BouncyCastle

TLDR: 1a.

DSA signature generation is generating a signature (for data). As you quoted

  ... gain information about the signatures [sic - should have an apostrophe] k value and ultimately the private value as well.

k is a value that is chosen randomly for each signature and is not part of the key, so it could not be part of key generation (or parameter generation which in DSA is often conflated, including in Java/JCE/BC). In order for there to be a k value at risk, the operation must be signature generation.

Verifying a signature, called signature verification, is not affected because it does not use the privatekey which is the target of sidechannel attacks including timing.


Completely encrypting virtual machine (for free)

You can not securely use encrypted virtual machines without full disk encryption on the host.

While the virtual machine is running, the host stores memory chunks, log data, configurations, and loads of other files on disk, leaving permanent forensic trail of a live decrypted virtual machine. File and project names will almost certainly be recoverable.

If you really have to, you can create a Truecrypt volume (it works fine on all Windows versions) and install VMware in it. The install would work only on the original computer you did the installation on.

If you are really paranoid, you can encrypt and external HDD with Truecrypt, and create a hidden partition it with VMware and virtual machines.
Don't write too much data in the original drive, as it would destroy the hidden partition, unless that was the intention ;)


Is this encrypted information? Why is it in a URL?

No. The link propably contains the full url of the article that wasnt relevant, and also user details of the user that sends "this is not relevant", so only those that received the report can tell that "this is not relevant".

Its not security-by-obscurity, rather, its a link with authentication data embedded, so you don't have to type your username/password or ask the company manager to tell "this is not relevant".

The reason to encrypt the url also, is that a integrity-verifying code at the end, can ensure, that authentication data belongning to link 1 cannot be misused to link 2. Eg, when you have clicked that link, then the corresponding article is then marked as not relevant. If some unauthorized individual clicks the link again, it does not matter since the article is already marked as not relevant.

The encryption then prevents someone from changing the article url/article id inside the link so one link cannot be misused to mark another article as not relevant, or misusing the link for other things like unsubscribing or such.

Think the link as this:
http://example.org/auth?username=somebody&password=somepassw0rd&action=markasnotrelevant&url=http://www.somenewssite.com/article/article39587395837u59.html&hash=5acf768c5fcafac85afc785fc8c
and then you encrypt that with a symmetric algoritm, and then encode as urlsafe base64, before sending it out.
Since the server created the encrypted link, the server can also decrypt the information with the same symmetric key, but nobody can abuse the information stored in the link.

It has NOTHING to do with DELETE/PUT and such HTTP verbs. A browser is normally unable to send anything else than GET/HEAD/POST, so the request done is a GET in the above case.


Doesn't Hashing Negate Quantum Computer Cracking?

Shors algorithm breaks the assumption that finding primes pairs is hard (one of the main assumptions of algorithms like RSA).
So Shors Algorithm allows you to 'quickly' find the matching prime pair given a known prime (e.a. the public key)

Elliptical Curve Algorithms are not vulnerable to Shors algorithm, (and currently there is no known algorithm to shorten it)

The above is Wrong. Eleptical curves are also vulnerable to Shors algorithm
So your assumptions are wrong:

Do you need to break the hashing/salting: No
Do you need to capture the key: No

What you need is some processing and the Public key of something (e.g. the key you do not keep secret and here with everybody)


Digital Ocean "Droplet" allgedly compromised for trivial, unpublicized website. Should I be worried abouty my own machine?

The presence of any service on the Internet will lead to it being attacked to a certain degree, as some attackers are just looking for free resources (bandwidth, CPU power) and don't really care too much about what's on the host.

Assuming that you patch the OS it's not too likely that the SSH service was compromised directly, but if you're running a web application, a security flaw in that (for example SQL Injection or Remote File Inclusion) could allow the attacker to take control of the system.

Assuming you have backups the best bet would be to destroy the droplet and recreate the system but also to review the security of your web application.


Can the person who buys my old number access my old Viber contacts?

Assuming the platform works similar to WhatsApp or Signal Private Messenger. Viber should only use your phone number as a unique identifier, and no content (contacts or messages) should be stored on the server side.

This seems to be confirmed by Viber such that message backups are done through a cloud service; Google Drive or iCloud. Also, Viber uses end-to-end encryption, so their servers cannot see the content of messages, only metadata.

Consequently, if someone does receive your old phone number, no messages can be seen (as no content is stored by Viber), and the same is applicable to contacts.


Protecting against cross-subdomain cookie attacks

The specific scenario can be prevented easily: Create a new sessionid on login.

Please note that the issues exists across domains, if the sessionid is an url-parameter.

Generating a new sesionid, however, not be sufficient to prevent other kinds of attack: Once Alice is logged in and visits Mallory's subdomain, will the cookie be transmitted?

It is common practice to use a completely different domain for all trusted activity. For example Google uses google.com for trusted activities and *.googleusercontent.com for untrusted sites.


If you are running the service from your home then it will need to listen on port 443.  You will need to open this port on your allowed incoming traffic of your router.


Best practices manual for Alienvault USM?

This cannot be answered in general because this depends on your requirements. The vulerablity scanner unitilized by Alienvaults OSSIM/USM is OpenVAS. So the right place to look after information about the processes launched is in the OpenVAS documentation.

From my experience I can tell you that an extensive test will likely cause some trouble with blackbox devices. I have seen cheap switches and embeded devices (aka IOT devices) that go down even in an allegedly non harmfull scan. This is of cause a useful result of such a scan but it is of cause not very pleasant for the users. This is why I only do default scans in the week and extensive scans at the weekend. To get a realistic result I use wake on lan to start all workstations s they can be scanned even on the weekend.


Encryption using multiple Yubikeys, any of which can unlock

Since Yubikey supports OpenPGP. So yes, you just need to address any messages you encrypt to both the recipients and and the backup key. PGP messages can have multiple recipients.

You'll also need to tell people sending messages to you, to also address your backup key, or to reencrypt their message to your backup key whenever you receive them.


How do WPS (Wi-Fi Positioning System) databases have the MAC Addresses of the networks?

Wardriving is now out of date, if you're a corporation that sells phones. Google used to perform wardriving with their Street View trucks, but they no longer do. You might describe the modern tactic as "distributed war-usering". A ZDNet article entitled "How Google--and everyone else--gets Wi-Fi location data" describes the process:

  How it works, according to Google, is that the Android Location Services periodically checks on your location using GPS, Cell-ID, and Wi-Fi to locate your device. When it does this, your Android phone will send back publicly broadcast Wi-Fi access points' Service set identifier (SSID) and Media Access Control (MAC) data. Again, this isn't just how Google does it; it's how everyone does it. It's Industry practice for location database vendors.

To describe a simple case: your Android phone has GPS and Wifi turned on. Your phone sends a message to Google saying, "I am at long/lat location (X,Y), and I can see two Wifi networks; one with SSID Foobar (with MAC 11:22:...) and another with SSID Bazzle (with MAC address 33:44:...)." Google uses this information to learn that networks with those particular SSIDs and MACs are near geographic location (X,Y).

Thus, when a user without GPS wants to know his location, his phone can say to Google, "I see Bazzle with MAC 33:44:..." and Google can respond that he is probably near location (X,Y).

EDIT

The MAC address of an access point is no more private than its SSID. Wifi encryption can protect the information above the media-exchange level, but currently no Wifi protocols encrypt the Level 2 communication. The advertised MAC addresses of participants in any Wifi communication is public information to anyone nearby.


Perfect forward secrecy in Instant Messaging with multiple devices

I understand that in order to have PFS you must use different keys to
  encrypt messages. So your IM client could be generating a new key for
  every message you write (or every few messages).

  This would mean that DH exchange will happen to generate a new key and
  then both IM clients should have that key so the sender can encrypt
  the message with it and the receiver can decrypt it.

  Did I understood it right so far ?

Not quite.

PFS is the property that plaintext confidentiality for passively captured ciphertexts is retained even if a long-term key is compromised.

As an example of a system without PFS, in traditional SSL/TLS configurations one might use the long-term RSA keypair (from the certificate) as a way to exchange a session key. This is called static key exchange. The problem is that if an attacker records all sessions and compromises the certificate at a later date, they may decrypt those sessions using the RSA key. This is, understandably, a problem.

TLS uses Diffie-Hellman (DH) in an ephemeral manner, known as DHE. Ephemeral, in this case, means that the keys or parameters used to exchange the key are discarded after the session is created.

Diffie-Hellman has the property that two parties can agree upon a shared secret in a context where an attacker is watching, without exposing that secret to an attacker. An incredibly simplified (mathematically incorrect, but more intuitive) description of DH would be that Alice generates a pair of values As and Ap (secret and public) and Bob generates a pair of values Bs and Bp (again, secret and public), each with certain special mathematical properties. By exchanging Ap and Bp, both Alice and Bob can calculate the same resulting secret value x. If Eve, an eavesdropper, listens in on the exchange of these values (i.e. she knows both Ap and Bp), she cannot calculate x because she does not know As and Bs (i.e. the secret parts).

As a short aside, DH on its own has a problem: an active attacker can man-in-the-middle the DH exchange and interpose their own secret values in order to compromise the connection. DH alone has no resistance to active tampering, and we generally call this kind of usage "anonymous DH" or ADH. In TLS we solve this by signing the exchanged DH values with the long-term RSA key in order to prove that they have not been modified.

Diffie-Hellman Ephemeral (DHE) works by randomly generating the DH secrets for each session, exchanging the public parts, then throwing those secrets away after x is calculated. You'll notice in the exchange between Alice and Bob above that the As and Bs parts are never transmitted, and that Eve cannot calculate x without them. Once As and Bs are discarded, nobody can recreate x. If you compromise the long-term RSA key, you cannot recover plaintexts from previously recorded sessions and ciphertexts.

  But then I see that some IM clients allow using multiple devices to
  access encrypted messages.

  Does this mean that the private key and the encryption keys would need
  to be copied to every device ? Is not this a security risk ?

  Is there any protocol or cryptographic method to copy this private key and encryption keys securely to other devices ?

Multi-party encryption is complicated and there are a bunch of different mechanisms that are involved. I personally think that Signal's double ratchet algorithm is one of the most easily understood and elegant solutions to the problem, but even that is a fairly involved system. I recommend that you read the paper as it is very well written with minimal crypto jargon.

The way these protocols generally work is that you have some sort of long-term identity key that gets exchanged between devices in some way (e.g. via QR code) when you pair them to your account. This key gives you different levels of access depending on the protocol - in the case of Signal and WhatsApp it allows that device to "join" a group chat in your name. When any party in the group sends a message, it encrypts it for each of the other parties (including each individual party sharing the same identity) so that they can decrypt it. I recommend reading this other question for a wider background on how WhatsApp (and Signal) perform group chats. One critical factor here is that the identity key is only used to sign the prekey, which is effectively a surrogate for the identity key which can be rotated periodically. This means that the long-term key itself is never used to sign bulk data, which limits its exposure significantly and allows for it to be expunged from memory after a prekey is signed.

The ratchet part of the algorithm refers to some cryptographic processes which allow for keys to be continually derived in a chain. These processes allow an individual derived key to become compromised without compromising other keys in the chain. There generally need to be multiple different key compromises of different types in order to more completely compromise the chain and decrypt prior and future messages. This results in a number of forward secrecy properties for messages.

To answer your questions more directly: the identity key is security-critical (although there are ways to recover from a compromised identity key) but it does not impact forward-secrecy directly. The public part of the identity key is published to the Signal servers, but the private part is intended to stay on the device. Exchanging the private key to a new device is done via QR code or similar (implementation specific) and is generally considered secure because it is a local physical operation.


Store To Store communication through MPLS VPN

PCI-DSS speaks to the Credit Data Environment.  If the entire "store" is all part of the CDE then in compliance terms it doesn't make one bit of difference, all systems in all of those environments are in scope for a QSA auditor to poke at.

That being said, it's probably not a good idea.  The more pathways attackers have to bounce around within, the harder it is to define secure channels.

Let me just throw a realistic adversarial scenario out there:
A badguy gets on a POS register in Store A, it's an underperforming location that handles a very small number of transactions.  Someone in the store connected a third party device to the network outside your control and the attacker managed to transition to the private network.  It's low volume and low impact if the attacker pokes around and discovers a weakness in a trust model (Like, the key encryption key "hiding" in a dll in plain sight... yes I'm talking to you PA-DSS compliant folks...)  And is able to start gathering a minimal number of credit cards.

They discover that Store B is accessible through the WAN and apply the techniques they were able to pioneer in the low volume store much more effectively the second time around in the store that's processing 100x the number of transactions as the first.

Store B has a much better set of controls, but by leveraging the less maintained systems in Store A the attacker is able to scoot off with all the credit information from both locations.  Whereas Store A alone might have led to a compromise of a couple dozen customer records, Store B turned it into a national reporting incident with tourists from 30+ states being compromised.

In other words, if you made it this far and didn't just run away happy with the compliance answer I wouldn't do it unless there was an incredible business need for it.  Even though it's "on the MPLS" you're no doubt connecting it to your head end, which in turn is connected to the internet.


If either of the static_upgrade_mode: or the dynamic_upgrade_mode: lines are set to STRICT then HSTS is enabled.
Dynamic
Dynamic means that the browser has been instructed to enable HSTS by an HTTP response header (served over TLS) similar to the following:
Strict-Transport-Security: max-age=157680000; includeSubDomains;
This is vulnerable to an attack whereby the very first time the browser requests the domain with http:// (not https://) an adversary intercepts the communication.
Static
In order to overcome this weakness we have the static mode which allows for hard-coding HSTS records directly into the browser's source. The header is changed to indicate the administrator's intention:
Strict-Transport-Security: max-age=157680000; includeSubDomains; preload
Note the inclusion of preload at the end. The domain is then submitted for review. If approved then it is added to the Chromium list which is also included in the Firefox, Safari, and IE 11+Edge lists.


I've had the same question myself and by research as well as by practical tests I found out, that the openssl ocsp command is not able to verify complete certificate chains.

You can only verify one "step" at once, so you would need to issue

openssl ocsp -issuer sub-ca.crt -CAfile sub-ca-and-ca_mere.crt -cert interne.crt -url http://ipa-ca.sub.cedricdomaine.fr/ca/ocsp

to verify the validity of the server certificate and something line

openssl ocsp -issuer root-ca.crt -CAfile root-ca.crt -cert sub-ca.crt -url http://ipa-ca.root.cedricdomaine.fr/ca/ocsp

to verify the validity of the sub-ca certificate.

A "clever" client (browser, e. g.) however should probably do it the same way, sending multiple requests to multiple OCSP responders along the chain, given the corresponding responder URL is mentioned in each certificate.


Most likely you are adding -i PATH to your key_file which is being stored in default location. So basically it doesn't matter if you provide -i argument or not, since ssh will search for the key file in a default location anyways.

  -i identity_file

  Selects a file from which the identity (private key) for public key
  authentication is read.  The default is ~/.ssh/identity for protocol
  version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa
  for protocol version 2.  Identity files may also be specified on a
  per-host basis in the configuration file.  It is possible to have
  multiple -i options (and multiple identities specified in
  configuration files). ssh will also try to load certificate information from the filename obtained by appending -cert.pub to identity filenames.

https://linux.die.net/man/1/ssh


To be safe from having mails that possibly harm your system through an attack you first need to know what attacks you want to be protected against.

Mail body Attacks (like malicious HTML inside the mail) Protection options are

Open Mail in plain text mode, in this mode None of the text is treated as having special meaning and is just show on the screen, in case of an HTML document you do need to be able to read HTML to understand your mails.
Set the mail client to NOT display Images. Images have been used as a means of infecting a system through several means. some involve maliciously crafted images that exploit the viewing system, some that employ Track and Trace for scouting new locations to attack.
Disable JavaScript. Some people think that disabling the JavaScript inside mails can protect you. while it does offer a slight barrier in my opinion, I do believe not running any of the code is better. so reading HTML ;)

Attachments Attacks (Like malicious Zip files) Protection options are

Disable Attachments inside the mail server. Hardly a user friendly option.
Have a virus scanner integrated into the mail server. solves known viruses but does not protect against directed attacks or new virus (types)
Simple NEVER EVER open an attachment unless you specifically asked to be mailed one. (good policy in my opinion.) Mails are most often the most effective when there short and to the point. you do not need to send a big blob of data to do that (like a document)
Save attachments and run the virus scanner over them before you view them. same protection as doing this server side with the added bonus of someone consciously doing the task and understanding that there are risks.

In short none of these methods offer a foolproof method of protection or are complete in any way. just use common sense and understanding of how the "bad guys" work go a long way.


What's the PROPER way to validate a signature timestamp?

AFAIK, the goal of adding a trusted timestamp is not to extend the validity of the signed document, but just to prove that is was signed at a precise time.
It matters when anteriority is a thing. For example when two research teams want to publish an article on the same subject, it can be interesting to have evidence of which one established/discovered the thing first. Here a signed document with a trusted timestamp could be such an evidence.
Without the trusted timestamp, it is too easy to set the clock of local machine several months back, sign a document and reset the clock to the current time.


What do we have to keep in mind when opening up our data to a third party?

There is a framework that exists specifically to enable this sort of scenario.  It is called OAuth 2.0.  What you want to do is to have an API that exposes the resource owners' (your users) resources (their pictures) for the client (the third party) to consume with the permission of the individual resource owners.

So, in this model, you become an OAuth 2.0 provider, and the third party implements an OAuth client.  Then, the users who are user of both servers can authorize the client to access their pictures, and the third party will be given an access token that will allow them to retrieve the pictures from your API for the users who have granted them said access.

I don't know that the second database serves any purpose.  Since you're going to be exposing access via a service rather than granting direct access to the database in any case, the second copy of the database simply sounds like unnecessary additional complexity to me.


Difference between system uptime and last boot time in windows

The left window is not showing the system uptime but the network connection uptime.

The network may have only been up for a couple of hours for multiple reasons:

The network wire was -perhaps briefly- disconnected
The switch it is connected to was rebooted
The computer was previously connected to a different network, but then changed to this one
The network connection itself was disabled then enabled.
If it's just slightly different, it's normal that the boot time will have happened a bit before the computer booted, loaded the OS and actually connected to the network.

I can imagine a several scenarios where the reported system uptime is different than Now - Boot time for a machine, though:

The machine was hibernated and the time it was in that state is not taken into account for the uptime.
The system clock changed after boot, so the boot time might even be dated years ago (whatever the BIOS clock default is) but the System time itself was corrected shortly after boot-up through NTP.

I understand the discrepancy to show in SIEM / AV dashboards. However, I don't see that as a reason to not accept security policy from AV. If the AV refuses to apply a security policy because it considers that they don't match -as seems implied by their support reply-, perhaps it is buggy.


Can I infect the entire network (all computers, servers inside) if I broke into and infect the router? If so, how?

Not really. It isn't the fact that you broke into the router, that "only" gives you a foothold. You've still then got to break into the computers in that network. However, you are a major step closer and that's why enterprise networks are segmented. You are also confusing a home network where the router and firewall are the same device with an enterprise network where, typically they are not. In those cases, the firewall and possibly several other protection devices are inside the router.
Can I track down the router using information from the website?

Maybe. But only if the server is in the same network as the router. This is likely to be the case in smaller networks but may not be in larger ones that may have several DMZ networks. In those cases, you may only be able to find the nearest router or firewall.

So if I can connect to the server site, I can also connect to the router. If so, how?

Nope, same problem as before. While you know where the device is logically speaking, you still don't know the credentials to get into it to do anything "useful".
change the DNS settings so that all network traffic flows through your computer ... inject malicious code into traffic to any computer in that network. Is such an attack feasible?

Partially. If the network were using something like DNSsec then probably not at all. Otherwise, you would still need to MITM any HTTPS/TLS certificates, it isn't enough to have a MITM for the raw traffic if that traffic is encrypted.

But in an internal enterprise network, it is less common for the traffic to be encrypted between machines. It causes overheads in running and also in operational support so it is often ignored. In that case, your MITM device would have to also be inside the network of course and not outside. Another good reason for large networks to be segmented since it limits the number of machines a rogue element can get to.


Is it safe to authenticate user by email confirmation link?

It depends on why you want to confirm an e-mail. If that e-mail will later be used for password reset, the proposed workflow has a major security problem. Consider the following scenario:

Alice creates a new account and inadvertantly write Bob's mail (say she copy-paste the mail and uses wrong line)
evil Bob sees the mail, confirms the account, writes down Alice's login name if it is different from the e-mail and logs out
Alice tries to connect later and sees everything works fine - she assumes validation was automatic and she normally uses her account for a while
some times later, Bob tries to connect using Alice's account, asks for a password reset => as he own the registered mail, he is successful in changing the password
Bob now owns Alice's account and can do anything on behalf of her!

Ok, Alice was not very cautious when creating her account, but the proposed workflow did not really protect her :-(

That's the reason why my prefered workflow is:

let a user create a new account with login, password an e-mail (may be login or not, better not) -> the account is created unactivated and will be destroyed if not activated within a limited period of time (say 2 days)
send a unique confimation link to the given mail
the link opens a login form - the user name should be pre-filled and read-only. If the user successfully logs in, the account is validated, the link is invalidated and the user is put his session. If the password is incorrect after three attempts the connection is broken.
if a user tries to connect using a non validated account, he/she sees a message saying that a validation mail was send to that address, that he/she still has n days/hours to validate the account, and proposing him/her to re-create the account with a new mail address. In that case, the old validation link is immediately invalidated.

If the previous scenario happens, Bob will not be able to validate Alice's account nor to steal her account later.


Do systemd-nspawn containers provide the same security guarantees as FreeBSD jails?

Systemd-nspawn only manages isolated processes. It cannot isolate resources (which systemd can).

As a constructive difference, in the case of namespaces, you start with no isolation and you add whatever you require — mounts, PIDs, networks, users, etc.
In the case of jails, you start with a reasonable secure baseline since the processes, IPCs, mounts and users are always isolated.
That does not mean you can't get to the same level of security.

We can create a fully isolated environment, which will automatically monitor the /proc and /sys pseudo-file systems and create an isolated loop-back interface and separate name space for PIDs. From there we can run what we want.

To limit the isolation problem we can use systemctl:

systemctl set-property  CPUShares=80 CPUQuota=25% MemoryLimit=1024M

So to conclude, by default you don't have the same level of security but you can get to the same level. Nspawn will probably also evolve a lot more in the near future.


using ndisasm, the data in the sh array can be disassembled into the following valid 64bit x86-machinecode:

00000000  EB0B              jmp short 0xd
00000002  5F                pop rdi
00000003  4831D2            xor rdx,rdx
00000006  52                push rdx
00000007  5E                pop rsi
00000008  6A3B              push byte +0x3b
0000000A  58                pop rax
0000000B  0F05              syscall
0000000D  E8F0FFFFFF        call qword 0x2
00000012                    '/bin/sh'

It looks line simple position-independent shellcode to do a kernel syscall to execute /bin/sh.

The first instruction jumps ahead to the instruction just before the /bin/sh string, that in turn does a call back to the second instruction again. The return address is then popped from the stack into register rdi.
This is a trick to get the memeory address of the /bin/sh string, since the shellcode does not know where in memory it is when it gets executed.

The register rdx is then set to 0 and pushed to the stack and poped back into register rsi. The byte 0x3b is then pused to the stack and popped back into register rax.

We are now set up as follows:

rdi = pointer to the string /bin/sh
rdx = 0
rsi = 0
rax = 0x3b

At this point, we hand over control to the kernel with syscall, where the argument 0x3b in rax tells it to execve() the file path that is at pointer rdi

If we translate this back into C, it is basicly doing:

execve('/bin/sh', NULL, NULL);


Using tor with SET to bypass firewall policy?

Whether or not you can send email with TOR depends on the exit policy of whatever exit node you end up using.  Almost invariably outgoing TCP 25 is blocked by tor exit nodes because of spammers.

More importantly,  most email providers are using the Sender Policy Framework which can be used to detect forged email.  Welcome to 2012 where most stupid hacks are prevented by simple security systems.

There is nothing magical about sending spoofed email,  and you can do it with telnet or netcat,  you just need to be able to access your victim's SMTP server on port 25 and deliver the forged email directly.  You should be able to find a socks proxy server that can do this.


Is it dangerous to have the built-in Administrator account enabled?

I understand the confusion.. let me try and explain..

  But.. Why disable it..?

The reason behind disabling it.. Well.. Let me first kind of define an administrator account in a very generic way:

It is a user profile that is had administrator level privileges enabled which essentially gives that particular user complete access to the system.

So.. On windows it is named as 'Administrator'. It always exists on the system, whether enabled/disabled/in-use or dormant. So.. when malwares are written they are programmed to check for the existence of such profiles. Someone could also rename it to admin or root or something like that are generally privileged profiles.

If they do exist.. Voila... It saves me the work of "executing additional code" to gain privileges in the system. People make mistakes.. If they are enabled, let's take control and play havoc.

To make it more clear, let us assume that you are a skilled burglar and want to break into a house. Assume that the "house key" is the admin account. If I check for the house key in generic places like 'under the pot, or under the welcome cat, or on the ledge".. If I get them, I'll break in easily. If you don't keep the set of house keys outside, then I don't find it. The burglar will break it using additional pick-locks and levers (Privilege escalation methods). If your lock is unpickable then you are safe. (Relate it to something like hardening your security).

So you see, disabling it will ensure that the malware atleast has to "put in work effort" in order to gain access to the system. A highly motivated and skilled hacker might be able to get through but can be stopped by implementing tight security controls on the system. If your system is secure, then the malware is useless.

Theoretically speaking.. I hope its helpful.. :)


There are two ways to create such a message. Either you can sign a message with the signature in the message and with --clearsign not specified, or you can use --store.

Signed but unencrypted

As for the specific message you provided, it is not an encrypted message, it is a signed message, not using a clear text signature. In other words, the signature and message are fused together. See section 1.1.2 of the GnuPG manual, which explains clear text signatures created with the --clearsign option. What you are seeing is a signature for an unencrypted file which is not using this type of signature. As a result, PGP-compatible software is required to read the file, despite it being unencrypted. This allows you to ensure integrity without requiring a decryption key.

You can create a message with a clear text signature easily:

$ md5sum message.txt
ecccffe1886ca709442672e65d66b409  message.txt
$ gpg --armor --sign message.txt

And then to access it again, you "decrypt" it:

$ gpg --decrypt message.txt.asc > message2.txt
$ md5sum message2.txt
$ ecccffe1886ca709442672e65d66b409  message2.txt

Or you can simply verify the signature:

$ gpg --verify message.txt.asc
gpg: Signature made Sat 30 Dec 2017 06:06:52 AM UTC using RSA key ID 8085AFFB
gpg: Good signature from "Test Key"

Store only

There is a way to create a message without a signature either, using --store. This option is effectively equivalent to symmetric encryption with a null cipher. It stores the message encoded with an RFC1991 literal data packet. If your goal is simply to create an unencrypted message, this is probably what you want. It does not guarantee either integrity or confidentiality.

Store the message in PGP format, without encryption:

$ md5sum message.txt
ecccffe1886ca709442672e65d66b409  message.txt
$ gpg --armor --store message.txt

And "decrypt" the message:

$ gpg -d message.txt.asc > message2.txt
$ md5sum message2.txt
ecccffe1886ca709442672e65d66b409  message2.txt


What prevents me from using ARP poisoning to force a client to use HTTP?

If the client's initial request is for HTTPS, then the client will insist on first doing the SSL handshake, and only then, within the newly created SSL tunnel, will the client send the actual HTTP request, the one you want to respond to with a 301 code. This means that if the client entered the https:// URL (either he typed it, or followed a bookmark which includes it), then, as an attacker, you still have a SSL thrown against you.

Of course, if the client is prone to click through the "friggin' browser warnings" then all bets are off.

Similarly, if the client always types the raw server name, and expects the server to receive the HTTP request and send back a redirect to HTTPS, then you can intercept that redirect and keep the client on a pure-HTTP fake site. It always bring us back to the client and what he is ready to accept. If the client performs an HTTP (not HTTPS) request at some point, and won't notice the lack of padlock icon or green URL bar, then you can leverage that single point of vulnerability to keep the client in a non-SSL world, intercepting all attempts at redirection to SSL. Automation of this attack has been demonstrated under the name sslstrip.


RDP is as easy protocol to scan for, and thus attempt a brute force login, especially if you still use the default user accounts on Windows PCs.  Never expose RDP externally for that reason.

That said, we still enable it internally for providing remote support to users.  Make sure you lock down the users that can use it internally via the local Remote Desktop Users group on the workstations.  You can do this through: Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Allow Log on through Remote Desktop Services

If you do want to disable it, you'd be better off disabling it via group policy (Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections\Allow users to connect remotely using Remote Desktop Services) and/or blocking port 3389 on the client firewall, rather than trying to stop the execution of mstsc.exe.


Steps to find out whether a SSL certificate is trustworthy

If you run the following command, you will see that when the person managing TLS for the server replaced the leaf certificate (the certificate for the server himself), he did not replace the chain (the certificates of the Certifying Authorities that build the chain of trust).

echo |openssl s_client -connect www.prioenergie.de:443 -showcerts 2>&1 |grep -E '^ [0-9 ] (s|i):'

Specifically, the leaf certificate was issued by CN=thawte DV SSL CA - G2, but the first CA certificate in the chain handed back by the server is CN=Thawte DV SSL CA.

Chances are, the person managing the server tested it with Internet Explorer, which tries to be permissive with what it accepts by walking the AIA if the chain does not match, but which does not follow the TLS spec and which in uncompatible with the way most other TLS clients (other browsers like Firefox, OpenSSL, NSS, the Java TLS libraries, etc) behave.

I would recommend to contact the company and let them know they need to install the new chain provided by the Certifying Authority (Thawte).

At this point, you need to make the business decision. Do you lower your security posture to be able to do business with this company, based on the presumption that this is a configuration mistake? Or do you decide this is not an acceptable risk and only deal with the company via known acceptable channels, such as the phone/fax number printed in the phone book?


How secure is a MD5 hash of an 128bit key

Collisions are not useful in this case.  You need a pre-image attack that can find the correct input that was used to generate the hash.  An alternate input that creates a collision is still not the correct key, and won't decrypt the data.  Finding the correct 128-bit random input is not feasible, even with MD5.


What happens if two parties have a same pair of public&private keys

Simple explanation

The only way this will ever happen is if you give someone your private key. It will never happen by random chance. Never. You'd have a better chance of winning the lottery twice, getting struck by lightning and being mauled by two gorillas all in the same day. Instead of worrying about generating a private key that someone already has, you'd be better off worrying about how to protect yourself from lightning and gorillas so you can spend the money you'll win in the lottery.

So as long as you keep your private key private, you will never have to worry about this.

Scientific Reasoning

Let's say you are dealing with 1024-bit RSA for your public key system. A good key generator will choose the two 512-bit primes independently, so the probability that any two instantiations of the key generator will choose the two primes necessary for RSA is 2-512 · 2-512 = 2-1024 or about 1/10308. That number is so astronomically small that there is no way it will happen in a properly functioning system. Your odds of being struck by lightning in a given year (forget on a given day) 1/1,000,000 (1/106). Probability of getting mauled by two gorillas 2-120 (see post in Rory's comment). The lottery one is a little harder as it depends on what lottery (as the odds are different for every one), but hopefully you get the point.

Improper System

All bets are off. As pointed out in Jeff's comment, this happened in Debian's version of OpenSSL due to a simple bug which caused the random number generator to be seeded with very little randomness. The result was that people could potentially have the same private keys.

Having the same private key as someone else would allow those two people to decrypt each other's messages, etc.


You need to privately contact the person who manages the software in which you found a vulnerability. Tell them about the vulnerability you found, including how you think it can be exploited and what you think it can do. Give them some time (often in the range of a few months) to verify your claims and provide a solution.

Once they have fixed the issue and a link to a patch has been made available to their customers, contact the CVE list and ask for a CVE number if you're out for the glory.

Edit: be aware that some software providers are morons and refuse to acknowledge their mistakes, so they try and sue whoever presents them with a vuln in order to quiet them and avoid the shame of having security issues in their software. Some cryptology researchers I've met have had this issue time and again with smart card manufacturers. If you suspect you're facing this type of individual, stay anonymous when reporting.


When the question is:

  How do I know if my encryption algorithm is strong enough?

then the probable short answer is:

It is not strong.
It is strong enough.
It misses the point.

When professional cryptographers design an algorithm, they always assume that what they produced is weak. They will not trust it until it has been seriously looked at by their "fellow" cryptographers (who are actually their competitors, and a rather fierce bunch, though generally good humoured). It would not be wise, for a non cryptographer, to be less cautious than that.

Your algorithm is probably strong enough, where "enough" means "enough not to be the weakest point in your system". It takes really special effort to make a cryptographic algorithm which is so pathetically weak that attackers find it worthwhile to break it upfront (an example is CSS used on DVD, but that's still quite rare).

Your algorithm probably misses the point because most of security is not about cryptography ; cryptographic algorithms fulfill an important role, but with a narrow scope. I spend my days explaining to people that the magic crypto dust they sprinkled all over their systems is not as magic as they assumed (e.g. no, encrypting a SQL database does not prevent an attacker from successfully altering its contents by modifying the files on the disk).

It is possible that your algorithm (about which you give no detail at all) is actually strong, and fulfills a point which is relevant to your situation. Possible, but, as experience shows, not probable.


OpenSSH server default configuration options

/usr/sbin/sshd -tT enables test mode and extended test mode. This command dumps a normalized output of what settings are going to be set and to which values.

I use the -tT first, and use the captured output as the starting point of all my configs.  This way I know exactly and explicitly what is going on with this particular release/build of OpenSSH.  It's annoying to do it for every release, but it's the only way I found to get the real values.

I used to parse out the manpage, but that turned out to be lagging behind the settings in the code.


Actively running anti-virus mechanisms in a centralized environment should and can be configured as a domain policy or AV centralized policy so that no user can alter them, including users with administrative privileges on their own stations. A good AV policy can also completely control the firewall settings of the client stations.

Only the authorized by management personnel (the administrators of the anti-virus systems) should be able to alter such a policy (and only they can do it in a proper setup environment).

So the term 'users' refers to anyone except those designated anti-virus administrators.


Using Client-side certificates for Authentication

The most pressing reason is that people login from multiple computers: home PC, laptop, tablet, work PC, friend's PC, internet cafe, etc. While it is theoretically possible to have a system that syncs your certificates - either through a cloud service, or a physical device you carry - this is beyond the capability of most users.

Now, could someone create an authentication service that does this for you? That takes care of all the certificates under the hood? Well, that is exactly what Mozilla Persona does.

The second reason is that there are millions of websites that already use passwords. To change all these to use some other authentication scheme (whether it's OAuth, SRP, certificates, or something else) would be an enormous undertaking - and why would a website bother? What's the incentive for them?

Because of this, password managers are a far more practical technology to solve the authentication problem. Ok, they are not quite as secure as client certificates, but the differences are fairly minor. Systems like LastPass give you a single-sign-on interface, and work with (almost) any website.


I use VPN+Socks5 proxy for torrents in Utorrent. What is the security risk?

Running a SOCKS5 proxy inside of a VPN is a pretty common setup, and can provide pretty good security since in theory you wouldn't be relying on a single entity for your anonymity.

If you pay for the SOCKS5 proxy, and some authentication is used, then that may be a week spot if that could be connected to an identity.

DNS leaks are one thing to be careful of, since they aren't always tunneled correctly. WebRTC is usually another thing to look for, but as long as you're only using BitTorrent traffic on the VPN it's not an issue.

One last thing to note is that this VPN should only be used for BitTorrebt traffic. If you have any unencrypted HTTP traffic you increase your risk from an attacker who is monitoring the VPN output (before it hits the SOCKS5). An attacker could use WebRTC or a browser fingerprinting technique to at least track and coorolate your traffic. Then if you ever connect without the VPN, and the attacker compare the fingerprints your IP may be exposed.

Overall VPN+SOCKS5 is going to be good enough protection for the vast majority of people seeking for privacy in their BitTorrebt traffic.


Monitoring a specific application for creation or modification of files

If you're looking for something interactive, and not service-style long-term monitoring software, check out Microsoft's (nee SysInternal) Process Monitor.
Very versatile.


I have been googling and I found someone who had a problem somewhat like mine. I think my problem may have to do with chromium. https://stackoverflow.com/questions/36018544/imagemagick-enoent-error . I'm not sure what to do at this point but at least I think I know where the problem is. The command I was using to run nodefuzz is sudo node nodefuzz.js
I am using a Mac running OSX Yosemite 10.10.4. Looking at other posts online I'm going to say that Nodefuzz can't find chromium. If that is the problem I'm not sure how to solve that issue.


Is it possible to use steganography on an analog audio channel?

There are a few ways to do this. Use ring modulation to add a virtual carrier to the audio you want to hide, for example at 14khz. Goldwave's mechanize feature can do this. This will give an amplitude modulation-like signal with sidebands above and below 14khz. Then use a highpass filter to get rid of the lower sideband, and only kids or dogs may hear the deedle deedle deet of the single sideband audio signal, but may not know what it is unless they're familiar with shortwave listening or ham radio. Someone else with a ringmod plugin or goldwave can apply the same 14khz effect to demodulate the signal. The normal un-hidden audio at the same time will get modulated at 14khz and will sound like hash that you can get rid of using a lowpass filter to hear the hidden audio totally in the clear, but you probably won't need to bother. I suggest before you hide your audio that you filter it with a 300hz to 3000hz filter which is what telephones and communications radios use. This will limit aliasing of the converted audio and make it harder for normal ears to hear when listening to the undemodulated file. Another method is to simply record a short message and slow it down 32 times, and mix the result with the ordinary in the clear audio you want to mask the message with. Be sure to mix it at a reasonably low volume so that the low thunder rumbles of a slowed-down human voice are not obvious under the normal audio. Then all the guy on the other end needs to do is speed up the file 32 times to hear your short message. This method needs lots of room, 32 seconds of file for each second of slowed-down audio, so make it quick.


cryptencrypt produces visually similar ciphertext

RC4 is a stream cipher.  If you're using the same key and IV, you will get ciphertext that looks very similar when the plaintext looks very similar.  This is why IV reuse with stream ciphers is a really, really, bad thing.


Attacks on using https at coffee shop to access bank account?

They are awfully vague in the linked video, so no real guidance there. I could think of the following risks:

Even if you use HTTPS, the domains you visit will be visible to the eavesdropper. You might not want the world to know about all the domains you visit...
Sure, everything is fine as long as you use HTTPS. But are you actually using it? SSLStrip is a real thing, and unless you trust yourself to check that the connection is secure every single time you could easily fall for it.
In theory, the bad guy could have come across a rogue certificate somehow or there could be some bug in your browsers TLS implementation. While not common, these things are not unheard of.
There are known vulnerabilities (such as POODLE, CRIME, and BEAST) in older SSL cipher suits. But if you use a modern browser this should not be a problem (and I am not sure it would be even if you use an old one).

Of these four points, the first two are the only ones I would really worry about. But the first one doesn't really apply to banking, and the second can be handled by just checking the connection. So while I wouldn't do online banking in a coffee shop unless I really had to for some reason, it is not the end of the world if you do it.

Also note that the show you linked to disclose that they are sponsored by a VPN company on their homepage.

I should also mention there might be legal issues involved here - is your bank willing to pay you back in case your account is hijacked if you have accessed it over coffee shop Wi-Fi, even if the reason your account was hijacked has nothing to do with it?


Can a rootkit hide processes from "Volatility" or other memory forensics tools?

But can a rootkit also modify a processes metadata in a way that it won't even be recognized by a RAM forensic tool like volatility?

The short answer is, not really.

Rootkits routinely change process metadata.  Cosmetic changes are made to bits that aren't vital to the process running, and significant changes are made to the bits that make the process run.  But if you make changes "in a way that it won't even be recognized" to a forensic tool, most likely you'll have made changes in a way that it won't be recognized as a process by the operating system.

In other words, the rootkit is constrained to make the process follow the rules enough to allow it to run - and by the same token, it will always follow the rules enough to allow Volatility to explore it.

In fact, a lot of what Volatility does is look for inconsistencies that are unusual in a normal process but are exactly the sort of tampering a rootkit would do.  Oh, look, the pointer for a given system call points off to userspace, not kernelspace like it should!  That's a giveaway.

Now, I said "not really..."  Volatility has a number of predefined plugins that follow rules to find things that are out of place.  Is it possible to write a new rootkit that isn't immediately obvious to these plugins?  Sure.  Clever people come up with new tricks all the time.  But then the clever, clever developers and users of Volatility find these things - you can walk through memory manually with Volatility, you aren't constrained by what existing plugins think you should look for - and they write new plugins that recognize the new evasion.

SANS forensic training uses the tagline "Malware can hide, but it must run."  For it to run, it's got to follow some of the OS's rules.  And when it does that, it puts itself on the map for Volatility to identify and explore.

(minor exception: I have heard horror stories about hardware that visited China and came back with tampering that left it beaconing home with no evidence in system memory.  If you let the enemy make changes to your hardware, then they can move beyond memory analysis.  But that's a pretty rare and exclusive club.)


Transferring of keys from key servers to recipients

If you use the signatures on the key to validate it (such as the web of trust model), then you only depend on the key material you have, and not the key served to you.  In fact, if you know the fingerprint of the key you want (with certainty) you can just verify the fingerprint after retrieving it.

If you want to avoid a MITM, you can use the hkps protocol described on the SKS Keyserver page here: https://sks-keyservers.net/overview-of-pools.php.

Keep in mind that anyone can upload any key to the keyserver, so just because it has the email you want doesn't mean it's the right key.  Only the signatures on the key (and the trustworthiness of the signatures) can help determine if the key you have is the legitimate one.


The ".htaccess" file can be downloaded. Why? How to fix?

It depends on the type of the webserver in question.
If it's apache, it should contain something like this in the config file (usually in the "main" apache.conf):

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
    Satisfy all
</Files>

If it's missing, that can cause the problem you described.

The other typical cause of this is that the client have used apache in the past, but switched to something else (e.g. nginx) which does not use .htaccess and hence doesn't treat it in a special way. The solution in this case is webserver-specific, but it usually boils down to restricting access to files beginning with ".ht", or - if they are really not used - you can simply delete them.


Disclosing security vulnerabilities to paying customers first

It's easy to say that this behaviour is bad. But I think it is worth to have a more detailed look.

Security issues are quite a difficult situation for many companies, that have decided to open source (some of) their programs, while keeping a commercial version. This gets worse if a fix cannot be created immediately.

Motivation for informing paying customers first

The company obviously depend on its paying customers to survive as any company does. So they need to provide some additional value to those customers.

It is likely that huge companies will be paying customers while small companies and independent persons will tend to use the free version. Those huge companies are more likely to be the target of an attack. And in case of an successful attack, it is more likely that they will be subjected to bad press coverage.

Furthermore there is a higher risk that public security warning without a fix will get attention from people with malicious intents. Just because the number of people is a couple of orders of magnitude larger.

This is especially true, if almost all serious users are paying customers. In other words: The open source version is basically a demo for the commercial one.

Motivation for issuing a combined security warning

After the company has issued a public warning, it can claim that it is no longer responsible for any damage caused afterwards. If the users did not take counter measurements such as installing the fix, it will be their own fault.

Giving information out early to paying customers may enable someone of them to use  that knowledge for evil. Depending on the legislation it might pose a legal threat to the company that it did not warn all users, although it obviously was aware of the issue.

From a user's point of view

Having talked about the motivation for the company, let's have a look at the user side. I think it is quite obvious that paying customers will appreciate this as service.

Users of the open source version are subjected to an additional risk and should therefore be very careful with using such a software in a production environment or with sensitive data.

How does the non-commercial Arianne open source project deal with security issues?

I'd like to conclude with some personal experience. Arianne is an open source project which consists of an online game framework and a 2D online role playing game called Stendhal. It is non-commercial and does not make any money at all.

There are many people out there that run Stendhal servers since it is completely open source (client, server, graphics, everything). We run one instance of Stendhal ourselves.

When we discover a security issue in Stendhal we have ended up with this process:

We share the information among the trusted core developers, we discuss it and work together on finding the root cause.
We fix the issue and commit the change to the public CVS. Other core developers review the fix and test it themselves.
We take the fix live on our server.
We prepare a bugfix release based on the latest stable version. In the meantime other core developers do some more testing. Normal players just continue playing and therefore implicitly test for side effects.
We do a minor release of the last stable version together with a source code patch and post an announcement describing the issue.

The whole process takes about 1 to 2 hours.

We do not release bug fixes for older versions because we pay a lot of attention to make updates between versions very easy to install. The only reason someone cannot jump to the latest version is that he did modification to the code himself. For those people we provide the source code patch.

I can see that someone may argue that updating our own server first is evil, as is committing the fix to the public CVS before the announcement. But this is the most effective way to get a high quality fix out in the shortest time possible. We do need the short test on a live server because people really expect that they can install security updates blindly without having to fear side effects.


Deciphering ciphertext with an unknown key and algorithm

I performed frequency analysis and found a shallower distribution than I would expect for a monoalphabetic ciphertext of this size. Might indicate a polyalphabetic, homophonic, or polygraphic substitution cipher. These are just a few possibilities.

You can learn more about frequency analysis and its relevance to cryptanalysis here and here.

I would start with learning about frequency analysis and then running the analysis yourself. Search around with the links I've provided and google to help learn how to interpret the results and narrow the list of likely ciphers from that. Once you have a narrowed list, start looking for weaknesses in those ciphers and how to crack them. The wikis I've linked to have several descriptions on weaknesses of some implementations of these non-monoaplhabetic cryptographic methods.

If you end up narrowing the cipher list down and make a programmatic solution to bruteforce keys like I have had to in the past, you'll need to find a way to determine if a result is cleartext for each decryption attempt. Assuming this is English, you can implement an English detection tool. I've written about it here. Feel free to pilfer my English detection code in order to interpret your results. It's basic but has gotten the job done for me.

If you really want to get into solving crypto programmatically, this is a great resource: http://inventwithpython.com/hacking/.

And if you to take your learning a step further, learn about Friedman's IC, Cohen's kappa test, and the chi test and their relevancy to cryptanalysis.

If this is some school or crypto event challenge, it very well might be an implementation with a known weakness that can be exploited. If this is something like Raytheon's job offer challenges (as have been found on business cards in the past), I would expect it to require much more effort.


Perform CSRF attack when CSRF token is sent in custom request header?

The custom HTTP header works as a defense in and of itself. Actually, one rudimentary form of CSRF protection is to simply set a custom header to a constant non secret value and then check for it server side. This protection is sometimes applied unknowingly by simply requireing certain content-type headers.
OWASP describes this technique:

Adding CSRF tokens, a double submit cookie and value, encrypted token, or other defense that involves changing the UI can frequently be complex or otherwise problematic. An alternate defense that is particularly well suited for AJAX/XHR endpoints is the use of a custom request header. This defense relies on the same-origin policy (SOP) restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers do not allow JavaScript to make cross origin requests.
A particularly attractive custom header and value to use is "X-Requested-With: XMLHttpRequest" because most JavaScript libraries already add this header to requests they generate by default.

The limitation to this is, as you say yourself, Flash vulnerabilities:

[B]ypasses of this defense using Flash were documented as early as 2008 and again as recently as 2015 by Mathias Karlsson to exploit a CSRF flaw in Vimeo. Riyaz Walikar from Appsecco Labs was able to exploit this even in early 2019 using older versions of Firefox and also in some recent versions of Chrome (with a bit of user involvement). Since we cannot the control the versions of browser end user uses nor depend on it for their security, this technique is not recommended as a primary defense in measure.

The last sentence is key here. If the victim uses a vulnerable combination of browser and Flash plugin, you can exploit this. If not, you are probably out of luck (unless a permissive CORS policy lets you set the header).


Is HostGator storing my password in plaintext?

Yep, that's a big problem, especially if that was your old password (i.e. not a newly assigned one).

Technically, the password might be stored under reversible encryption rather than plain text, but that's nearly as bad. The absolute minimum standard should be a salted hash - anything less and anybody with access to the auth database who wants to can use an online rainbow table to get back the plaintext passwords in moments - but single-iteration secure hash algorithm (SHA) functions are still easy to brute force with a GPU (they're designed to be fast; a high-end GPU can compute billions per second) so they really ought to be using a proper password hashing function such as scrypt or argon2, or in a pinch bcrypt or PBKDF2.

Also, there is absolutely no way to guarantee that the email was encrypted along the entire path between their mail server and your email client. Email was designed in a day when people didn't really consider such things to be critical, and short of an end-to-end encryption scheme like OpenPGP or S/MIME, email is at best encrypted opportunistically, and may be passed through an unencrypted relay.


Normally a Key Signing Ceremony only makes sense for root level keys. For non root level keys, the way it happens should be described in the policy rules of the PKI.

The main points of attention are IMHO:

how do you guarantee that the private key has always been under the sole control of its recipient - it can be a problem where you use physical devices such as a smartcard
how do you guarantee that the person that recieved the signed certificate is actually who he claims to be (control of an ID card, who did the control, how and when, etc.)
how do you save the proofs of those 2 previous parts (mainly important for the second one)


Should a corporate laptop client-server VPN connection last for days?

This will depend entirely on the use case for the majority of the staff.

If they typically run long term sessions because their applications or work require it, then you can be sure that trying to move to a shorter session length will cause problems.

If they mostly run applications that can work unattended and only need to be checked later, then a very short session time may be appropriate.

This is one of those areas where you need to weigh up usability and security. If you are in a position where someone stealing your laptop and videoing or watching you entering your pin is a realistic risk then perhaps it is appropriate to have a conversation with your IT team. So no, there is no 'best practice' as it will depend entirely on your requirements.

Most organisations I have worked with have an RSA token or a soft token as part of the connection, so they would have to steal the token, know the username and password and PIN. All without me knowing, as I could call in and cancel it if I knew it was stolen.


Can a Patient's Name, Birth Date, and Study date be sent in a plain text email to a referring doc?

HIPAA does not explicitly require emailed PHI to be encrypted.  HIPAA requires "reasonable" protection/consideratoins etc. when emailing PHI.

HIPAA does require secure transit of PHI, which could easily be violated (e.g. using a webmail client over http vs. https).

So it is not directly a breach of HIPAA.  HOWEVER, the bottom line is that unencrypted email is a risky approach.  You are dependent on email privacy policy adherence, you are dependent on never accidentally sending to the wrong person (which is a required event to report as a HIPAA breach), and other concerns.

DIRECT, as mentioned by Freiheit, is a direct exchange protocol on the uptake that not only ensures the proper recipient, but authenticates the sender as a trusted source as well, through pre-established circles of trust, so to speak.

Other basic services such as Zix (very straightforward secure email service that basically emails your recipient a message "hey, some stuff was sent...click here and prove it's you [login to secure server] to read it).

If it's a theoretical debate on your thread, you can say "technically it's legal".  If it's in consideration for building a workflow to share that reason, choose another path.

Some decent opinions/descriptions: http://blogs.hcpro.com/hipaa/2010/01/phi-in-e-mail/


You will want to use the fresh queries switch:
    --fresh-queries     Ignore query results stored in session file


How are browser saved passwords vulnerable?

Assuming that as you say you don't use a master password, and so the password database is stored in clear text:
It depends on what kind of malware you refer to.
If there is a 0day exploit (or you use an unpatched browser), which 'breaks out of', embedded in any of the things you mention, effectively causing arbitrary code execution on your host, then that malware will be able to recover the whole database (but that will be the least of your worries).

In the common case of simple javascript execution (by xss for example), the script may be able to capture the password associated with the forms of that specific page.
Again, if there is a unpatched flaw in the browser which the script takes advantage of, like breaking the Same Origin Policy protections of the browser, then it might be able recover any password from the database.

Finally, if the attacker can not 'trick the browser' (as in attacking a vulnerability), he may also in the end try to 'trick the user' - think social engineering - by using some subtle way to make it so that you send the database yourself without noticing it.


I use Spring Security extensively, but it's intended to solve a different set of problems than the ones you cited: registration, change-password, reset.  You'll still need to handle all that yourself.  Spring Security is a very effective tool for handling authentication, authorization, and access-control.


Why does john force MinLen to 8 for wpapsk?

and still generates 8-character passwords. What am I missing?

"incremental" mode is limited to lengths up to 8 by default, at
compile time.

  How to deal with this ?

Download JTR source code

Now edit the src/params.h file - replace the following lines (around
line 200):

define CHARSET_MIN ' '
define CHARSET_MAX 0x7E
define CHARSET_LENGTH 8

with:

define CHARSET_MIN ' '
define CHARSET_MAX  0x7E
define CHARSET_LENGTH 10

Then let's rebuild JtR with this modification:
And generate a new .chr file:

  ./john --make-charset=digits10.chr

Now you can define a new "incremental" mode:

[Incremental:Digits10]
File = $JOHN/digits10.chr
MinLen = 10
MaxLen = 10
CharCount = 64

hope this will work for you


Secure cookies and Path Length Constraint

There is no relationship between cookie processing, and certificate extensions. The path length constraint (in the Basic Constraint Extension of a CA certificate) enforces a limit on the length of the certificate path beyond that CA; with a path length constraint equal to 1, that CA certificate is good for issuing non-CA certificates (e.g. a certificate for a SSL server), but not for issuing other CA certificates.

Cookies occur at the HTTP level, when the SSL tunnel has been successfully established. There is no HTTP, hence no cookie at all, if something goes wrong with the SSL tunnel; conversely, when cookies come into action, everything already went fine with the SSL handshake, in particular the validation of the server certificate and the processing of certificate extensions that this entails.


How to block requests in web app when certificate is insecure?

... wanted it to be secure from attacks from the application layer. ... website is allowing introspection from Burpsuite  ...  detect an insecure SSL certificate from the frontend using JS?

Based on your previous question you want to protect your application against reverse engineering and manipulation by the end user itself, i.e. the user controlling the client (browser).
But you cannot use a transport protection (TLS, HTTPS) to protect against manipulations at the endpoint of the communication. You can try to protect against reverse engineering the protocol and manipulating the traffic by a man in the middle proxy, but you cannot protect against somebody intercepting the communication before encryption and after decryption in a manipulated client, since you don't have full control about which clients are used.
Apart from that certificates from Burpsuite are not necessarily insecure. Once the issuing proxy CA is imported as trusted into the browser, the issued certificates are considered as valid and secure as certificates issued by a public CA. Thus basing the protection on the validity or security of the certificate would not protect against the end user itself intercepting the communication.
And even if one manages to get access to the certificate from JS to check if it is exactly the expected one, the code to do this would first need to pass the intercepting proxy and could be manipulated there to disable the checks or simply lie.
In other words: as long as one cannot fully control the client one should never trust the client to behave as expected. Any critical computation should be done at the server, all data sent from the client should be validated and critical state should be held at the server or be protected (like with HMAC) by secrets only known to the server.


I don't know how you get the impression that there isn't a message to verify the servers certificate, there is a message to request certificate verification in both directions, though the server certificate request is always implied with the ClientHello and the client certificate verification response is bundled with the ServerHello:

The key exchange mechanism also validates that the peers own matching private keys. Due to the maths involved, it is not possible to successfully do the key exchange unless both parties have the private keys matching their respective certificates.

Image credit: https://zoompf.com/blog/2014/12/optimizing-tls-handshake


Learning ethical SQL injection with php login form

You're syntax is a little off in both of your attempts at this. Since you mention you're using DVWA I'll provide the source here (so that we can rule out PHP/DB errors on your side)

<?php

if(isset($_GET['Submit'])){

// Retrieve data

$id = $_GET['id'];

$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";
$result = mysql_query($getid) or die('
' . mysql_error() . '
' );

$num = mysql_numrows($result);

$i = 0;

while ($i < $num) {

    $first = mysql_result($result,$i,"first_name");
    $last = mysql_result($result,$i,"last_name");

    echo '
';
    echo 'ID: ' . $id . '
First name: ' . $first . '
Surname: ' . $last;
    echo '
';

    $i++;
}
}
?>

The following line will trigger a successful injection:

foo' or '1' = '1

Notice that there is no tick at the beginning nor at the end of the payload. This is because (as you can see in the source) that the query itself is providing it (on both ends of $id).

In your examples of

' OR 1=1 and ' OR 'a'=a'

The first case is missing ticks all together, and the second case has an ending tick. Both will likely produce SQL syntax errors.

If you want to check your SQL syntax use an online resource such as this.


How to separate and secure domains using cPanel?

Any server controlled by cPanel (or similar) is insecure. cPanel is a huge pile of internet-facing code running as root that appears to work while containing tons of yet to be found exploits. Chances are your server is already compromised thanks to one of those exploits, and given that cPanel hides away all the tools you'd use to check for compromise (server logs, etc) you have no way of knowing until it's too late (when a clueless customer calls you because they hosted an e-commerce site on your server and got their credit card numbers stolen).

Now, even if we assume cPanel itself is secure, "shared hosting" isn't. Even if file permissions are set up correctly, all it takes is a single kernel exploit to get root and then break out of your own account and go poking around other account's files.

The proper way to do "shared hosting" is to either not execute any code at all (purely static hosting is fine - all CDNs are essentially just that and they seem to be doing fine), or run every customer's code in a VM or even a dedicated machine (to protect against hypervisor exploits).

Of course, this VM-based solution isn't something your average cPanel (or equivalent) would do - it would require some custom code to create and tear down the VMs and then manage URL routing (the idea is to host all static content on the host, and have that host act as reverse-proxy to app servers in the VMs for any executable code).