Right way to use the TPM for full disk encryption

First of all: NO system is 100% safe, but using TPM is better than no TPM at all. TPM Chip is just some kind of encrypted storage, that resides on the motherboard of computers that support Trusted Platform Environment, and have BIOSes prepared to handle it.

PCR are registers with specific functions that are handled through the TPM_Extend operation. They cannot be "set", only extended(new_hash = [old_hash||new_measurement]).

TPM have Static Root of Trust for Measurements (SRTM) and Dynamic Root of Trust for Measurements (DRTM), and the combination of both creates the Secure Environment. This guy explains very well how this is done. It is a chain of trust between fixed and dynamic items.

Back to PCRs, they are platform independent registers, and the most common ones are:

PCR 0 to 3 for the BIOS, ROMS...
PCR 4 - MBR information and stage1
PCR 8 - bootloader information stage2 part1
PCR 9 - bootloader information stage2 part2
PCR 12 - all commandline arguments from menu.lst and those entered in the shell
PCR 13 - all files checked via the checkfile-routine
PCR 14 - all files which are actually loaded (e.g., Linux kernel, initramfs, modules...)
PCR 15 to 23 are not used

Intel based notebooks commonly use the first 16 registers, but it could be extended to other softwares/uses.

While writing information (sealing) to TPM, you can add a Storage Root Key (SRK) that is somehow a "Management key" and is used to add other keys to this storage. As per manpages, using -z will set TSS_WELL_KNOWN_SECRET (20 zero bytes).

-z, --well-known
    Use TSS_WELL_KNOWN_SECRET (20 zero bytes) as the SRK password.
    You will not be prompted for the SRK password with this option.

So, having this SRK set to the default secret (TSS_WELL_KNOWN_SECRET) will not be enough to attack someone since TPM can only be unsealed if the current PCRs match those used to seal the data. Also, some of the PCR handling happen at boot time(BIOS) and it's very hard to manipulate those and thus create "fake" PCRs. BIOS is the only place where PCRs are seen as zeros before the rest of the process takes place.

The only FEASABLE attack is the one who aims to MITM communications between BIOS and PCR to zeroes PCR without restarting the machine to put the system on "trusted" state. This attack is known as TPM Reset Attack.

  The Attack

  So, given everything we've seen above, it should be very difficult to
  fake a trusted boot process, as long as the BIOS takes the first few
  measurements. The critical assumption here is that the PCRs cannot be
  easily reset without restarting the whole platform that the TPM
  resides on. If an attacker is capable of monitoring the measurements
  sent to the PCRs by the BIOS (with, for instance a logic analyzer, see
  this paper), and capable of zeroing out the PCRs without restarting
  the machine, then she could take a platform in any configuration and
  put it into a 'trusted' state. So, the difficult part is getting the
  TPM to reset without bringing down the whole machine. It is worth
  mentioning that we've also looked at interposing memory and other such
  things to change the running system after its been measured, but due
  to the speed of the busses that memory and hard drives sit on, this is
  a tricky endeavor. Attacking a slower bus is much easier.

  TPMs typically reside on the Low Pin Count (LPC) bus. The LPC bus
  supports a ground driven reset line. This means that when this
  particular line on the bus is driven to ground every device on this
  bus is supposed to reset. Other devices attached to this bus include
  the BIOS, and legacy keyboard and mouse controllers. The video below
  demonstrates that driving this line is indeed possible, and fairly
  easy to do. Please note that in the video, we are accessing the
  computer in question via a remote ssh session. This is because the
  keyboard and mouse controller get reset when we drive the reset pin,
  but the network card does not. More details of this attack (and
  others!) can be seen in my senior honors thesis: A Security Assessment
  of Trusted Platform Modules, Dartmouth College Computer Science
  Technical Report TR2007-597.

Note that this is an oversimplified version of ALL THINGS that involve Trusted Computing. Please take a look at the Architecture Document of TPMv2 to get more information about all operations that happens between bios, hardware and software during the setup of a trusted environment.

tl;dr: Using the default Storage Root Key(20 zero bytes) is not enough to create an insecure system.

Related stuff:

LUKS, TPM and full disk encryption without password.
Full disk encryption with LUKS (including /boot) without TPM.


Preventing boot from external media in case of theft of laptop or physical security breach in case of desktops?

One measure to seriously take into consideration with laptop theft protection is physical security. Your thief may not be tech savvy enough to avoid the traps you set, but he's got the unit in his hands already, and depending on what he wants to do with it he can always make a quick buck on the hardware alone.

In previous companies I've worked for they did have these anti-theft software mechanisms, but they almost never got our hardware retrieved when the unit was stolen from a vehicle or lifted at an airport. You should consider desk or bag locks for units like this, or simply keeping the unit with you at all times and training users to do the same thing. I've found in the past that having the unit on you in a sling bag was one of the best deterrents against laptop theft. Data backups before traveling with the unit are always a good idea too. It's a great idea to have anti-theft software in case something terrible happens, but I'd make plans for physical security a priority.


Any information about the internals of a system or application helps an attacker craft a specific attack. For instance, that error message includes table names, which means it becomes far easier to craft a SQLi attack.

In addition, with detailed error messages, I could try to trigger different errors to map out the function of the backend, and even find vulnerabilities much faster.

In general, detailed error messages are a no-no. Use them only on a QA instance for debugging.

