My bank makes me enter my password using the mouse. What's up with that? Internet banking login process for Westpac requires user to enter the password using the mouse.  It's annoying, what's up with that?  Is it just to try and stop keyloggers on public computers or is there a better reason?

Their mobile app lets you login with the keyboard.

The graphical entry of passwords is initially an attempt to thwart keyloggers. When such things began to appear, keyloggers naturally evolved (the people who write keyloggers have not stopped developing them; they adapt to new conditions) and modern keyloggers are also mouseloggers which record, for each click, a partial snapshot of the screen (a small area surrounding the click point).

Another reason why some banks use graphical password entry methods is because they do not like Web browsers which remember passwords. This can be for legal technicalities: if the browser remembers the password, then the user is not entering it, and this may make it more difficult for the bank in case of some conflict between the bank and the user. But, in practice, as a security measure, the graphical password backfires: if the user cannot have his browser remember the password, he will use another storage medium, for instance a stick-up note.

A more compelling reason, for a bank, to implement a graphical reason is trust management. The banking system foundation is trust: a bank is an entity to which you give your money, on the belief that it will give it back to you whenever you want. But since the bank uses that money (to lend it to other people), it intrinsically relies on the idea that not all its customers will want their money back simultaneously (that would be a bank run). As long as all the customers share that idea, the bank lives. That's the reason why bank buildings are always impressive (in the 19th century, they were all full of stone pillars and iron and marble, with extremely "massive" architecture): this is a conscious display of stability and robustness, so that you think of the bank in those terms.

In the age of the Internet, the graphical password entry is a stone pillar: it establishes a firm psychological distance between the bank and the less serious sites. It would not look good if the online bank Web site was too similar to the site you use to order a pizza. When they log into their bank account, the customers must have a feeling that they enter a "high security" zone in which their safety is taken seriously. The "graphical password entry", like all things graphical, is a nice gimmick for that (humans are visual animals, they react strongly to what they see). The Web site of my bank does not have a graphical password entry, but it takes care to open a popup window with a picture of a padlock, for the same reasons.


