Check if the source ip belongs to that user

how we can check for example if the packets we sent or we received are going/coming from the router (192.168.0.1)

You could hard-code the (MAC-address, IP-adress) mapping of the router and throw away packets claiming to come from the router's IP that didn't match the mac-address.

Most likely, nothing else will work reliably. However, fixing the MAC-address of the router will likely cause maintenance problems.

  is it safe to determine that the second call of an ARP request is fake?

Not necessarily. ARP tables are repopulated periodically. Hardware might be exchanged, explaining MAC-address changes.

  so we cannot ping , is it safe to determine that its a fake packet ?

No. Just because you can't ping a host doesn't mean it doesn't exist, or isn't real. It's firewall - or any firewall along the route - might simply discard ping requests.

Also, ping works above the ethernet level, so if someone successfully steals an IP-address on your network segment by poisoning arp caches / switches, he won't have any trouble replying to your ping. Basically, ping is worthless as an authentication method.

  and if we can ping the source ip its source hostname is up and running how we can find out that the packet being sent or received is fake

Set up an authentication protocol. If the host successfully authenticates to you, you know it's the real thing. If it can't, it's a fake. However, this doesn't work on the IP level - you'd need to build the authentication into an application level protocol, or use a preexisting one, such as TLS.


AFL can perform qemu user-mode fuzzing.  It is capable of providing the input to the executable on standard in, so it can handle most interactive programs.  However, if your login binary is using special ioctls to directly access the terminal, you may still need to do some work to begin fuzzing it.  In that case, I'd suggest building an LD_PRELOAD shim to transform the terminal-specific ioctls into raw read operations from stdin.


Authoritative DNS server resolve also any other domain - Is that a risk?

There is a small security risk associated with running a public recursive name server. Those risks include the possibility of increased load or being used as being part of a DNS amplification attack

You will have extra load on your servers if they are public recursive name servers as people will end up using them. A non-recursive name server will just reply with the DNS equivalent 0f "I don't have the answer" if people try to use it instead of say 8.8.8.8 as their defined name resolver.

Additionally attackers can fake a from/client address when performing a DNS lookup as part of an amplification attack, where that fake address then gets the response. Attacks fake a huge amount requests and DDoS the faked address. Read more about them here: https://www.us-cert.gov/ncas/alerts/TA13-088A

You public authoritative name servers should respond only to requests for  you associated zones.

Hope that helps.


What are the considerations when migrating from Bitlocker to Veracrypt?

To begin with, VeraCrypt is open source. So, you can ensure the code does not contain backdoors. While BitLocker is closed source and hence not open to inspection. For this reason posts like, Can the NSA Break Microsoft's BitLocker have come about. While Microsoft Opens Windows Source Code to EU Governments is good news, it still allows me to make the statement BitLocker is as trustworthy as Apple's FileVault, because the source code is not public, until that date, this statement remains true.
To my understanding, VeraCrypt's hidden partitions work similar to the discontinued TrueCrypt. The hidden partitions work very nicely,

It may happen that you are forced by somebody to reveal the password to an encrypted volume. There are many situations where you cannot refuse to reveal the password (for example, due to extortion). Using a so-called hidden volume allows you to solve such situations without revealing the password to your volume.

The principle is that a VeraCrypt volume is created within another
VeraCrypt volume (within the free space on the volume). Even when the
outer volume is mounted, it should be impossible to prove whether
there is a hidden volume within it or not*, because free space on any
VeraCrypt volume is always filled with random data when the volume is
created** and no part of the (dismounted) hidden volume can be
distinguished from random data. Note that VeraCrypt does not modify
the file system (information about free space, etc.) within the outer
volume in any way.
The password for the hidden volume must be substantially different
from the password for the outer volume. To the outer volume, (before
creating the hidden volume within it) you should copy some
sensitive-looking files that you actually do NOT want to hide. These
files will be there for anyone who would force you to hand over the
password. You will reveal only the password for the outer volume, not
for the hidden one. Files that really are sensitive will be stored on
the hidden volume. - Source

VeraCrypt has cross-platform support. Such that you can access VeraCrypt volumes on FreeBSD, Linux, Mac OS X and Windows. However, BitLocker volumes can only officially be supported, as of writing, on Microsoft Windows. Furthermore, Cryptsetup can decrypt and open VeraCrypt volumes cryptsetup --tcrypt-hidden open --type tcrypt [volume] [name].
If looking for aspects of BitLocker which are less secure, it should be noted that TPM does not aid security when compared with using a removable USB key, as this can be taken with you more easily, while the TPM cannot. Furthermore, BitLocker does support password decryption, similar to that of LUKS. So, BitLocker provides three options for where to store the decryption key: TPM, USB key or password (which you remember).

Assuming that there is the ability to adopt Veracrypt, I imagine the natural progression would be to decrypt the devices currently using Bitlocker first. If yes, what risks does this present to the data on the disks?

Storing any sensitive data on a decrypted drive presents a considerable risk. As once done, you have to properly overwrite the data after, which on SSDs can become considerably more tedious.

Should the data first be migrated across to another alternative destination that is already encrypted prior to decryption and encryption again?
As the devices that currently use Bitlocker store sensitive information such as personally identifiable data, financial statements, etc, i would like to limit the risk of data leakage.

Copy the sensitive data directly from the BitLocker encrypted directly onto the VeraCrypt encrypted partition, this mitigates data leakage. Alternatively, if this is not viable archive the data into a 7z archive and encrypt that using AES256 with a strong random password. Then extract that archive onto the VeraCrypt partition. Then discard the password and overwrite the 7z archive, the overwrite part is optional.


From a security standpoint should users be asked to confirm their password when registering?

The real reason to have a user type their password twice is to avoid mis-typing it in. It is very easy, when typing a new password, to get a capital letter incorrect, or accidentally type the letter next to the one you think you are typing.

If this happened the user would not be able to access their account, at which point weaker forms of security, like a password reset, may come into play.

Typing it twice is a quick check that the user is consistent enough to get it the same twice - so they probably have it correct.


Is SQL Server 2016's Deterministic Encryption any good?

The currently published documentation on what that deterministic encryption really does is not sufficient to come to any definitive conclusion.

What can be said is that such deterministic encryption may be designed and implemented "properly", in which case it incurs no extra weakness beyond the ones inherent to its functionality: namely, that if two values are identical, they will be encrypted to the same value, and this will be visible to the attacker. This is a big unavoidable problem if the values are in a small enough set (e.g. a boolean true/false).

Existing documentation seems to imply that the underlying encryption algorithm is "AEAD_AES_256_CBC_HMAC_SHA_256", which says both a lot, and not nearly enough to actually know what runs under the hood. A "proper" implementation that matches the documentation would compute the IV for CBC encryption with EK(SHA-256(m)) (symmetric encryption of the hash of the complete data to encrypt). Such an implementation would avoid the ECB/Penguin issue. However, it is not clear whether this is what Microsoft actually implemented.


In short, that scan doesn't show you any layer 2 information. You're interested in what MAC address the computer associates with a given IP address.

ARP poisoning affects network layer 2, or the ethernet layer. While the computer still sends the message to the same IP (layer 3) address, the packet ends up at a different layer 2 address which is purporting to own that IP. It purports to own that IP address by poisoning ARP in an attempt to associate that IP with a different MAC address.

Once that computer has, for example, taken over the IP of the DNS server it can serve invalid DNS records or any other devious service it wishes to run.


Snort rule for syn flood attacks - Limiting number of alerts

You can use thresholds (that were replaced with event_filters) to do this:

/etc/snort/threshold.conf

event_filter gen_id 1, sig_id 10000002, type limit, track by_src, count 1, seconds 3600

This will generate max. 1 alert per 1 hour for your rule


Is a 'remote' cookie replay attack possible?

I'm not really sure what you exactly mean with "cookie replay attack" but I assume that you mean using a captured cookie by the attacker for session hijacking by reusing a captured session cookie.

If this is possible depends on which information the web application associates with the cookie. If it associates a browser fingerprinting or SSL session information with the cookie it might detect session hijacking when the attacker uses another browser. If it associates the IP address of the client with it it might detect if the cookie is used from another client IP address. If it does not associate any such or similar information with the cookie it will not be able to detect the session hijacking.


Forcing new password with zero-knowledge proof authentications

First of all, note that if the server generated the first insecure password, than it is easy for him to check whether the client switched password or not. Because the only secret value in this scheme is the password itself. Hence the server can try to generate the v variable and simply check if they are identical. So your original problem is solved that way.