That said, there is a reason why "info disclosure" is not regarded as an automatic "high" finding. It is possible that even the details of the application or system would not help an attacker, but that is up to each and every system. So, the risk needs to be evaluated in each instance (which doesn't provide you with a quick answer to your lead dev).

As an evaluator, though, when I see highly detailed error messages like the one you posted, I know that the devs have not been careful, and I can assume that the application is not properly coded, and likely with a lot of vulnerabilities. In short, if I see a message like that, I pull out all the guns to find the holes there are likely to be, and I have all the details I need to precisely exploit them.


Conceptual design of vulnerability scanning program in global retail network (PCI DSS)

In the strictest sense the safest thing to do is to, of course,

As you've no doubt found this can be difficult in a distributed environment. The specific vulnerability scanning tool you use can also add in some problems. Take Nessus for example. When building a scan profile there is an option called, "Check for PCI-DSS compliance." This makes a bunch of internal changes to the scan profile to meet the muster they've defined. However, this also requires there be no network protections between the scanner and the device. So no firewalls, no IDPs, hell they don't even want any routers involved.

Going back to the conceptual level, keep these kinds of problems in mind as you're building out your infrastructure. Here are the design features that I would start with, presented as a bulleted list in no particular order.

Remote scanner housed at each site
Centralized system to pull reports from all remote scanners for processing
Vulnerability management process to

Review reports
Analyze results for false/true positives
Define actionable items
Prioritize items
Determine remediation/mitigation paths for each items

So yes, this type of a program comprises both technical and procedural aspects that must work in tandem. Additionally, the process for reviewing and handling the reports must include representatives from all involved units. Primarily whomever is involved in managing the endpoints, the terminals, servers, etc. May also include the groups responsible for managing the networking, internal customers outside of IT who actually use the system, or others as fit within your environment.


Mathematically, you are correct that if your data key is properly generated using a cryptographically secure pseudorandom number generator, the master key can’t be reversed from a message (assuming AES is unbroken.) But operationally speaking, this scheme provides a “crib” to an attacker trying to guess the master key. It enables a “known plaintext” attack.

Consider the case where an adversary believes he has part of your master key. He can use any intercepted message from this system as a test to see if his guesses are correct. Or he can unwind the algorithm, should such an attack against AES ever become known.

This scheme isn’t following the principle of “a key should be used for a single purpose.” Because the master key still lives in each message, each data key is now sharing your master key with all other keys.

That said, I’m not familiar enough with AWS’s KMS to know how your system is configured, but all the KMS systems I work with perform key management by granting permission to individual users to access only their application’s keys. No user would ever have access to use the system’s actual master key to directly encrypt a data key. So it’s possible that your description isn’t complete, and what you have been referring to as a master key could simply be referring to an application-specific key. In that case, the leak of your key won’t lead to the leak of the other keys in your KMS. Your organization’s other keys wouldn’t be compromised even if your key was.

Even in that case I’d still consider taking your colleague’s advice and changing to use an asymmetric key solution like the one he described for exchanging keys, instead of encrypting the data keys directly with the master key. You can still have the sender and recipient use the KMS to decrypt the private keys, because the private keys are never sent with the messages. It removes the known plaintext attack against the master key.


Rounds of MD5 and SHA512 Hashing Algorithms

There is no objective, systematic and consistent notion of what is a "round". Each algorithm specification defines things its own way.

MD5 is described as first padding and then splitting its input into 512-bit blocks. Then, as the RFC puts it, there are four rounds where each round happens to be a sequence of 16 very similar operations. So we could say that MD5 uses "four rounds" (per block). However, cryptographers have soon shunned this terminology, and when they talk about the potential weaknesses of MD5, they concentrate on the internal operations, which they call "rounds". In that view, MD5 has 64 rounds.

SHA-512 is specified similarly as padding and breaking input data into 1024-bit blocks, and each block is processed with a loop which repeats 80 times a sequence of 4 steps. So we could say that SHA-512 uses "320 steps" (per block). There again, cryptographers agree, more or less implicitly, on talking about "80 rounds". It can be noticed that each of these rounds roughly implies twice as many operations as an MD5 "round" (when MD5 is said to have 64 rounds) so it could be argued that SHA-512 actually has 160 rounds. Or not.

These terminology issues are not important as long as everybody agrees about what they are talking about. The important point is that there is no absolute notion of "round" which is more correct than any other, or which could allow comparing different algorithms based on "how many rounds they have".

As for knowing what happens within the rounds, the simplest way to know is to read the specification, and implement it in some language. This is not hard (begin with MD5) and it is a great pedagogical experiment.


Ubuntu: How do I download PPA software over HTTPS?

It's simple: Ubuntu provides e.g. http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/, but not https://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/. Nothing you can do about this. How could any mirror be more secure than the origin?

File a bug report to https://bugs.launchpad.net/ if you want to see https://ppa.launchpad.net/, but don't set your hopes too high.


Should I avoid deploying package.json or bower.json files to production?

Allowing access to your package.json and similar files is going to be a bit of information disclosure and as such should generally be avoided.  In a scenario where a JS library had a known vulnerability, leaving this accessible in the web root would allow attackers to quickly assemble a list of valid targets.

It's unlikely to be a very high risk issue, but the general principle of not providing information to attackers holds, so I'd say that it shouldn't be placed into production in a form that's accessible to end-users.

In terms of standard practice to address this risk.  Typically either strip these files as part of the deployment process, or using something like .htaccess to prevent access to them.


Penetration Testing Silverlight Applications

If you are code reviewing then I would recommend that you use Microsoft Visual Studio Unit Tests (See http://silverlight.codeplex.com/ and http://weblogs.asp.net/scottgu/archive/2008/04/02/unit-testing-with-silverlight.aspx) or Nant to test the code. It is would be the most effective way to do these type of tests.

If you don’t have access to the source code and need to do external/blind tests then you should cover the following above normal web application testing.

Coverage

In Silverlight there are typically 3 areas that need to be tested over and above a normal web application:

Deep linking
Isolated Storage
Back-end services

Deep Linking

Test for flaws in flow particularly authorization and data input.

Allows direct access to a page within Silverlight and could allow bypassing security such as authorization if authorization checks are only done at specific points.

For example: An application only checks authorisation on or just after the login screen, but application is deep linked to allow direct access to data read/write.

Isolated Storage

Same as any data storage tests however the special note is that it is client-side storage.

Questions such as:

What can be stored in isolated storage?
What can be overridden in isolated storage? For example, had the application stored files that can be overridden by the user?
How is that presented back to the user?

Backend Services

In web application usage cases Silverlight will commonly form the top tier / front-end and a backend web service will be responsible for some sort of data handling / storage.

Because Silverlight is a client-side technology web services if they exist are exposed to the client to, which is different to the usual server-side web application which may not need to expose these at all.

Web services should be aggressively tested using automated and manual tools. The normal tests of content type, size constraints, and performance are important. Also some fuzzing would also be good.  This all falls back to the generic web services testing is not Silverlight specific.

Tools

First Floor's Silverlight Spy can aid in investigating the isolated storage issues:
http://firstfloorsoftware.com/silverlightspy/download-silverlight-spy/

It is also sometimes helpful to review the xbap code of the app using ILSpy or .Net Reflector:
http://wiki.sharpdevelop.net/ILSpy.ashx

Try these for web services:

Are there any tools for automated penetration testing of Silverlight applications?

https://www.owasp.org/index.php/Fuzzing

Hope this helps.


Why is it not possible to capture a WPS handshake to WLAN

A Diffie-Hellman key exchange occurs before exchanging the sensitive information. Please see https://www.grc.com/sn/sn-338.htm . The relevant part:

"But it absolutely will encrypt the dialogue so that somebody just capturing the packet traffic is unable to, as I said last week, get the data, take it home, and crack the PIN offline. That can't happen because the dialogue is protected by this initial establishment of a secret key which doesn't authenticate, but it does give them privacy."

So cracking the 'handshake' as you call it (it isn't really a handshake), would be much much more complex than just performing a brute-force attack against the PIN, as this 'handshake' is encrypted with strong asymmetric encryption.


Is there any advantage to using encrypted DNS on a VPN server

I would strongly recommend using DNSCrypt and DNSSec directly on your client PC. There is no reason I can see to shift this to your VPN server, and it is probably a lot harder to set up. If you however for some reason have clients using your VPN, that would not be able/not know how to set these up themselves, then this may be worthwhile.


Which kind of SSL certificate is the big one?

This is an EV Certificate. You pay more for it, and you are rewarded with a green rectangle in some browsers.


Is it possible to find who posted comment on my blogspot anonymously?

I don't think that there is a way through what you have on Blogger if you have been allowing anonymous comments.

It would be possible for Google to track the IP; but even if they were inclined to react to an abuse report, they would not pass on that information to you.

There are indirect ways you could narrow things down if circumstances are right and if you want to spend a lot of time doing a lot of work for uncertain results. Let's call your anonymous comments, T (for Troll). If you can find other things around the net that T has posted (using the same phrases, style, etc) then you may be able to work from those. For example, if T is posting under some pseudonym on a forum that uses Gravatar (even if T doesn't), then you may be able to get an MD5 hash of the email address T used to sign up for that forum.  This sort of de-anonymizing is described here.

Or maybe T boasts about trolling you in some other place. Or something like that.

But these sorts of methods involve a lot of uncertainty. And if T is even half way experienced at this kind of thing, then then the IP is going to be through some proxy anyway, and any email address you find will be a throw away email.

It may be presumptuous of me to advise when I don't know the situation, but my inclination is to suggest that you just let it go. Don't let T's actions control your mind. Don't try to seek revenge. Just disable anonymous comments and let things go.


What is the correct crypto to use for a "Password Wallet", where decryption of the secret is needed?

There are two simple ways to do this.

The simplest is to have one wallet per individual.  If both Alice and Bob should be allowed to view a particular username/password combination, no problem, you just add it to both their wallets.  Each individual's wallet is encrypted using the passphrase that individual uses to open their wallet.

This is a very simple scheme.  Before you object that it requires storing multiple copies of some entries, I want to remind you that space is cheap.  The extra storage required is absolutely trivial.
Here is a slightly more clever, and slightly less simple, solution.  For each username/password combination, you pick a new random symmetric key K.  You encrypt the username and password under K.  Then, for each user who is authorized to read this username/password, you append an encryption of K under that user's passphrase.

For instance, suppose Alice and Bob are authorized to read the username/password "bloggerdude/fye7wi".  Suppose the passphrase that Alice uses for opening his wallet is PA, and the passphrase that Bob uses for opening his wallet is PB.  Then you might store the following entry in your wallet:

Encrypt(K, "bloggerdude/fye7wi"), Encrypt(PA, K), Encrypt(PB, K).

I don't think this has any strong advantages over the first scheme, but I thought I'd mention it for completeness.

Lastly, I'd like to mention a few other considerations you may want to keep in mind, as you design your wallet:

I suggest you use some mechanism to slow down dictionary attacks on people's passwords.  For instance, you might use PBKDF or the bcrypt password hash.
Use a random salt.  Never store any deterministic function of just a user password; that is vulnerable to time-memory tradeoffs ("rainbow tables", in the popular venacular, though it's broader than that).
You might consider providing an easy way for users to generate a new strong password, to add to the wallet, when they create an account on a new site and need a password to go with it.


Can a malware jump from a virtual to the physical machine?

Check this out : https://security.stackexchange.com/a/20341/11218

Ideally, the malware should not jump out from the VM to harm the host system. This is what virtualization software strive to achieve. But there have been demonstrated attacks of VM ESCAPE that shows how a malicious program can modify the memory of the host OS.

So, unless the virtualization software used is really old and un-updated, a malware wouldn't be able to jump to the host OS.


I guess you already know this, but you are in a precarious situation. Other malware you are not familiar with may have already be installed remotely.

To answer your question, certainly it is possible. Linux operating systems are commonly used as router/firewalls, and they can be run within a VM.

However, it may be simpler to customize the Windows Firewall, as that can be configured with filters on outbound connections by IP address. (not just listen sockets as is the default configuration)

Both of those run within the compromised machine so they could be bypassed.

The best solution (short of removing the malware which you should be doing) is to have a separated firewall device which you connect to with a direct cable connection. You should disconnect or power off the WiFi connection ability of your laptop.

Be sure to configure your Firewall to use a white-list (only allow known good IPs) and not a black-list (I think these are the only bad IPs so I'll block them) because you never know if it might try a different IP at some point. Sometimes malware is set for a delayed install.


Mitigations for Windows clients that don't support OCSP Nonces

Rook, Chrome on Windows uses CryptoAPI on other platforms they use NSS but NSS's revocation platform isn't "Faster" and doesnt send nonces (by default) either - its actually the least performant and robust revocation implementation of all the browsers.

There are a bunch of pending improvements to the NSS revocation behavior that should fix this in the near future.

We offer OCSP services for our products, one of the larger pool of responders on the internet; the number of requests we get with nonces approaches 0 (almost none).

makerofthings - Java applications will each behave differently, its possible to get Java to send nonces, sign requests, etc; its all up to the application.

As for the original request, there is limited protection to replays based on time (see security considerations in - http://www.ietf.org/rfc/rfc5019.txt). Supporting nonces also requires dynamically signing OCSP responses, Symantec issues 3 billion OCSP responses a day under normal load and this is with cached responses. Introducing dynamic signing would both be several orders of magnitude more expensive to operate (especially globally) but also expose them to a trivial resource consumption DOS.

Nonces make the most sense in the enterprise where signed requests also have a chance of working,  if you want to use them you should look at installing a revocation provider in windows like the Axway desktop validator.

@rmhrisk


What is required to ensure users' information being sent over my website is secure with the use of account log ins

Only provide the pages over HTTPS (most servers have a requires HTTPS option).  HTTPS will make an SSL connection that will protect the information in transit.  On the server side, what you need to do to store the information depends greatly on the type and sensitivity of the information, as well as how it will need to be used.

For example, is it information that the client will need to be able to later retrieve, is it financial information or PCI (payment card information)?  Do employees of your organization need to be able to access it?  Does the information need to be able to be shared with other (select) clients?


It is a mistake to try to focus on one architecture that will work for everything.  That just doesn't exist.  The solution has to match the problem and the requirements of a particular application.  So, my advice is: don't waste your time looking for a one-size-fits-all "architecture"; instead, look at some specific application's needs and seek a solution that will work well for that application.

If you want an end-to-end secure communication channel, use TLS.  No fancy security architecture is needed.  If that is not what you are looking for, you will probably need to edit your question to identify your requirements more clearly.

If your goal is to better understand some ways to secure web applications, then what you want is not "an architecture", but just a survey of work in this area.  In that case, you should also spend some time reading OWASP's materials.  You should also check out the resources linked to in Beginners materials for web security.  Another tip: use the "search" bar in the upper-right of this site, and you can find a lot more information about web security.

I would not start by reading standards documents.  They're probably not the best resource to start learning about this area.

P.S. I might be overly sensitive, but I have to admit I get skeptical if people get too focused on "architecture" rather than focusing on solving the problem.  So, just a small suggestion: you might want to start by identifying what is the problem you want to solve.  That will help you make sure you are focusing on a real problem.  Then, you can ask yourself questions like: what are the security requirements?  what are the resources that must be protected?  what's the threat model?  what are some available controls or mitigations that help address those threats?


Server certificate proving client identity

What you see is not how the certificate is used but how the certificate can be used. This certificate can be used and also is used to authenticate a server against a client. It can also be used as a client certificate to authenticate a client against a server - although it is currently not used that way.

Using the same certificate for server and client authentication is useful in cases where a system/application can take both client and server roles. This is for example the case when transferring a mail between two mail servers or when SIP (VoIP) devices communicate with each other (a call might be created by both).


Why does Microsoft Windows not allow special characters in file and folder names?

1) I want to know whether it is done to enhance security of the named files? If yes, how?

Well, most of the character restrictions are due to them being reserved to system functions. So I suppose the answer would be no.

Examples: vertical bar (|) is used on Windows to designate software pipelining, less than (<) and greater than (>) are used to redirect input and output, respectively, question mark (?) is used as a wildcard, etc.

There is a most detailed list of reserved characters on this Wikipedia article.

2) Is there any way to bypass this check?

Well, yes and no. As far as I know there is no way of using a slash (/) in a filename. Period. But, as pointed out by William Hilsum at this answer, instead of a slash (/) one could use a division symbol (∕), instead of colon (:) one could use the use the modifier letter colon (꞉), and so on.


How important is a dedicated SSL certificate vs. shared for eCommerce?

The "shared SSL certificate" actually translates in a visible form an underlying structural property, i.e. that Shopify is a shared eCommerce platform. When you use Shopify, your store is running on their systems. If that makes you look like a cheap business, then well, I guess you are a cheap business after all. The shared SSL certificate is just a technical point in which your cheapness is made apparent.

Technically, having your own name for SSL connection can be at odds with some constraints on Shopify's side. It is due to the following:

In HTTPS, the SSL occurs first; the HTTP request (which includes the target server name, as seen from the client) will be sent only when the handshake is completed.
During the handshake, the server shows its certificate to the client.
The client expects the intended server name (as it appears in the URL) to be part of the identities contained in the server certificate.

So a server who is hosting several (many) sites with distinct names on the same IP address must somehow guess the intended server name, so as to use the right certificate. Such guessing may use the Server Name Indication extension, if the client sends it -- but IE on Windows XP does not send any SNI. The consequence is that if Shopify wanted to support shop-specific server names for SSL, then they would have to do one of the two following things:

Allocate a new IP address for each shop (given the current relative shortage of IP addresses, this can become expensive).
Forfeit XP+IE customers (a non-trivial business decision).

In any case, Shopify is God: they have full control over your online store. The shared SSL certificate corresponds to that fact; it does not add any additional security issue.

(Said otherwise, you get what you pay for. If you want your SSL with your own name, then you have to own your own IP address, preferably your own server as well.)

Personally, as an occasional online customer, I feel rather safer when I see that the payment system is handled by a bank or some specialized platform like Shopify. That's because I know that 99.99% of frauds and other similar adverse events don't occur during the transit of the credit card number over SSL, but afterwards, on the server side. I really prefer it when professionals are at the command. Attackers don't bother trying to run fake SSL server to catch a dozen credit card numbers; they prefer hacking into amateurish servers to purloin thousands of credit card numbers where they were (poorly) stored.

However, I am known not to think like an average customer. That's the fate of being an information security professional, I believe.


Stop software updates after the system is "stable"?

In theory, what your professor is proposing sounds reasonable.  But there's a problem in practice.  You never get to a stable configuration.  Ever.

There is no non-trivial software out there that doesn't have unknown bugs.  None.  And some percentage of those bugs are security vulnerabilities.

What does the professor propose to do if someone finds a remote code execution vulnerability in the system after certification is complete?

Does he really believe it's safer to keep a system deployed with a known remote code execution vulnerability than to take the risk of a patch?

The answer (surprisingly) might be "yes".  And that goes to the heart of real-world security.  Security is really about risk management.  Every deployed piece of software has a certain amount of risk associated with that software.  The newly deployed software might break an existing line-of-business application.  It might introduce new vulnerabilities.

There's basically no way of knowing what might happen.  So you need to decide what your tolerance for risk is.

For some systems (often systems where someone's life depends on the system), it's actually better to keep the system unchanged (even if there are known vulnerabilities) and mitigate the vulnerabilities outside the system (with a firewall maybe).  For other systems, all you need to do is ensure that your line-of-business applications continue to work.

There is no one-size-fits-all solution here.  Every enterprise needs to make their own decision about the risk/reward trade-offs associated with a security patch.  Some will accept the risk, others won't.


Here is the difference between Implicit Flow and AuthCode Flow:

Implicit Flow

NOTE: As of April 2019, the Oauth Working Group no longer recommends the use of Implicit Flow for most cases because there are better, more secure ways to accomplish the same things.

User navigates to SPA, which redirects user to IdP to sign in.
User signs in (and authorizes the application, if needed).
IdP returns user to SPA with Access Token and ID Token.
JavaScript code in SPA stores the Access Token and ID Token in the browser's localStorage and sends the Access Token to the REST API server for every request it makes (usually as an Authorization: Bearer <access token> header).
If needed, REST API Server checks the validity of the Access Token by talking to the IdP. (Often, signing the token in the IdP and verifying that signature will be enough, and no communication is actually necessary.)

Authorization Code Flow

User navigates to SPA, which redirects user to IdP to sign in.
User signs in (and authorizes the application, if needed).
IdP returns user to SPA with Authorization Code.
JavaScript code in SPA sends the Authorization Code to a login endpoint on the REST API Server.
The REST API Server sends a request to the IdP Server containing the Authorization Code (and usually also a Client ID and Client Secret which identify the REST API Server to the IdP server).
The IdP validates the Authorization Code and sends the Access Token and ID Token to the REST API Server.
The REST API Server stores the Access Token and ID Token in its memory, and sends its own Session Token back to the SPA.
For every request the SPA makes to the REST API Server, it includes the Session Token which the REST API Server gave it. If the REST API Server needs to request resources from another server, it uses the stored Access Token to make that request.

You can see from here that the AuthCode flow is significantly more complicated than the Implicit flow, but with the benefit that the Access Token is never stored in the user's control.

However, the main point of storing the token in this case is not for your own authentication, but for the case where the REST API Server needs to talk to other services, such as Google, Facebook, Twitter, etc.

If you are only using OpenID Connect for logging into your own REST API Server, but then the credentials never need to be used by the server itself, implementing Implicit Flow is significantly easier, and implementing AuthCode flow doesn't actually gain you anything.


ROP Attack :Force the program to manipulate an instruction as a gadget

Short answer: yes.

Long answer:

Instructions on x86 processors vary in their length between 1 and many bytes.
(This works because no instruction can be a prefix of another instruction. Much like phone numbers. See this guy for the theory behind it.)

The CPU sees everything as bytes and does not know what the compiler intended, so if you point the instruction pointer at some executable memory, the CPU does not care as long as it decodes to a valid instruction. It will then continue executing until it encounters any kind of error.

Example:

  89 EB FE 40 C3

If you jump at the first byte you get:

  89 EB FE 40 C3 : mov EAX, 0xC340FEEB

If you jump at the second byte, you get:

  EB FE : jmp $, endless loop, will spin forever

If you jump at the third byte, you get:

  FE 40 C3: INC BYTE [EAX-0x30]

If you jump at the fourth byte, you get:

  40: INC EAX
  C3: RET

Look, a ROP gadget!
It increments EAX then returns.

Which is the "real" instruction the programmer intended? Who cares?

This whole concept is what makes ROP so easy on x86 processors. E.g. MIPS, where you cannot jump in the middle of instructions, it´s much harder to find good gadgets.


You don't need to go that much. Just install any Android emulator on your computer, install WhatsApp on the emulator, and start WhatsApp. When it asks your number, you can give your own number, get the authentication code via SMS and input it on WhatsApp inside the emulator.

The emulator is a VM, so it's a sandbox. If the primary concern is WhatsApp sending private data from the phone to Facebook, the emulator will have no private data. Just install only WhatsApp and nothing else, so there's little to no data to be leaked.


First we must consider that built-in machine architecture decisions impact the way you exploit these issues. For example, in the classical writing Smashing the stack for fun and profit by Aleph One, we can see that an x86 stack typically grows downward (i.e. the base for the stack is the highest address, and as we push onto it, the stack pointer decreases in value)...

  Depending on the implementation the stack will either grow down (towards lower memory addresses), or up. In our examples we'll use a stack that grows down. This is the way the stack grows on many computers including the Intel,
  Motorola, SPARC and MIPS processors.

So for example, assuming your compiler doesn't rearrange the order in which bufferA and bufferB are pushed onto the stack, Aleph One describes an architecture where-by bufferB actually has an address which is lower than that of bufferA. I'm pretty sure this explains your observations correctly; when you overflow bufferB, you're not actually overwriting the return address, but a part of bufferA (or some padding before bufferA). You could verify this by codifying your assertion, such that your runtime will validate it (by either succeeding or generating an error message), like this:

assert(bufferB < bufferA); // I'm asserting that in your case overflowing `bufferB` will result in modifications to `bufferA`.
assert(bufferA < bufferB); // You probably expect that overflowing `bufferB` into `bufferA` is impossible because of this condition... let's see which test passes?

You might need to #include <assert.h> to use assert.

Now having said all of this, there are many, many other issues standing in the way of successfully demonstrating a stack-based buffer overflow. Various protections have been created, such that the only reliable reproduction is typically referred to as a ret2libc attack, and that requires quite intimate knowledge of the specific hardware and OS configuration. As such, I recommend that after reading the paper by Aleph One (linked to above) and before attempting to reproduce that experiment, I highly recommend watching this DEFCON video entitled "(un)Smashing the Stack: Overflows, Countermeasures, and the Real World".

Once you've reviewed these two resources, I'm sure you'll have a much better chance of reproducing a stack-based buffer overflow.


Publish an image to github with rsa keypairs, what are the security risks? (NOT PRODUCTION)

Must assume key harvested on upload. Suggest first-run-script.
There seem to be bots that filter for Amazon EC2 keys on GitHub
Therefore I would assume that your RSA keys will be harvested by a similar bot. As soon as you upload the image.

The whole thing is meant for labbing and tutorial purpose, NOT production.

This has never stopped people from deploying.
If you want more peace of mind, then incorporate a technical antidote to this.
Like a first-run-script that does individual key generation upon first startup. (Either for SSH pubkey-auth or SSH password-auth.)


Why is the OS obfuscation defense against "It's a Unix system!" not widely implemented?

Before I tear your idea apart, let me say that it's a really interesting idea and it was super fun to think about.
Please continue to think outside the box and ask interesting questions!
Alright, let's do this!

Let's take a step back and ask why that baby monitor is running Linux in the first place? What if there was no operating system and the application was written in bare microcontroller code (think arduino code)? Then there would be no sudo or ls or even a shell for the attacker to use, right?
I'm not an expert here, but I expect that we, as an industry, have gravitated towards putting Linux on anything big enough to run it largely for developer convenience:

Reducing dev time: When building your WiFi-and-bluetooth-capable web-administered cloud-syncing self-patching whizpopper with companion Android and iOS apps, Linux comes with all the libraries, utilities, and drivers you need to do that.
Increasing testability: If the device is running bash or busybox with an SSH port, then it's super easy to connect in and figure out what went wrong during your product testing phase.

For your obfuscation idea to work, you'd need to obfuscate not only the names of command-line utilities like sudo and ls, but also every Linux kernel API to prevent the attacker from dropping in their own compiled binary that calls the kernel directly. So let's take another look at your idea:

Implementation would be fairly easy for compilers. Take the simplest case of "rename this function and all calls to it." You could give an OS compiler and an application compiler the same randomized names and they'd be able to talk to each other.

You'll need to do this randomized compilation yourself; otherwise someone could look up the mappings on google.
So, you'll need to build the kernel from source with your "obfuscating compiler" so that only you know the mappings of the obfuscated kernel APIs. (ever built the linux kernel from source? It's certainly more of a chore than docker pull alpine, which is the direction that dev culture seems to be going).
But an operating system is more than just the kernel. You want drivers for the Broadcom BCM2837 wifi chip that comes on that mini-pc device? You'll need to build that driver against your obfuscated kernel with your compiler, if Broadcom will even give you the source code. Then you'll need to build the entire GNU wifi and networking software stacks. How many other things will you need to find source for and add to your build pipeline before you have a functioning OS?
Oh, and if the upstream repos of any of those things issues a patch, you're now responsible for re-building it (assuming you saved the compiler obfuscation mapping files that match your kernel binary) and pushing it out to your devices because - by design - your devices can not use patch binaries produced by the vendor.
Oh, and in order to foil hackers, there'll be none of this "Here's the binary files for Whizpopper 1.4.7", oh no, you'll need to build a uniquely obfuscated version of everything from the kernel up per device that you ship.

So to your questions:

Is OS obfuscation as described used widely and I just haven't encountered it?
If not used widely, what are the practical or technical barriers to usage?

I think the answer is that what you're describing pretty much completely defeats the purpose of using pre-existing software components if you need to find and build literally everything from source. It might actually be less effort to ditch the operating system entirely, pretend it's 1960, and write your application directly in CPU microcode.
I like security more than most developers, but like f* that.


Is persistence via scheduled tasks possible if the user is not elevated?

It is possible to use schtasks.exe without elevation, though you can't create tasks for other users without knowing their passwords, or for system accounts without knowing an admin password. For example, the line schtasks /create /sc once /st 14:08 /tn testcalc /tr calc.exe, run from a non-elevated prompt, successfully popped calc.exe for me at the expected time. It's possible it wouldn't have worked if I wasn't a member of the Administrators group at all, but I doubt that; unless there's a bug in the way schtasks considers permissions, it shouldn't have "seen" the Administrators group membership on my security TOKEN, since for a non-elevated process that group is only present in the DENY list (I can't do something if admins are prohibited), not in the ALLOW list (I can't do something even if admins are permitted).


Tracking IP address to prevent abuse without logging user metadata

Lets say you need to view the IPs over a 30-minute period to decide on abuse. Here is a scheme to keep the IPs no longer than one hour.

Every 30 minutes, generate a memory-only random string, RS.

For any time period, keep the current and previous RS: rs_c, rs_p.

For every IP, compute the current hmac using the current random string:

IP_c = HMAC(rs_c, IP)

Store the IP in a table:

IP_c, last-update

Compute the ip count over the last hour.

func get_ip_count(ip):
  IP_p = HMAC(rs_p, IP)
  IP_c = HMAC(rs_c, IP)
  count = [select count(*) from ipHistory where IP in (IP_p, IP_c) and last-update < [30-minutes-ago]]

As long as you can protect the RS, you'll not recover the IPs for more than your sliding window.

Clean the table based on last-update/age.

delete from ipHistory where last-update < [30-minutes-ago]


How does Look Out Secuirty and Anti-Virus determine if an app is harmeful?

Exploits often have very distinct signatures.  For example, z4root uses exploits to gain root access to a device.  These techniques for privilege escalation can be known to an anti-virus program, an flag any app that contains similar API calls.

Lookout uses some advanced techniques.  For example, it can determine the difference between adware, and an app with advertisements.

  Displays advertising outside of the normal app experience
  Harvests unusual personally identifiable information, or
  Performs unexpected actions as a response to ad clicks; appropriate user consent entails providing a clear alert in the application that
  allows the user to accept or decline before any of the above behaviors
  takes place

For runtime checks, it can observe dynamically generated content.  For example, I could write a malware program that intends to send data to http://evil.example.org.  If I hard coded that into the app, it would be flagged by their domain filters before being installed.  If I instead set up a server at http://imnotevil.com, that would return a redirect to http://evil.example.org on the third request from an IP, it would need to be checked at run time.

I recommend reading their blog for the various exploits they've discovered.


Getting confusion that this responce indicate CORS vulnerability

Access-Control-Allow-Origin: *

This is only a vulnerability of cross-origin requests from everywhere should not be allowed. But an application might explicitly be designed to allow cross-origin requests from everywhere  - in which case this would not be considered a vulnerability.

Since nothing is known about the specific application it cannot be said if this is a vulnerability or not.


What is the strategy used by the itunes store and Google Play to protect and securely install applications on eligible devices?

I'm more familiar with iOS, so I'll focus on that.

All iOS apps are signed.

When connecting to the App Store, the iPhone uses the Secure Transport API, which means you're using TLS.

I'm not quite sure what you mean by strategy, but yes the apps are transmitted securely, and are signed by Apple.


Can I use elliptic curve DSA in a secure message service?

ECDSA is a signature algorithm. The private key for ECDSA is an integer x between 1 and n-1, where n is the size of (the subgroup of) the used elliptic curve (normally a prime number). The public key is a curve point Q equal to xG, where G is a conventional fixed point on the curve.

You cannot use a signature algorithm for anything else than signing, of course, but it so happens that there is a key exchange algorithm called ECDH which uses public/private key pairs with exactly the same format. In that sense, it is technically feasible to use the same key for ECDSA and ECDH. Key exchange can be used for asymmetric encryption through hybrid encryption (you use the exchanged secret as basis for symmetric encryption); in the case of ECDH, this process has even be standardized under the name ECIES.

However, using the same key pair for signature and encryption is not a very good idea. This is frowned upon by many cryptographers and standards; it is a capital offence in the world of risk analysis and certifications. There are two main reasons for that:

Signature and encryption keys have distinct life cycles and call for distinct, incompatible management methods. In particular, you usually want to have a backup or escrow of your encryption private key, and you certainly do not want such a backup or escrow for your signature private key. See this answer for a discussion.
Interactions between different cryptographic algorithms have not been thoroughly analysed. We do not really know whether using the same private key for both ECDH and ECDSA may put either at risk (e.g. allowing an attacker to forge a fake signature by engaging in some ECDH with you, with niftily crafted DH messages, or something like that). Remember that any given cryptographic algorithm can be deemed secure only because it has sustained scrutiny from many cryptographers for several years; interactions between ECDH and ECDSA cannot boast such an amount of review.

When in doubt, abstain. And, in this case, you should doubt. Really.


How big a vulnerability is phone number theft and how to protect against this?

There's a number of ways that someones number can be acquired by attackers. Perhaps the victim has it, and their email address exposed publically on Facebook, or Skype, or LinkedIn. Or perhaps that data has been leaked in a data breach and then sold and shared by Criminals.

In my opinion, the root problem is that the phone companies employee(s) broke procedure and transfered someones number to another sim without proper authentication. Those procedures are in place for a reason, but the attackers socially engineered the operators into breaking them.

I can't say exactly how widespread the practice of sms recovery is, I believe its fairly widespread, as its nice and easy for an average user. The article mentions Facebook, Twitter, and Google, and I know LastPass does it too. The first three are very big players on the internet, so that suggests it would be a widespread practice as others follow their example.

To avoid it, we can either hope that phone companies change how they work so this becomes impossible (or at least a lot less likely). You can also limit the exposure of your phone number, or have a specific phone number on a pay as you go sim in a 'dumb' phone (an old one like the classic Nokia 3310) that you only use for account recovery. Finally, while this won't be applicable for every website, you could also try enabling alternative methods of account recovery.


sql injection, exec and preg_replace filter

The only sure way to guard against SQL injection is by using parameterized queries. See: SQL Injection Prevention Cheat Sheet by OWASP.


Suspicious VMware connections that bypass firewall

If netstats says it is established I'm inclined to believe that it is correct. I would suspect that your firewall setup is at fault.


An overt channel is a communications path that is not hidden.  Anyone can see that Steve connected to Stack Exchange.

A covert channel is an intentional communications path that is hidden, using a technique like steganography.  This might use a technique like a dead drop, where I post a picture on eBay, you view the posting on eBay, but nobody can easily see that John sent a picture to Steve.  That picture might then contain a hidden message, either encoded in the bits of the photo, or in a prearranged meaning of the photo:  "if I post a picture of a teapot with the spout pointing left, that means attack at noon.  If I post a picture of a teapot with the spout pointing right, that means attack at midnight.  If I post a picture of a teacup, the plans are on hold."  This is an example of a covert storage channel.

Another type of covert channel can be created by hiding a message by varying the timing of otherwise normal communications.  Imagine a streaming video that is "suffering" from occasional interruptions in the stream; it would be easy to imagine it's just a system load problem.  The timing of the interruptions could be used to convey information:  a long pause followed by a short pause could be interpreted as the Morse Code letter 'N', for example.  That is a covert timing channel.

The primary differences between these two types is that a storage channel leaves some evidence behind but doesn't require the recipient to be listening for the message; a timing channel leaves almost no trace of its existence, but requires the receiver to be actively listening to receive the hidden message.

A side-channel is typically a case of unintended information leakage, and not the intended means of communication.  Common cases are RF emissions from keyboards or monitors (google for TEMPEST to see examples of this), timing differences (this paper: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf documents a timing attack on SSL), or power consumption differences (see the paper available at this address:  https://www.rambus.com/differential-power-analysis/ ).  Sometimes these differences can be used to discover enough bits of an encryption key to break the encryption.


I think that you are trying to fix a problem that doesn't really exist?

Typically, individual files would be encrypted using either a stand alone tool such as WinZip or an integrated tool such as Bitlocker. In the former case, the encryption key IS based on a passcode but one that the person encrypting sets and then shares. In the later case, the file will be encrypted locally when stored in a filing system controlled by the application. Then the user sets the passcode. Each has benefits and disadvantages. You can, of course, combine both approaches.

There are other, more complex approaches to this problem but they require a degree of cooperation and trust between the originating and the receiving systems. Microsoft Azure Rights Management is a good example of this.


SQLmap works in a heuristic way, firstly it learns about difference about good and bad response from the application, then you have to introduce a real value for username parameter to get a good response, SQLmap will analyze the responses after that it will inject sql commands to detect a possible SQL Injection. Your SQLmap command must be something like this:

sqlmap -u http://thehost/include/login.php --data "password=letmein&username=this_is_a_real_username" -p "username" --dbms=mysql

The option --method POST is not neccesary, SQLmap knows it's a request POST when you use the option --data.

I hope this information helps you.

Good Luck.


What are the penal consequences for a passive or active scan on a WebApp with no damage?

Sepcifically since you mentionned France: it is illegal to access, modify, maintain your presence in, or delete information in systems you don't have the authorisation to do so.

Furthermore, the attempt to do such an act is punishable as if you did it (no matter how successful it was).

You can expect something like : 150k euros, 5 years in prison (as mentioned on legifrance)

In general, the rule applies differently depending on the country you're attacking from and the country you're attacking in, you could be held liable under multiple jurisdictions or jurisdictions different from you're own. Ask an expert.

As to the last part of your post, having no one convicted of something does not mean it's legal, or that no one will be convicted. In this case, it might just be too costly, or difficult to prosecute, but it could change.


How to GET security answer values via AJAX for user edit

Is the best choice to use some fake text to show in the box and then
check that fake text on save?

Yes, this sounds like the way to go.

This option doesn't show the true number of characters for what they
originally typed in. Is there a better method?

I would see that as an advantage. I would see little benefit in revealing the number of characters in the original answer.
I would also be tempted to store these answers in my database using something like bcrypt. This depends if there is any requirement for the answers to be verifiable by a human (e.g. in a call centre to authenticate the user). If not you could uppercase the answer and strip all non-alphanumerics. This would allow correct answers to be easily entered by users, with a small increased risk of hash cracking by an attacker (e.g. if they enter "Foo Boy's School" as opposed to "Foo Boys School" because it would be stored as FOOBOYSSCHOOL). Iterations could be increased though to account for this as this information should be used rarely. This would mitigate a situation where your answers table is exposed to attackers where they could then use them to carry out a password reset.
Again, this depends on how any password reset mechanism works for your system and your level of acceptable risk.


The aluminium coating of the CD reacts and creates plasma. So it burns the CD effectively. Below you can see the image of a microwaved CD. It's safe to say it's been destroyed.


I need assistance in properly understanding the IA-7 control in NIST SP 800-53

Waking the zombie at my own peril and for the benefit of people looking to understand this control.  I did a fair amount of research on the subject and was able to find a pretty definitive answer.  Stay with me because it isn't short, but it's pretty definitive.

As best I understand it, if you are an implementor of a cryptographic control module that provides an authentication mechanism or if your system provides access to a cryptographic control module that provides authentication then you must meet the authentication requirements "...of applicable laws...standards..." etc.  This reference is calling out the requirements in FIPS 140-2 which refer to a human operator interacting with a FIPS 140-2 compliant cryptographic control module.

  4.3.3 Operator Authentication Authentication mechanisms may be required within a cryptographic module to authenticate an operator
  accessing the module and to verify that the operator is authorized to
  assume the requested role and perform services within that role.
  Depending on the security level, a cryptographic module shall support
  at least one of the following mechanisms to control access to the
  module:

  Role-Based Authentication: If role-based authentication mechanisms are
  supported by a cryptographic module, the module shall require that one
  or more roles either be implicitly or explicitly selected by the
  operator and shall authenticate the assumption of the selected role
  (or set of roles). The cryptographic module is not required to
  authenticate the individual identity of the operator. The selection of
  roles and the authentication of the assumption of selected roles may
  be combined. If a cryptographic module permits an operator to change
  roles, then the module shall authenticate the assumption of any role
  that was not previously authenticated.

  Identity-Based Authentication: If identity-based authentication
  mechanisms are supported by a cryptographic module, the module shall
  require that the operator be individually identified, shall require
  that one or more roles either be implicitly or explicitly selected by
  the operator, and shall authenticate the identity of the operator and
  the authorization of the operator to assume the selected role (or set
  of roles). The authentication of the identity of the operator,
  selection of roles, and the authorization of the assumption of the
  selected roles may be combined. If a cryptographic module permits an
  operator to change roles, then the module shall verify the
  authorization of the identified operator to assume any role that was
  not previously authorized.

...so that's what this rule is talking about.

This control is only applicable if you're providing authentication to the cryptographic module for purposes of managing the cryptographic module.  Evidence that it is not applicable in other cases can be found in a STIG (although not easily)...

https://www.stigviewer.com/stig/application_security_and_development/2018-09-13/finding/V-70159

  Details Check Text ( C-70635r1_chk ) Review the application
  documentation and interview the application administrator.

  Identify if the application provides access to cryptographic modules
  and if access is required in order to manage cryptographic modules
  contained within the application.

  If the application does not provide authenticated access to a
  cryptographic module, the requirement is not applicable.

  Review and identify the cryptographic module. Refer to the NIST
  website listing all FIPS-approved cryptographic modules.

It seems like an uncommon use case in the private sector but may be more common in government sectors like DoD.


Why aren't application downloads routinely done over HTTPS?

Because HTTPS is not very well suited to securing downloads of large public files. For this use case, it's slow and not that useful. There are reasons for not using HTTPS well beyond incompetence or unawareness.

HTTPS doesn't fully solve the problem. This If you're getting your application straight from the vendor's website, HTTPS does ensure the authenticity of the application. But if you're getting your application from a third party (e.g. mirrors of free software), HTTPS only protects the connection with the third party. A package signature scheme works better: it can protect the whole chain from the vendor. Application distribution requires end-to-end protection and HTTPS doesn't provide that.

HTTPS uses more bandwidth. The overhead per download is minimal if you don't take caching into account. This is the spherical cow of “HTTPS doesn't cost more”: if you use SSL, you can't cache data except at the SSL endpoints. Application downloads are cachable in the extreme: they're large files that many people download.

HTTPS is overkill. The confidentiality of an application download is rarely an issue, all we need is authenticity. Sadly, HTTPS doesn't provide authenticity without also providing confidentiality. Authenticity is compatible with caching, but confidentiality isn't.

HTTPS requires more resources on the server. Google mail got it down to a 1% overhead and a 2% bandwidth overhead, but this is for a very different use case. The Gmail frontend servers do more than mindlessly serve files; a file server doesn't need a powerful CPU in the first place (it's very strongly IO-bound), so the overhead is likely to be significantly larger. The same goes for memory overhead: a file server needs very little memory per session in the first place, almost all of its memory is a disk cache. Getting the resource usage down requires a serious amount of work.

HTTPS wouldn't help many people. The security-conscious will check the hash provided by the vendor (that should be over HTTPS). The non-security-conscious will blithely click through the “this connection is insecure” message (there are so many badly configured servers out there that many users are trained to ignore HTTPS errors). And that's not to mention dodgy CAs who grant certificates that they shouldn't.

If you want to make sure that you're getting the genuine application, check its signature, or check its hash against a reference value that you obtain with a signature (for example over HTTPS).

Good vendors make this automatic. For example, Ubuntu provides GPG signatures of its installation media. It also provides the hashes over HTTPS (sadly not linked from anywhere near the download page as far as I can see). After that, the software installation tool automatically checks that packages come with a valid signature. See How to use https with apt-get?

Note: if you're getting the application directly from the vendor (as opposed to via some package repository or application marketplace), then HTTPS does provide protection. So if you're a vendor providing your application directly for download on your website, do protect it with HTTPS!


How to deal with this fundamental problem with the advice: "Don't trust obscure PHP libraries that nobody uses!"?

You say that you don't have a choice, but that's not true. You could write all the code you need yourself. Or you could pay a trusted professional to write the code for you. Or you could could pay a security firm to audit the code before you use it. Or you could accept the risk, and implement other security controls to mitigate the risks. For example, if you are afraid that some code might be vulnerable to SQL injection, you could set up a WAF (Web Application Firewall) in front of it.

Security has a cost: time, resources, expertise, money. There's no free lunch. If you can't afford it, you'd have to either avoid the problem (rethink your project), or delegate it (somebody else will deal with it), or mitigate it (for example with defense in depth) or just accept the risk that you might get hacked.

Personally, in your case, when you have to deal with code that is not widely used, if the library is not too big I'd try to read the code, at least to check if there's any "code smell". Even if you don't check all the logic, it's easy to check if there are enough comments, if they make sense, if the code is clean and understandable, if certain functions are used according to best practices, if there are checks on the input data, etc. The risk of code used by only a few people and maintained by only a few developers is also that it might stop being maintained, or maintenance turns out to be too slow anyway, so at the end of the day you might be forced to read and understand the code anyway, to fix your application.Then if possible I'd also try to implement something for defense in depth, although configuring a WAF correctly might not be easy, if you really want it to be effective and at the same time avoid breaking your application because of false positives.


Clickjacking vulnerability of file attachment downloads?

My verdict
You can't have clickjacking on static pages as a valid or pertinent vulnerability, it won't hurt me atleast to skip those headers intentionally on static pages like that of attachments unless it's an API endpoint or so.
Professional Advice
Hell yeah it's the false positive and the sole reason why you are advised to go for bug bounty programs for your company and advised against running automated scanner, not even netsparker which costs a few thousand dollars. If you chose the latter option, do teach yourself the basic skills to understand what's a false positive and that these scanners have much lower precision than manual testing techniques.
No it isn't a vulnerability. Clickjacking by industry standards of the day, requires an attacker to be able to exploit it from the point of view of being able to coerce the user into performing a state-changing action in user's context. Judge the fact by Google's BugHunter university which states clickjacking which can have a state-changing impact on user account is only eligible for their VRP.
What's a valid attack scenario like strictly in technical terms?
So let's say attacker can make the frame hidden beneath a button, now makes unknowing user click on that button and this leads to the user deleting all his data and account. Then yes, it's a valid attack vector and is of P4 priority to an average security engineer like me.
Further clarification
Ask yourself again, can it be used for phishing by an attacker or can he accomplish something useful by embedding an attachment within a frame or iframe, can he record the keystrokes of victim user with the help of embedding the attachment in an iframe? Well the straightforward answer to it is no , not.
Further, you can go and read my article https://dzone.com/articles/looking-at-some-practical-examples-of-security-bug on DZone which was distributed to thousands of developers via weekly digest. It must be a good read for you, just ignore the typos their editorial team made.


Secure and fast communication between 2 VM's

If two machines (virtual or not) must be made to communicate with each other, then establishing a VPN between them cannot harm; by definition, the VPN aims at emulating an isolated set of wires between your two hosts (hence presumably free from hostile eavesdropping and interference) so that arbitrary traffic between the two machine becomes "secure". OpenVPN has good reputation and is free, so using it is not a bad idea. Alternatively, if the applications which must talk to each other can handle their own security (say, SSL), then that is also applicable; the VPN, though, is probably simpler to set up, and more comprehensive.

As others have said, if your machines are VM, then the cloud provider is God: if he wishes so, he can technically see all your secrets and alter them at will. The provider is thus trusted. So the provider cannot be an attacker, and must be assumed not to fall under hostile control. Under these conditions, if the provider can set up a "private link" between your two machines (a VLAN, indeed), then that's fine. The security of the VLAN is strong as long as the actual wires and routers of the provider's network are clean and honest, which is, as I just wrote, a core assumption of the Cloud model.

Now, of course, there can be a subtle difference between "the service provider is honest" and "the service provider is honest and competent". A small configuration mistake (the dreaded human error) can put third party systems onto your VLAN. There again, running your own VPN can add protection against the provider's vagaries (it would not stand against provider's malice, but incompetence is much more common than wickedness).

Edit: I forgot the classic argument about performance. It goes thus:

Performance issues do not exist.
Performance issues do not exist until duly measured.

So if you fear performance issues, then the only sane way is to try, and see if the fears were justified or not. One can make a priori estimates but this requires some intimate knowledge of both the behaviour of involved algorithms and of network protocols and latencies; you cannot realistically hope to get decently accurate estimates unless you are highly competent in cryptography, low-level programming and TCP/IP internals. Trying out and quantifying issues is a much better way; more often than not, alleged performance issues happen to be non-existent (but other, unpredicted performance issues may unexpectedly appear). If you want to make benchmarks on OpenVPN, you should first read what has already been done on the subject, namely this page.


Where should a team store server credentials

Your issue is quite common and in general referred to as Privileged Account/User/Identity Management short PAM/PUM/PIM/PxM.

Keepass for sure is a solution used quite often, but from security, compliance and audit perspective not the best one. Since you are a team of five it's hard to tell if you have to comply with any policies. But if you have to, a commercial solution would be something to look into. It addresses more than just the password management and sharing passwords across a team, but also individual accountability, reporting and such.

So really it depends on your requirements, what way to go.
From my experience I can tell you that there are many different ways used in enterprise environments, starting from paper in a secure location, down to files on shares. Especially regarding files on shares, e-mails or other 'online' storage always remember that there might be some administrator being able to access those who is not intended to.

HTH.


Is it possible to "reverse engineer" identicons?

It used to be possible, as Gravatar identicons are a graphical representation of the MD5 hash of an encoding (trim leading and trailing whitespace and convert letters to lowercase) of your email or IP address. Both of these things are small enough to make brute force feasible. Nowadays, Gravatar includes a secret salt in the hash operation, making it impossible to even attempt to brute force them without knowledge of that secret. The secret is stored somewhere on the Gravatar servers. If someone was able to obtain that secret, they would be able to brute force the email or IP address.
Note that Stack Exchange's Area 51 site still does not use a salt, unlike the rest of the network.


Getting a certificate warning for one email but not another

What I can see, is that the main difference is not about "SHA1" but about the certificate chain. See the icons. Both "SHA1" messages are locked with a green icon, but the part about about the identity of the website is different.

GOOD: *.mail.live.com . Certification owned by Microsoft, verified by Symantec Class 3.

According to digicert.com, no error or warning was found in the certificate. Not sure why no warning is displayed about the use of "SHA1".

Issuer: (Extended Validation : EV)

Symantec Class 3 EV SSL CA - G3
VeriSign Class 3 Public Primary Certification Authority - G5

BAD: outlook.live.com . Certification owned and verified by Microsoft. Probably the certificate is not correctly set or recognized by Chrome (see issuer).

According to digicert.com, it found 1 warning: SSL Certificate uses a deprecated signature hash.

Issuer: (Organizationally Validated: OV)

Microsoft IT SSL SHA1
Baltimore CyberTrust Root

So I strongly think that there is a small recognition problem of the chain issued by Microsoft itself.


The Python manual comes with a warning about the pickle module:

  Warning The pickle module is not secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source.

This warning should be taken very seriously. If you unpickle untrusted data, an attacker will be able to exectue arbitrary code on your system. That is bad. Very bad.

The key part of the quote here is "untrusted or unauthenticated source", though. If you are just loading a static file that you trust no malicious actor would have control over, unpickling is safe. For instance, if you store the file together with your source code and with the same access restrictions, an attacker could just as well modify the source code as the pickle file. So the unpickling does not have to be a security risk.

What if you can't trust the file? You have two options:

Switch to a format not vulnerable to code execution, such as JSON.
Create a restricted unpickler using the find_class method (see the manual).

My guess is that #2 would probably be quicker to implement as it requires less changes in your code. But it is also a risky strategy, as I suspect that it is very easy to make a minor mistake opening you up to a vulnerability. If you want to minimize the risk, I would go with #1.


What is the purpose of a targeted email without any meaningful content?

Attempting to send a message to a non-existant email address will typically result in a “bounceback” message with an error code like 510 or 550 invalid address. If you try several addresses and there is no error message for only one of them, you know this one actually exists.
Someone who has a mailbox on a corporate email server also probably has access to multiple other systems or services, possibly with the same user name. The sender now has the name/handle of an account they can target on these systems.


Is super paranoid use of HaveIBeenPawned password API going to help?

To answer your specific question - "is super paranoid use of Have I Been Pawned password API going to help?" - yes, it is. Question is by how much and whether it's worth the effort to reduce the risk. But you make a lot of assumptions that are worth addressing:

You assume that you're using a weak password. Almost without exception, every password in Pwned Passwords is weak. One of the primary reasons is that they're often sourced from cracked hashes and strong passwords (generated by a password manager or a pass phrase)
You assume you're reusing passwords. If you're creating a unique one on your login portal then it's never going to appear in Pwned Passwords.
You assume you're publicly exposing a login portal to the world from your home IP address. There's a whole bunch of reasons why you really don't want to do this.

Thing is, if you're doing point 1 and point 2 (which you most definitely should be), there's no real value in Pwned Passwords anyway. So do that - create strong, unique passwords - and don't hit HIBP at all! And if you really, really want to check password exposure without sharing even a hash prefix, download the data for free and check it locally: https://haveibeenpwned.com/Passwords

BTW - When you say "they", it's actually just me


Which files are more insecure than others?

Typically the "insecurity" of files comes into play when they are accessed, not just by having them downloaded. Downloading a file unopened and having it pwn your computer is the stuff of Hollywood and science fiction (as far as I know, though there may be research into this too).

Thus, to understand the problem, the real question is not about the file types, but rather about the typical programs commonly used to access those files.

Thus, a .txt file should be relatively harmless, since it's accessed in raw form by simple text readers and not recognized as code in any way. (Though of course a 0day vuln found in e.g. Windows Notepad could change that....)

PDFs and Office docs are typically opened by Adobe Reader and MS Office programs, respectively - and these all recognize numerous types of dynamic content, e.g. Office Macros. Furthermore, there is a whole lot of data handling, parsing, translating, activating, and rendering going on, and there can be (and are, and were) many different vulns at each step of the way, in each of those programs (and of course others).

Same thing goes for media files - JPEGs and GIFs can have hidden code (see GIFAR), movie files can have embedded codecs, etc.

Of course, executable files and code (compiled or not) are the most dangerous, since they are trivially exploitable - the code is already there, and the user explicitly asks to excute it. This includes, e.g. on Windows exe, dll, com, bat, htm/html, js, vbs, jar, etc.
Of course source code (.java, .cs, .vb, .c, .cpp, etc) can also be an issue, since these are typically passed directly to a compiler - arguably one of the most complex pieces of common software - and gives execution instructions, not to mention the later output... It is not too complicated to obfuscate malicious code.

Choice of OS is not necessarily the most important factor here, though of course different files will execute differently on each OS - and each OS has its own share of unsafe filetypes.
More importantly, is if/when a malicious file is executed, what kind of damage can it do? An OS that defaults to minimal user privileges (compare Win7 to WinXP), will of course be that much safer.


Methodologies for test & benchmark of Antivirus Software

As for test environments, there are several open source mechanisms that combine given mail server with one or many antivirus engines. You can analyze them and reimplement invoking each engine in your own environment to scan a file.

As for test data, look at http://vxheaven.org/ website for samples.

And yes, you should use virtual machines instead of running anything possibly rogue on your production systems.


How is it possible that a virus can infect the system if the browser is started with non-admin rights

No virus is possible if the browser has no bug.

No escalation to admin rights is possible if the OS has no bugs.

Unfortunately, bugs happen... in both the OS and the browser. Vulnerabilities which allow a non-admin process to gain admin rights (e.g. this one) are rather common, and it is usually assumed that getting through the browser is the complex part, not obtaining admin rights. Also, with "only" the rights of the user who runs the browser, the malware can plunder your cookies and your data, and grab your site passwords when you type them; this is already quite damaging.


Is Session Fixation a tough one to resolve?

Question 1: Why this is happening?

Your session is only bound to a session cookie, not to the IP or any browser details. This is entirely common - even Github does that. (Using additional properties to bind the session can have undesired consequences, e.g. it could lead to random logouts when a user updates their browser or changes their IP.)

  Question 2: Probable way's for resolve this issue.

It's not a major security issue. Copying cookies from one browser to another requires access to a browser's cookie storage which an ordinary attacker doesn't have. If you still want to ensure that a user can't reuse their session in a different browser you could bind additional properties, e.g. invalidate a session as soon as the User-Agent header changes.

  Question 3: Is this even a session fixation vulnerability?

No, it's not. In a session fixation attack you force a known session ID on an (unauthenticated) victim. This ID remains valid after the victim logs in so that you can reuse it to be authenticated as the victim yourself. But without an additional vulnerability there is no way to inject the session cookie into the victim's browser in the first place. The OWASP page on it has some examples that show which possible preconditions can lead to a session fixation vulnerability.

  Question 4: Should I report it to their bug bounty program?

Most likely it's out of scope. With the hordes of bug bounty hunters you have to expect that issues like these are already covered on high-profile sites and if they persist it's by design.

  In some cases, I am able to login into second browser even after logout from first browser.

A logout should invalidate the current session but not necessarily terminate all other active sessions. Just because you log out from Github on your phone, you don't necessarily want to be logged out in your browser, too.

This demo shows on the example of Github that copying the same session cookie from one client to another is often permitted:

Login on Github.
Copy user session cookie user_session from the browser's cookie jar. (You can't do it with JS because the cookie is HttpOnly.)
$ curl -b "user_session=[your session id]" https://github.com/
You will find that the HTML response is still authenticated. (You should see your own username and your repositories in the code.)


How to prevent bypass of user agreement window

Whether or not this is a cyber crime depends on the jurisdiction you and them are in, and even then it is a topic for law stackexchange. So I am not going to talk about that.

If you want to make sure that only users which at least saw the user agreement can download a file, you need to give them (or rather their web browser) a secret together with the license agreement.

Don't have the user agreement page set a simple 0/1 token.

When you generate the user agreement page on the server, randomly generate an unique token for each page impression. Put that token both into a hidden input field on the agreement-page and store it in your database.
Have the submit-button below the agreement also submit that token
Have the download-page check if that token is in the database. If it is, allow the download and delete the token from the database so it can not be used again.
(optional) regularly purge tokens from your database which weren't used within X hours to prevent your database form getting too large and slow due to unused tokens accumulating in it.

By the way, this is also a good precaution against bandwidth stealing, because deep-links directly on your downloads won't work. Anyone linking to files on your website will have to link at least to the agreement page.


This excellent guide by @SwiftOnSecurity lists multiple notable services where you can report the malicious script to.

  VirusTotal.com (Shares reports publicly, shares files with Premium subscribers)
  Hybrid-Analysis.com (Shares reports and files publicly, uses Payload Security's VxStream sandbox)
  Malwr.com (Shares reports and files publicly)
  Microsoft (Select 'Home User')
  Webroot (Detections and threat intelligence go to multiple other products)
  Kaspersky
  ClamAV (Especially for files that came through email, used in many spam filters)
  Emsisoft


How isolated are 2 operating systems on 1 harddisk?

Well, they aren't isolated at all if they can both see the hard drive.

You are correct that they both should have their own anti-virus solutions though.


Is there a reason why /proc/interrupts is world-readable?

It's world-readable now because it was made world-readable when it was created twenty years ago or so. I haven't researched the history (which probably exists only in Linus Torvalds's head anyway) but it's likely that this file is world-readable because there's no obvious reason to make it so. After all, it doesn't contain any confidential information: just some system configuration and some performance statistics...

The subtlety is that while taking one snapshot of /proc/interrupts is harmless, reading it in a tight loop isn't, because that reveals the rate of keystrokes which in turn leaks quite a bit of information about what was typed.

Side channels didn't get much attention outside of cryptography until a few years ago, when app markets became mainstream and everybody and their grandmother runs code downloaded from shady sites such as the App Store or Google Play. So I'm not surprised that such issues (which already existed on typical multiuser systems in the 1990s) are now getting publicized and studied in more depth in the context of smartphones.

Changing the statu quo isn't an easy decision since the Linux kernel has some very strong backward compatibility leanings. The information in /proc/interrupts is useful when debugging application or driver code or system performance problems.

Restricting access to /proc/interrupts wouldn't block the side channel completely, just one relatively convenient way to observe it. It's also possible to observe keystroke timing by observing when the process that reads them is scheduled, and what an attacker needs to do that is more or less what the top program needs (and displays, if you just increase the default 1Hz refresh rate).


How to persuade average people that security matters?

Frankly, I believe the only way to achieve that is to offer no other choice - or at least make doing the right thing much easier than the alternatives. All of the points you raise put a burden on the user to get some aspect (however small) of information security correct: well users are not for the most part information security experts. They are bricklayers, or physics researchers, or project managers: we should let them get on with laying bricks, or researching physics, or managing projects. Those are the things they are expert at: we should be doing the security for them.
To pick on one example, "don't click on links that he doesn't trust". Just how should an administrative assistant, for example, decide whether a link is trustworthy? Look at the WHOIS record for the domain (having ensured that their DNS is being resolved through a 'trusted' channel)? Examine the details of the SSL certificate? Phone the webmaster and verify the key fingerprint? Only, why does he trust the phone number, the phone network, the person on the other end of the phone... It's a ridiculous position to give people hyperlinks that can point anywhere then tell them to make a judgement on using hyperlinks.
So I might be busy ranting, but am I going to suggest an alternative? Yes: stop using backwards compatibility or familiarity with the existing workflow to justify continued use of broken systems. To address the trusted link example, we have two problems:

we can't identify all websites reliably because they don't all have identification data, which is currently the SSL certificate.
we don't necessarily trust the people who are telling us to trust SSL certificate holders

Point 1 can be easily, if expensively, addressed.
Point 2 is harder: from a technological perspective, you can imagine issuing multiple certs from multiple authorities, but then you have to have UI for examining and evaluating multiple certs; yuck. Or you could imagine a 'web of trust' model where people countersign keys from sites they trust, and people they trust to trust, and so on; but now we're back in the same position we were before, where we have to know who to trust (this is basically what Moxie Marlinspike came to implement in Convergence). Or you could adopt the approach of current web filtering tools, and while you don't trust a vendor to tell you who is good, you trust them enough to declare that some sites are definitely bad.
This rough description fits with what Microsoft's SDL team has called NEAT security UI: the interface should be Necessary, Explained, Actionable and Tested. Compare that with the current UI for trusted websites: you get the interface (the padlock icon) when the trust is OK, i.e. when it's not Necessary. Clicking on that usually lets you see the details of the SSL certificate, but did anyone (and should anyone) explain what all of the fields in an SSL certificate mean to the user? Not Explained. Also, most browsers only stop you proceeding to sites with obviously broken certs, so in many cases the UI is not Actionable either.
The point is that if the UI were NEAT, then it would become more valuable: users would see the UI at the point that they (not we) need to make a decision; they would be told the supporting information relevant to their decision; their decision would have a meaningful outcome; and we would know how they react in both benign and hostile conditions.


authentication file sharing with qr code

QR codes are just encoding of text. There is nothing to embed. The QR code is simply a representation of an URL, in your case. There is nothing about the QR code that you can use as a control, so you need to think beyond that.

To do what you want, it would appear to be better to simply display a password in the file that the user enters once they use the QR code. The challenge here is to maintain passwords. You could use the same password (or a small set) for each file to reduce your programming complexity, if you're ok with the possibility of someone with a file trying to brute-force URLs and trying passwords.

The purpose of QR codes is to make URLs easier to access. That's all. Adding a simple field to ask for a password does not violate the purpose of QR codes.

Alternatively, because QR codes are most often scanned with phones, then your server could inspect the user-agent of the client connecting to determine if it is a phone or not, which might filter out unwanted automated requests. This is a weak control since anyone who understands your protection mechanism could also change their user-agent to one that looks like a phone.


Chrome status warning on a netbanking secure site connection

The website is using SHA1 certificates to provide security. The new Chrome browser is showing it as a weak algorithm, because most of the organizations are already migrated to SHA2 certificates. It is just a warning, it does not mean that it would be a non-secured connection.


Is there anything I can do past SSL pinning to secure my connection?

Right now, we're concerned with an attacker getting around pinning and using a proxy to be able to open the html page (by getting its URL from the proxy) in a device browser (like Chrome) outside of the app

Pinning is to ensure in the client that it connects to the right server. But it looks like that this is not your actual problem. Instead you are trying to ensure that the expected client connects to the server. In this case you obviously need to authenticate the client - client side pinning only authenticates the server to the client.

To authenticate a client to the server client certificates can be used which then of course need to be properly checked by the server. Note that it might still be possible to extract the certificate and use it outside the application. This again might be prevented by hardware backed certificates, i.e. certificate on a smartcard or similar.

Note that all of this does not help to protect the manipulation by an attacker which has full access to the device, i.e. you cannot use this to hinder the owner of a device to reverse engineer and use the application in a way which was not intended by you.


Google shows indexes of non-existing hacked-like URLs of my site and cached to other pages

There is one other possibility (other than what's mentioned by @bacon-brad):

Hackers don't always deface the site they hack.

It is possible that your site was once hacked and cached from that time. Redirection is not unusual when hacked (even today) and serves multiple purposes ranging from drive-by downloads to malicious ads to click-fraud.
If you've recreated / done major changes to your site since the hack-time, it explains you seeing "page not found" on your site but a cached site points somewhere else.


Prevent network users from creating an unauthorized outgoing VPN connection to avoid network policies

No.

Well, yes, but probably not the way you're thinking. You'd have to block all outbound traffic by default, and then white-list only the outside hosts (not ports, not services) which you can guarantee won't be usable to bounce traffic (generally because they are also similarly restricted).

If you wanted to block all traffic types that for which tools already exist for relaying VPN traffic, you'd have to block HTTP, HTTPS, and DNS among other things, making your internet connection almost useless.


How does Authy's 2FA work, if it doesn't connect to the server?

Authy show me secret numbers without any connection with server. How can it do it ?

Authy is using a one-time passcode (OTP) algorithm which come in a number of flavors, the two most popular being HMAC-based OTP (HOTP) and Time-based OTP (TOTP). Authy is using TOTP.

Both algorithms are essentially the same; they require some seed data and a counter to generate the next passcode in the series.  HOTP implementations increment the counter each time the user requests/uses a passcode, TOTP increments the counter after a given time interval.

In Authy's case, when the user submits a passcode to the server, the server looks up the user's seed data, calculates the counter value based on the timestamp of the request and then generates the proper passcode. The server then checks that the generated passcode matches the user-submitted passcode.

  Is it secure ? Can I know next number if I know N previous numbers ?

Yes and no, it depends on whether or not you trust the server's security.

Given N previous tokens an attacker still shouldn't be able to recover the seed data. However, these algorithms require the server to store the seed data for all of the users.  If an attacker is able to compromise the database (through SQL injection, etc.) then they will be able to generate valid passcodes. This is what happened to RSA and their SecurID tokens (http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-compromised/)

Some companies like Duo Security (https://www.duosecurity.com/) and Twitter (https://blog.twitter.com/2013/login-verification-on-twitter-for-iphone-and-android) are tackling this issue by implementing challenge-response two-factor authentication with asymmetric key encryption. They only need to store public keys in this case, meaning that if their database is leaked an attacker doesn't have the private keys necessary to generate valid responses.

Disclaimer, I worked at Duo.

Updated based on questions in the comments

  The algorithms (HOTP or TOTP) must be the same on the server and the client application?

The algorithm is identical, just the way the counter value is generated is different. If Google were HOTP and Authy wanted to support Google accounts, their app would have to generate and store the counter value differently from TOTP accounts.

  Does HOTP client require connection with server to get next passcode (because it doesn't know how much requests was made from last time), while TOTP doesn't require it?

No, HOTP doesn't require a connection to work, but HOTP is generally not used because it's easy for the phone and server to fall out of sync.

Say both the server and app start out with a counter value of 0. The server usually has a window, maybe the next 10 passcodes, that it will consider valid. When the user submits a passcode, the server will compare the submitted passcode with the next 10 generated passcodes. If any of the 10 match, the server can update the stored counter value and remain in sync.

The problem though, is that the user may be able to generate too many passcodes in the app without using them.  If the user is able to increment the counter beyond the passcode window size, then the server can no longer verify that the passcodes are valid.

To see in detail how the OTP tokens are generated, see this informative blogpost.


Dangers of PHP uploading word docs into a quarantine

What dangers are you worried about?

Are you worried about dangers to the server?  If so, the precautions seem adequate: nothing you're doing is treating the files as anything but a collection of bytes, so even a file with a harmful payload won't do anything to the server.

Are you worried about dangers to other computers?  If so, your precautions are inadequate, but verifying that the files are Word documents won't help much: custom-built malware can get past an antivirus scanner, and even valid Word documents can carry malware.

Are you worried about your server being used to transmit illegal material?  In this case, you'll need to do deep, possibly manual, inspection of uploads, because a Word document can embed images, or can carry classified information, or...


Determining which encryption algorithm was used to encrypt a particular drive?

This depends on what information you have available. If you have the encryption key, you can select the volume name in the VeraCrypt dialog and click the Volume Properties button. This will tell you information about the volume, such as the size, mode, and encryption algorithm. If you do not have the key and only the opaque, encrypted data, then there is no way to detect the encryption algorithm in use. VeraCrypt encrypts the header, which includes metadata such as the algorithm. The way it is able to decrypt without knowing the encryption algorithm beforehand is by trying each possible algorithm with the provided key. If the header decrypts correctly, then it uses that algorithm. If none of the algorithms work, then it assumes you entered an incorrect key and tells you such.


I'd say that looks like a brute force attack - they are likely trying to gain access to your mail server to send out spam, or using SMTP as a general avenue of attack on your server.