Taxonomy of Ciphers/MACs/Kex available in SSH? SSH offers a large variety of algorithms for Ciphers, MACs and KexAlgorithms configuration options.  Sometimes I need quick and light (my own internal network), and sometimes I want all the protections I can get (VPN'ing home from DEFCON).

Is there a taxonomy of what's slowest/fastest, and most/least secure (given known attacks on reduction of complexity, or increasing likelyhood of collisions, etc...)
 set of algorithms for each of the aforementioned categories?

I've read What are the realistic, and most secure crypto for Symmetric, Asymmetric, Hash, Message Authentication Code ciphers?, but I'd like to see more discussion on different recommendations per application (beefy server to server vs mobile device with short battery life and weak CPU), as well as other side-effects of different modes of operation (CBC vs CTR vs ECB) for let's say interactive use, vs file transfer.

Addition:
Just found this summary of effective transfer speeds of different encryption algos/modes.

An alternative response to the above is that if you're worried about security then focusing on algorithms is largely irrelevant, because where you'll get 0wned is through an implementation bug in your SSH server, not through anyone attacking the crypto.  In particular if you're doing something like VPN'ing home from DEFCON then you need to defend against metasploit, not a DES-cracker.  You could use the weakest algorithm that SSH normally supports, single DES, and be perfectly safe, because what's going to get you is an 0day in OpenSSH or, if you're not running the latest version, simply that.  So you're really asking the wrong question, pretty much any algorithm will keep you secure, it's the implementation bugs where they'll catch you.


Do the BEAST and CRIME attacks apply to an IMAP service? While setting up the Dovecot IMAP service, I noticed that the default parameters are not optimal, it allows SSLv3 for example. Using Thomas Pournin's TestSSLServer.java program, I saw the following:

...
Minimal encryption strength:     strong encryption (96-bit or more)
Achievable encryption strength:  strong encryption (96-bit or more)
BEAST status: vulnerable
CRIME status: vulnerable

For comparison, GMail seems not to be vulnerable to either attack:

$ java TestSSLServer imap.gmail.com 993
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
  SSLv3
     RSA_WITH_RC4_128_MD5
     RSA_WITH_RC4_128_SHA
     RSA_WITH_3DES_EDE_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA
     RSA_WITH_AES_256_CBC_SHA
     TLS_ECDHE_RSA_WITH_RC4_128_SHA
     TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
     TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  (TLSv1.0: idem)
  (TLSv1.1: idem)
  TLSv1.2
     RSA_WITH_RC4_128_MD5
     RSA_WITH_RC4_128_SHA
     RSA_WITH_3DES_EDE_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA
     RSA_WITH_AES_256_CBC_SHA
     TLS_RSA_WITH_AES_128_GCM_SHA256
     TLS_ECDHE_RSA_WITH_RC4_128_SHA
     TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
     TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
----------------------
Server certificate(s):
  89091347184d41768bfc0da9fad94bfe882dd358: CN=imap.gmail.com, O=Google Inc, L=Mountain View, ST=California, C=US
----------------------
Minimal encryption strength:     strong encryption (96-bit or more)
Achievable encryption strength:  strong encryption (96-bit or more)
BEAST status: protected
CRIME status: protected

Vulnerability for CRIME is tested by checking whether compression is enabled or not. Someone from the Dovecot mailing list asserted that BEAST does not apply to mail, is that true? Should I be worried about BEAST and/ or CRIME in the context of an IMAP service?

By only allowing TLSv1.1 and up, the BEAST status turns into "protected". I was not able to disable compression though. What are the recommended parameters for an IMAP service where the clients are sufficiently modern?

CRIME and BEAST are chosen-ciphertext attacks. The attacker needs to send tens of thousands of requests in the connection of the user. This works well for a web browser. Theoretically, it is possible for IMAP by sending mails to the victim, however the target plaintext (IMAP password) needs to be in the same packet as the chosen ciphertext. This is usually not the case for IMAP.

Nevertheless, it's probably good to copy the offered SSL versions and algorithms of popular IMAP services, like Google.


Can someone take money out of my account with just my Account & Routing number? I had recently given someone my account number and routing number to deposit money into my checking account. They owed me money I had lent and said this would be the easiest way for them to do it. I had recently asked if they followed through and they blocked my phone number. I have a bad feeling they're trying to do more than deposit money. They don't know where I live, my real name nor do they have my card number. Is there anything they can really do with just my account and routing number? Should I get a new account? Will I be fine?

In theory they can, just like companies can directly take money (called Direct Debit here in the UK) from your account using those values.

However to be able to do direct debits you'd need an established business account with a major bank which won't do any good for a fraudster as it's pretty much impossible to open one anonymously.

Finally all transactions are logged and banks can reverse them if there is suspicion of fraud, so there's no need to worry. Account and routing numbers are fairly low entropy so if this was a good fraud opportunity we would already have crooks bruteforcing those numbers.


Is there a Standard Verification process for Certificate Authorities to follow? So the premise of the question is to quantify the risk of wild card certificates versus regular certificates.  From my research the greatest fundamental danger of wild card certificates is the possibility of compromising a weak system, getting the private keys then you can masquerade as any system.  For this to work you have to compromise a system and compromise the public DNS server(assuming this is an Internet based attack) and do so before the certificate is revoked.

It occurred to me that if the requirements of certificate authorities for verifying companies validity changes, where some are easier to social engineer then others, it may discount the risk of Wild card certificates.  That is, it may be easier for someone to social engineer a CA then it is to break into a system and steal the private keys.  Further the named Certs may foster a false sense of security as they may be mimicked by another trusted authority.  This also creates another issue where certificate revocation is out of the hands of the company, where a wildcard could utilize it.

What I have not been able to find is a standard that root Authorities must follow when verifying client domains. Is there a standard they must follow?  If not does anyone know a list or site of the different verification requirements of each CA?

Thanks

This document can give you an historic overview of how standardisation for CAs has evolved.

EDIT:

A fragment of the document that gives a well overview:

  The first requirement imposed specifically on CAs as a group was in
  2000 when an annual security audit under the WebTrust for CAs
  standards was mandated by browsers and others with trusted root
  stores. See the original WebTrust audit standards available at
  http://www.webtrust.org/homepage-documents/item27839.aspx. These
  standards have been updated from time to time, so the current WebTrust
  audit standards are reflected in the detailed v.2.0 requirements found
  at the same link. Even before the first WebTrust for CAs standards in
  2000, most CAs also underwent annual performance audits under SAS 70
  standards (later replaced by SSAE 16 / SOC 2 / SOC 3) – and many still
  do in addition to WebTrust. Nearly all CAs in North America follow the
  WebTrust standards, but CAs in other parts of the world may be audited
  to the equivalent ETSI (European Telecommunications Standards
  Institute) audit standards – see www.etsi.org. Government CAs must
  submit equivalent government performance audits on a periodic basis as
  well.


Skype chat history and web browsing history CHECK In an office work place, can a network admin have access to my Skype chat history and web browsing history without logging in to my pc since all pc's are connected with the same network?

i am wondering weather is it secure to keep my login details saved in a office computer?

Can our skype chats be read in real-time without any body noticing?

Chat history and contacts are saved in a windows directory : C:\Documents and Settings\\Application Data\Skype\ .
Network admin has access to those files and can access them.
So basically, Yes. Network admin can view your chat history or even export them without you noticing.


KPTI - Meltdown - PoC Analysis Based on this PoC:

https://twitter.com/brainsmoke/status/948561799875502080

I see there are four rows outputed, the second one are two bytes of address of sys_read. What is the first one? Would third row be sys_write? I did some calculations on my laptop with Kernel 4.10 and the offsets of the syscalls on my laptop and the screenshot outputs don't match ....

Anybody has ideas what are those?

First row is guess (leaking by guessing), second timing (for this guess). So best guess, that syscall sysread is at 3a50, that matches reality.


How do we change the public key in our commercial app? We have a commercial library that uses a public key to sign an XML request that goes up to our license server. The response that comes back is XML that has been signed with our private key, and the library then uses the public key to verify the response.

How do we handle the situation where the private key was compromised (intentionally or through a mistake)?  We now need a new public/private key. However, people will not be willing to update their library for this case.

Should we have a property for the library that, if set, is the new public key to use? And then send that out asking people to update that setting?

Library is runnign on Java or .NET and the server end is .NET on Azure if that matters (likely doesn't).

Simple option:  Use two public keys embedded in the library.  One of them is used day-to-day, and the second is in offline cold storage.  If key compromise necessitates a rotation, you can bring the offline key back online.  Then you update the library before the next compromise.

More complex option: embed a certificate authority key.  Keep it offline.  In addition to the signed responses, include the public key (just like an HTTPS request).  Verify the CA chain.  (This need not be a commercial CA, you can run your own easily.)

Most complex and most flexible: combine both.  Two CAs, offline cold storage in HSMs/Smart Cards for CA keys.


What's the difference between "Public Key Algorithm" and "Signature Algorithm" in OpenSSL output? If the output is:-

➜ $?=0 % openssl x509 -noout -in ./cert -text | grep Algo
        Signature Algorithm: sha256WithRSAEncryption
            Public Key Algorithm: id-ecPublicKey
    Signature Algorithm: sha256WithRSAEncryption

Does it mean it's an ECDSA cert?

The Public Key Algorithm refers to the public key inside the certificate: This certificate is used together with the matching private key to prove the identity of the peer (authentication). In your case it is an ECC key (id-ecPublicKey) which means that this is an ECDSA certificate.

The Signature Algorithm refers to the signature of the certificate created by the issuer: This signature proves that the claimed issuer of the certificate is the real issuer since the signature can be verified by using the public key from the issuers certificate. By verifying the link to the issuer a verified trust chain can be built up to a locally trust certificate (i.e. local trust store, root CA). In your case sha256WithRSAEncryption is used which means that the issuer has an RSA public key inside its issuers certificate and that the hash used for signing the leaf certificate by the issuer is SHA-256.


Securing passwords for REST Authentication I'm developing a REST application using the Spring Framework, as as part of the requirements, we have to secure the different functions of the system to different user roles (pretty standard stuff). My current method of determining the roles for the currently logged in user is that every time they call a REST url from the frontend, I am adding a Base 64 encoded string to the request header. This string when decoded resolves to their username and a bCrypt generated password hash in this format username:hashedpassword.

I'm slightly concerned that this is not secure, even though the request will be made over a secure HTTP connection, because it could give a potential hacker access to at least the users username. They couldn't get the password because that is just a hashed value, but they could use that hashed value to call the REST API successfully.

How can I secure this system properly? Do I need to add in a session token or some kind of randomly generated key for the session?

My followup question is then how can I do that RESTfully? I was thinking that I could generate (using bCrypt) a hash that represented the username:hashedpassword together on login, save that to the database and check against that whenever a REST call is made. When the user logs out, just set that to null. Rinse and Repeat. That way any potential attacker would only get a single bCrypt string that wouldn't expose the username, but they could still use that string to call the REST API.

The following links may provide you with an in-depth answer:

REST security standards
I just send username and password over https. Is this ok?
https://stackoverflow.com/questions/3461298/password-hashing-non-ssl

Please keep in mind that it is better to not use the username-password combination in every request that you make. Better is to authenticate the user, generate a token server-side, communicate it to the client (e.g. in a cookie) and use that token as authentication for subsequent requests. This link can guide you in that process: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md.


SSH Protocol classification version exchange messages I am trying to classify network protocols over network  traffic . Now my task is SSH protocol. I read the RFC and know SSH starts with protocol exchange message from both client and server .

Format is : SSH-protoversion-softwareversion SP comments CR LF

Also I found an open source project called "ndpi" which already implemented this

if (flow->l4.tcp.ssh_stage == 0) {
    if (packet->payload_packet_len > 7 && packet->payload_packet_len < 100
        && memcmp(packet->payload, "SSH-", 4) == 0) {
        flow->l4.tcp.ssh_stage = 1 + packet->packet_direction;
        return;
    }
} else if (flow->l4.tcp.ssh_stage == (2 - packet->packet_direction)) {
    if (packet->payload_packet_len > 7 && packet->payload_packet_len < 100
        && memcmp(packet->payload, "SSH-", 4) == 0) {
        ndpi_int_ssh_add_connection(ndpi_struct, flow);
        return;
    }
}

It is checking if payload contains "ssh-" string . But I can't understand connection with "packet_direction" . I think simply checking if 2 payloads in a flow contains "ssh-" string would be enough. I want to ask if I should take packet_direction into consideration and if yes why?

The piece of code you show is doing exactly that: it is checking that there is a packet (of size 8 to 99 bytes, beginning with "SSH-") in both directions. Since client and server are supposed to talk somewhat simultaneously, the detection engine cannot assume that it will see the packet from the client or the packet from the server first; and knowing which side of the connection is the "client" might be difficult anyway in the context of packet-by-packet processing.

So the code you show uses a flag called packet_direction which has value 0 or 1, for the two possible directions. I will thereafter call direction 0 "AtoB" and direction 1 "BtoA" (it does not really matter whether A or B is the client at the TCP level). The code also uses an internal flag ssh_stage, initially at 0. When a first packet which matches the conditions (size 8 to 99 bytes, begins with "SSH-") is detected, the first half of the code is used (since ssh_stage is 0 at that point), and ssh_stage is set to 1 if this first packet is in the "AtoB" direction, 2 if it is in the "BtoA" direction.

When a second matching packet arrives, packet_direction is now set to the direction of that second packet. If that second packet is in the same direction as the first packet, then the current value of ssh_stage will not match the expression 2 - packet->packet_direction; however, it will match it if the second packet comes from the other direction (e.g. the second packet is in "BtoA" while the first packet was in "AtoB").

To sum up, the code checks that there are indeed two "SSH-looking" packets in opposite directions, as opposed to two successive packets in the same flow direction.

What you should do depends on how reliable you want your engine to be. If you only require two SSH-looking packets without considering direction, you might get some false positives, in case a non-SSH client happens to send two such packets to a non-SSH server. Requiring that the two packets flow in opposite directions will trigger fewer false positives. Note that the ndpi code is already not 100% reliable.

Indeed, if you look at RFC 4253:

The initial strings sent by both client and server may have length up to 255 characters, not 99.
After the exchange of the version strings, the connection setup dialog continues with some extra data from the client, which the client is allowed to send immediately, possibly in the same packet as its version string, so the client payload length might be way above 255 bytes.
The server is allowed to send some extra lines of characters before its version string, so the server packet payload length may also exceed 255, and it does not necessarily begin with "SSH-".

So the ndpi code may miss some perfectly standard SSH connections. It is up to you to decide whether you want to miss more or fewer such connections. Of course, the more reliable you want your code to be, the more work you will have to do...


Android key protection I was reading this documentation and saw this part;

  When an application performs cryptographic operations using an Android Keystore key, behind the scenes plaintext, ciphertext, and messages to be signed or verified are fed to a system process which carries out the cryptographic operations. If the app's process is compromised, the attacker may be able to use the app's keys but cannot extract their key material (for example, to be used outside of the Android device).

It makes me a bit confused as I don't quite get how being able to access app keys but not the "keying material" is still safe (or secure). I mean if the key is the ultimate output of a KDF, does it make any difference not being able to access the corresponding keying material? I can still use the keys, for example, to decrypt messages, right?

... use the app's keys

This means perform cryptographic operations using the key, like signing or decrypting something.

  ... cannot extract their key material (for example, to be used outside of the Android device)

This means the attacker cannot extract the keys from the device, i.e. he must always have access to the device for doing operations with the keys. This is possible if the attacker has stolen the device or has a remote backdoor to it - but ultimately the owner will know that the device could be compromised and can make the appropriate mitigations, like revoking the keys so that no new messages will be encrypted for the owner using this compromised key.

If instead the attacker would be able to extract the keys from the device than a short access to the device might be enough and the owner of the device might not realize that the keys are compromised since the device is still there and it does not look compromised either. Thus the keys will not be revoked and the attacker might be able to decrypt future messages too or impersonate the owner of the keys.


Is it necessary to test all input parameters of a web application when testing its security? We know that testing input parameters for lack of validation is one part of a black box web vulnerability assessment but, is it necessary to test ALL input parameters (parameters, cookies, HTTP headers, URLs...)? If we don't test one it is possible that that parameter is the one vulnerable to a SQL injection or the XSS.

Prioritizing is one of the common answers but, how to prioritize if a SQL injection in a completely non-critical functionality opens access to the database giving complete control to the attacker?

If we have to choose a sample of input elements, how to choose that sample?

Should pentesters base its decissions just in experience or instinct when choosing which input parameters to test?

NOTE: I know that the correct thing is to test all parameters but sometimes this is unrealistic due to time limitations.

Yes you need to test all parameters if you want to perform a good test. You may choose to use automatic vs manual testing depending on how critical the input variable is and where it is situated in the application. Note that while a certain input variable may seem non-critical it might leave attackers with a vector to get to more critical functionalities of the application (think of stored XSS)
Prioritize based on likelihood and impact on your business. If that vulnerability allows to execute commands or dump all contents of your database,including confidential information, you need to patch it as soon as possible. If it only allows access to public information (and it can't be abused to gain more privileges within the application or access to the underlying OS) then you might make it less of a priority (depending on what the other issues are you are prioritizing on)
I'm not sure what "input elements" are but if you mean parameters, you need to choose all. You can choose to pay more attention on some fields than others (depending on your budget/time)
It depends, you need to do what your client asks, obviously if your experience has learned you that certain variable are more susceptible than others, you might just give them a bit more attention. But I'd say you need to take the requirements of the client into account.

Even if a functionality is not considered critical, you always need to assess the impact your exploit has on the application and the information stored within the application. The opposite is true as well, if you have a critical functionality with an exploit, but you can't actually gain any valuable information from it, then you should make it less of a priority to fix it. So, the impact of exploiting a vulnerability  is important and not the criticality of the function you are exploiting. Prioritizing needs to happen based on impact.


What constitutes a Virtual Private Database? I recently came across this term "Virtual Private Database" and I'm wondering what criteria need to be satisfied to allow use of the term.

I first saw the term in an HP/Fortify doc:

  A virtual private database is used to ensure separation between
  customers. The database is setup as a virtual per-client relational
  database management system (RDBMS) instance with database encryption,
  ensuring that users can only access their own data in their own
  database.

And here is some Oracle documentation:

  Oracle Virtual Private Database (VPD) enables you to create security
  policies to control database access at the row and column level.
  Essentially, Oracle Virtual Private Database adds a dynamic WHERE
  clause to a SQL statement that is issued against the table, view, or
  synonym to which an Oracle Virtual Private Database security policy
  was applied.

  Oracle Virtual Private Database enforces security, to a fine level of
  granularity, directly on database tables, views, or synonyms. Because
  you attach security policies directly to these database objects, and
  the policies are automatically applied whenever a user accesses data,
  there is no way to bypass security.

Does the policy have to be applied by the Database software in order for it to be a VPDB? Can the policy be applied by your application? Does the Database have to do the encryption?

Say your application encrypts a field in a table and your application has rules that in effect apply a policy that ensures that users can only access their own data. Does one then have a VPDB?

TIA

The name is slightly misleading, but Oracle have obviously used it in a similar way to VPN being a virtual private network.

With a VPN, the network is actually public, but encryption and authentication provide privacy without the network itself needing to be private.

With Oracle's VPD, the database can be public (or at least open within an organisation) with access controlled through authentication and encryption so private areas can be created virtually within this public database.

In order to manage this, the database software needs to run the additional clauses and encryption to enforce the controls.

Your scenario, where the encryption and authentication is done separately to the database should still be able to provide the same Virtual Private Database.


Any difference between these certificates from a security perspective? I understand some might buy a particular brand because, I guess, it's like buying a Rolex instead of a Swatch? But marketing considerations aside, is there any real security difference between the first ($36/yr) and second ($63/yr) certs offered on this page:
https://www.namecheap.com/security/ssl-certificates/wildcard/
The only difference I see between the two is they say the cheap one is good for personal websites and blogs, and the second is good for small/medium sized businesses. What am I missing here, if anything?

All X.509 certificates used in TLS certify the same sets of data.  The security of the certificate is bounded by the key size and type (which you pick when you generate the private key) and the key size and type and signature algorithms used by the certificate authority to sign it.  Provided all of the keys and signature algorithms meet your desired security level and certify the domains and IP addresses you wish, there is no difference in them.
The relevant difference appears to be different levels of "assurance", whatever that means.  Since these are domain-validated certificates and the CA/Browser Forum specifies the approaches that may be used to securely validate a domain, there is no reason to believe that one of these is better than the other, except possibly for the pocketbooks of the sellers.
Do note that Let's Encrypt offers free 90-day wildcard certificates through automated issuance via the ACME protocol, and so unless you need a longer lifetime or a feature Let's Encrypt doesn't support (e.g., IP addresses or ECDSA roots), you can end up paying nothing at all by going with them.


Unusual file permissions on WordPress websites I've been asked by a customer of mine, to manage a few hundred WordPress sites.
Doing an initial security assessment, I've found that every site (350 sites) has unusual file permissions on every php file (755) that means executable bit on all groups (user, group and other)...
Trying to investigate further, I've checked umask settings and it seems ok: 0002 (that means 775 for newly created directories and 664 for files) which is the default on Linux systems.
Asking my customer about this unusual permissions, he confirmed that he wasn't aware of this issue...
Which could be the security implications of such a setting? Can this be exploited somehow by a remote user?

From what you have written, it does seem to me, this is fairly standard and not too unusual for file permissions. Compare this to other blogging websites of a similar fashion for example. I do not believe that the vulnerability is much higher than for a usual blog website or any other such similar service.


Regarding malware and hardware Bit of a weird one, hope this is the appropriate venue:

I've just purchased some Ethernet-over-power adapters that were returned to and repackaged by a brick and mortar retailer. I'm trying to be more vigilant with security recently and was wondering: should I be concerned in at all that these devices could have been loaded with malware or something nasty?

I know this may be paranoia but I am sharing this internet connection with others and am mindful of something that will be connected directly to the router.
Any advice would be greatly appreciated. Thanks

Any device that you are using can be malicious; and what you bought can be full of spy tools made by your government especially to spy on you. You don't know. ¯\_(ツ)_/¯

You should ask yourself whether you can trust the manufacturer and the retailer.

I honestly think you should not worry about that; or start worrying about all the devices you are using. (firewalls, USB keys, bluetooth headsets, etc.)

But remember that at some point, you have to trust in something.


Are (Intel) chipsets spying on us? I had a conversation yesterday where someone claimed that I should only use (Intel) computers from before 2006. This was allegedly because after this, software has been embedded in the chipsets that have the ability to "phone home" or let them "phone in" in various ways. The exact details of how and what were not elaborated further.

This sounded a bit like runaway paranoia, but stories about things like secret 3g chips that can switch off your computer remotely don't seem like total science-fiction to me, and are deeply worrying.

So I thought I'd put it to the floor: What reliable sources exist that could support such a claim?

What is he talking about?

He is referring to the Intel Manageability/Management Engine, or ME. It is a processor embedded in the chipset's PCH, and is typically composed of an ARC, ARCCompact, or i486/i586 hybrid microprocessor. It is designed to, among other things, make remote administration easier. On servers and certain business laptops that support AMT (Intel Active Management Technology), certain network cards can be used to control the system remotely. This requires enabling it in the BIOS/UEFI and setting a password. If you have a 3G card installed, then it in theory could use that card for remote management, but in all likelihood, you don't.

The danger of exploits

There is a risk of vulnerabilities in the network protocol, as with everything that implements a network stack, and there have been bugs involving them in the past. They typically require you to actually enable remote management to be vulnerable. Overall, the whole ME scare is a bit overdone. All the scary capabilities listed are opt-in or not even present.

The danger of rootkits

There is also the fear that the ME could be used to hide a low-level rootkit. This is not an issue in most cases because it requires either very privileged access to the computer, or the ability to physically modify the motherboard (replace the BIOS chip, for example). Even without the ME, very stealthy rootkits can still be installed with that level of access.

The benefits of newer processors

I would not recommend using an older CPU model. Newer models have had significant improvements in security. A current modern processor may support many of the following:

NX - One of the oldest security features, it allows marking pages as non-executable, so a buffer overflow that overwrites NX data cannot then execute it.
SMEP - Prevents low-privilege userspace code from being executed in a high-privilege, kernelspace environment. This forces attackers to inject their shellcode directly into the kernel, which is far more difficult and prone to crashes.
SMAP - Same as SMEP, but prevents all accesses, not just execution.
UMIP - Hides certain potentially sensitive information which otherwise could be accessed at low privileges.
VT-x (virtualization) - Not usually used for security, but can be used for sandboxing, in a pinch.
VT-d (IOMMU) - Allows isolating devices from each other and from the rest of the memory, preventing DMA attacks.
IR and x2apic - While their functions are unrelated to security, they are both needed for VT-d to function against malicious actors.
MPX - While designed for debugging, it can be used to prevent buffer overflows on programs which use these instructions.
SGX - Creates a secure, encrypted "enclave" that even high-privilege code cannot access.
RDRAND/RDSEED - Adds high-quality random data to the system, which is useful when doing things like generating passwords. While there are reasons to be skeptical about using it as your sole randomness source, it is harmless when used to augment your system's other sources.
AES-NI - Accelerates AES encryption with dedicated hardware instructions, but is also useful for security by preventing side-channel attacks, since the processor's cache is not used.
CET - An upcoming feature that is designed to help mitigate ROP attacks (attacks that allow running arbitrary code on memory which is executable but cannot be written to by executing instructions out of order).
MPK - An upcoming feature that, among other things, allows code to be executable but not readable by providing more fine-grained control over memory permissions.
BootGuard - Prevents any unauthorized modification of the BIOS, by signing it and verifying the signature at each boot.
TPM - While limited in capabilities, it's still useful for secure attestation, key storage, and detecting evil-maid attacks (see Joanna Rutkowska's "anti-evil maid" program).
fTPM - Similar to a hardware TPM, but integrated into the ME itself. While it has its own downsides, it is also invulnerable to the classical MITM attacks against regular TPMs.
TRR/pTRR - Strongly resists rowhammer attacks on supported memory modules by detecting when a row is being accessed too often, and refreshing it by force.

Of all of these security features, only NX is typically supported on older processors, and even then, it can be buggy.

The issues with older processors

Additionally, older processors often have severe bugs which are not going to be fixed due to no longer getting microcode updates. Many 32-bit Core2duo processors have a bug which causes NX to be active on only one of the two cores. Newer systems also often have more secure BIOS, largely due to the work done by Legbacore. These newer systems lock the BIOS so it cannot be modified. Old systems do not have this and are very easy to infect with BIOS rootkits, as they offer no write protection for the BIOS.

Even worse, some old processors (especially Atom processors) are highly vulnerable to cache exploits. This can be so bad that it can allow a webpage running JavaScript to hijack the CPU itself, without ever needing to break out of the browser. Other old processors are vulnerable to SMM rootkits which, like an ME rootkit, cannot be detected by the operating system. The "sinkhole" attack is one example which exploits SMM on older processors.

Older processors are probably going to be 32 bit, which reduces the quality of ASLR, a technique to randomize the locations of loaded libraries. On Linux for example, the strength of ASLR is limited to 16 bits (8 by default) on these processors, compared with 32 (16 by default) when running on a 64 bit system. Certain side-channel attacks can break ASLR much more easily on 32 bit systems because of this.

But what is the actual risk?

If your system's ME supports remote management and if you have a supported network card and if you enable it in the BIOS and if there is a remotely exploitable bug in the network stack and if you allow incoming connections, then you can potentially get your computer infected with the equivalent of a BIOS rootkit (the ME code exists in the BIOS, after all). If you use an older system to avoid the ME, you will be forgoing a large number of important security features and will need to live with known, often severe bugs.

Mitigations

If you are still worried about the ME, or your threat model makes it a bigger risk than it would be for most people (e.g. you need to use a 3G card), there are currently two ways to limit the powers of the ME, aside from simply turning off AMT. The first method works on Sandybridge and Ivybridge processors. Overwriting the first page of the ME can cripple it, so only the core functionality is enabled. The second method allows completely disabling it during runtime. An undocumented switch was found which causes the ME to lock itself up after running the necessary hardware initialization routines.

To end with an analogy, imagine a web browser. Sure, older browsers were simpler and do not have potentially exploitable features like WebGL or WebRTC, but would you really trust someone if they recommended you use an outdated web browser with known bugs, just because newer models which fixed them may potentially have their own set of problems?


Spamassassin public corpus I selfhost my mail server and have earlier downloaded Spamassassin corpus from http://artinvoice.hu/spam to have a head start on the bayes learning.

The artinvoice.hu site is down and has been for weeks.
Are there any known good alternatives?

There is also Untroubled.org,
They tend to publish montly spam as well.

http://untroubled.org/spam/


How can I store and manage my GPG key pair securely? I've taken measures and thoughts on how to securely store and manage my key pair. In the process of it a few questions arose, which I'm not capable of answering yet. My key pair will be used to encrypt passwords and documents of banks, insurances, invoices, photos and the like. All this data is not publicly available. It is stored in a cloud with password restricted access. I'm evaluating right now, which one fits best.
This is how I set up my key pair:
# Generated a key pair in the past, following general tutorials
gpg> list
sec rsa2048/9AB628FC04C23871
    created: 2019-02-29 expires: 2022-02-29 usage: SC
    trust: ultimate    validity: ultimate
ssb rsa2048/17832C40CF826BA9
    created: 2019-02-29 expires: 2022-02-29 usage: E
[ ultimate ] (1). Thomas Kelly <Tkelly@ua-corp.com>

> gpg --list-keys --with-fingerprint Tkelly@ua-corp.com
pub    rsa2048 2019-02-29 [SC] [expires: 2022-02-29]
       B69A 8371 FC28 402C C204 82CF 7138 A96B B8F4 C87A
uid         [ ultimate ] Thomas Kelly <Tkelly@ua-corp.com>
sub    rsa2048 2019-02-29 [E] [expires: 2022-02-29]

> fdisk /dev/sdb # n, 2048, +2G, w
> cryptsetup open --type plain -d /dev/urandom /dev/sdb1 data
> dd if=/dev/zero of=/dev/mapper/data status=progress bs=1M
> cryptsetup close data
> cryptsetup luksFormat /dev/sdb1 # pw ...
> sudo cryptsetup open /dev/sdb1 data
> mkfs.ext4 /dev/mapper/data

Then I went on and exported my keys towards this device, I've created. After I got used to it, that private keys are always a little bit different from another and you can't export your sub-public key, the following questions remained:

Are both of the following commands returning the ssb key (17832C40CF826BA9)?

gpg --export-secret-keys 17832C40CF826BA9
gpg --export-secret-subkeys 9AB628FC04C23871

Is it fine to remove the key 9AB628FC04C23871 from my system, after I backed it up on the drive, created above?

Should I save a revocation certificate with it?

This key pair once expired and I changed the expire date. I can't remember correctly, but I've found two additional certificates lying around that seem to be these old expires certificates. I've read that the process of changing the expiring value creates new certificates. Can you confirm this?

I want to have two certificate stores like this on different locations. I'd renew the key on a yearly base. Should I use paperkey or the same digital method above?

Are both of the following commands returning the ssb key
(17832C40CF826BA9)?
gpg --export-secret-keys 17832C40CF826BA9
gpg --export-secret-subkeys 9AB628FC04C23871

Yes, in addition to other things: The first command exports the full key - the primary key pair (public+secret) and its subkey pair (even though you specified the subkey ID, gpg exports the entire key because of the command used). The second command exports almost the same thing, the only difference being the primary secret key it exports is unusable.

Is it fine to remove the key 9AB628FC04C23871 from my system, after I backed it up on the drive, created above?

Yes. But take care that the output of the first command export-secret-keys is the one you have saved.

Should I save a revocation certificate with it?

If your use case doesn't involve sharing the public key with others so they can encrypt documents to you and/or verify documents you sign, there's no web of trust and hence no reason to be concerned with the revocation certificate.
A revocation certificate is used by importing it to your keyring (you can also revoke any key pair in your keyring using the --edit-key menu) then uploading the revoked key to a keyserver and/or sending it (and the revocation certificate) to any of your contacts with whom you had shared the public key. The certificate itself contains instructions on how to apply it.

I've read that the process of changing the expiring value creates new certificates. Can you confirm this?

Changing expiration dates has no effect on revocation certificates. The only times a revocation certificate is created is when you first generate the key and if you manually generate a revocation with --gen-revoke

I want to have two certificate stores like this on different locations. I'd renew the key on a yearly base.

Given that your use case seems restricted to securing personal data in cloud storage there is little reason to set an expiration date at all. If you ever want to change to a new key, you'll still have to retain the old one (or else unencrypt everything made with the old key then re-encrypt it with a new one).

Should I use paperkey or the same digital method above?

Be advised that if you use Paperkey it saves only the secret key data without any accompanying public key material. The public key will be required when you want to import the secret key to gnupg. The best thing you can do is use a strong password for your private key.
The only thing you might consider is a larger RSA public key. Your current key is 2048-bit  the default key size in GnuPG is now 3072-bit. While it is probably far outside the realm of possibility for any entity to factor a 2048-bit RSA modulus, that probably won't remain the case forever.


Encryption key storage I recently inherited an in-house built key storage system. The company stores credit card data in two database servers which are AES encrypted. The keys reside in a separate system that is located in its own DMZ. When a web server needs to encrypt some data, the key server is called via https and requests a key. It returns a key, and an encoded serial number. The app server stores the encrypted info and the serial number then discards the key. When data needs to be decrypted, the serial number is sent to the key server which returns the key that was used for that record.

The fellow that developed this did not use key pools. Every key is a unique random value. The key database is encrypted using a key generated by 2 passwords provided by 2 custodians. From what I am seeing, even if you got hold of the keys, you would have to be able to decode the serial numbers to be able to use them, and then each key would only be good for one record. He even wrote a php extension in c that has the encoding/decoding functions.

This seems to be a pretty good design. Anyone Have any experience with this type of thing that can give an opinion on this method and any possible holes or improvements.

On first glance, it appears to be ingenious and a double layer of security.  On further thought, it is quite similar to tokenization of credit cards, with 1 pro and 1 con as opposed to tokenization:

pro - there are two layers of encryption in two separate systems
con - full credit card numbers, although encrypted, are still stored in the business system and the encryption is reversible.

Although the two custodian setup is a good mechanism, the keys to the kingdom are still the encryption key of the 'key database'.  If they are compromised, the rest is just lookup and algorithms and ALL credit card numbers can escape.

Based on a preliminary analysis, I would venture that, on the whole, it is perhaps less secure to a tokenization system.  A token cannot be reversed, it can only be looked up, and thus throttled, controlled from IP etc. A good tokenization system has other advantages like it can be outsourced, or the CC number can only be released to a third party like a payment processor, etc. and CC numbers, encrypted or clear, are never stored in a business system and may not even enter the business estate after having been exchanged for a token the first time.


Can cURL block a rogue CA? I know which Certificate Authority (CA) my server uses for its TLS certs.

My client system also knows who the CA is.

When I use cURL, I can specify --cacert to specify a custom CA file to use, but it seems that this is used IN ADDITION to the trusted CAs installed on my system, not instead of.

So is there a way of telling cURL to ONLY accept CA certs that I know to expect, when making a connection to my server?

Otherwise, I can't detect a rogue CA from issuing a cert for my server unless I manually scrape the verbose connection details during connection...

Good question - in a browser there is certificate pinning.
After looking this up I came across the curl flag --pinnedpubkey

  Certificate pinning

  TLS certificate pinning is a way to verify that the public key used to
  sign the servers certificate has not changed. It is "pinned".

  When negotiating a TLS or SSL connection, the server sends a
  certificate indicating its identity. A public key is extracted from
  this certificate and if it does not exactly match the public key
  provided to this option, curl will abort the connection before sending
  or receiving any data.

  You tell curl a file name to read the sha256 value from, or you
  specify the base64 encoded hash directly in the command line with a
  sha256// prefix. You can specify one or more hashes like that,
  separated with semicolons (;).

  curl --pinnedpubkey "sha256//83d34tasd3rt..." https://example.com/
  This feature is not supported by all TLS backends.

Reference:
https://ec.haxx.se/usingcurl-tls.html


Is it ok to use computer while scanning for viruses? Should one refrain from using the computer while a virus scan is in progress? Are there certain things that are ok and others not? For example is it ok to use a web browser while a scan is in progress?

This may be entirly unrelated but Avast 7 says "Multiple scans can be run at the same time".

Your AV might be unable to scan some files while they are in use. If that does happen, then any good AV should report this in a summary of the scan when it finishes, I'd have thought.

Performance could be pretty dire while it's running a scan, too!


SSL: How to send generated client certificate from server to avoid MITM? The question I have is simply how do I prevent a MiTM attack on a certificate once the server side creates a new one and tries to send it to a client? Does the certificate get encrypted by rsa and sent or...

You have two potential attacks:

The attacker poses as a fake server, and talks to the genuine client, feeding him a wrong certificate or other nefarious data.
The attacker poses as a fake client, and talks to the genuine server, obtaining a valid certificate with the genuine client's name but the attacker's key in it.

A man-in-the-middle attack is when the attacker does both simultaneously. However, each attack is problematic in its own right.

Defeating the first attack (impersonation of the server), use the standard mechanisms: have the server use a certificate, issued by a well-known CA, that the client trusts. All HTTPS Web sites do that. This is how, when you connect to https://www.paypal.com, you get the nifty padlock icon and know that you are really talking to Paypal's server.

To defeat the second attack, well, it is up to you: the server is creating and sending a certificate to "a client who just connected". How does the server know what to put in the certificate ? From where comes its knowledge of the client's identity ? If, for instance, the "genuine client" is authenticated by virtue of having been granted a one-time registration password, then the communication will occur within a HTTPS connection. In that connection (where the server is verified as "true" by the client, see above), the client sends its one-time registration password, and the server, from that point onwards, knows that it is talking to the expected client, and can send him a certificate or whatever it wishes to send him.


Size of a secure random number taking into account quantum computing and size of universe Most random secure numbers are 256 to 512 bits. But given the size of the universe and eventually quantum computing, I am wondering what is a better sized randomly generated number, taking into account minimizing its size while also making it unique enough to cover that amount of space and quantum computing. Or is 2256 ≈ 1e77 large enough?

Quantum computers are not magic. They can only accelerate a very specific class of problems in the so-called BQP complexity class. This includes integer factorization, which is why a cryptanalytic quantum computer is said to be capable of completely breaking RSA keys in polynomial time by utilizing the quantum Shor's algorithm. However, their ability to brute force through a keyspace is much more limited. The most efficient quantum algorithm for searching a keyspace is Grover's algorithm, which provides only a quadratic speedup over classical algorithms. This means that a quantum computer can brute force a 256-bit key in only 2128 operations instead of 2256 as with a classical computer. Luckily, this means all we need to do to resist quantum computers when choosing key size is choose a 256-bit key or larger. You only need to double the key bits to retain the equivalent classical security against quantum computers. If we consider 128-bit keys to be the minimum, then double them to 256 bits.


GPG: Detaching Public Subkeys - why can't I do it? I understand the benefits of using subkeys. I also know that, in the case of private keys it is possible to detach the subkeys from the master key, since there are times when a user may prefer not to store the private master key with the private subkeys. (Using gpg, --export-secret-subkeys)
Moreover, when you do --export a public key, it appears not to matter whether you use the fingerprint of the master key or that of one of the subkeys.

As far as I can tell, it's not possible to detach public subkeys. Let me be clear: I can't think of any significant reason why one would wish to. The only rationale I can think of is minimalist - you might want to only import the public subkeys because that's all that you intend to use.
But I am trying to figure out whether there is a more fundamental reason.

Is it because the user id details are attached to the master key, and detaching subkeys would allow unidentified keys to float around? (I'm not convinced by this - when you import detached private subkeys, the absent master key still gets a reference [sec# etc.], even when it is absent. So surely the same could be done for public keys.)
Is it just because there is no good reason for doing so?

If, however, there is some reason public subkeys can't logically be split from the public master key, that would suggest I don't properly understand subkeys.

Detaching Subkeys in Theory...

Detach subkeys does not correspond well with the OpenPGP model of primary keys, subkeys, user IDs, certifications and trust.

Both subkeys and user IDs are bound to the primary key, each individually. Certifications are applied on tuples of primary keys and user IDs, trust directly on primary keys.

You could very well detach a subkey from its primary key and use it (as a primary key), in necessary by fiddling with the bits in the OpenPGP packets. But without the connection with the primary key, it is in fact a completely new key without any certifications and trust (although the key material, the numbers behind it, stay the same).

... and Practice

Be aware that when exporting subkeys using gpg --export-secret-subkeys, a primary key stub is always exported, together with user IDs; because of this, GnuPG will display the "absent master key [...] reference [sec# etc.]" as you called it.

You can easily verify it by running

gpg --export-secret-subkeys [subkey-id]! | gpg --list-packets

for example (for subkey 0xDEADBEEF)

gpg --export-secret-subkeys 0xDEADBEEF! | gpg --list-packets

Make sure to include a ! after the subkey id, otherwise GnuPG will resolve the associated primary key and thus export all available subkeys!

Really Breaking Things Apart

To really separate the subkey, you could use gpgsplit, which dissects an OpenPGP message into its actual subpackets. Working with them requires deeper knowledge of the OpenPGP specifications (RFC 4880), but it makes fiddling with the individual packets (also with hex editors) and recompiling valid OpenPGP messages using cat rather easy.


OpenSSL create both keys at once Is there any way to create private and public keys with one command?
The classic way is two commands

$openssl genrsa -out privkey.pem 2048

and after that

$openssl rsa -in privkey.pem –pubout –out pubkey.pem

I tried with | (pipe) but no.

OK, since noone is trying to answer this I have few tips. OpenSSL doesn't seem to know that.

If you need to use pipe with the private key in stdin, you can use following. E.g. to output the pubkey right away (in fact, it is useless since you don't save the privkey):

openssl genrsa 2048 | ....

openssl genrsa 2048 | openssl rsa -pubout
You can use ssh-keygen for similar thing. The following will print the pub/priv rsa key pair with empty passphrase, but afaik it's in a bit different format than the OpenSSL would give you.

ssh-keygen -t rsa -f file -P ""
And then there is the fact that using && or two separate commands should be okay for most situations.


How do online banking applications work? It's suprisingly hard to find concrete information about that topic. I've worked with the Flask framework lately and I just managed to create a proper login that stores the passwords in a database after hashing them. While reading about this topic the following question came to my mind. What technology is used to build properly secured web applications like e banking platforms? Could you build something like that with Flask or is there a similar technology that is much safer?

I just managed to create a proper login that stores the passwords in a database after md5 hashing them

No, you didn't...

  What technology is used to build properly secured web applications like e banking platforms?

Java

  Could you build something like that with Flask?

Maybe, if you're careful and can find quality libraries or build your own

The correct way to store passwords is to use a slow, cryptographic hash like bcrypt, scrypt, or PBKDF2


Storing OAuth access and refresh tokens in non HttpOnly cookies I am using OAuth auth code flow to generate access and refresh tokens and then I store them in two browser cookies that are not HttpOnly and send them back too the client.

The cookies need to be non HttpOnly because the client needs to know if an access token exists to know if it should talk with the authorization server and perform a refresh token flow to get new tokens.

How bad is this security wise ? What are the risks when the refresh / access token get stolen ? What are some ways to mitigate these risks ?

EDIT

Also, do you think PKCE can improve the security of refresh token in any way ? From what I understand, it can only improve the security of the auth code flow but after you obtain an access+refresh token it's not much different, you just don't need to use a secret when exchanging the refresh token for a new token pair.
Thanks

The main element of risk is from XSS. If there is any XSS in your application, then it can be used to trivially steal your tokens.

As soon as such a token is stolen, the attacker can fully impersonate the user.

What isn't clear for me is why you need to have these cookies available outside HTML: can't you use another cookie for storing the public element of the cookie (maybe the whole payload or simply the expiration and whatever you need for your client to figure out if it needs to go to the auth portal) and keep the JWT tokens in HTTP-only cookies?


Can you securely allow users to create VM's on their workstations I've moved from a job where developers were encouraged to use technologies like docker and vagrant to create VM's on their workstations for testing and development.

At my new job, the IT manager insists that allowing a user to create a VM will compromise the security of the entire company. I know of many companies (like puppetlabs, and opscode) that allow vagrant and docker inside their company.

In what ways would allowing users to create VM's increase risk?
Is there a way to allow VMs that minimizes risk? (Perhaps use approved images)

Update

Primarily focused on the risk of allowing full virtualization on workstations (virtualbox, vagrant, hyper-v, kvm)

It all comes down to the network segmentation of the VM or container from your host operating system. If you have a guest virtual machine that contains a vulnerable operating system or an container that is hosting an application that is not properly maintained (i.e. patches), assuming that either of this two connect to your corporate network via a bridge network or shared network then you run the possibility of an attack that could penetrate the internal network. If proper steps are taken to segment the VMs or containers network from the host network (i.e host only or custom NAT networks) then there shouldn't be any issues with having users create their own VMs. This is assuming to you have a way to auto-force this settings because I wouldn't trust a process or a human to stick to the proper network enforcement.


Can just receiving or opening a spam email put my computer or emails data at risk? Sometimes you receive some emails which are mostly (and correctly) categorized as spam email by your email provider and you are almost sure that they are in fact spams. However, you are curious to open and take a look at the contents of some of them to see what they have. I was wondering is there any risk involved at receiving/opening such emails, of course without clicking on any of its links or downloading its attachments? Is it recommended to not even open them at any case?

Further, It would be great if you could consider and compare in your answer the cases of using an established email provider (e.g. Gmail, Yahoo, Live, etc.) vs. the ordinary (self-hosted) email systems, as well as the difference (if any) in this regard between using internet browsers for viewing email vs. using email software clients (e.g. Mozilla Thunderbird, Microsoft Mail, etc.) or mobile email apps.

The majority of the emails programs organize the messages on two formats:

All the messages in one file.
One file per message.

Is fine if you open the file message with vim, notepad or so program that don't do any parsing and potentially can execute something such as attachment, or follow a HTTP link. With any other program I will be skeptical of opening but just because I don't know what is going to do the program that opens the message with an infected body part for example.


Is running "apt-get upgrade" every so often enough to keep a Web-server secure? Assumptions:

Normal LAMP Web-server running web app. (Eg. AWS EC2+Apache2+MySQL+Php7)
Not directly targeted by some super-hacker or governmental organisation etc.
Related to point above, no social engineering and the web app itself is secure.

Targeted by whom?
Automated scans and exploits. Are there others?
Is running apt-get update && apt-get upgrade every so often enough to keep a web-server secure?

If no
What else should the 'average' web app programmer, who is also taking care of the server, do to keep the web server reasonably secure for a startup company.
It depends...
Yes, it always depends on many things. Please include assumptions for the most common cases (pareto principle) that the common web app programmer may or may not be aware of.

You've removed a lot of problems that normally get you in trouble (namely, assuming that the app you're hosting is completely secure). From a practical perspective, you absolutely have to consider those.

But presumably since you're aware of them, you have some protective measures in place. Let's talk about the rest, then.

As a start, you probably shouldn't run an update "every so often". Most distros operate security announcement mailing lists, and as soon as a vulnerability is announced there, it's rather public (well, it often is before that, but in your situation you can't really monitor all the security lists in the world). These are low-traffic lists, so you should really subscribe to your distro's and upgrade when you get notifications from it.

Often, a casually-maintained server can be brute-forced or dictionary attacked over a long period of time, since the maintainer isn't really looking for the signs. It's a good idea then to apply the usual counter-measures - no ssh password authentication, fail2ban on ssh and apache - and ideally to set up monitoring alerts when suspicious activity occurs. If that's out of your maintenance (time) budget, make a habit of logging in regularly to check those things manually.

While not traditionally thought of as a part of security, you want to make sure you can bring up a new server quickly. This means server configuration scripts (tools like Ansible, Chef, etc. are useful in system administration anyways) and an automatic backup system that you've tested. If your server's been breached, you've got to assume it's compromised forever and just wipe it, and that sucks if you haven't been taking regular backups of your data.


Preferred access mode for a directory with PHP scripts and the PHP script itself The people I work with have the tendency to set the access mode in numerical notation to 777 every time they face access right problems.

The mess is caused by using many users.

The creator of files (user: john),
The php interpreter (user: www-data),

I'm wondering if there exists a preferred / best / safest access mode setting for directories containing php scripts and the php script itself.

Always try to use the minimum permissions required to do the job, like this you can protect against current and unknown threats. With this in mind, there are three requirements that can be extracted from your explanation:

john needs to be able to read and edit the files
www-data needs to be able to read the files
Other users on the system have no business with the content of the files

To meet these requirements one common pattern is to create a group with only john and www-data as members, say phpgroup and have the PHP files (and the directories where these are located) owned by user john and group phpgroup.

For files the permissions will then be 640 (rw-r-----) and for the directories you will need to add the execute bits so that both users are able to change to it, e.g. 750 (rwx-r-x---).


How to find malicious images in server? Recently my Drupal site on a Linux server has been targeted by session hijacking attacks. I guess the attacks were originated from images containing malicious code which where uploaded to the web root because I have found some of the crafted images by looking at uploaded files.
So I am wondering how best to find all those images?

If you know what you're looking for, then you simply examine the data within the file to see if it matches the pattern you're looking for. How you do that depends on what sort of pattern it is; you could view the files in a text editor (for text-based patterns) a hex-viewer (for binary patterns) or you could write (or otherwise acquire) a program that will tease these patterns out of the files and present you with a report.

On the other hand, if you don't know what you're looking for, then you're obviously not going to find it.


Normal usage vs. denial-of-service? How many requests are needed to talk about a denial of service? Recently I used a tool to download a website and as part of the tool one could adjust the number of parallel connections. So now I found myself asking: starting from how many requests a provider could rate it as a denial of service. I googled around however didn't find specific numbers or at least hints about what dimensions we are talking about. Is there any definition e.g. like 100 requests a second?

So my question is: How many requests are needed to state that a denial of service is in progress?

Update: the technical background is definitely of interest. I understand that one malicious packet could be enough to cause a denial of service or the slashdot effect is another. But what I wanted to know was more of a firewall style rule: Some servers / service providers block out users which send too many requests in a certain time frame. About what dimension are we talking about here? Or is that too specific? If so what would your rule look like?

The question also had a legal component - let me illustrate a high(!) theoretical scenario:

A provider of a service checks its logs and sees that there has been high traffic from a single IP. Now the provider goes to court (for whatever reason) and labels this as an attempted denial of service. The judge would probably ask for their definition of a DoS. "Anything beyond the normal usage" would be their answer. So where is the threshold between normal usage and "none" normal usage (which could be interpreted as an attempted DoS even if the server remains totally unimpressed and this is probably a highly constructed scenario ;-)

Enough to cause the service to be denied to someone. Might be 1 unexpected malicious request, which causes excessive load on the server. Might be several million expected requests, from a TV advert with a really good response.
There isn't a specific value, since all servers will fail at different levels - serving static content is a lot easier on the server than generating highly customised content for each user, so generally authenticated services will have a lower "problem" threshold than unauthenticated ones. Servers sending the same file to multiple users may be able to handle more traffic than servers sending distinct files to multiple users, since they can hold the file in memory. A server with a fast connection to the internet will usually be able to handle more traffic than one with a slow connection, but the distinction might be less dependent on that if the generated traffic is CPU bound.
I've seen systems that fail at 3 requests per second. I've also seen systems which handle everything up to 30,000 requests per second without breaking a sweat. What would be a DoS to the first, would be a low traffic period to the second...
Updated to respond to update
How do firewall providers determine when traffic is causing a denial of service?
Usually, they watch for response times from the server, and throttle traffic if they go above a pre-set limit (this can be decided on a technical basis, or on a marketing basis - waiting x seconds causes people to leave), or if the server responses change from successful (200) to server failure (50x).
What is a legal definition of "denial of service"?
Same as the original one I gave - it's not denial of service if service has not been denied. It might be abusive, but that wouldn't be quite the same thing.


Does CSF-LFD include a Fail2Ban analogue or should include Fail2Ban at all? I am not of the field of IS and After reading this CSF-LFD installation document, I've installed CSF-LFD via:

cd /usr/src
sudo rm -fv csf.tgz
sudo wget https://download.configserver.com/csf.tgz
sudo tar -xzf csf.tgz
cd csf
sudo sh install.sh
sudo sed -i 's/TESTING === "1"/TESTING === "0"/g' /etc/csf/csf.conf
sudo csf -r
sudo perl /usr/local/csf/bin/csftest.pl

The article displays this installation as dealing with "CSF" but the Uninstall chapter of the article says that when you uninstall it, both "CSF" and "LFD" will be effected...
Moreover, I can do sudo apt-get install fail2ban even though I already installed CSF (and LFD?) in the above way.

The combination of these two facts confuses me because from these data I can't be sure if this setup also installs LFD and if it is, must there be a conflict with Fail2Ban.

Given what I described, my question can be comprised of these two:

Does the above installation installs both CSF and LFD?
Is Fail2Ban installed via sudo apt-get install fail2ban actually the same as the above LFD (that may or may not be installed) and if so, musn't there be a conflict between the two?

I have been investigating this some more and can answer reasonably well now. Answers to each part of the question:

Yes, LFD is installed as part of CSF. You have LFD installed if you use that process.
Fail2ban is NOT the same as LFD and there IS a conflict. You should not use them both. Using CSF and LFD is all you need and fail2ban would only be an alternative to some parts of LFD.

So I recommend you use CSF, which includes LFD, and do not install fail2ban. I also highly recommend reading the readme file for CSF/LFD at:
https://download.configserver.com/csf/readme.txt


Malware threats from other mounted hard drives I am going to install Linux on an external hard drive and my internal hard drive is currently running Windows. When I boot to my Linux and I still have my windows hard drive mounted is it possible for any malware on my windows hard drive to run or spread to the external hard drive even though I'm not booting to windows? Are there any other security issues if my windows drive is compromised?

Thanks!

Malware can only be executed if something loads it and executes it. Malware in the form of a Windows program will not run unless you boot Windows or you run a Windows emulation layer on Linux. In the latter case, it's unlikely (but by no means impossible) that the malware will have enough privileges to do harm.

It is however possible for malware to come with Windows but run outside of it, Windows being here the platform of the malware installer but not the platform of the malware itself. The malware could lodge itself in your hard drive's boot sector or could even infect your BIOS or other firmware.

It's also possible for malware running under Windows to access your Linux drive (unless it isn't physically plugged in) and plant Linux malware there.

These threats are not very common. Linux compatibility is not a feature that most malware authors aim for, and there isn't much hardware-infecting malware in the wild. In practice, such malware is unlikely to arise in the form of an untargeted attack. Targeted attacks are a different matter; if you're concerned about the NSA spying on you, get new hardware (among other precautions).


Do I need to patch Linux for Meltdown/Spectre if the hypervisor has been patched, and I trust the guest? If I'm running a VM on Amazon EC2 or Microsoft Azure, and they've patched the underlying hypervisor, do I need to upgrade my Linux kernel to protect against Meltdown or Spectre?

Assume that I'm not running any untrusted software in my VM.

I know that if I don't patch my kernel, I'm at risk from untrusted software running in my VM. This is no different from a normal (non-virtual) server, and thus not interesting.

If the hypervisor's patched, but my kernel isn't, am I at risk from neighbouring (compromised or malicious) guests?

To answer the question you originally asked: whether or not you're running untrusted code, if you want to protect against Meltdown or Spectre, you still need to upgrade your kernel, even if your cloud provider has patched the underlying hypervisor.

The GCE customer announcement (linked from the Google security blog post, which is a bit light on detail but also links to the project zero writeup which is full-on) says under “Mitigation Status”:

  Infrastructure patched against known attacks. Customers must patch/update guest environment.

If you don’t trust Google, AWS has their own security bulletin which states:

  While the updates AWS performs protect underlying infrastructure, in order to be fully protected against these issues, customers must also patch their instance operating systems. Updates for Amazon Linux have been made available, and instructions for updating existing instances are provided further below along with any other AWS-related guidance relevant to this bulletin.

The reason why this is necessary is because paravirtualization allows the guest kernel to have control over the TLB in the CPU directly, without mediation from the hypervisor (it’s one of the major performance improvements of paravirt over full virt, along with direct I/O). Thus, if the guest OS kernel doesn’t implement the mitigations, processes running in the VM can still grab data from the kernel and other processes running in the same guest.

The answer to the second question you've edited your question to add, as to whether you're at risk from your neighbours, appears to be, with the information currently available, "no".  The answer to the third, seemingly implied question, of whether you should patch now or in your regular patch cycle, isn't answerable with the information you've provided, as it is deeply rooted in your own organization's risk profile and threat models, and I'd go so far as to say that you're bordering on "primarily opinion-based" with that one.


Placing a firewall—without creating a new subnetwork I have a couple of networks that have multiple IP addresses, and where I have absolutely no choice as to the equipment used for the network's edge router (the device that connects both to the LAN and the ISP).  The system that is at the network's edge is inadequate for a firewall, and so I want to use a Linux box to perform the firewalling functionality.  However, what I do not want to do is subnet; one of the networks this needs to be done on is a /29, and the other is a /28.

For the sake of this example, we'll call these networks 10.0.0.0/29 (network A) and 10.0.1.0/28 (network B).

On both networks A and B, the last usable IP address is the one that is used for the ISP's required gateway device (which is a combined cable modem and four-port Ethernet switch).  So, on A it is 10.0.0.6 and on B it is 10.0.1.14.  (Note also that these devices perform NAT functions, using its claimed address for the NAT gateway as well.)

Now, what I want is to have a system on network A, give it IP 10.0.0.1, and make it the firewall for the other hosts on the network (that is, 10.0.0.2, 3, 4, and 5).

However, I am somehow not figuring out how I can do that.  I do not have control of the routing table on the ISP's gateway device, so I cannot tell it to route packets to my network via a gateway that I control on my network.

Physically, the network connection comes in on a coax cable into the cable modem.  The cable modem's four gigabit ports are fanned out throughout the network:

One is connected to a server system that has a bridge and four additional ports on it.
One is connected to a wireless router, that feeds my wireless network in the upstairs of my home.
One is connected to a workstation.
One is connected to a printer.

So logically, it is one network segment.  What I would like to do is hook the server up to the device on a single port, and have the server feed the network with its multiple port network card.  But I can't think of how to do that without breaking IP; I am handed a /28 on this network (and as I mentioned earlier, a /29 on the other) and I cannot afford to lose any IP addresses to subnetting, I'm using most all of them.

Any ideas?  And also, if I have left out anything relevant, let me know.

Sounds like you are just looking for a bridging firewall.

http://www.cryptolife.org/index.php/Linux_Bridge_Firewall

Graphic below is from the link above:

http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge

"A bridge is a way to connect two Ethernet segments together in a protocol independent way. Packets are forwarded based on Ethernet address, rather than IP address (like a router). Since forwarding is done at Layer 2, all protocols can go transparently through a bridge."


How unsecure would I assume old PHP code is? We have several websites that are client facing at a very large company.  These websites do gather client information.  They were written 6-7 years ago, quite possibly using a PHP/mysql code generator.    It hasn't been touched since.  The code gives very very basic CMS functionality - puts a few field items in a template.

Without being able to audit the code or directly access the sites (I have seen demos) I am being asked to estimate the security vulnerabilities of the site and how long it would take to rebuild.  I run the web OPS group for my sector and this is another sector so there are some political issues in the way.  I have my opinion about possible issues but would like to hear others too.

Server is LINUX running apache 2.   Running older versions of PHP and mysql. Clients are forced to fill out a form to see content so we are storing a bunch of client info in plain text on the site.  Passwords are not salted and not even sure hashed. Let me know if there is anything I can add to make the question better.

Well first of all its an assumption, so assume away!

Your talking about the PHP code's security, so can we ignore the outdated versions of the stack: Linux, Apache, PHP, MySQL. All of which you should be able to pull up a number of exploits for (knowing the version) via Google. We can then talk about the PHP application. The code is going to be as secure as it was written.

You mentioned some kind of code generator was used to create it? Which one? I recommend you find out, and get some samples of what it generates.
Considering the age there is a good chance it doesn't take into consideration of few common vulnerabilities: XSRF, XSS, SQL Injection.

They don't call it "Pen Testing" for nothing.

I'll try to be more helpful... by giving you a bunch of questions for you to find answers to.

What kind of information do these sites collect? Does the CMS side of the site have logins?  Does the site use session cookies to authenticate?
Try logging in and have a look at the network logs with the inspector in Chrome/FF.

Also what kinda of attacks are you worried about? What information is stored in the site that is sensitive? Are the servers inside a network that contains other sensitive data or assets? Try to model your potential threats and what worst case scenarios they could create.


Has anyone actually been hacked by video subtitles? This morning's news brought this story:

Hackers are hiding computer viruses in film subtitles, security experts warn

Where they warn that subtitles in videos played on computers could be used to deliver ransomware.

Yes we all know about steganography - hiding messages in jpegs and mp3s, and I don't doubt that a message could be hidden in video.  But it seems a stretch to say that subtitles could somehow activate themselves and take over a computer.

So my question is simple:  Does anyone here actually know of any cases where this has happened?

From this blog the issue appears to be a file parsing problem with subtitle files used by media players.

This kind of issue can be exploited as the media player program needs to parse the subtitle file as part of using it, so a malicious file may be able to exploit vulnerabilities in the media player to execute code on the affected system.

That blog doesn't mention number of affected systems, but they're offering PoC examples and IPS signatures, so it's quite likely they're seeing active exploitation of it.


ldaps query against dc from appliance recently I had to configure a feature called directory sync on our appliance to sync with our DC. The requirement was to run the sync over LDAPS. It works BUT what I'm wondering is, the DC's cert is issued by our internal CA, and the appliance has absolutely no knowledge about it (it's not domain joined, the root CA cert is not uploaded in to the appliance). Now I'm not sure whether this is the proper way to handle it, I mean a browser will notify you that something is "wrong" so I would assume that some sort of protection / warning mechanism should be in place on the appliance or am I worrying to much ?

thanks
Adam

... am I worrying to much ?

Maybe not.
Unfortunately it is not uncommon that certificate validation is done improperly.  Many think that encryption is enough and that certificate validation is just an annoying thing with all this root CA hassle etc. In not so far away times for example PHP or Python did not check any certificates at all by default and this was only fixed in PHP version 5.6 2 and python 2.7.9 about 2 years ago. And for example most mail server simply ignore bad certificates too.

Thus it might well be that the unknown application you use does not check certificates properly. It might also be that you need to explicitly configure it to check certificates. When in doubt look at the documentation or contact the vendor.


Which server is responsible for “security” when ASP.NET Core Kestrel is hosted behind IIS? I want to understand how the flow between IIS and Kestrel works with regards to security. It seems that the integration between IIS and Kestrel is that IIS just sends absolutely all that it receives to Kestrel, be it valid HTTP request or not. IIS does handle the SSL though, so it's quite transparent for Kestrel.

So I have a question: does that mean that with the exception of SSL, security is  handled by Kestrel? So all potential vulnerabilities in IIS are pretty much not possible or easy to exploit? Like e.g. a bug that allowed to get the web.config some time ago from IIS would only be possible to abuse if Kestrel has the similar type of bug.

The simple answer is: both.  They have different roles and manage different security functions, but there are some aspects of security that each must handle.

In this model, IIS is operating as a reverse proxy, and Kestrel is the application web server.  Reverse proxies (IIS and otherwise) often are responsible for more than simply dumb routing.  As you've noted, if you're using HTTPS, termination happens at the IIS layer.  IIS may also serve other functions, such as compression and caching, just as any reverse proxy might.  It also continues to need web.config, in order to find out what that configuration is.  Each of these functions has some number of security implications that need to be kept in mind.

Application specific security functions, like most authentication and authorization, input and output encoding, and other application specific functions will be handled within the application execution pipeline and environment inside Kestrel, as you expect.

So, while the role of IIS in security is greatly reduced in this model, it isn't eliminated entirely.


Is it dangerous to share a USB flashdrive? Recently I've watched a movie "Blackhat" where just by inserting a USB flashdrive he could infect a host PC with some malicious program. Is it true that it's not safe to share USB flashdrives just like that? If yes, how come a "virus" can initiate itself in a host machine without being executed by a user? In other words, doesn't it need to be clicked on first?

Using something like BadUSB can turn any USB device into a keyboard, RubberDucky makes this even easier.

Using these techniques you can run commands and install mallware on a computer without the user ever pressing a button or opening a file. So yes, using a untrusted USB (storage) device can be dangerous.


How can MITM be performed in WebRTC? From what I could tell, certificates are self-signed. When A wants to call B, after they finish relaying data to server, they initiate communication with each other. Certificates are self-signed, therefore there is no problem in switching them up. Is there some mechanism to make sure that if C is on the same wifi as B, why he could not send to A and B the certificate of C and intercept A and B's certificate then proxying the whole conversation?

Is there some hash that is sent from A to B and vice-versa via the authenticating server that can then be validated against the certificates?

WebRTC

The fingerprint of the DTLS self-signed certificate is exchanged through the signaling channel with the offer-SDP and answer-SDP.

During the DTLS handshake a session key is established and the fingerprint of the endpoint certificates is compared to the fingerprint exchanged in the signaling phase.
Therefore, the certificate cannot be replaced without the endpoints noticing.

The signaling server needs to be trusted.


How can you detect kernel exploits? Is there something that all kernel exploits have in common?

Sure, they all exploit the kernel, but I'm more interested in the underlying mechanisms or the result. At the moment my interest goes mostly in the direction of memory forensics. Since the kernel is stored in memory after boot I was wondering if an exploit necessarily needs to make changes in this memory region and could, therefore, be detected. Of course, if you have an exploit at that level you could disable every detection mechanism on the OS, but this is a different topic and memory forensics also doesn't always need to be conducted at OS level.

I'm not sure if memory forensics would work at all or for each exploit mechanism. Maybe there are other ways? Does detection depend on the specific kernel i.e. from Windows, Linux or Unix systems?

No, there is nothing all kernel exploits have in common.
Or at least, there is nothing unique to them and not present in standard, legal interaction with the kernel (such as using syscalls or accessing special filesystems). Typically, a kernel exploit involves making a syscall (an interface that allows userspace processes to communicate with the kernel) with arguments designed specially to cause unintended behavior, despite the syscall attempting to only allow valid arguments. Other exploits may involve concurrency issues (race conditions) between two syscalls. Let's look at a few examples:
CVE-2016-5195
This is better known as DirtyCow, and involves a race condition in the kernel's memory management, specifically Copy-on-write (CoW). Copy-on-write is a memory management technique that allows instantly duplicating a large amount of data, independent of how much data it is. When a range of pages of memory is CoWed, it is shared between two tasks. If one task modifies the page, only then is the page copied to allow it to be modified. That way two tasks can share the same physical memory while still not being able to interfere with each other.
The exploit involved a race condition with two syscalls, madvise() and ptrace(), between two tasks attempting to write to the same page. If a page is mapped in memory, and madvise(MADV_DONTNEED) is called, the kernel is told that the page will not be used in the future. Combining this with a ptrace(PTRACE_POKETEXT) call which writes directly to memory allowed modification of the original, read-only page due to the CoW bit being inappropriately removed. This could be exploited by writing to the vDSO, a small executable region of memory shared by all processes. If an unprivileged, malicious process were able to change the vDSO, then when it gets executed by innocent, privileged processes, those privileged processes could be compromised.
Both the madvise() call and the ptrace() call are benign actions. There is no reason to think that, by using them rapidly in a specific order, a page of memory in the kernel that is shared by many processes would end up becoming "owned" by a malicious process, allowing that process to change it however it wants. How could that possibly be detected?
CVE-2016-0728
This vulnerability involved exploiting a syscall, keyctl() for managing the in-kernel keyring facility. The bug involved an overflow of a reference counter, leading to the refcount wrapping around to zero. When a single keyring session is shared by multiple processes, the refcount is incremented. This is intended to allow the kernel to know when no one is using that memory anymore so it can free it.
Because of a bug in the kernel, there was as specific way to increment the reference counter without decrementing it afterwards, leading repetition of that action to increment the counter arbitrarily. Once this refcount leak caused the variable to wrap to zero, the kernel naturally thought that no one was using the object anymore, and that it would be fine to free it. However, there are still one or more tasks using that object when it gets freed. As a result, if they try to access it, they will be accessing unallocated memory. If the attacker then causes a memory allocation by creating another kernel object from userspace, and puts their own malicious data in there, the highly privileged kernel task that was previously referencing that memory area will instead access malicious code, resulting in its execution. This is termed a Use-After-Free vulnerability, or UAF.
Using the keyctl() system call and triggering memory allocations in the kernel are all normal, benign actions. How could such a thing possibly be detected without foreknowledge of the vulnerability? After all, the assumption is that a reference counter will not leak!
CVE-2017-1000112
The Linux kernel is able to "peek" at an existing packet of data without causing it to be removed from the receive queue, allowing a task to peek a bit of the data before actually taking it from the kernel. This is done with recvfrom(), using the MSG_PEEK flag.
A rather complicated bug in the kernel's implementation of UDP fragmentation offload (UFO) can allow an attacker who can set up a network interface with UFO to disable CRC checking, trigger fragmentation of a large payload, and copy a user-controlled number of bytes to another memory location. This can be used to overwrite an important struct with arbitrary data. A certain memory of this struct contains a pointer to a function, and if that member is modified to point to the address of malicious attacker-controlled code, the kernel can be made to execute it, compromising the system.
Configuring network interfaces is not a malicious activity, nor is disabling CRC checking, or using MSG_PEEK, but a specific combination of all this leads to overwriting a function pointer in the kernel, with devastating consequences.
Summary
It is true that many kernel exploits fall into just a few "classes" like UAF, integer overflow, refcount overflow, buffer overrun, etc., they all involve the system behaving in an unexpected way when told to perform a certain task. Whether or not this task is sane and should result in normal behavior, or is incorrect and should result in a returned error does not matter. The kernel is supposed to behave properly regardless of how one interacts with it, and the fact that there are bugs that allow completely legitimate interactions like telling the kernel that it's done with a page or creating new keyring objects to result in incorrect actions on the kernel's part is what can be abused by attackers. All interaction with the kernel should be defined, so even exploits attacking the kernel make use of defined but incorrectly implemented behavior.
There are, however, ways to prevent entire classes of exploits. For example, Control Flow Integrity (CFI) can be used to mitigate all forms of bugs that exploit out-of-order execution, like ROP. SMEP, SMAP, and grsecurity's UDEREF, while possible to be bypassed by leveraging additional bugs, can prevent all forms of unintentional access of userspace memory by the kernel, preventing exploits that involve modifying a function pointer to point to attacker-controlled userspace. These techniques cannot defeat all exploits as there are just too many, and they cannot defeat exploits using entirely new techniques (though thankfully those are rare).
Grsecurity is a company which aims to mitigate entire classes of bugs, and though it has shut down to the public (for only the time being, hopefully), there are still forks of it which are public. Many interesting exploit mitigations can be learned of by reading their last public patch source code.


Securing integrity of a large file with cryptography Let say I have a large file that is of considerable interest to the public and I want to publish it. The plan is to hash it using reliable function and publish its hash on a public blockchain (btc or eth) to timestamp it. Then, encrypt it asymmetrically and share copies to journalist around the world. When the time comes, I drop the public key and the cat's out. BUT! Opposition to the dissemination is the most technically powerful actor in the world whose strategy is to edit file to prove it an unreliable forgery and to do that - edited version needs to have the same hash. And they have an edge to do it - the file does contain amount of redundant data that may be changed without affecting underlaying functionality.

Let set a scene. Imaging that I have a 4K video file of a president of a powerful country murdering former secretary of state. The face of the president is seen in only few seconds of a few minutes of video, but would prove damning nonetheless. Its secret spying agency ASN is set to edit the video by planting my face on the murderor's body thus turning tables. Let say that the rehashing effort is of order of billion dollars worth of hashing power of entire bitcoin mining community. If a doctored version with correct hash is produced, my proof would not qualify as beyond the reasonable doubt and the pres walks away.

Ok, I am playing here, but I hope you get my question. How to cryptographically protect integrity of a file that has some redundancy whose fiddling may cover for functional changes? Or, in another words, is there a modern hash functions powerful enough to protect integrity even against available nonce to make editing unfeasible today?

You are asking for resistance against a pre-image attack, i.e. that an attacker will be able to generate some input data which result in a specific hash value (i.e. the same hash value as the original file). Modern hash functions like the SHA-2 class (i.e. SHA-256, SHA-512...) are considered strong enough against this types of attack while older hashes like MD5 or SHA-1 are considered too weak.

But I'm not sure that it is even needed to generate data with the same hash value to mount an attack. Your scenario is build on the assumption that timestamping the hash (and thus the data) is a strong trust anchor. But, attackers can simply claim that the video is fake in the first place. They might even create some fake videos by their own to show how easy such faking is and thus undermine the trust in your video.