As far as I understand, the idea behind the salt in this scheme is exactly to prevent from an adversary to figure out when the same password is used.
It seems to me (haven't checked it through, but with a quick glance) that the scheme will be secure enough if you will fix a random salt for each client. It seems that the only advantage in this case is that the server can detect password reuses.


Any hex editor that can read disk sectors directly can handle this.  One such is HxD for Windows.

Note, however, that checking the sectors where the file most recently lived does NOT tell you whether there is any data from the file remaining.  Merely deleting at the file level does nothing at all to deal with, for instance, a file that was recently defragmented - the old sectors are now "free", but still contain that file's data.

If you really want to securely delete, wipe the entire drive, verify it, and then shred it or wrap it carefully and hit it with a hammer until little tiny glass shards are visible.

If you must do only a partial secure delete, you can try deleting that file, verifying the most recent location, and then doing a full free space delete.  Piriform's CCleaner does have secure erase options, and free space erase options that at least once were reasonable.

If you go that route, you're going to want to wipe your free space + cluster tips once, and then build a few huge files of, say, all 0's that take up most of the remaining drive space so the next free space delete is easier.
You'll also need to do a free space + cluster tips erase after every defragging.

And probably routinely, for that matter.


what I do not understand is why I would use a SOCKS proxy. I mean, for
  example, Why I would use a SOCKS proxy and not an HTTPS proxy, what
  SOCKS offers me as a proxy

If you are a user, and your administrator offers you a SOCKS proxy but not an HTTPS proxy, then you would use a SOCKS proxy (or vice versa).  It is rare for an environment to give you the choice of both.

If you are an administrator, and wanted to decide which proxy to install, then a SOCKS proxy handles non-HTTP connections better and may be the only proxy supported by non-web-browser clients.  Depending on whether you're enabling or restricting your users with the proxy helps dictate which choice is right for you.

  how it allows connections to bypass a firewall?

Generally speaking, all proxies work the same way.  The firewall permits the proxy to go outbound, but not the clients.  The clients are allowed to talk to the proxy, and the proxy decides whether to resend their traffic onward or not, acting in some ways like a firewall but with different access control criteria.  The firewall is, in essence, trusting that the proxy will control access differently and better than the firewall could (for example, blocking access based on site name rather than IP).


How are games and software executables injected with custom code & without breaking offset?

There are several methods to achieve this.
Code Caves
The oldest and simplest approach is called Code Caves. Simply put, the process memory has some allocated, but unused memory. By modifying the code - either by injecting it dynamically or overwriting the binary file - code can be inserted into the code cave and be jumped to and returned from.
The advantage of using code caves is that you need to modify very little of how the program works to get your custom code running. However, you depend on the availability of memory caves, and even if you find any, the size of them will pose an issue.
Allocation

"If you need more memory, just allocate more memory"

The other approach being used means you allocate more memory, jump from the existing code to the added section, do whatever custom stuff you'd like to do, and then jump back.
The advantage of this method is that you essentially have free reign over how much code you wish to inject, with the downside being that the underlying program is much more likely to "be aware" of your changes. That means if you plan on cheating in a multiplayer game - which I personally disapprove of - the underlying game has a very high chance of noticing that something is up.
Patching
Sometimes, just overwriting things is easier than any of the other methods. If your required changes are simple, then overwriting some addresses in memory might be enough. For example, if a program has a complicated function to check whether or not a valid license is present, one can simply overwrite this function with a bunch of NOPs (to keep the offsets correct) and returning true.
The advantage of this approach is that it is by far the easiest and can usually be done on-the-fly without ever modifying the binary file. The downside is that it is an even more limited approach than code caves, since you're only changing things, not adding new code.


Switch Private- and Public- key for Identification

if Alice gives Bob her private key and vice versa, they can identify them self

I think you've misunderstood something. For identification Alice does not give Bob her private key to identity herself.

Instead Bob issues a challenge (i.e. some random message) and Alice signs this challenge with the her private key. Bob then can verify this signature using Alice public key (which is public as the name says, i.e. known to Bob). And since Bob had control of the challenge he can be sure that Alice is currently in possession of the matching private key. Since only Alice should know this secret private key this can be used as a proof that this is Alice at the other end of the connection, i.e. proof of Alice identity.


Well, if said end user had a rooted Galaxy S3, they could use Darshak on their phone to check for "baseband attacks" that indicate they are communicating with a rogue tower. There's a company called ESD that sells a "cryptophone" that can do the same thing, but for a hefty price tag (like 1,300 USD!). Edit: Here's another cool app I found from a comment by @wesleyac: Android IMSI Catcher Detector.

Unfortunately, no one seems to have a good explanation of how it's done. But ESD does release the source code for their phones freely for security audits, and the SecUpwn group has released their app on Github. If you want to wade into the implementation details, that would be a good place to start. A brief technical explanation of the GitHub app is here.

These towers seem to be the modern-day number stations. We may never know, but we'll always get that creepy feeling when we think of them ;)

(I am not affiliated with either of these products.)


Using the Android hardware-backed KeyStore

setEncryptionRequired(): It is used to encrypt the key pair at rest and the encryption key is derived from the secure lock screen credential(e.g., password, PIN, or pattern).

Hardware Backed-Keystore: The key-entry files generated by hardware-backed keystore are encrypted using device-specific keys that is only accessible to trustlets executing in the TEE.

From the Android Sources

  TEE processors have become a mainstay in today's mobile devices. The
  main processor on these devices is considered "untrusted" and cannot
  access certain areas of RAM, hardware registers and fuses where secret
  data (such as device-specific cryptographic keys) is stored by the
  manufacturer.

So these are the two different encryption implementations using different encryption keys.
The key-entry files generated by hardware backed keystore are encrypted using device-specific keys.

To implement another layer of security, Android allows developers to encrypt the keys further using encryption key derived from the screen lock through setEncryptionRequired() option. It is clearly a functionality/security tradeoff relationship.

I personally feel that setEncryptionRequired() must be enabled for the devices that do not support hardware-backed keystore.


What types of vulnerabilities just can't be located by a default scanner?

Automated scanners, especially with out-of-the-box configuration, can only identify low hanging fruits at best. What types of attack vectors are covered, depends on the individual tool.
This leaves a broad range of attack vectors that are not covered, which will most likely fall into one of the following categories:

Business Logic Vulnerabilities
Security Scanner do not understand your business logic. A typical example is a web-shop that allows an attacker to manipulate the price during checkout. A scanner cannot know that changing this specific value results in a loss for the company selling the product.

Multi-Stage Vulnerabilities
Some vulnerabilities need several distinct steps before they can actual trigger. If you must perform multiple steps to get the application in the right state to exploit a specific vulnerability, the automated scanner will very likely miss it. Complex authentication and authorization protocols like OAuth and OpenID Connect fall into this category as well. Exploiting those often requires several complex steps.

Compliance Violations
Security problems are not always purely technical in nature but can also be compliance driven. Lets take a vulnerability that allows a user to see PII of other users by circumventing a search filter. An automated scanner cannot identify the nature of the data and also doesn't know that access to this data is a violation to the GDPR.

Violations against security design principles
There are security risks that are not immediately exploitable, but leave open the potential for attacks once the stars align. They often stem from neglected security design principles. This could be the violation of the principle of least privilege. Users that have more permissions than required might not be able to compromise the application right away, but under the right circumstances (e.g. a 0-day in an API that shouldn't be accessible with proper defined access restrictions) this negligence leads to an actual security problem. A scanner cannot foresee such scenarios or even identify violated security principles.

Vulnerabilities that need access to the source code or configuration
Many security scanners use a black box approach. They do not know the source code or the configuration of the system. There is a broad range of vulnerabilities that can easily be missed without this internal information and are therefore also easily missed be a security scanner.

This list is not necessarily comprehensive. The main message is that there are a lot of issues that cannot be detected automatically at the moment. Relying on a security scanner to verify application security is therefore not sufficient for most applications.


Issue certificate through CA that contains a different domain in it?

Since google.com\0x.whynot.com is not a valid hostname you should not by able to get a certificate for it.  But it was possible once to misuse null characters like you attempt. For more details see Black Hat 2009: Breaking SSL With Null Characters.


What can websites learn about me when I disable cookies?

A great deal amount you can be learned, and correlated without using cookies or your IP address.

Cookies serve the purpose of tracking specifically you. However other methods of tracking have been found to be 99.1% accurate  in tracking you by using other unique characteristics of your browser/session/machine. Some of the unique identifiers are your user-agent, your screen size/density, your java/flash version etc. Read the white paper here (or at least the abstract for an over view of their findings).

You can see the unique characteristics that can be pulled to represent you without the need of a cookie on the main site of that white paper here.


System nmap shows port closed but online nmap tool shows port open

What does closed state means:

  A closed port is accessible (it receives and responds to Nmap probe
  packets), but there is no application listening on it. They can be
  helpful in showing that a host is up on an IP address (host discovery,
  or ping scanning), and as part of OS detection. Because closed ports
  are reachable, it may be worth scanning later in case some open up.
  Administrators may want to consider blocking such ports with a
  firewall. Then they would appear in the filtered state, discussed
  next.

https://nmap.org/book/man-port-scanning-basics.html

It can be firewall or IDS system. Also I have checked and it states that port 25 is open:

PORT   STATE  SERVICE
25/tcp open   smtp

You can also try telnet:

telnet 194.95.6.16 25
Trying 194.95.6.16...
Connected to 194.95.6.16.
Escape character is '^]'.
220 mx01.mpi-bremen.de ESMTP


The implication of X11 forwarding is that it opens a channel from the server back to the client. In a simple SSH session, the client is more trusted than the server: anyone in control of the client can run commands on the server (assuming shell access), but the converse is not true. With X11 forwarding, the server is likely to gain shell access to the client.

In a text session, there is a limited channel from the server back to the client: the server determines the output that is displayed on the client, and can in particular try to exploit escape sequences in the terminal running on the client,

In an X11 session, the server can send X11 commands back to the client. X11 was not designed with security in mind, it was designed with the idea that all programs that you're displaying are run by you and hence trusted anyway. By default, SSH subjects commands from the server to restrictions through the X11 SECURITY extension. The SECURITY extension disables some obvious attacks such as keyboard grabs and key injection, but allows others like focus stealing.


What is a preferred method of security-conscious creation of login cookies

Upon login, create a random value that is stored in your database with a time expiry of your choice (1 day, 1 year, whatever). Pass that random value to the client's browser with the corresponding expiry of your choice (session only, years, etc.)

Now when the client visits a page, they will be transmitting the random cookie to your server which has no connection to their password. If you verify that cookie matches that user in your database, then they are authenticated.

This also gives you (and your users if you implement it) the ability to kill all sessions independently of a password change. It also means that you should implement code to kill all sessions upon a password change.


Can a TPM storage key used to generate encrypt leaf key (child key) if it is stored outside TPM?

Migratable doesn't mean it is stored outside the TPM. All keys except the SRK and EK are stored outside the TPM.

The TPM protection comes from the fact that the blob stored outside the TPM are encrypted by the SRK and can only be used when we feed back in the TPM.

The 'migratable' distinction defines that a key is not tie to a specific TPM and can be used (with proper authorization) elsewhere. I suggest reading this document to understand the different migration process options even if it seems a little outdated.

IIRC, only the EK, SRK and Certification Keys cannot be migratable. You define whether a key is migratable or not at creation time.

Updated: Here's two other documents covering the process to different extent.

TPM Key Management and Key Replication Mechanisms
Introduction to the TPM 1.2 - see section 7


Reading Wireshark Result and Security Learning Recommendation

I can't view the video from where I am right now, but I'll help as I can.

There are a lot of resources to learn more about Wireshark. Try the Wireshark University for intro classes (for free as well as paid) and the documentation has some nice resources, too.

Securitytube has videos for this kind of thing, too.

Wanting to learn about 'security' is a pretty wide topic. Search this forum for the 'professional education' tag for lots of resources, and tell us more specifically about what you are interested in for better results.


Dangers of self-signing a certificate and having clients import them?

I see an additional problem with this type of setup. As self-signed certificates usually are signed by itself, not by a CA (otherwise it would not really be a self-signed certificate), you won't be able to revoke the certificate if the private key is compromised. The only way to revoke the certificate will be removing it from the clients trust store, which usually cannot be done remotely.

If you want to do this setup, create a CA, and save it securely (offline is preferred). Then, create an intermediate certificate signed by your CA and use that to sign the final certificates. Then, you will be able to revoke the certificates (unless base certificate is compromised).


How safe is opening any website on new browser tab?

So if I wish to open "any" site on a new tab while doing my online shopping, is it safe

The same origin policy should prevent other sites from accessing your data in the online shopping site. That is assuming that the shopping site has no vulnerabilities that leak data (CSRF, XSS, XSSI, broken CORS, broken messaging, etc.).
Having only one tab open may mitigate some of the damage malicious sites could do. But with technology like serviceworkers, malicious sites may also be able to perform attacks even after you closed the tab. If you want additional security, you should use other mechanisms which are designed to separate different areas (e.g. private/incognito tabs/windows, different browsers, Chrome's browser profiles, or Firefox's multi-account containers).


As you can see from https://github.com/libtom/libtomcrypt/blob/develop/src/pk/ecc/ecc_export.c it's ASN.1/DER encoded data you're printing, which contains the same data besides the 'k' parameter.

So yes, it's normal that private and public key look similar.

To decode this you can install dumpasn1 which can parse and display the ASN.1 data.

If you want more information on how to use the ecc API, you can have a look at https://github.com/DCIT/perl-CryptX/blob/master/lib/CryptX_PK_ECC.xs.inc

It's not very obvious AND it's not the exact same API as not all of karel's changes are merged into main libtomcrypt (yet), but it should give you an idea.


If you have physical access to the server, then log on its console and see if the server's public key has indeed changed. If it has changed, then try to work out why; if it has not, then this means that when you try to connect to your server with SSH you are actually talking to another machine, possibly because of an ongoing attack attempt, but more probably because of some routing or DNS misconfiguration.

For hosted servers, the provider should offer some IP-based KVM or rescue system which would be equivalent to physical access (in that context).


"Unusual activity" on multiple Microsoft accounts

Most likely the attacker is not cracking the password itself, but probably getting it through other vectors. Some recommendations:

Check if the "password recovery" email was not changed
Check if the "Security Questions" were not changed
Check your profile and security settings, see if you see something changed
Run a full anti-virus scan to ensure you don't have malware on your laptop
Perform network checks (such as running netstat on your laptop or check firewall logs) to see if someone is exfiltrating data from your laptop
Enable two-factor authentication on your Microsoft account, that will most likely stop the attack.


Should a user be able to change another user's role to match their own?

Although it is up to you, common way is a user can set other users equal to them.
There can be many admins if it is wished to be so..

Giving a lower rule is a harder case in my opinion.. I made you admin and you can un-admin me? weird huh? well...this could happen...

So yeah, I can set you equal to me, than you can downgrade me.
Thus, having only one master user is safer. Not that there can't be many, but having a lot of them may lead in to using your app/website etc...


WEP has a flaw that renders it essentially unsecure. If you look at How does WEP wireless security work? it explains in better detail.

WPA(2) has fixed that vulnerability but they also suffer from their own problems.

WPA significantly less secure than WPA2?
WiFi WPA cracking with Reaver
How to get hold of and use WPA session keys?


How to work effectively to win bug-bounties?

The fact that you are trying to 'prove' something to someone else confuses the process.

Look for bug bounty programs
Look for the most error-prone service
Use your knowledge to find a bug

If you try to look at the major products/services, you are aiming too high. Choose something small and overlooked.


Can I get 2FA for my private domain e-mail account?

It depends what email service you're using. I'm using Office 365 with my private domain name which does support MFA so I can enable it on my email account(s).


In Return-Oriented Programming how can the machine execute unaligned instructions?

x86 is not RISC. The instructions are variable length. From 1 to 15 bytes. They are of course not aligned. Few things on x86 are aligned (atomics, some vector instructions, cache lines of course, etc.).

The text you're reading basically says that an instruction can't be a prefix to another instruction, but anything else goes.

So if we have 4 bytes in memory: AA BB CC DD

If the instruction pointer ("program counter") points to AA, it might execute the single 3 byte instruction AA BB CC, then start decoding from DD. But if the instruction pointer points to BB, maybe BB CC is a valid instruction too! Or maybe BB alone is a valid single byte instruction. Or maybe BB CC DD is a valid 3 byte instruction. Who knows? The possibilities are endless.

Since instructions can contain constants, if you can feed constants into a JIT (like firewall rules that get compiled into eBPF programs or lua code in a game or javascript code in a browser or whatever), you can make the JIT produce code with the bytes you want, and then you can jump into that code (basically, jump into the constant, make the CPU interpret it as instructions, profit). Some JITs take care to produce "safe" byte sequences instead of short/fast byte sequences for instructions bearing constants to ensure this doesn't happen. Same for ahead of time compilers.


Why doesn't SELinux prevent access to this file?

Disclaimer: I am not an selinux expert. I am learning like you.

But, on my CentOS 7,

sesearch --allow -s unconfined_t | grep net_conf
   allow nsswitch_domain net_conf_t : file { ioctl read getattr lock open } ;
seinfo -ansswitch_domain -x | grep unconfined_t
      unconfined_t

Looks like unconfined_t type (which has the nsswitch_domain attribute) processes are allowed to access net_conf_t, which the file /etc/resolv.conf has.


How secure is lastpass if TLS is MITMed?

If an adversary is able to issue arbitrary certificates your browser trusts, then everything you do in the browser can potentially be compromised. On the three points above:

If the vault blob is encrypted properly, it should be useless without the master key known only to you. They could use other techniques to intrude though, such as seeing if the file size has changed and correlate that with your web activity to infer that you created new credentials for a site. If they also control your e-mail system, then they may be able to use password reset techniques to enter those accounts.
If your browser trusts that CA to sign code, then you should probably not be using the browser for trusted tasks like password management in extensions. The most powerful change they could introduce in the "trojaned" update is to simply transmit your master password to a location they control, and they will have everything. Consider using a non-browser-integrated password management solution if you are concerned.
This particular MitM can view the credentials for everysite you authenticate with, LastPass or not, since they are (typically) transmitted as a simple text field over HTTP within the TLS session or a cookie in the HTTP header.

If they are not interested in breaking into the LastPass extension, then they have as much access to your actual database file as LastPass themselves. The bigger problem is them able to snoop passwords you enter for all sites right now. Additionally, any cookies used to automatically authenticate you to sites are also visible and can be used to gain access to those sites.


Why do we use asymmetric encryption only for authentication when establishing a SSH connection?

There are several reasons why this can't work in real world (even though it sounds quite ok with the basic knowledge you are presenting).

SSH servers support also password authentication. What asymmetric key would you use in that case?
Transferring huge amount of data and serving many clients would make the host keys extremely prone to the various attacks. In cryptographic algorithm, you need to rekey (exchange the keys) after some time or some amount of transfered data. That would be impossible unless you would need to redistribute the server public key very frequently.
Last but not least as mentioned in the comments, the CPU cycles to achieve the same security strength with RSA is gradually higher than AES and it is similar with other algorithms.


Would it be a big security vulnerability if someone wrote a browser extension to retrieve personal information on Google's behalf?

It would be a security vulnerability, yes.

Executing javascript code in the context of a web page allows that code more or less full access to the content of the page, in this case Google Drive. Such code could leak content, and ask for information such as passwords.

This is generally referred to as Cross site scripting or XSS in shorthand.

The specific case of making the user enter the code is called Self XSS. Sites such as facebook warn against it if you bring up the console by pressing F12 in chrome:


WPA2 Enterprise AES encryption key size?

You are correct in thinking that each session uses a set of psuedo-randomly generated keys. If the network is set up to use a Pre-Shared Key (PSK) then the process works as follows:

The connecting device makes itself known to the Access Point (AP).
The AP sends a psuedo-randomly generated nonce to the device (as plaintext).
The device generates its own psuedo-random nonce.
The device then uses these two nonces, the MAC address of the AP, the MAC address of the device, and the PSK as input to a cryptographic hash function, to create a block of keying information called the Pairwise Temporal Key (PTK) which is 64 bytes, or 512 bits in length.
This PTK is cut up to produce 5 separate session keys. The Key Confirmation Key (KCK) is 128 bits long, the Key Encryption Key (KEK), 128 bits, the Temporal Key (TK) 128 bits, and two shorter keys Rx and Tx used for providing Messsage Authentication Codes (MACs), both 64 bits long.
The device now responds to the AP with its own nonce, concatenated with a hash of the AP's nonce it received and the KCK.
The AP derives the same PTK and session keys as the device as it now holds the same input information (nonces, PSK, the MAC addresses). It can then hash its own nonce with the derived KCK and check it against the received one. This confirms that the device shares the PSK and the device is now authenticated to the AP.
The AP responds to the device with a hash of the device's nonce using the KCK and a sequence number to prevent replays of previous messages by an active attacker.
The device checks the received hash of its own nonce against the expected result (with the KCK), and if they match the AP is authenticated to the device.
The device responds with an acknowledgement of receipt, and the handshake is complete.

From this point onward, messages between the AP and device are encrypted using AES with the TK derived by both devices. The Rx is used to create MACs on messages sent by the device, and the Tx is used to create MACs on messages sent by the AP.

Note that the use of the KEK is not mentioned. I'm not entirely sure on its use, but I assume it was added to the standard to allow for implementation specific extensions to the authentication handshake.

This answer might be more theoretical than you were looking for but I hope it helps.


The master-to-working key derivation is defined as part of the Record Protocol in section 6, and therefore uses only the 'parameters' passed through a theoretical API from the Handshake Protocol in section 7.3 and 7.4 (and 8) which can directly process the handshake messages including both Hello's and the KeyExchange(s) and/or Certificate(s) contents. I suspect this thinking may have come at least in part from IPSec where the data-level 'bearer' processing is largely isolated from the setup/management processing. In practice no SSL/TLS implementation I have looked at enforces this separation; there are normally code blocks (methods etc) for the two protocol levels that are separately usable (and need to be) but share session/connection/crypto state.

Also, it's not clear at all from the notation, but the premaster-to-master happens only when a full handshake (key exchange) is done, while the master-to-working is repeated if and each time a session is resumed using an abbreviated handshake, using the new nonces from the new abbreviated handshake not the ones from the original full handshake; see F.1.4.


What is the difference between authenticity and non-repudiation?

Authenticity is about one party (say, Alice) interacting with another (Bob) to convince Bob that some data really comes from Alice.

Non-repudiation is about Alice showing to Bob a proof that some data really comes from Alice, such that not only Bob is convinced, but Bob also gets the assurance that he could show the same proof to Charlie, and Charlie would be convinced, too, even if Charlie does not trust Bob.

Therefore, a protocol which provides non-repudiation necessarily provides authenticity as a byproduct; in a way, authenticity is a sub-concept of non-repudiation. However, there are ways to provide authenticity (only) which are vastly more efficient than known methods to achieve signatures (authenticity can be obtained with a Message Authentication Code whereas non-repudiation requires a Digital Signature with much more involved mathematics). For this reason, it makes sense to use "authenticity" as a separate concept.

SSL/TLS is a tunneling protocol which provides authenticity (the client is sure to talk to the intended server) but not non-repudiation (the client cannot record the session and show it as proof, in case of a legal dispute with the server, because it would be easy to build a totally fake session record).


How secure is my encryption security Using Truecrypt?

I am using a non-SSD drive: Western Digital Black 1TB. Windows XP (please don't judge why I'm still using XP).

OK, I won't judge, but I will say that Windows XP (or any other equally vulnerable operating system) will only provide you with data at rest security. That is, when the system is powered off, the encryption is as secure as the underlying encryption and the key. An attacker with physical or network access to the computer can violate integrity and confidentiality without needing to break the encryption itself.

Q1. If I were to create a system partition drive C: and 2-3 non-system partition drives D:, E:, F:, etc. using a good password, is my data pretty much secure as long as nobody knows my password? Are there any flaws in my Truecrypt Security Setup? It shouldn't be less secure than "Whole Disk Encryption" since we are encrypting every partition?

If you define secure as providing data at rest security, then yes, it is as secure as your password. Do note that the presence of a hidden volume may be revealed due to a bug in TrueCrypt. Of course, even if you encrypt every partition, the bootloader itself still must be unencrypted. This makes it vulnerable to "evil maid attacks", where someone with the ability to write to privileged locations on the disk replaces the bootloader with a malicious version to steal your password. This requires the attacker have, e.g., physical or privileged local access, and it will only violate confidentiality at the next reboot. Assuming no one has tampered with your disk and your password is strong, it is secure.

Q2. If I had a weak password, and changed my password to a more secure password, is my data still secure? (As long as any "adversary" doesn't have the original TC Rescue disk or copy of your original Volume)

Yes it is. The way TrueCrypt (and many other disk encryption utilities that encrypt large amounts of data) work is by creating a master key and encrypting the drive with it. This master key is generated completely randomly and is not influenced by your password choice. The master key is then encrypted with your password, and the encrypted master key is stored on the disk. If your password is weak, it becomes easier to decrypt the master key, and then use it to decrypt the rest of the drive. When you change your password, you are not changing the master key itself. Rather, you are decrypting it with your weak password, then re-encrypting it with your new, strong password. The newly-encrypted master key is written over the previous, weakly-encrypted master key, making it unrecoverable. As long as no copies of this previous, weakly-encrypted master key are recoverable (through the recovery disk as you mentioned, or through SSD wear leveling), it cannot be retrieved.

Q3. SSD drives, I believe, are different because if you were to write data on the SSD drive BEFORE you created an encrypted partition, that data may possibly be retrieved. However, if you created encrypted partitions first, and wrote data to your encrypted SSD partitions AFTER they've been encrypted, is the data safe as long as nobody has the password?

The thing that makes SSDs a bit strange for encryption is wear leveling, which makes it impossible to intentionally overwrite specific data. The SSD's internal controller manages all writes and does not let the operating system control it directly. While you are correct in that there is no issue with writing to an encrypted partition on an SSD, the real issue is different. There are two issues, actually:

Wear leveling prevents the operating system from overwriting specific data, causing previously-written contents to persist. This can be an issue if you set a weak password and later switch to a stronger one. The VeraCrypt documentation explains this. TRIM, if enabled, is a way to tell the SSD controller to securely overwrite and zero sectors that are no longer in use.
TRIM can reveal to an observer what sectors are unused. This is unfortunate because TRIM can make the former issue less problematic. TRIM is designed to improve performance and allows secure deletion of unused data. While not an obvious issue (after all, the used sectors are still encrypted, and the unused ones are just zeros), it does give away the structure of your filesystem. This is described more in an excellent blog post.

Do I have to Turn on AES-NI? or is it default? so am I secure with default CPU settings or do I have to do something

AES-NI is a set of CPU instructions for doing AES encryption in hardware. It is designed to improve the performance of encryption, but it also has the benefit of creating side-channel resistance. A side-channel attack against AES is usually a cache attack. This involves running a malicious program on your computer that listens very closely to nanosecond-level delays when accessing data in the CPU cache in clever ways to determine what the AES key is. AES-NI prevents this by not using the cache. Since you say you are using Windows XP, you hopefully are not in a situation where a malicious process is in the position to run on your computer, or it has far better ways to get your key than a side-channel attack. In other words, a side-channel attack is an active attack against running encryption, but it cannot violate data at rest security.
TrueCrypt will use AES-NI by default if it is available.

I'm also switching to VeraCrypt but I don't know how secure it is in terms of TRUST and REPUTATION in comparison to Truecrypt (which is very trustworthy in my opinion)

It is based directly off of TrueCrypt and, like the former, has been audited. The source code is entirely open source. While some design decisions it has made are, in my opinion, kind of silly, the core of VeraCrypt is both secure and trustworthy. Continuing to use TrueCrypt opens you up to several unfixed issues which, of course, were not fixed since there are no more developers to fix them. This includes code execution vulnerabilities and some minor weaknesses in the crypto (bad random number generation, for example). Additionally, TrueCrypt uses a very low number of PBKDF2 iterations (usually 1000). Each iteration makes it harder to crack a password by making it take longer to derive the key from the plain password. VeraCrypt uses a variable number of iterations, often exceeding 100,000. For a very strong password, this does not matter.
To summarize, you are using a non-SSD drive on an insecure operating system but are using a strong password. This provides you with data at rest security. No one, should they get their hands on your disk, will be able to decrypt the contents without the password. The only way they could obtain the password is by attacking your computer with malware or exploits, or by tampering with your disk so that, next time you boot it up, you boot into a malicious bootloader. As long as your threat model only cares about data at rest security (e.g. you're using this on an airgapped PC), you should be fine.


Where to download revoked certificates from?

You could just use a MD5 rogue certificate (directly to the demo page). Also see the research paper.

I also found a research on the rogue certificates from March 2011.

Maybe searching the Internet for those black-listed rogue certificates' serial number will help:

00:b0:b7:13:3e:d0:96:f9:b5:6f:ae:91:c8:74:bd:3a:c0 login.live.com
00:e9:02:8b:95:78:e4:15:dc:1a:71:0a:2b:88:15:44:47 login.skype.com
00:39:2a:43:4f:0e:07:df:1f:8a:a3:05:de:34:e0:c2:29 login.yahoo.com
00:3e:75:ce:d4:6b:69:30:21:21:88:30:ae:86:a8:2a:71 login.yahoo.com
00:d7:55:8f:da:f5:f1:10:5b:b2:13:28:2b:70:77:29:a3 login.yahoo.com
00:04:7e:cb:e9:fc:a5:5f:7b:d0:9e:ae:36:e1:0c:ae:1e mail.google.com
00:f5:c8:6a:f3:61:62:f1:3a:64:f5:4f:6d:c9:58:7c:06 www.google.com
00:92:39:d5:34:8f:40:d1:69:5a:74:54:70:e1:f2:3f:43 addons.mozilla.org

These serial numbers are from the Microsoft certificate store after applying the relevant updates.

I did some searching, but all i found was the link 4 I already mentioned above.


Known plaintext; What cipher is being used here?

This could be encrypted with any key length that is equal or longer than 28 characters (sum of lengths of ciphertext you provided) and as such unsolvable. The character variation between the plaintext CANDY VERY CRANBERRYhttphttp and its ciphertext TXOtWjYhVk 8&O$4AmSAcZf.r5Hz is:

17,23,1,48,-2,74,3,35,4,18,0,-11,-44,14,-42,-14,-4,27,1,-24,-5,-26,-14,-66,10,-63,-44,10

or visually in a scatter plot:

I don't see any pattern in it. The encryption is obviously not a simple letter substitution, otherwise same plaintext characters would translate into same ciphertext characters. The function could still be a simple modulo n + shift k though. For example, using n of 32 and k of -80, the key (or rather the first 28 characters of a key of unknown length) could be:

agQ`NZSSTbPED^FBLkQ8K6BNZ1DZ

Or agQXNrSsTbPEL^NBLkQ8K6B6Z9LZ with 40 -80 respecitvely. Of course, there are countless values of n and k that produce 28 printable character strings, and we can't say for sure only printable characters are accepted for the key either, or indeed that this is the encryption method used. Scatter plot suggests good randomness, which doesn't exclude advanced encryption algorithms such as AES, but nether it does a running key cipher or, as @Luc mentiones in the comments, one-time pad where the key used is at least as big as plaintext.

Your question is thus - with the data you provided being insufficient to detect any patterns or repetition - unsolvable.


Should links to images contained in emails be secure?

I would say yes. While an eavesdropper (in either case) can still see what server they are connecting to and therefor infer that they have some interaction with your company, you deny them at least some minor insight into what that interaction is.

Really what it comes down to is that you'll be exercising a best practice, that is to say using SSL when linking to your website. Consider it secure communication hygiene.


Multiple OpenPGP encryption keys signed by a single certificatation key?

You already seem to have realized that there is no way to attach user IDs to subkeys.

You cannot impose ultimate trust on others

The problem with your concept is that while you can issue ultimate trust on your own devices, you cannot impose this for other users. If they're able to validate your "master" primary key through the web of trust, the other keys are still to be validated again, with the effect depending on the kind of trust issued on your key and the trust settings of the validating user.

In the end, all you can do is handing over this kind of handling to the others. Sign your other keys with the "master" key (consider certifying them cross-wise) and hope that (if they care to validate keys) they realize this certification and put trust and certifications on the other keys as they require it, too.

Is it worth the effort?

Consider whether using one signing key for multiple devices is not acceptable, anyway and the gained additional benefits don't weigh up with the effort. If somebody gets hold of your encryption subkey, simply revoke it and create a new one; you will still be able to decrypt old messages, and an attacker can only decrypt what he got hold of (so the exposure will usually be the same compared to different encryption subkeys). Consider switching encryption keys more often.

Personally, I only use one encryption subkey on all devices but my mobile phone, which will get its own primary key in the future (which I will not exchange during signing, but only "loosely couple" through cross-certifications.


Proper way to ask for parameters renegotiation with SSL

See the standard:

  The client can also send a
        ClientHello in response to a HelloRequest or on its own initiative
        in order to renegotiate the security parameters in an existing
        connection.

(emphasis is mine)

So the client sends a ClientHello message when it wants to perform a new handshake. This is the very same message that the client would send when first opening the connection, with the same contents (except for the point detailed below). There is no relation with the previous handshake contents, except that the ClientHello, and subsequent messages up to (and including) the next ChangeCipherSpec, are sent within the current cryptographic context. This means that these handshake messages get encrypted and MACed with the algorithms and keys that have been negotiated during the first handshake. When the second handshake reaches the ChangeCipherSpec stage, the newly negotiated algorithms and keys replace those in force up to that point.

The slight difference in the ClientHello and ServerHello for a re-handshake is the Renegotiation Indication Extension: it is a method by which a client may (and should) indicate whether, from its point of view, the handshake is the first one or a new handshake within the context of the current one. The introduction of RFC 5746 explains the issue that RIE purports to fix. The structural issue, though, is that there is no clear definition anywhere of the security properties that a re-handshake are supposed to provide; implementers have resorted to guessing, and the attack for which RFC 5746 is a countermeasure demonstrates that such guessing, as usual, has gone wrong.

(One way to see it is that handshake security goes forward: security guarantees from a TLS handshake are transported into subsequent handshakes. RIE tries to make them go backward too: any authentication resulting from the second handshake would be deemed good enough for data exchange before that second handshake. But RFC 5746 makes no actual promise to that effect and I am not aware of any consistent, coherent and complete analysis of the issue.)


Trying to keep high school students out of the Wi-Fi network

Enforce Consequences for Students Found on the Network

The first thing you need to do is ensure you have a written policy outlining what devices are allowed on the network. However, if you are not consistent in the enforcement of your policy, it is useless.

This should also cover the usage policies for the Teachers, including locking their computers when they are not present at the machine. You can also use Group Policy to prevent users from being able to view the WiFi password.

Technical Measures

The following consists of various options for limiting the use of student devices on the school network. The most effective is WPA2-Enterprise. The others are included because they may be effective enough in limiting unauthorized access by students and, depending on you particular network, may be easier to implement.

However, the question suggests that the students are on the main network for the organization. Only WPA2-Enterprise is going to adequately protect your network from an attack of an unauthorized device. Once a PSK is known, a student has the ability to sniff teacher web traffic, and possibly capture email and windows hashes. Additionally, a malicious user could start attacking other machines directly.

WPA2-Enterprise

The best solution would be to implement WPA2-Enterprise, instead of using a pre shared key (WPA2-PSK). This allows individual credentials to be issued. This is implemented by installing client certificates on each machine. This requires a good bit of engineering and is not trivial to set up in larger environments. This page has some good pointers on how to deploy WPA2-Enterprise.

Captive Portal

As @Steve Sether mentioned, the Chillispot captive portal can be used to authenticate users once they have connected to the network. Although I don't have evidence to point to, I suspect such a portal can be bypassed by spoofing MAC and IP addresses. However, it does raise the difficulty and will be easier to manage than MAC Filtering on multiple devices.

MAC Address Filtering

As you mentioned, MAC addresses can be spoofed, so the effectiveness of MAC address filtering is limited. However, many phones prevent spoofing the MAC address, so this will address some of the problematic users. The iPhone for instance, needs to be jailbroken before the MAC address can be changed. The hardest part of using MAC address filtering is going to be managing the list of allowed MAC addresses especially across multiple devices from various vendors.

I would also argue that there is 'legal' benefit of using MAC Address Filtering or a Captive Portal. It can be hard to claim a user was unauthorized to access a network when the password is written on a whiteboard. However, if a user has to explicitly bypass a security restriction, you have a stronger case against the activity.

Using an Internet Proxy to Prevent Unauthorized Uses of HTTPS

Implement a HTTPS solution that uses your own private key. You can install the corresponding certificate to the organization's machines and they won't notice anything different (though the organization should still tell the staff that HTTPS interception is occurring). However, unauthorized devices without the certificate will get a nasty message about HTTPS being invalid whenever they try to browse a secure page. Additionally, since you are decrypting the HTTPS traffic, you will be able to monitor the traffic. For instance, seeing which students log into Facebook will allow you to address those students directly.

Many Content Control implementations offer the ability to decrypt HTTPS traffic. If the school already has a Content Control mechanism in place (such as Bluecoat or Net Nanny), talk to your vendor about how to implement this feature.


How paranoid should the average user be about heartbleed?

Your system isn't vulnerable to the issue as you're on Windows browsing with Chrome, but a majority of the sites you visit and use were quite possibly vulnerable.

There are several things you can do:

Check the SSL certificates of websites you visit, make sure they have been issued after 7th April 2014
Verify the websites you visit have been patched or aren't vulnerable (This might help: http://filippo.io/Heartbleed/)
If they aren't vulnerable and the certificate is post-Heartbleed, then change your password (in case it was compromised)

Personally I have a Firefox addon called "Certificate Patrol", that alerts me when a certificate has been replaced or is new, which helps remind me to check to see if they're safe or not. I also have addons that identify the software running on servers, so I know if they're running a server that wasn't affected by Heartbleed (Windows Server for example, or OpenSSL 0.9.8)

  If the bug is that old, and it really is this serious, then why wasn't
  anything done till now?

Nothing was done until now because nobody knew there was a problem until now. Unfortunately it slipped in without getting noticed - In projects that are large and have a lot of contributors, mistakes happen. It is unfortunate that it went so long without being noticed and fixed though.


Apart from the lack of native Outlook support, why should one prefer S/MIME over PGP/MIME for email?

The main reason to prefer one technology over the other is usability. Regardless of the tools you use, email security will depend mostly on how well the users cooperate -- most of the confidentiality of their emails rests on their ability not to do anything stupid with their data, and to react appropriately in unusual conditions. You will get decent security only if the tools they use are available, easy to use and reliable. Therefore, it is difficult to compare S/MIME and OpenPGP in abstracto.

However, we can still make some distinctions on the PKI model. S/MIME relies on X.509, a behemoth of a standard which is meant to support a hierarchical PKI with controlled trust delegation from a limited set of trust anchors and down short paths. OpenPGP uses a Web of Trust which is decentralized. Your expression "blindly trust a CA" says a lot on your own preferences, but is quite subjective.

If you look at how X.509 and OpenPGP operate, you will see that in the Web of Trust, everybody is a CA; hence, while in X.509 you put your trust into a handful of CA, in the Web of Trust you put your trust in... everybody ? That's because most people forget half of the WoT system. In a true WoT, the graph of certification (i.e. who signs the key of who) should be overconnected.

When you want to validate the public key of someone (let's call him Bob), then you need to find certification paths which lead from you to Bob; such a path begins by your public key (which you know "absolutely") and each step is a signature computed over the public key of the next individual in the path. Security in the WoT model comes from the verification of many paths which all begin by you and end on Bob, but with no other individual being common to any two paths. When everybody can act as a CA, any single path is "potentially suspect": when people sign other people's keys late at night and under the auspices of heavy alcohol drinking, you cannot expect all paths to be 100% reliable. An attacker intent on forging a fake key for Bob will just have to find a few gullible or intoxicated individuals. The WoT credo is that "the crowd is right": an attacker may subvert some people, but not most of them. Thus, if you can find many valid paths which lead to Bob, then Bob's key is probably genuine, because bribing or deceiving that many people would have been "probably too hard".

Bottom-line is that the Web of Trust is hard. The description above uses the fuzzy terms "few", "many", "most" and "probably". We do not know how to estimate the number of paths which must be built in order to achieve a given level of security; in fact, we do not know how to quantify a "security level". It is unclear whether WoT can work at all. OpenPGP implementations tend to use a "reliability percentage" which is a totally unsubstantiated guesswork. Of course, in practice, nobody spends time to rebuild many chains; you are already lucky if you find one chain.

When I must exchange confidential data with customers, I use OpenPGP -- but not the Web of Trust. I use OpenPGP because the usual implementations have the ability to bind keys to indentity permanently: if I can make sure once that the key is genuine, then my software will remember it and things will be safe thereafter. So the customer and I exchange the key fingerprints when we meet in person, or over a phone call (which we assume to be safe from impersonations -- eavesdropping is not an issue here).

Such binding is not supported by S/MIME implementations. They could do it (although certificate expiry makes it slightly more difficult) but they do not. It is not intrinsic to X.509 (the X.509 model makes it possible to change your certificate every five minutes, but it does not make it mandatory); but deployed implementations work that way. Usability trumps the PKI model, as I said above, so that's OpenPGP for me.

(Note: in another context, HTTPS relies on the X.509 hierarchical PKI with a few dozens of hardcoded trust anchors, and the same issues arise there too; e.g., see Convergence, which is a proposal to, indeed, bind keys to servers in a semi-permanent way, and which relies on the same "crowd is right" mantra as the WoT. And yet they do that with X.509 certificates, which shows that the actual format for certificates is not that important.)


What damage can a malicious .iso file cause without explicitly executing it?

According to the post on Superuser here, I would say it is safe to say it can't run anything malicious. Pavium's reply is:

I think it's more accurate to say 'a virus can't execute itself, unless it has the cooperation of the Operating System and/or software bugs and/or the user.
If the OS allows files to be executed automatically because of their name or location (for example an email attachment) then a virus can masquerade as a legitimate file and be executed by the OS without user intervention. This used to be the default behaviour in early email clients.
Also, if the OS or specific software has errors that a virus can exploit to run its code, then a virus can start itself.
But users are most often the means for a file to be executed. I was surprised recently when a work-colleage told me she thought her computer had a virus after she opened an attachment in an email from a complete stranger. I thought she would have known better.

I really liked the fact he mentioned:

if the OS or specific software has errors that a virus can exploit to
run its code, then a virus can start itself.

This statement can't be true enough. Around the time I've worked with exploits, and always keeping an eye on the exploit database, the code that's most powerful is, I believe taking advantage of a systems own error. So, the summary is, unless your OS has an error it can exploit to run itself, it can run malicious code and do damage it intends to do. Unlikely, though.


Is it possible to secure an Android Intent from other calls from apps?

So this is a really tough problem, and I don't believe there are any APIs out there to achieve what you want.

What you can't do: Custom Permissions

While they sound like a good idea custom permissions are defined in the AndroidManifest.xml.  Checkout this SO answer on how to define/use them, but they look something like this:

<permission
    android:name="com.testpackage.mypermission"
    android:label="my_permission"
    android:protectionLevel="dangerous">
</permission>

To use the permission all another application has to do is put the following in their own AndroidManifest.xml:

<uses-permission android:name="com.testpackage.mypermission"/>

Since Android APKs are trivial to reverse engineer to gain the most basic information about an application; this would fall your fear of someone gaining access to the APK.  Anyone with a rooted phone can pull the APK from their phone.

I do admit that there is likely more to using a custom permission than just that XML line.  But it seems if someone is going through the trouble to begin with, then they can figure it out.

Solution?

This is a tough problem, because at some point you'll need to ask the user to verify that they trust an application to be used with your core app.  If the user verifies that they trust the app then I would probably record the application's signature; which can be found at runtime.  If the signature changes from what you have recorded then it's not the application the user trusted.

This is probably the easiest solution.  Verifying the signature itself should be possible as the META-INF/CERT.RSA contains the signature and public key to verify the signature.  I believe this post on SO shows how this can be done.

Again, you're still relying on the user to verify trust of an application through your core application.  I'm not sure if this is acceptable to you or not.


Storage on Root CA and intermediate CA certificate on Embedded device

Embedded device or not, the only requirement is that you have to be able to follow the cert chain up to something you trust. So if your server is indeed delivering the whole chain (as you seem to imply it), you'd only need to store the Root CA in the embedded device.


Using OpenSSL as a library versus calling output from standalone command in a program being written

As a rough summary, OpenSSL has been designed as a library and was meant to be used as such. The command-line utility was, initially, a tool for testing and for manual tasks. Potential issues with invoking the command-line utility from a C application, with system() or popen(), include the following:

The tool expects its inputs as files, which must be produced and managed. Some of them are sensitive, e.g. files which contain private keys; you need to exercise great care when copying them.
The tool produces its outputs as files or text on its standard output; the text is meant for human consumption, not for automatic parsing. A number of corner cases can be troublesome (e.g. if you use openssl as a way to analyse the contents of X.509 certificates, what does happen if a string within the certificate contains a newline character ?). The format of text output might vary with details of the system configuration (e.g. system-wide language or encoding).
Error reporting will be hard. With the C API, you can know exactly which step failed and why; with the command-line tool, you will get, at best, a synthetic error status ("something failed") and a text message.
system() and its brother popen() are a definite no-go in setuid applications (that's the king of "get root shell" holes of the 1980s).

To sum up, calling openssl (the command-line utility) from C code is cumbersome, inefficient, and complex. Complexity alone almost mechanically implies security issues.


Could I be defrauded by a website who has my address, phone number, and credit card number?

To answer the precise question; No, YOU can not be defrauded if you acted in good faith.  You can be INCONVENIENCED while your credit card company works out what happened.  But at the end of the day, YOU will not be out of pocket with regard to the fraudulent transactions.  It is YOUR BANK bank that ends up being defrauded.  To re-iterate - this only applies if you act in good faith and not recklessly.

Disclaimer: This is the situation if your card is issued in Western Europe, US and Canada. Your liability in other jurisdictions may vary.


Loginless Client/Server Architecture (iOS)

If you can store a device ID on the client, then you can use that as both "username" and "password": within the SSL tunnel, the client sends the device ID, which the server looks up in the database. If the device ID is found, voilà! the client is authenticated. Remember that "a client is authenticated" has the same meaning as "no other entity than the client himself could have said that". As long as the "device ID" is client-specific, secret, and unguessable, it is a proper basis for authentication.

Of course, a customer who extracts the data contents of his device and reverse engineers the code will find his own device ID, and will be able to access the server from other computers. That's unavoidable. You cannot enforce usage of a specific client device unless the client device contains a tamper-resistant element (e.g. a TPM), and, apparently, iPhones do not. Certificates or other cryptographic gizmos won't help you there.


To quote The Grugq on this:

  "VPNs provide privacy - Tor provides anonymity. Confuse the two at your peril."

So, don't use VPN for anonymity but use it to protect your privacy instead.

Update: to answer your questions in a more direct manner:

  Given this set-up, has VPN B any chance to identify an user?
  so how could VPN B identify a single user?

VPN B only knows that traffic is coming from an endpoint of VPN A. Depending of the abilities of your adversary, the mere fact that both VPNs are located in different countries may or may not help "them" to e.g. get connection logs from each of these VPN providers. For example, an intelligence service could sneak into each of these VPN providers, no matter where they are located.

If your only adversaries are the VPN providers itself, then you'd have to trust them that they don't work together and VPN A doesn't tell VPN B about its users.

So, it all depends on your level of security and/or paranoia trust towards the involved parties. However, the quote from above still stands and I'd recommend NOT to rely on VPNs for anonymity but use e.g. Tor for that purpose.


How can I defend against Heroku (or any PAAS) ID theft?

Yes, your heroku username/password might be a weak link in the app’s overall security, but so would be your database credentials, your router credentials and any other credentials...

As long as you have a strong password in place I would not be worried about heroku ID being stolen any more than any other ID you use.

what you CAN do to improve your heroku account security is enable two factor authentication: https://blog.heroku.com/archives/2014/9/25/two-factor-authentication-ga


My computer hacked? tcpdump show a connection to an ALLOCATED UNSPECIFIED ip address

Just because the IP shows as Allocated unspecified does not mean you are being hacked.

This IP status is because you asked the wrong entity, as ripe.net is not the responsible for allocating that IP. If you look at IANA IPv4 Address Space Registry, you would see that this IP range is managed by ARIN.

If you ask arin.net, you would see that the IP is owned by Microsoft Corporation.


The DSA-4371-1 is a vulnerability that requires a man-in-the-middle between APT and a mirror. Of course this can happen, but it's not the only possible source of the infection. Reading the article made you extra cautious, and you ran chkrootkit, which then found something. If you didn't run chkrootkit shortly before, it may well be that those problems have been there longer. First thing is to rule this possibility out.

It's hard to know what has happened on your mirror unless they have published finding malicious content. If you have a snapshot backup of your system from time before 22 Jan 2019, you could test that version again with chkrootkit or similar. If the backup was clear, then this vulnerability in APT is likely the cause for your infection and you can run the system safely after recovering it from the clean backup.

If there's no clean backup, reinstalling the whole system is the only option, no matter how it was infected.


Different Microsoft-signed excecutables have apparently the same signature!

Some questions can be answered, other are speculative.

X.509 relies on ASN.1. ASN.1 defines two data types for dates, UTCTime and GeneralizedTime. UTCTime has only two digits for the year, so it is not Y2K-clean; it was defined in the late 1980s out of what can only be described as a consummate lack of foresight. It was temporarily fixed by defining that UTCTime really covers years 1950 to 2049, making the interpretation unambiguous. Dates beyond 2049 shall use GeneralizedTime, which has four year digits and is thus fine until December 31st, 9999.

Therefore, the two-digit years are a symbol of incompetence, but not a security issue stricto sensu.
The GeneralizedTime format (with four digits for the year) can contain fractional seconds, indicated by a dot followed by extra digits. The number of extra digits is theoretically unbounded; however, upon encoding, trailing zeros are supposed to be removed. If you see "20151030033209.248Z" and "20151030033209.24Z", then these dates were measured with (at least) millisecond precision, but in the latter, the number of milliseconds was "240" and the trailing zero has been removed.
Usually, signature and time stamping are done by distinct machines; the time stamping is performed by a dedicated Time Stamping Authority whose job is to maintain an accurate clock. Time stamping is often delayed. In your case, you see that the time stamping occurred four days after the signature.
I find some reports that the two versions of bootsect.exe correspond to two different builds of Windows, called "10.0.10586.0 (th2_release.151029-1700)" and "10.0.10135.0 (winmain_prs.150531-1700)", respectively. According to this site, the latter is an internal Microsoft build that was leaked on June 6th, 2015, but was not meant for release and is thus relatively rare in the wild.

From these information, I infer the following: within the Microsoft build process (which is probably quite intricate), two versions of bootsect.exe were compiled at the same time, differing probably only in the "build number" (I suppose your bytes at offset 0x148 are part of the build number) and signed in short succession (8 milliseconds between the two signatures). The two builds might correspond to a "stable" and a "development" versions with different building options, but integrated within the same compilation process. These two versions were then scheduled for time stamping, which occurs elsewhere, on another machine, with its own queueing. The two time stamps were performed a few days later, with an 11-second delay between the two files -- one has to imagine that the queueing is not fully "in order" and files which where queued in short succession may be handled at different times.

It is improbable that the two files behave differently. The signature uses Authenticode, which covers the complete file except the few fields that cannot be logically part of it, i.e. those for the signature and certificates, and the header checksum. It is possible for a signed executable to inspect its own binary and leverage a one-byte difference in the header to change its behaviour, but this is quite artificial: the code has to do it on purpose. Signatures are supposed to protect against malicious alterations of honest files, not against shifty executables that try to perform underhanded trickeries.

My conclusion is thus that your two bootsect.exe correspond to two distinct builds that happened to be done concurrently within the Microsoft compilation process, and for two versions of the source code that are, in fact, identical, thus leading to the same behaviour. The two files were signed in short succession, time stamped a few days later independently of each other, and one was part of an official release while the other was an internal build that got leaked.


Should an app remove or encrypt locally stored user data after a user logs out?

Anytime you use a computer of unknown provenance, you are at risk. It could have a hardware keylogger, a rootkit, or sketchy SSL certificates, etc. You really have no idea. It's best to do your sensitive work on machines you trust -- in this case I should think your friend trusts you.

You actually asked two questions though: should an app remove OR encrypt local user data?

Let's start with encryption. Yes, an application should encrypt data if it is considered sensitive enough. I personally doubt that chat logs are sensitive enough, but if a program is storing credit card numbers or SSNs, then it would be reckless and irresponsible not to encrypt that information. If you believe your chat logs are truly sensitive, then you are probably the type of person that should be using whole disk encryption (WDE).

Of course, when implementing encryption, you run the risk of muffing it up. If you do manage sensitive information, please use a well-known framework rather than writing that code yourself. For example, on OS X, you can use Keychain Services to store credit card numbers and social security numbers.

Now let's consider removal. One of the growing niches in security is privacy, and we're seeing more and more now that it's not acceptable to capture information about a user without that user's permission, especially if the information capture isn't obviously required to perform whatever tasks the application is supposed to do.

In client-server applications, there have been some obvious examples of failures in this regard, such as Path uploading all of your contacts. However, even storing user data on the client side can be a major privacy breach, as seen when Apple accidentally stored GPS tracking data on user's phones. Another example of this is malware that targets bitcoin files.

In the first two cases, the central issue seems to be the unexpected and indefensible collection of information that users did not expect them to be collecting. In Path's case, they should have never collected that data in the first place. In Apple's case, they have a valid use case for recording recent GPS data, but a bug resulted in those GPS logs not being truncated properly. Apple should have been more up-front about why iOS collects that data, and they should have tested that feature more to make sure it worked right.

The bitcoin example is slightly different: in that instance, the user clearly expects that data to be saved, but does not expect that his/her data can be stolen so easily. In this case, the application managing that data should have encrypted it. It was reckless to design digital currency management software and not build encryption into the design of it.

Your question is actually very insightful. As an industry, we're still not 100% sure what the answers are to some of these questions regarding privacy and security. I believe that over time we will see more and more attention placed on the issue of encrypting or removing data collected about users.


http blocked over very low ports in Opera web browser

I am using opera 11.52 right now. For quick local web servers, I used MoWeS Portable. I set apache to listen on port 72, so in opera I typed

  http://localhost:72

and I am not having any such error.

However, when I changed the apache configuration to listen on port 70, I can replicate your error.

It's possible that because HTTPS is typically used for HTTP over SSL (HTTPS) that trying to run a url as a regular http://... gives an error. Though, in my testing I can run a non HTTPS server connection on 443.

Now, port 70 in particular is for the (virtually) deprecated gopher protocol which was more common before the rise of WWW http://en.wikipedia.org/wiki/Gopher_(protocol). So maybe they now block port 70 in particular.

As for your 443 error posted on the opera boards, perhaps as the first responder noted you were trying to connect to a port expected SSL and your server is not setup to automagically handle that for you. Did you get the same unsafe port error?

In your case it could be a combination of things, perhaps you can provide some more information to clarify.


The simplistic scenario would be to try and send --><?php phpinfo();?>
 <?php phpinfo();

(newlines added for clarity). But the presence of <?php ...?> in the HTML page might not be enough; the PHP code needs to be interpreted server side, not just sent back to the client.

By examining more closely the beginning of the resulting string:

which would be rendered as HTML, or is defanged more thoroughly into

which renders to nothing useful. This depends completely on how the HTML open tag detection is done, and how it operates. Sometimes preg_replace is used with incorrect, incomplete, or not-greedy-enough regular expressions, which may defang only the first or last tag, or blindly defang the first opening with the last closing, ignoring whatever lies in the middle. If that is the case, then the page is vulnerable to Javascript injection and a variety of related attacks.

Is the sanitizing code available for inspection?

Example of naive validation

For example, this code apparently sanitizes HTML output.

preg_replace("/<(.*)>/", "", $input);

but (apart from being a badly thought out measure) the lack of the ungreedy operator ? leaves it vulnerable to a simple pre-unescaping attack:

<?php
    $params = array(
            "",
            "< -->", $param) . "\n\n\n";
?>

results in the first naive attack to fail, while the second succeeds:

Unfortunately, this preg_replace option is often suggested or implemented as a "quick fix" for HTML injection attacks, and as most "temporary fixes" are wont to do, it may become permanent.

A better strategy would be to filter out anything that doesn't belong in the original parameter (e.g. replace [^A-Za-z0-9_] with nothing at all), or reason that the presence of forbidden characters means that something wicked this way comes, and therefore the safest reaction is to drop the request altogether (maybe informing the user, on the off-chance that it happened by accident or due to a problem - e.g. maybe a syntactically incorrect link - somewhere else; for which reason a logging of HTTP_REFERER is highly recommended).


Excluding cipher suites containing SHA or AES128

The upgrade to AES-256 is happening and new servers offer it as 1-st option. To illustrate you how this is done here is list of newer httpd SSL ciphers (test with nmap), see below.

Now the thing is that if browser would not be able to use any strong variant then it can use any other weaker supported cipher. Ciphers are tried from the highest TLS protocol supported and then variants from the top first to the bottom last.

The following configuration makes good clients using strong ciphers but keeps compability with older ones so no-one is affected.

After change to that, one can analyze SSL logs to see what variants can be removed and how many users will be affected, but if it's big company then the list below should work for everyone for the start.

Regarding CDNs, to do switch from AES-128 to 256 is huge change which costs significant $$$. However, such change will have to happen once they upgrade the software to the newer one which will surely happen in the coming years.

So with this server Firefox is using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, OpenSSL is using best choice TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Google Chrome says TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA, all with TLS 1.2.

Doing it differently will upset many users.

nmap --script ssl-enum-ciphers -p 443 127.0.0.1

443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C


Chrome: Watch for modified https-certificates

Is there anything like this for Chrome?

No. Chrome Extensions currently have no way to access information about the TLS certificates being used, and a proposal to add this functionality was rejected back in 2015.

  Would this yield a good security layer?

Probably not.

Let's clarify the threat model here: you're concerned about a scenario where "a MITM exchanges the shipped https-certificate and my computer trusts the signing CA". This would require the attacker to obtain a valid certificate from a trusted certificate authority for a domain they do not own.

While CAs have mistakenly issued certificates to the wrong entities in the past (Comodo, WoSign, Symantec), these are pretty rare events, and CAs that consistently fail to uphold the validation requirements in the baseline requirements have their root certificates distrusted by browser vendors. (This happened to WoSign, and is currently happening to Symantec.)

Furthermore, the security benefit that these sort of alerts would provide depends entirely on your response to noticing a modified certificate. Sites change their certificates all the time (often as frequently as once every other month, such as in the case of Let's Encrypt certs managed by Certbot), so the vast, vast majority of the time this alert appears it's just going to be a false alarm. How do you plan to distinguish these false alarms from a legitimate attack? Unless you have some out-of-band way of verifying whether the new certificate you're seeing is legitimate, an alert won't do much.


If my data is encrypted with a password, how does the website know me?

Your password does not encrypt anything

The owners of the website can see everything*, including your plaintext password

*There are exceptions, but always assume that they can.

This is one of the reasons why you should not reuse passwords.

Your perception is a dangerous one to have. Maybe you can expand your question to what lead you to believe this?


new format of keepass (2) database file and hashcat

This question was cross-posted on the hashcat GitHub and answered here.
The relevant keepass2john comments say that only versions prior to KeePass 2.36 are supported for conversion.
Newer versions may use Argon2 or ChaCha20, but hashcat does not support these at this writing. See also related posts on the John the Ripper GitHub issue.


Scan password protected email attachments for malware

There are many archive formats, which have many "password protection" features. It so happens that Zip archives traditionally used a custom stream cipher which has been broken. But though the break can be implemented in practice, and requires relatively few known plaintext bytes (13 to 40), its cost is still a bit high (roughly 238 elementary steps of the stream cipher). It is a nice implementation exercise for students, and an effective warning against homemade schemes, but doing it automatically in an antivirus would not be very practical.

Moreover, recent Zip implementations have switched to AES-based encryption, which is not broken.

To break through a password-protected archive, you have to "guess the password". Now let's see how this would work with malware. Such malware emails itself, automatically, to millions of people; in order to evade analysis, it encrypts itself as a password-protected archive, but, of course, this does any good (to the malware) only if the victim can still open the archive. So the victim must "guess" the password. Therefore, what malware does is that it includes the password as "text" in the email. The human victim sees the password, and uses it to open the archive.

Malware has no trouble whatsoever coming up with passwords which are random enough to defeat brute force. This prevents your "breaking attempt" strategy from being effective; in fact, if you can find the password from the antivirus then the archive is most probably not from a malware, but from an honest human (who, like many honest people, seems incapable of using strong passwords).

The strategy for archive scanning would imply "understanding" the email contents, like a human user, so as to guess the password in the same way as the victim. This is hard, because the malware just has to encode the password so that the victim "sees" it, so it can be a picture, an HTML table with pixel-sized cells (the background color of each cell is then modified to build a visible picture), an elaborate charade ("password is the capital city of Germany"),... (I have seen all of these employed). Ironically, this places the antivirus in an attack position, as if it was trying to break a CAPTCHA.

The one-line summary of all this is: it won't work.

A purely automatic antivirus software will not be able to "break through" password-protected archives which are used as malware vector. The antivirus may detect such malware through some heuristics; e.g. the presence of a password-protected archive could increase a "spam score" which, combined with other bad points from other email features, may result in a "this is spam/malware" conclusion. However, this is back to the usual trade-off: some spam/malware will get through, and some non-malware will be blocked.

Alternate strategies:

Block password-protected archives. Arrange for another transfer system for customers, e.g. some HTTPS-based server where files can be uploaded.
Delay emails with password protection until a human operator has looked at them and declared them "good" or "bad". Interns are cheap. But the extra latency can be an hindrance to business, human inspectors can fail, and having poorly paid underlings inspect emails may raise additional security issues (now your competitors know who to bribe, and that won't be expensive).
Implement the antivirus right on the users' desktop systems, to be run when they actually open the archive. At that point, they have typed the password, so the clear contents become available, and the antivirus may act. Of course, this has drawbacks: maintaining an efficient antivirus on all desktop systems is expensive, introduces interoperability issues, and is not feasible in some cases (e.g. in a BYOD world).
Request that customers protect their archives with PGP encryption, using a specific destination address and public key. The corresponding private key will be owned by the antivirus, who will then be able to scan the contents, and then forward them (internally) to the actual user within the organization (this second step needs not use encryption: the email is already on your network).

In practice you will want to use the first system, not because of all this malware-scanning problematic, but for a much more mundane reason: big emails don't travel well. A lot of email servers will drop emails which are bigger than some limit, typically around 5 megabytes. 5 MB used to be huge, but not anymore. A PowerPoint presentation with some photos will easily exceed that size. Therefore, there is pressure for using a non-email-based transfer mechanism. A Web-based upload system, with HTTPS protection, is not hard to put in place; some people use Dropbox as an extension of that principle.


Are there solutions to managing AWS root keys by a team?

In a properly secured AWS account, the root account should only be used as a "break glass in case of emergencies" thing. Users should be using IAM accounts as their "daily driver". I would enable MFA on the root account, and print or save a copy of the QR code. Put it in a safe or vault. Only pull it out when you need it.

You can scan the MFA QR code multiple times, so you can have several devices setup for MFA.


Regarding the storage of Root CA certificate and any Intermediate root CA certificate on Embedded Device

Only the Root-CA needs to be known (and trusted) by the client. Everything else can be chained on demand.

Your server can be instructed to send the intermediate certificate along with the server certificate. This process is called "certificate chaining" and often implemented by concatenating both certificates into a single certificate file; older versions of e.g. Apache Webserver required a specific statement ( SSLCertificateChainFile ).

A client receiving this chain of certificates does follow the server's certificate via its issuing CA until it reaches a client-trusted Root CA; if it doesn't reach a client-trusted Root-CA, the certificate will be regarded as "not trusted" and depending on the actual client application, the application will refuse to send data over that (encrypted, but not authenticated) connection.

Please also do keep in mind Root CAs do have an expiration date, so (depending on the estimated lifetime of device and Root CA) you may need to update or exchange Root CA certificates on your embedded client device as well.


Currently, WebSockets are suppressed deliberately.  This will be addressed eventually by implementing this feature request:

https://github.com/droe/sslsplit/issues/216