SQL injection vulnerability to CodeIgniter

This sort of question has likely never been asked here before because it is more suitable for StackOverflow.

There are easier and better ways to protect against SQL injection in Codeigniter - I strongly suggest you look at Query Binding (at the bottom of the linked page) or Active Records. Both of these will escape queries for you in a way that is much easier to do and harder to accidentally forget. I have developed and mantained several Codeigniter websites, and Query Binding & Active Record are much better ways to protect your database, as you're less likely to miss escaping a parameter.

What you have is safe from SQL injection (provided Codeigniter's db->escape function works properly, which to the best of my knowledge it does), but if at any point you forget to escape even one thing that goes into your query, then you'll be vulnerable to SQL injection.

If this is for a college assignment then this remark isn't terribly applicable, but outside of academia, storing passwords in plain text is considered terrible security practice. It is much better to use crypt with a per user salt, or password_hash if your PHP installation is recent enough.


In the majority of cases, an identity is just a row in a database, typically in a table called something like "users" or "accounts". It could also be a line in a file or some XML in a document or some such too. Even if it a DB, it's not necessarily a SQL DB. It is typically some sort of structured data, though (for example, local machine Windows user identities are stored in the SAM registry hive).
It will have a primary identifier (a username or email address are common, but it could also be a phone number, SSN or other government-issued identifier, physical address, or other sufficiently-unique characteristic[s]). It will most likely have an authentication verifier (a password hash, multifactor token key, etc. are pretty common, but it could also be something more exotic like a smart card public key, TLS client certificate info, or similar). It will typically have some additional information depending on the purpose of the identity (name is common; shipping address and payment info is likely if it's a shopping site; an employer might have stuff like employee number, job title, and manager), often including stuff from the list of potential primary identifiers (almost every online identity wants at least one of phone number or email these days, even if they use something different like a username to actually identify you).
How this database is accessed and used depends on a lot of factors. It could be the back-end DB of a web app, where the DB stores all info relating to any user accounts in tables with foreign keys to the users table but nobody except the web server ever uses the DB. It could be an LDAP server, possibly for an organization's email directory or full-blown Active Directory server, where the DB itself might be in any number of formats but the data is exposed through a standardized interface with any number of clients. It might be the local users list of a PC or mobile device or similar, used directly by the OS and (often indirectly, through OS APIs) by software it runs. It might be internal to a service, but exposed to lots of clients through a proprietary protocol, perhaps in a chat system.
Relatively few identities will have encryption keys - symmetric or asymmetric - associated with them, but it does happen (mostly with systems built for, or around, end-to-end encryption). For example, Signal identities use a phone number as the identifier but a public key as an authentication verifier. An identity in a GPG keyserver obviously contains a GPG public key. It would be quite uncommon for the identity provider to generate a private key, though; typically the key pair would be generated on the client and only the public key shared with the server (in plain text), since that way the server can never know the private key.


What is the benefit with using encrypted RAM?

Encrypting RAM is about preventing unauthorized access to the RAM contents.

Under normal operating conditions, the Operating System maintains RAM access permissions and blocks applications from seeing memory from other applications; so we are talking about an attack context where the attacker plugs into the RAM "from the outside". It has been demonstrated in lab conditions. Theoretically, properly applied encryption could thwart such kinds of attack.

If RAM is encrypted, it must be decrypted automatically for usage by the CPU. The CPU does not operate on RAM directly; it loads code and data from the RAM into its internal caches. This loading/unloading process is transparent for both the applications and the operating system. This means that an automatic RAM encryption system is conceivable, but would have to be done in hardware, preferably in the CPU itself (if it was done in the RAM chips, the attacker could just freeze the RAM and then plug it into his own machine; similarly, decryption in an external RAM controller would not prevent active attacks).

Such CPU with RAM encryption exist (but are still pretty rare). This 15 years old article from Anderson and Kuhn cites the Dallas DS5002FP microprocessor, a 8051-compatible CPU, which is still in production today (the article explains that the encryption is actually quite weak).

Note that encrypted RAM (decrypted only in the CPU) cannot work well with DMA -- so disk and network accesses would be quite slow in a PC with encrypted RAM.


When should I sign a PGP key with a non-revocable signature?

RFC4880, 5.2.3.12. Revocable considers non-revocable keys a "commitment" to a signature that cannot be revoked. The certification's validity can only be invalidated by revoking the entire key used for signing.

I cannot think of a bunch of use cases apart from yours of non-revocable signatures to other keys you're owning yourself.

I could imagine use of this flag for special signatures, like in a situation where an employee designates a revocation key (like an OpenPGP key acting as corporate CA), which cannot be removed any more (so the corporate CA is definitely able to revoke the key, even if breaking up with the employee in conflict.


How can I tell if a zip file uses the 7-Zip exploit?

You cannot tell as an user because it's an exploit, not a virus.

CVE-2016-2335 is related to UDF file format interpretation, while CVE-2016-2334 is a heap overflow related to the handling of Zlib files.
Such things would not at all be easy to exploit. Note that most archivers at a point have such exploits (i.e. CVE-2016-2347 for LHA), but most of the times they are not that dangerous. Exceptions exist, of course, here's a really dangerous one from winrar.

The problem was immediately fixed though, so currently there is no such problem in the latest version.


See SSD (Flash Memory) security when data is encrypted in place and watch the discussion links on hard drives.
On older drives, it was likely possible to recover overwritten data. The density of modern drives for the past 5+ (and the plus may be 10, 15, or more) years has been so high that a single pass of random data means whatever was there before is just not going to come back unless the NSA knows something about this that the rest of the general public doesn't.
Modern file systems are such that the data may have been cached in several places, so unless the entire disk was wiped, the answer is to look for cached, duplicated, versioned, etc. copies of the file that were overlooked during the erasure process.


Can the username be used in HMAC during client-side hashing?

Hmm.

Your stated requirement is almost, but not quite, the same as the usual requirement of "If a hacker gets the db of users' password hashes, they should not be able to easily tell which users have the same password. This is usually solved by server-side salts.

You say:

  Keep in mind that I can't use a salt because the resulting hash has to be consistent between logins when given the same username/password combo

I'll push back on whether that's actually true; salts are per-user, not per-login, so why not have the server look up the salt in the db and send it down to the client?

Ultimately, I'm not sure you're going to be able to solve this problem.

Let's say I (the hacker) find out that some user's password on memegenerator.com is letmein1234. Then I go to the the login page of your site and enter that password for them. As far as the server is concerned, that's literally identical to the real user trying to log in.

Remember also that the attacker gets to see the source code of the javascript, so any obfuscation that you do to the password client-side counts for zero security because it's completely known to the attacker.

If the user decides to reuse passwords across sites, I'm not sure there's anything you can do about it, unless you're willing to go all the way to implementing 2FA with Google Authenticator, SMS OTP codes, FIDO2 USB keys, etc.


You want a string that is unique every time the registration key is checked and something that the user will not be able to easily reverse engineer (and thereby bypass your DRM restrictions).

One way to do this is to have the application store your crypto key. You concat/combine the software keys, IDs, and whatever other data you want, along with a random string that changes every time this data is accessed/requested. You encrypt this with the crypto key and pass to your server. The server decrypts with its crypto key, extracts the decrypted data and dumps the random string.

The use of the random string means that the resulting cyphertext string is unique each time, making it difficult to reverse engineer.
Encrypting means that you can read the plaintext data even though the cyphertext is different each time (a feature that a straight hash cannot provide).

The downside is that the cyphertext might get large (depending on how you do it). You should also make sure that the random text is of a variable length to further make it difficult to guess the component strings.

The other problem you will have is the proper handling of the key in your app. Once a user gets that, then they can craft their own strings that will pass your tests.

In general, you are asking about how to devise a DRM solution. There are lots of established ways to do this, and I recommend you look at their design patterns.

The common struggle is that once you place your app in the hands of a user, then you lose a lot of control. It is better to design your solution so that it does not matter if a user copies your software, or design a framework upon which your app runs instead of locally (which is way web-based apps are so popular). You also have to weigh the cost/benefits of all this design work against the work a user will have to go through to defeat it. Are you placing your efforts in the right place?


Can IP Security camera be tampered by flash of another camera?

It is possible to destroy a CCD using very strong light or, even better, a laser (a portable green/blue laser is enough), but the result will be "dead" pixels either in spots, such as in here, or in whole columns and rows depending on the CCD architecture. This holds true even for 3-CCD and Foveon systems, since it's very unlikely for the whole surface to get burned - unlikely as it is that such a system is employed in a surveillance camera.

Your symptoms seem to indicate that the whole green channel has disappeared or is no longer encoded/transmitted.

There are some AGC troubles that will give similar symptoms, and may not recover from a reboot but need a complete power cycle. What happens is that red and blue channels are boosted at the expense of the green one.

Another possibility is that the camera is stuck in "infrared" mode (even if this is usually B&W), or both systems are running at once and interfering. Here, again, a power cycle might help, but a soft reboot should have, and yet it didn't.

But it almost looks like (a screen capture would have helped) the CCD assembly and the encoder are actually separated assemblies inside the camera, and they're connected through a VGA line... whose green wire got disconnected (e.g. by a shock). This would account for the magenta bias, even if it still doesn't satisfactorily explain the washed-out appearance. But similar problems are known and due to the CCD packaging.

Barring a very unusual internal construction of the device, I do not see a laser or a flashlight wreak this kind of havoc. Unless one took a large laser assembly and used it to smartly rap against the camera body.


Best way to manage private keys for users of an application?

When it comes to private keys or secrets that are critical such as in the case of cryptocurrency where if you loose the private key the funds are gone forever, always rely on hardware, less on software and never on cloud. You can use cloud resources for other things, but never give your critical assets if their loss means you're out of business or you'd suffer a huge impact. HSM are probably the best solution at the moment. I wouldn't suggest using Amazon's solutions, I think they're known for not having the greatest security. And you can choose whether to host the HSM by yourself or hold them in third party vaults depending on the amounts. You don't want to risk your well being by holding too much amount and become a risk yourself, but if you handle your assets to third parties, you want to make sure no one from there could get their hands on your assets as well.


For CA-signed ssh keys, how to see various attributes: principals, identity, serial number, options, validity time, etc

My cohorts at Gravitational wrote a pure golang tool that parses SSH certificates and run it online here: https://ssh-certificate-parser.gravitational.com/ If you are asking about parsing signed SSH certificates I believe that tool will output all data that's available within the certificate.


VeraCode static code scan of django view reports "External control of Filename or Path" on render method

I don't see anything wrong with this implementation.
It is also completely according to documentation:
https://docs.djangoproject.com/en/3.0/topics/http/shortcuts/
It seems like this Veracode result is a False Positive


First, a brief disclaimer. I work for AgileBits, the creator of 1Password, on their security team.

1Password for Teams, as with most password managers, makes use of a "master password", the password which grants access to all of your other passwords, to create an encryption key. That encryption key is then used to encrypt everything else you store.

Unlike other password managers, it makes use of an additional secret - a 128+ bit randomly generated "account key". The Master Password and Account Key are used to perform 2-Secret Key Derivation, in which the "master unlock key" (MUK) -- the key which protects all of your passwords -- is based on the entropy from both of those. So, if your Master Password contains 60 bits of entropy -- which isn't particularly high, but is a nice example value -- the MUK has at least 188 bits of entropy.

AgileBits has access to neither of those values - we don't have your Master Password and we don't have your Account Key. None of the random numbers which are used as encryption keys are ever generated by AgileBits either, so we aren't in a position to have any of your encryption keys.

To the point that was made in an earlier answer, even if your Master Password is disclosed, the Account Key must still be obtained, and it provides over 128 bits. This means that an attacker must make 2^127 trials, on average, to guess your Account Key. In short, if I told you that my Master Password is "fast cars are fun", you'd have an insurmountable computation - enumerating 2^127 possible Account Key values - ahead of you. Just that step - enumerating 2^127 possible values - is beyond the capabilities even of State actors (governments).

Being that secure has its downsides, and we have created a mechanism which protects you from us, and us from attackers, and minimizes the risk that you will lose all of your information. Because we don't have any of the secrets required to access your information, we cannot "reset" your password or allow you to create a new Master Password if you've forgotten it. This prevents us from abusing a "password reset" mechanism and gaining access to your information, whether for our own advantage or at the behest of a government entity. And if we can't get to your secret information to abuse or disclose it, hackers are going to leave us alone (so the theory goes) because they also cannot get your secrets from the data we have.

Our innovative solution to the "password reset" problem is called the Recovery Group. The Recovery Group is one or more members on your team who have encrypted access to all of the encryption keys used by the various team members. We also don't have access to the encryption keys used to encrypt the recovery keyset, so we can't abuse that either.

Not only can we (or an attacker) not gain access to your encryption keys, we cannot gain access to the mechanism needed to restore access to those keys, if a user loses their Master Password and/or Account Key.

For more information, please read our security page. It also links to the security design white paper which includes significantly more information.


What should I look at in the event of a major vendor suffering compromise with unspecified impact?

I think the fact that your security vendor is being far from transparent, is already a pretty bad case scenario.
When the vendor is being secretive wrt security details - be it specifics of an incident, or the security internals of the product itself (or at least proof of security, e.g. crypto algos) - this is an inherent risk, to the entire security posture of your own organization.

Now, while in certain circumstances it is legitimate to accept a risk, such a risk as this (having your whole security architecture rely on a third party, which may or may not be trusted)should not be accepted lightly.
When a vendor starts to tip in the direction of withholding critical information, instead of supporting customers in making smart choices, I would say that the risk acceptance decision starts being a bit murky.

As a result, if I was in that position (and ignoring constraints such as budget, time, and politics), I would re-evaluate my relationship with ALL vendors supplying a critical piece of my infrastructure. Note that this is irrelevant of the actual impact - high impact flaws can happen to (almost) anyone - the important part is how you choose to deal with it.
In my opinion, in this case the way they dealt with it (or didn't) shows that they don't understand the trust relationship that needs to be in place, for the above risk acceptance to be valid. At the very least, I might consider changing vendor relationships to one of risk transferrance instead of acceptance, via strict SLAs with penalty clauses.

And in this specific case?
Well, assuming that switching out the entire authentication mechanism until this deal gets sorted, is not really possible - not much else to do, except activate more logging on logins, pay extra attention to anomalous logins, watch what your users do, and generally try to minimize access for users...


Connection changes after waking from sleep

Don't be afraid, this is simply one of the several servers that host OFTC service.

Here is an explanation:

~$ dig +short irc.oftc.net
91.217.189.50
109.74.200.93
130.239.18.116
81.18.73.124
~$ for ip in $(dig +short irc.oftc.net|grep -E '^[0-9]') ; do dig +short -x ${ip} ; done
farad.oftc.net.
solenoid.acc.umu.se.
getic.rdsnet.ro.
plasma.oftc.net.

When querying DNS for ip for irc.oftc.net, DNS returns 4 records: this is round robin DNS, a kind of "poor people load balancing" ;-)

The server you reconnected to is legitimate as you can see...

EDIT
If you're un-familiar with Linux and dig command, then:

dig is to request DNS server.
dig +short only output usefull information (pretty cool for scripting).
dig -x will do reverse DNS request (getting the name from the IP).


How can I extract all required data to re-encrypt browser-decrypted requests identically?

If you want to replicate only the encrypted messages than you would need the symmetric keys used for encryption and also the random initialization vectors used together with these keys. Additionally you would need to know how much data got encrypted in each SSL record so you could replicate it exactly.

If you also want to replicate the SSL handshake you would also need to know the client and server random values used in the handshake, the servers certificate including its private key and if client certificates are used the same for the clients certificate. Additionally you would need to know which extensions got used and in which order, the ciphers offered by the client (and their order), protocol versions used etc. If DH or ECDH key exchange is done it gets even more complex.

And I'm pretty sure that I've missed something you also need. But even to get all of the values I've mentioned is nearly impossible unless you have very deep control of client and server, i.e. deeper than the API of the usual TLS stacks offers.


There are manual approaches and tools to analyze your logs (see eg here); but listing tools themselves would be off-topic here.
The problem with these approaches is that you are not monitoring for suggessful XSS attacks, but for attempts. This can also be useful to know how attackers are attacking your application, but there will be a lot of noise from automated scanner, etc.
It doesn't seem like this is what you necessarily want though. If you actually want to monitor for successful XSS attacks, you may want to consider using the reporting feature of CSP. You can also use it as report-only without negatively affecting usability of your application.


Only allow access to specific service running on computer in Demilitarized Zone over internet

The definition of a DMZ is that you have two firewalls, one between the system and your LAN and one between the system and the global Internet.

A skilled administrator will of course configure the firewall facing the internet to only allow those services which are required by the server.


Are there any anonymous OpenID providers similar to Gawker's "burner"?

It seems like it is probably equivalent to a throwaway account, although with less work involved. Another similar service that creates a disposable openid is at http://openid.anonymity.com/

Other services like myopenid.com allow you to create multiple aliases for a single account. Liquidid.net allows you to create multiple anonymous email aliases.

I guess it all depends what you want to accomplish and how permanent you want to make the identity.


Why don't web email clients put emails in an iframe?

TL;DR iframe cannot replace sanitization completely, but is a great feature to use as security in-depth.  Unfortunately, it does get in the way of some user-friendliness features.

I would be interesting in hearing a more informed answer, but I'm going to post some points I'm aware of.

Same Origin Policy works both ways. It's great that it keeps the iframe from seeing the outer document content. Unfortunately, if you select text, the outer document cannot tell what text was selected in the iframe. (thanks @paj28) Once could use postMessage feature by adding script to the inner page to work around this, but it is inconvenient. Furthermore, this will not work if you use iframe sandbox as a way to disable scripts. (which I would highly recommend)

You will want to use Content Security Policy (again, thanks @paj28) to disable beacons within the iframed content; and also to disable scripts and other potential issues.

I'd like to point out that iframe as originally designed is not complete. The sandbox attribute would be must if you have any doubt in your sanitization. Unfortunately, the sandbox feature was only recently implemented. This is of diminishing significance as older browsers start to drop off the charts.

Disabling scripts would get in the way of user-friendliness features anyway such as detecting selected text. (It is possible you could get away with 'disable scripts and treat as same origin' rule of sandbox, but that seems risky.)

Any time you add your own scripts or interactive functionality to the iframe'd document, you will be much safer if you still sanitize that document. While iframe sandbox combined with CSP may cover you completely, there might be something missing from that formula.

So in summary

For browsers that don't support sandbox, the iframe mitigates significant security risks, but is unable to protect against many issues. Content Security Policy might be able to isolate the content, to a great extent. But you still need to sanitize to prevent things like <a target="_top".
For browsers that do support sandbox, combined with a good Content Security Policy, you might be able to replace sanitization, but it is not advisable because it is hard to know for sure whether you are 100% secure. (sanitization routines on the other hand are older and better vetted)
If you have sanitization (which you probably should), and the sanitation is well vetted, then iframes only get in the way of user-friendliness. On the other hand, if a flaw is discovered in your sanitization, then you will be glad you iframed the content, using the sandbox attribute and CSP to reduce the scope of the attack.

Side note: desktop applications have more liberty in sandboxing their webviews, even better than the iframe sandbox attribute. So, for example, the Android apps could benefit.


What are escalation pathways from a VM to its host?

An advanced attacker could compromise a hypervisor through emulated device drivers more easily than through clipboard handling. The way a hypervisor works is by providing a new execution environment for a guest, and exposing emulated hardware. When a driver in the guest tries to access the virtual hardware by, for example, reading and writing to PCI BARs to interact with PCI devices, the hypervisor's emulated device software will hear the request, temporarily pause the running guest, and emulate in software what the actual hardware would have done before unpausing the guest and allowing it to see the results. This allows the guest to be effectively unaware of its underlying virtual environment. When you think of the emulated devices as acting merely as a proxy, implementing a complex and often poorly documented protocol between the guest software (which is designed to talk to real hardware) and the host hardware (which is capable of listening to software), it's easier to see how a bug in the parsing of such complex data structures could result in a security breach.

This is a look into some of the security caveats of a hypervisor, specifically QEMU with KVM, though the general concepts should apply to pretty much any hypervisor software.

Note that most of the time, exploiting a bug in emulated devices requires the attacker to have privileged access to the guest. They have to completely compromise the guest before they are even allowed to interact with the emulated hardware. If the guest itself is sufficiently secure, then the hypervisor will likely be, as well.

The full version of the famous quote from Theo de Raadt, founder of OpenBSD:

  x86 virtualization is about basically placing another nearly full
  kernel, full of new bugs, on top of a nasty x86 architecture which
  barely has correct page protection.  Then running your operating
  system on the other side of this brand new pile of shit.

  You are absolutely deluded, if not stupid, if you think that a
  worldwide collection of software engineers who can't write operating
  systems or applications without security holes, can then turn around
  and suddenly write virtualization layers without security holes.

  You've seen something on the shelf, and it has all sorts of pretty
  colours, and you've bought it.

  That's all x86 virtualization is.

In the end though, the chances that a "dodgy link" will contain a hypervisor-breaking 0day are pretty remote. If anything, it'll have an exploit for an old version of Flash, used to download botnet software.


What's the benefit of JWT if user needs to send his credentials once anyway?

Suppose there are 2 servers: TRUSTED (e.g Google) and UNTRUSTED (any site that allows 'Sign in with Google').

I don't want to send my TRUSTED username and password to UNTRUSTED. I also don't want to make a separate username and password for UNTRUSTED.

So instead I get TRUSTED to authenticate me, and send a signed JWT containing my identity to UNTRUSTED to prove who I am. UNTRUSTED can check if the JWT is really from TRUSTED by verifying the JWT signature using TRUSTED's public key (if the signing algorithm uses public/private keys, e.g. RS256).

JWTs can be stolen in transit, as can usernames and passwords, so this is a real risk (although, as you mentioned, JWTs will expire sooner). HTTPS will minimize the risk by encrypting data in transit.

Another major benefit of using JWTs is that verifying a signature is often faster than checking an access token against a database.


Methods root can use to elevate itself to kernel mode

I can think of these:

Indirectly modifying kernel image or signed modules by changing update or other system configurations (point update server to yours, add your keys). Or by compromising infrastructure where the updates come from.
n-days. syzkaller reports quite a few bugs and some remain unfixed for a while. https://syzkaller.appspot.com/
Loading firmware onto a device that can directly interact with RAM (e.g. PCIe, firewire devices).


The acceptable behaviour in my opinion is simply to inform the end user of why? & what? is being done by your system, so atleast they can evaluate
if they would like to use it, and maybe give them the chance to disable it.

All this can also be done without cookies, you could catch the devices "fingerprint" when login is performed and check if that "fingerprint" is allowed or not : new device fingerprint (notify owner)

Since you mention JS here is a Device Fingerprinting Lib : ClientJS


Is Skype secure enough to transmit passwords?

Questions I would ask myself before using skype for sending sensitive information:

Is the encryption truly end-user to end-user or is the data only encrypted between the user and Skype (thereby potentially giving Skype access)?
How are IM logs managed? Can you be sure that you have 'deleted' the password from the log?
Even if logs are not being stored to disk directly buy Skype, is the memory Skype uses for this non-pageable? i.e. could the password be placed into a page file without you being aware and hence become retrievable for local users?

Before satisfying these questions my own answer would have to be no.


HTTP authentication: identify the client

If they're screen-scraping, break their screen-scraper by changing your webpage.  Name the "password" field "username" and the "username" field "password".  Introduce a randomly-named hidden form field with random contents that needs to be posted back during login.  Introduce changes to the page structure that don't change the appearance.  Be creative.

Screen-scraping relies on "landmarks" on the page to find the important content.  If those landmarks are constantly shifting, the person writing the screen-scraper will need to constantly update it to keep it working, and hopefully will get the message that they shouldn't be doing things this way.


FIPS 140-2 Compliance vs Validation & Products vs. Modules vs. Ciphers

I think the answer comes straightforward from this quoted paragraph (Module Validation Lists) -I emphasize the important thing in bold:

  A product or implementation does not meet the FIPS 140-1 or FIPS
  140-2 applicability requirements by simply implementing an Approved
  security function and acquiring algorithm validation certificates.
  Only modules tested and validated to FIPS 140-1 or FIPS 140-2 meet the
  applicability requirements for cryptographic modules to protect
  sensitive information.

As for:

  What does this really mean for customers who wish to use the product?

NIST advises:

  Users in Federal Government organizations are advised to refer to the
  FIPS 140-1 and FIPS 140-2 validation list

Validation list.


At first look, and without more data, I would still say that you have a local firewall/AV issue.

Run wireshark or tcpdump to see how far the connection gets before it gets aborted.

EDIT

OR, you might have something running on your listener port.


Why does airodump-ng shows 2.4GHz AP beacons, but wireshark does not?

airodump-ng will hop channels unless given a specific channel with the -c flag, whereas Wireshark is going to capture wireless traffic on whatever channel the interface is on, and does not dynamically adjust the channel. If there are other processes running on your system that manipulate the wireless card (e.g. scanning for networks), the channel may be changing unexpectedly. Or, it is likely not hopping channels, but is currently on the wrong channel.

You can manually set the channel by opening the "Wireless Toolbar" under the "View" menu in Wireshark, or using the iw utility:

# iw dev <interface> set channel <channel>

If you desire channel hopping, you could put the above command in a script that cycles through all available channels.

If you have the aircrack-ng suite installed, the airodump-ng command can tell you what processes may be using your wireless card so that you can kill them.


For ISPs to do encryption across all lines they'd have to make sure that all devices on their backbone can support encryption.  Many of these devices are old.  As the OPM leaks taught us, many organizations don't upgrade equipment that can support what we consider now to be "secure communications".

At the root of it though is that it wouldn't make a difference in your communications.  Even if your communications to the ISP is encrypted, going out past them to a server would then be dumped back out into the Internet in plaintext.   No one's end point for data is the ISP.  Protecting this portion of the communication is redundant because anyone who wants to secure their entire communication path would use a VPN/TLS/HTTPS anyway.


What are security risks of serving user uploaded files without Content-Disposition?

Depends what filetypes are allowed to be uploaded and how the files are being handled.

If the page is directly loaded, the file ends in .php and the webserver recognizes and executes PHP files, then you risk having the entire domain compromised.
A smaller issue is that an html file may be a phishing page, sending any results to a server controlled by the attacker (cross-domain posting via javascript may not be possible, but you can make any cross-domain request through (visible or invisible) forms). The domain and perhaps even HTTPS certificate clearly shows that it is on your domain or a subdomain (unless you use a completely different domain), and thus the user might think that the page is trustworthy.
And perhaps other things that don't come to mind right now.


Encrypt a body instead of Signing it (with JWT for example)

TL;DR: It is not recommended. If you don't want to use public key cryptography, you can use HMAC.

Using encryption may work to some extent, but you would really need to know what you are doing or hope you get lucky.

Signature/MAC protects the whole message from being changed. Encryption does not prevent change, the only thing it can prevent is the attacker knowing, what he is changing.

Now if the format is known, for example he knows where the user ID is (and is lucky), he can change it to a different (random) ID blindly. Now this may or may not be useful for the attacker but it brings a lot of problems.

Also, depending on the encryption algorithm, padding (if any) and other factors, you may face additional problems.

For example, if there is no IV in the scheme, an attacker may take part of one message and part of another and mix them together. So let's say I intercept two messages. One makes you administrator and one makes me user. I may be able to take the name from my message and the rank (administrator) from your massage and make myself administrator.

Also as pointed out by AndrolGenhald, with CTR mode (AES or any other block cipher), the attacker can completely change the encrypted message as long, as it is the same length. This may also be possible with less well known modes and/or ciphers.

PS: AES in GCM mode can be used to both encrypt and authenticate data, so using it prevents all the above mentioned problems and is preferable, if confidentiality of the data is required. However, it is still necessary to send the IV and the MAC with the body.


How to identify unknown device that's ARPing on my network?

If you happen to use managed switch(es), you could log into your switch(es) and look into their forwarding table to see on what port of the switch is registered this mac address. You could then follow the trail up to its source.

The way to look at the forwarding table depends on the manufacturer of your switch(es). If your switch has a command line interface and you're familiar with terminal, try "show mac-address" (I know it to work on both my HP and Brocade switch). Else look at the Web GUI.

If your switch is not managed, or you don't have access to it, maybe you could find whose sending by capturing these arping packets on various places of your network: try sniffing the network using wireshark or tcpdump on suspicious VM, or on the physical network interface of your ESXi...

my 2 cents   :)


Does an *additional* company-wide password offer any real security?

You would be infinitely better off using certificates or two-factor authentication devices than a company-wide password.

The company password method suffers from the issue of key distribution (how do you get it out only to employees, and timely enough), people forgetting or otherwise losing t it, and wide distribution greatly increasing the likelihood of compromise. I guarantee you it will become culturally engrained to give that company password to nearly anybody or write it on post it notes all over the office as the pain of rotations is borne on people with a new password that they didn't choose.


(I can't find any documentation that goes into which order I specifically need it in, and which certificates I actually need to include).

RFC5246 is pretty clear on this:

certificate_list
  This is a sequence (chain) of certificates.  The sender's
  certificate MUST come first in the list.  Each following
  certificate MUST directly certify the one preceding it.  Because
  certificate validation requires that root keys be distributed
  independently, the self-signed certificate that specifies the root
  certificate authority MAY be omitted from the chain, under the
  assumption that the remote end must already possess it in order to
  validate it in any case.

  However, I'm wondering whether or not this is recommended to deviate from the given bundle provided by Gandi?

Why would you like to deviate from this? If Gandi is the CA that issued your certificate, you should definitely use its OCSP responder. Any OCSP responder further up in that chain is not responsible for any certificates issued by Gandi. After all, nobody (but Gandi) knows the private key, which is needed to sign the OCSP responses with (and/or the certificate that is used to sign OCSP responses).


If someone else has software installed on the computer you are using that allows them to view your screen than Tor will not prevent them from doing so.

If used correctly Tor will make it very difficult to associate your internet traffic with you and people snooping on that traffic will not know you are the one it is directed to. But, if an attacker has spyware on your computer that wont matter. They will presumably already have access to your computer and be able to see and record everything you are doing.

Potential alternatives are to use Tor on your own computer that doesn't have spyware installed on it by an educational institution. However, if you are using a school computer and internet connection there is no real way to garuntee that you aren't being snooped on.


certain websites not secure now, two days ago they were

If a browser tells you the site can't be accessed in a secure way anymore, and you aren't completely sure you know the exact reason, then don't do it.

Most likely, it's just an error in the Web site configuration (e.g. a secure certificate has expired and a careless site admin just forgot to renew it) and it will be fixed soon (probably in no more than 1-2 business hours) so just make yourself a cup of coffee and wait for the site to go up.

Less likely but much more dangerous, a man-in-the-middle sort of a malicious person is trying to steal your data or impersonate you on the respective Web site.

In both cases, it might be a good idea to call the Web site support if there's any and you somehow know its phone number.

Somewhat likely, it's just a captive portal. Try to open http://example.com/, is there maybe a WiFi login page displayed? If so, log in and try to refresh the page.

Check also that your timezone and clock are correct.


Sniffing TLS/SSL communication with Wireshark, possible?

Firefox and Chrome both support logging the symmetric session key used to encrypt TLS traffic, and therefore, can also be used to decrypt using Wireshark.

Here is a link that explains how to do this in detail and with ease: Decrypt Browser Traffic with Wireshark

  If so, how do I identify and show the messages?

Simply filter your results (assuming you are able to decrypt at this point).


How do digital signatures work - beginner's explanation?

While there are other answers on this site that walk through the maths of digital signatures, it can be difficult for people new to the field and to the maths to follow those answers. This is an attempt to bridge the gap in understanding.

There is only so far that a "beginner-level" answer can be provided because we are dealing with complex maths. So, permit a high-level explanation.

Alice writes a message
Alice creates a private and public key pair (this answer cannot go into the explanation of what these are - if you are stuck at this part, then you need to stop and read about these)
Alice creates a hash of the message (this answer also assumes that you know what a hash is)
Alice uses the hash and her private key to create a mathematical value called a signature (and that's as far that a beginner-level answer will go on this step)
Alice sends the message and the signature to Bob
Bob uses a "signature verification" process that includes creating a new hash of the message and Alice's public key as inputs.
"Signature verification" passes if Bob's hash of the message is the same as the hash Alice used when she signed the message, and if the public key matches Alice's private key.

Bob knows that the message was not changed since it was signed and that it was signed using Alice's private key.

This is a very high-level explanation of complex maths and there are a lot of subtleties in the processes that can change depending on the algorithms used.


Is it generally safe (and compliant) to log a stack trace?

Stacktraces would be really valuable for the developers in order to understand bugs in your application (Or for administrator in case of being attacked), but you shouldn't be loging sensitive information like usernames, passwords or any similar information. That's cause if you do and your logs fall in bad hands, the harm could be much worse than some attacker being able to understand a few bugs

Also, logs should be stored in a different partition than your webserver, that's to avoid a possible DoS. Under certain attacks your log files will increase drastically which may fill the webserver partition and prevent it from working. A good backup policy to prevent this is encouraged too


Not salting is fairly minor. The issue becomes credential reuse - i.e. someone using the same password on multiple accounts. This becomes even more of an issue when administrators reuse the same password on a local machine administrator account to their domain account.

Pass the Hash is an issue common to all Challenge Response algorithms that require a shared secret available in the same form at both ends (in this case the hash). Both ends require the secret to respond/verify challenges. Windows chose this approach because it allows communication to occur in plaintext over the wire. There are two alternatives I am aware of -

Traditional password authentication. I.e. the password is sent to the server and verified against the stored hash there. However you require an encrypted connection or risk Man in the Middle attacks.
Public/Private key verification. The server stores the users public key and the client proves themselves with the private key. The main drawback here is that remembering a private key is substantially more difficult for the client than remembering a password. This can be avoided by deriving the private key from a password (using the password+salt as a seed for a random number generator which is used to generate the private key).


Is checking a token without checking a header sufficient for CSRF protection?

Yes. This is the first time I see anyone recommending to do both. Checking the headers always feels a little hacky: the Referer header was not designed as a security header (there might be obscure cases where it fails) and is not always set. We typically recommend using tokens and don't suggest checking the "Referer" header.

It can't hurt to do both if you reject when either condition fails, but tokens are enough -- assuming they're implemented properly.


Why does SSL EV certification have a range of encryption (40-128 bit)?

Marketing.  The providers want you to select them because they list something that someone else doesn't list, even though all certs support the same level of encryption as you noted.
Price has nothing to do with security.  In fact, all the SSL certificates depend on the lowest level security of any of them.
No.  The SSL handshake has zero to do with location of either endpoint.
SGC is dead.  My guess is anyone that needs it for some strange reason (really old legacy applications?) are a niche market.  Niche markets have high prices because they can.
You didn't ask this, but why do you care about EV?  Literally the only advantage of EV is that it gives you a green bar in the browser window.  Almost nobody knows what this means.


Man in the middle attacks for Out of band Authentication

The threat is when the MITM owns the login screen.

If, for instance you click a link in an email that purports to be a link for https://yourbank.example but is actually a link to http://yourbank.evilbob.example, and enter the username and password you use for your bank website, Evil Bob merely needs to forward those on.

Then, https://yourbank.example which doesn't know that that it's EvilBob's website submitting your credentials and not you, dutifully sends an auth code to your phone and waits for your response.  However, you're still on http://yourbank.evilbob.example, which has accepted your username and password and presented you with an input field to type in the auth code you're going to receive on your phone.

So, you type the auth code into http://yourbank.evilbob.example, which turns around and submits it to https://yourbank.example, and Evil Bob's website is now logged into your online banking interface.

That is the man in the middle threat for out of band two factor auth.


Can an employer access Whatsapp messages if you are using their servers?

The following research paper describes four attacks on WhatsApp.  I don't know whether they have been fixed.

Guess Who's Texting You? Evaluating the Security of Smartphone Messaging Applications.
Sebastian Schrittwieser, Peter Fruhwirt, Peter Kieseberg, Manuel Leithner, Martin Mulazzani, Markus Huber, Edgar Weippl.  NDSS 2012.

Impersonation attack.
One attack allows an attacker to impersonate someone else.  In particular, if the attacker has a particular phone number in mind (the victim's phone number), the attacker can register himself for that phone number and receive all WhatsApp messages that might have been intended for that phone number.  See Section 5.2 of the paper.

This may be relevant to you.

SMS spam attack.
A second attack allows an attacker to send arbitrary text messages to anyone around the world, for free, from the WhatsApp servers.  See Section 5.4 of the paper.

Phone number enumeration attack.
A third attack allows an attacker to enumerate the phone numbers of other WhatsApp users and identify the operating system they are using.  See Section 5.5 of the paper.

Status message forgery attack.
A fourth attack allows an attacker to change any other WhatsApp user's status message to anything of the attacker's choice.  See Section 5.6 of the paper.

Implications.
None of these directly address the particular question you asked.
However, these vulnerabilities diminish my confidence in the security of WhatsApp.

The vulnerabilities described in the paper are extremely basic and elementary flaws.  We're talking facepalm territory. The flaws include, for instance, a complete lack of access control or authentication; as well as inappropriate trust in the client.  (Basically, OWASP A3, A8, and A9 violations.)
Of course, anyone can make mistakes, but these are such basic mistakes that they make me wonder what other mistakes the WhatsApp developers may have made, and what is wrong with WhatsApp's security review process that these slipped through into deployment.

So, based upon this analysis, I would be reluctant to rely too heavily upon the security of WhatsApp.


What are the best practices for trusting connection sources in open source software?

Your main problem is identifying who are your "real" customers. As the code is open, its easy for anyone to emulate a client. So, how can you do it?

You can use asymmetric encryption. As the keys are not inside the code, there is no way they can "emulate" those keys. Each server will have its own keys.
If encryption is too much for the client (and the information send is not that important), then you can simply use some shared key (like a password), which will be sent always along with the the request (something like a session cookie).

Either way, you still need to know who is who through some kind of authorization (e.g. login page). User/pass will be unique per server, so you can be sure that whoever download the keys or the "password", are authorized clients.

In the case your system has no login information (more general software) its more complicated (and that is what I believe is your real question)...

Well, am afraid there is no much you can do. Perhaps you can store some key downloaded from your server during installation (you can give each client an specific product-key). Not 100% safe, but it could help.

Web analytics are not 100% safe either. They can be faked (just google: 'how to fake web traffic'), but companies try their bests to identify real customers from fake ones with their own algorithms. The advantage they have, is that their code is not open, so you don't know what exactly they are taking into account.

I had once the same dilemma as you. In opensource, each server has its own configuration (which is private), and you can use that in order to keep away unwanted people on knowing everything about your service.

If I can think of something else, I will extend my answer, but that is all from now.


I completely support the encryption of sensitive information while it is in storage. Encrypting sensitive information in the database prevents an attacker from gathering useful information if he/she has obtained the database. However, as always, how you implement the encryption system is critically important.

First we need to compare and contrast two situations in which the database is compromised:

Situation one occurs when the database has been compromised, but the file system is still secure.
Situation two occurs when both the database and the file system are compromised.

Situation one is when encryption is the most useful. This kind of attack occurs when the attacker has used a method like SQL injection. This is ideal because the attacker does not have a decryption key/method and he/she would have to bruteforce the decryption key to get to the data (this should be infeasible).

Situation two is far less favorable. This kind of attack occurs when the attacker has obtained access to the server (e.g., physical access, FTP, SSH, etcetera). Because the attacker has gained access to the file system, he/she likely has the decryption key which means he/she can just decrypt the database and it's game over.

However, you have an advantage here because you have both a frontend server and a backend server. This means you can implement a more secure design to protect against situation two. You can encrypt/decrypt on both servers which means the attacker would have to compromise both server file systems. Here's what I mean: the frontend server can encrypt the sensitive data using its own key; send that data to the backend server; the backend server then encrypts the encrypted data using a different key; and finally the backend server stores that double-encrypted data. The decryption process is just the reverse of this: the backend server pulls out the double-encrypted data; the backend server decrypts the first layer of encryption and sends it off to the frontend server; the frontend server then removes the second layer of encryption; finally the frontend server displays the decrypted, sensitive data to the user.

This all said, like Kevinze's answer states, there are other protections which should be in place. You should be using HTTPS (SSL/TLS) for communications between the user and the frontend server. This would prevent MiTM (in most cases) and help protect the communications between the client and the server. You should also consider other protections like full disk encryption. I cannot give you much information about this, but it would of course add protection to the file system.

In your question, you asked about updating your database and converting it to an encrypted form. If I was in your position, I would construct a new database to store the encrypted information and then write a program to read all entries from the old database, iterate over them, encrypt the sensitive columns, and insert them into the new database. Here's some pseudo-code:

All_Entries[][] = Fetch_Array_All_Entries(FROM_OLD_DATABASE); // Multidimensional Array

for(int i = 0; i < count(All_Entries); i++){
    thisEntry = All_Entries[i];
    encryptedEntry = new Array();
    encryptedEntry["Some Insensitive Column Name"] = thisEntry["Some Insensitive Column Name"];
    encryptedEntry["Sensitive Column 1"] = encryptColumn(Backend_Key, encryptColumn(Frontend_Key, thisEntry["Sensitive Column 1"]));
    encryptedEntry["Sensitive Column 2"] = encryptColumn(Backend_Key, encryptColumn(Frontend_Key, thisEntry["Sensitive Column 2"]));
    // ... Encrypt all sensitive columns and assign them to the encryptedEntry ...

    // Once all encryption is done:
    Insert_Array_Entry(TO_NEW_DATABASE, encryptedEntry);
} // end entry loop

Once the new database has been updated with encrypted entries, simply replace the old database with the new one.

Your question mentions switching from VARCHAR to VARBINARY. This is really your own choice, but you could continue to use VARCHAR if you convert the bytes to a string format. Usually encrypted data is displayed as a Base64 string. Again, you have to make that decision for yourself, but that's how I would likely do it.


Benefit of having multiple DH moduli of same length?

Having only one moduli of some length makes Logjam attack feasible, because the attacker can make pre-computation of parameters for given moduli and them break the communication in fraction of the time needed without the knowledge what will be the prime used.

Having more primes (and of course long enough ones 1024 b and more) mitigates the attack, because even running pre-computation is really expensive operation and making it 40 times is usually blocker.


Ways to secure yourself from Firesheep kiddies and other sniffing

BlackSheep detects Firesheep in action, and HTTPS Everywhere helps use SSL-secured versions of popular sites - both are available as Firefox Addons.  In general though you should try to avoid using high-value sites from open networks - there's no panacea.


Could a user create an img tag that points to their own site with a link that no one would type in (example.com/placeholder/ping/ip/holder/record.php) and just record the ip address of every client that loaded the picture?

Yes.

  Is there any protection against this in web browsers? Is there any way to prevent this except by forcing all images on a website to be hosted by the site?

Well, you can't force the website to do anything, and hosting images on different servers is standard practice (and if it's just a cdn).

What you can do is to set your browser up to only load images from the original domain you are visiting. In firefox this would eg be done via permissions.default.image=3.

There are likely plugins for your favorite browser that make this a bit easier to manage (eg that allow additional image loading with your permission, that let you whitelist some URLs, etc), but that's more of a product recommendation and off-topic.


iLivid infection/ iLivid behaviour analysis

Several sites classify iLivid as a PUP rather than outright malware. The definition in part reads:

  Such software may use an implementation that can compromise privacy or weaken the computer's security. Companies often bundle a wanted program download with a wrapper application and may offer to install an unwanted application, and in some cases without providing a clear opt-out method.

Your statement of "I can say I didn't see any malicious behavior." seems unusual - I found a number of reports from late 2016 that indicates a homepage redirect and toolbar install were to be expected.

The reports also suggest a keylogger has been known to be dropped with iLivid, and your mentioning finding Captlib.dll would, prima facies, seem suggestive this happened on your system - it may be at the time you installed, iLivid was focused on stealth (although given their ad-related income model, that seems a little unusual).

If I was you, I think I would consider running a packet capture looking for automated activity, and notably, for C&C/exfiltration activity.
You may find it easiest to do a first run with something like Cuckoo Sandbox, as a means of testing whether you can replicate the reports that got you curious in the first place.


You've missed a key word in the download page:

  You can verify the signing certificate on the APK matches this SHA256 fingerprint

(emphasis mine)

APK files are just ZIP files in reality, so open it up with whatever archive tool you want (I use 7zip) and extract META-INF\CERT.RSA from it. You can then verify that the certificate fingerprint matches what is written on the site. Note that this isn't the same as the hash of the whole certificate either! You'll need to use keytool to check it.

The keytool binary is included in the Java JDK (usually in the %ProgramFiles%\Java\jdk_<version>\bin\ directory), and can be used as follows:

keytool -printcert -file X:\Path\To\CERT.RSA

Output looks like this:

Owner: CN=Whisper Systems, OU=Research and Development, O=Whisper Systems, L=Pittsburgh, ST=PA, C=US
Issuer: CN=Whisper Systems, OU=Research and Development, O=Whisper Systems, L=Pittsburgh, ST=PA, C=US
Serial number: 4bfbebba
Valid from: Tue May 25 16:24:42 BST 2010 until: Tue May 16 16:24:42 BST 2045
Certificate fingerprints:
         MD5:  D9:0D:B3:64:E3:2F:A3:A7:BD:A4:C2:90:FB:65:E3:10
         SHA1: 45:98:9D:C9:AD:87:28:C2:AA:9A:82:FA:55:50:3E:34:A8:87:93:74
         SHA256: 29:F3:4E:5F:27:F2:11:B4:24:BC:5B:F9:D6:71:62:C0:EA:FB:A2:DA:35:AF:35:C1:64:16:FC:44:62:76:BA:26
         Signature algorithm name: SHA1withRSA
         Version: 3

You can see that the SHA256 fingerprint matches what we saw on the site.

Once you've verified this you can go ahead and install the APK onto your Android device. Since you've verified that the signing certificate inside the APK matches the one that Signal expects you to see, you can then rely upon the Android operating system to validate that the APK is properly signed - it won't allow you to load it otherwise.


Set up your own DNS recursive resolver with DNSSEC and set an outgoing firewall policy blocking DNS requests to anything else. ISPs tend to abuse DNS, you don't want to use their servers, even if they are configured correctly.


Transmitting sensitive information using an HTTP GET request should be avoided at all times, as it could be cached or end up in (proxy) server log files.
I do consider a session based anti-CSRF token as sensitive information. As the name suggests, the token is valid for the duration of the entire session.
As far as exploiting this, this might be rather hard, but it could be exploited when multiple vulnerabilities are present in the application.
Without any other type of vulnerabilities I consider the likelihood quite low.


Build and execute code on a sandboxed environment?

As for the infinity loop scenario you can actually:

Limit the resources granted per container.
Assign the maximum execution time allowed. Optionally kill the container if someone uses 100% of assigned resources for too long (you should monitor the use of assigned processing time).
You can monitor the prcesses in the deployed containers for any strange patterns.

As for the security, it is as safe as your sandbox is, you should be at lookout for any escaping technics and vurnebilities related to that.


Need Explaination to Xerosploit's Sniffer Function code

xettercap is part of xerosploit and a wrapper around the now legacy ruby implementation of bettercap.
As such, all the options are just passed down to bettercap. Here is a quick rundown of the options you asked for:

-P, --parsers PARSERS
Comma separated list of packet parsers to enable, * for all ( NOTE: will enable the sniffer ), available:

COOKIE
CREDITCARD
DHCP
DICT
FTP
HTTPAUTH
HTTPS
IRC
MAIL
MPD
MYSQL
NTLMSS
PGSQL
POST
REDIS
RLOGIN
SNMP
SNPP
URL
WHATSAPP

Default is * (enable all)

As for which options to choose if you want to see "important" things depends on what you define as important. You specifically mentioned post data, so I recommend using -P POST at least. The documentation mentioned that enabling all parsers is the default, so I think you can't go wrong with that.


How does zeroing out/wiping your disk before encrypting it increase op-sec?

I think one source of confusion is about the order of operations. This page may help (or not).

Basically, this comes from a situation where the encryption is about to be applied on a complete, logically empty partition. Applying the encryption is easy because you just have to ask the OS to thereafter apply encryption whenever it is going to write something on the disk. However, there is no preparatory step for existing partition contents: these are all unused sectors anyway, so nothing will read them in the course of normal file management.

If the partition contained non-random data, then sectors that have been written to are encrypted and "look random", while sectors that have not been written to yet retain the bytes that were originally there, i.e. the non-random bytes. Observers may then infer which sectors have never been used. Whether this gives them any advantage is anyone's guess, but it seems that it is sufficient for some people to panic a bit and ask for a preparatory wiping.

The point of such a "wiping" is to populate the physical disk with bytes that will be undistinguishable from encryption output, i.e. they must "look random" since encryption output is supposed to en undistinguishable from random bytes. There are two main methods for that:

You overwrite the complete partition with random bytes (e.g. from /dev/urandom) before you apply the encryption.
You overwrite the complete partition with arbitrary data (typically zeros, because /dev/zero is there and just begs to be used) after you enabled encryption, because then the write on the physical medium will be done with encrypted data, that really looks like encrypted data, which was the point.


How can antiviruses protect our computers if virus maker checks them with antiviruses?

Because we know that the antivirus can detect what it was tested to detect.
There is no "silver bullet" in security. There is no one thing that will magically protect everyone from everything in the future. Security is about reducing risks and defending against specific threats.
And eventually, the antivirus makers will be able to detect the new virus. So, really, all you are worried about is the window of time where the new virus is released and when the antivirus starts to detect it. And since no virus can hit all computers at once when it is first released, you also get a reduction in risk by the fact that the chances are low that you will ever see a truly new and novel virus that your antivirus will not detect.


There are two "unknowns" that the attacker has to contend with.

First, the attacker is overflowing a buffer, supposedly on the stack, and among the bytes which follow the buffer in RAM are the bytes which store the "return address" where execution jumps after the current function is finished. The attacker wants to overwrite these bytes with another address, making the CPU jump into code written by the attacker. The first unknown is then: "what is the distance between the buffer (that is overflown) and the return address slot ?". The attacker must guess that, so as to know at which point in the attacker-provided data the "return address replacement" must be set.

The second unknown is the actual address of his shell code. In a traditional buffer overflow on the stack, the shell code is part of the data which triggers the overflow, i.e. it is in the buffer. The return address is absolute so it is not sufficient for the attacker to know the code of the attacked function; the attacker must also know what is the stack depth at that moment, and this depends on previous application behaviour.

The NOP slide, or NOP sled, is a simple technique to cope with accuracy issue for the second unknown. When the attacker guesses the address of his shell code with some possible jitter, then the attacker puts a lot of nop opcodes (or similarly harmless opcodes) before his shell code; thus, it suffices that the CPU jumps somewhere in the sled in order to make it, ultimately, reach the shell code.

For the first unknown, the tool is not a NOP sled, but another kind of sled. Simply put, the complete overflow will look like this:

90 90 90 90 90... 90 shellcode addr addr addr... addr

where shellcode is the actual payload, 90 is the hexadecimal code for the nop opcode, and addr is the attacker's guess of the buffer start address in RAM. When the overflow occurs, one of the addr values will overwrite the return address slot, and make the CPU jump at address addr; which one of the addr does the trick is the "first unknown" described above. Usually, the "first unknown" is not that unknown, because it only depends on the layout of local variables in the function itself, which is known through reverse-engineering (disassembly).

The attacker has guessed that the byte at address addr will be one of the 90, so execution jumps there. Which one is not very important, because the CPU will proceed to execute all subsequent nop opcodes and then reach the shellcode.

The pictures you show are indeed quite confusing. They seem to relate to more complex cases where the attacker, for some reason, cannot put his shell code immediately after the NOP sled, but at some place before the NOP sled, so he must then arrange for an appropriate jump at the end of the sled (jump opcodes use relative addressing, so that jump is easy to get right).


Why does Adobe recommend not setting CSP headers for its web fonts?

Disabling CSP altogether is not recommended, but you do have a security impact by allowing inline styles. For example, you could use the following policy:

default-src 'self';
script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https: 'report-sample';
style-src 'self' 'nonce-rAnd0m123';
object-src 'none';
base-uri 'none';
report-uri https://csp.example.com;

This would use 'strict-dynamic' for scripts, and would require you to add a nonce to every tag where Adobe Fonts wants to inject their webfonts. This may or may not be possible, depending on how Adobe Fonts works.

What is the worst that could happen?

If you really have to allow 'unsafe-inline' in your style-src directive, then you may open yourself up to CSS Injection, which may lead to stolen credentials. Of course, CSP should not your only defense against such things, so please don't see it as such.

What about the CSP directive on their website?

Adobe suggests the following CSP directive:

script-src 'self' use.typekit.net;
style-src 'self' 'unsafe-inline' use.typekit.net;
img-src 'self' p.typekit.net;
connect-src performance.typekit.net

The focus on whitelists suggests that this directive was added back when CSP was still very young and only whitelist-based approaches were possible. By using the 'nonce-' approach, you cam ensure that only the inline scripts loaded in specific locations are allowed.


How does a web client check the signing authority of a server certificate?

Public keys of certificate authorities are stored locally for every applicatives on the system.

For example, on Debian GNU/Linux:

$ dpkg -l|grep -i ca-certificates
ii  ca-certificates                       20190110                        all          Common CA certificates
ii  ca-certificates-java                  20190909                        all          Common CA certificates (JKS keystore)

When you look at ca-certificates content:

$ dpkg -L ca-certificates|head -n30
/.
/etc
/etc/ca-certificates
/etc/ca-certificates/update.d
/etc/ssl
/etc/ssl/certs
/usr
/usr/sbin
/usr/sbin/update-ca-certificates
/usr/share
/usr/share/ca-certificates
/usr/share/ca-certificates/mozilla
/usr/share/ca-certificates/mozilla/ACCVRAIZ1.crt
/usr/share/ca-certificates/mozilla/AC_RAIZ_FNMT-RCM.crt
/usr/share/ca-certificates/mozilla/Actalis_Authentication_Root_CA.crt
/usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt
/usr/share/ca-certificates/mozilla/AffirmTrust_Commercial.crt
/usr/share/ca-certificates/mozilla/AffirmTrust_Networking.crt
/usr/share/ca-certificates/mozilla/AffirmTrust_Premium.crt
/usr/share/ca-certificates/mozilla/AffirmTrust_Premium_ECC.crt
/usr/share/ca-certificates/mozilla/Amazon_Root_CA_1.crt
/usr/share/ca-certificates/mozilla/Amazon_Root_CA_2.crt
/usr/share/ca-certificates/mozilla/Amazon_Root_CA_3.crt
/usr/share/ca-certificates/mozilla/Amazon_Root_CA_4.crt
/usr/share/ca-certificates/mozilla/Atos_TrustedRoot_2011.crt
/usr/share/ca-certificates/mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt
/usr/share/ca-certificates/mozilla/Baltimore_CyberTrust_Root.crt
/usr/share/ca-certificates/mozilla/Buypass_Class_2_Root_CA.crt
/usr/share/ca-certificates/mozilla/Buypass_Class_3_Root_CA.crt
/usr/share/ca-certificates/mozilla/CA_Disig_Root_R2.crt
[...]

Every single files contains a certificate, for example:

 cat /usr/share/ca-certificates/mozilla/Amazon_Root_CA_2.crt
-----BEGIN CERTIFICATE-----
MIIFQTCCAymgAwIBAgITBmyf0pY1hp8KD+WGePhbJruKNzANBgkqhkiG9w0BAQwF
ADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQQDExBBbWF6
b24gUm9vdCBDQSAyMB4XDTE1MDUyNjAwMDAwMFoXDTQwMDUyNjAwMDAwMFowOTEL
MAkGA1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEZMBcGA1UEAxMQQW1hem9uIFJv
b3QgQ0EgMjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK2Wny2cSkxK
gXlRmeyKy2tgURO8TW0G/LAIjd0ZEGrHJgw12MBvIITplLGbhQPDW9tK6Mj4kHbZ
[...]
9jVlpNMKVv/1F2Rs76giJUmTtt8AF9pYfl3uxRuw0dFfIRDH+fO6AgonB8Xx1sfT
4PsJYGw=
-----END CERTIFICATE-----

The syntax you mentionned for Curl is if you want to override the system-wide certificates store to, for example, use your own certificate authority.
It's called bundle because you may have several certificates involved in the signing process. For example: "Root CA" -- sign --> "Intermediate CA" -- sign --> Final certificate, so in this case, your bundle must contain both "Root CA" and "Intermediate CA" to succeed verifying the whole chain.


Can't generate a CSR request with CA set to true

Why am I not seeing the CA set to true?

Because you are not looking at the part where it shows this. Look further down at the CSR Detailed Information:

    Requested Extensions:
        X509v3 Basic Constraints:
            CA:TRUE

If you want to know why these information are not included in the summary and properties section of the output than you have to ask the author of the website/tool you are using.

Apart from that, you don't even need such external tool to look at the CSR details. openssl req which you've used to create the CSR is perfectly fine to also look at the CSR details: openssl req -in out.csr -text.


RBAC model: user in two roles access dilemma

It seems that you are conflating between RBAC and DAC (Discretionary Access Control): Deny Access is not typically employed in RBAC, but rather it comes from the DAC world. F.e. its common to see an NTFS ACL (Access Control List) with DENY in it.

You might be trying to implement a merged model (see the example in my response here) - e.g. building an ACL with ACEs (Access Control Entry) pointing to roles. E.g. using groups to grant access to folders...

There are two possible solutions you can use, perhaps even mix'n'match, depends on what makes sense for your system (I've built and used both, in different contexts):

Ordered ACL - i.e. the ACL is not a big pile of ACEs, but they're in a specific order: higher on the list takes precedence, keep evaluating ACE until you find either a PERMIT ACE, or a DENY ACE for that user. Whichever is first on the list, wins.
DENY ACE overrides all other ACEs. I.e., if the user is granted access via Role1, scan the ACL for any DENY that applies to the user, and then Role2 would block access no matter what.

Note that you might not be implementing this with a standard ACL model, but truly only checking the user roles - that's still fine, the above still applies (just harder to visualize and explain).

The real question you need to figure out is, What makes sense for your system? Are you trying to implement SoD (Segregation/Separation of Duties)? If so, it's clear that DENY must override any PERMIT. If you want the user to configure this (in which case its DAC, not RBAC), the first option gives the most flexibility, since there IS a way to work around it.


Extract issuer public key from certificate pem file

The issuers public key is not part of a certificate. Only the public key of the subject itself is contained in the certificate. The issuers public key is contained in the issuers certificate (CA certificate) which need to be known by the one validating the subjects certificate.

See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for more information.


A Question About HTTPS Certificates & Their Fingerprints

The certificate of a site can change any time (for example if it gets renewed) and thus the fingerprint will change too.

I don't know what kind of attack you fear but if you think that some hacker is able to man in the middle your connection to some HTTP site and will only do it sometimes then this hacker might be able to intercept the connection to grc.com too and change the fingerprints shown to you which means this looking at this site is not an effective way to detect such an attacker. But unless you have to do with a hacker which managed to hack a CA to get the certificates he wants and thus can do silent man in the middle attacks, the browser will warn you that something is wrong.

If you instead fear that your computer might be infected by some malware which installed new trusted root certificates for silent MITM attack then it is enough to check from time to time if the certificates have changed. Note that certificates also change in case of legal SSL interception which is done by many antivirus products and enterprise firewalls.


How to communicate a positive feeling about ethical hacking to non technical people?

Sadly I think that such situation isn't new and isn't going to disappear in the near future. I don't know if you ever read the Hacker Manifesto? This text was written in the eighties, but chances are that you will recognize yourself in some aspect of this text...

It is interesting in your text that you first explain that you had difficulties to make friend, so you thought how to resolve the issue and finally made up a solution. So now you are reaching step two: how to deal with the authorities (I could limit it to the school administration, but I think the problem is more general than that, the school administration people just react to the wrong image that hackers have in the usual (sub)culture).

I worked as technical support engineer for a few years. Starting from day one, we were told to use the word "issue" as few as possible, and in all case to avoid the word "problem" at all cost. Instead, when communicating with a customer, we should only discuss about "unexpected behaviors", "fixes" and "improvement".

This might sound silly, but the fact is that using positive words makes your audience in a positive feeling, while using negative words just amplifies all the wrongs feelings they may already have.

So my advice for your next step, now that you have the technical skills, would be to develop your "marketing side".

You talk about bugs, exploits... Arrgh, such twisted, chilling, horrible words are they to the ears of the principal. Some kids loose themselves by touching drugs, this one touches BUGS! May someone save his soul!

Would you talk instead of sharing good practice from instance. In some way, ethical hacking is just about that: someone does not apply some good practice, causing a security weakness on his system, so you share good practice with him for his and others safety.

Would you imagine the principal stating "I'm a principal, do I go and share good practice with other schools"? I suppose you get my point ;). Added to the fact that using positive words makes people in a more positive feelings, it also lets less room for them to argue. It is easy to criticize someone hacking into systems, breaking security measures and exploiting bugs. It is less easy to criticize someone for sharing good practice, for acting as a good and responsible civilian taking his share to participate to public safety.

Another point is, I do not know the exact relationship you can have with the people working for your school, but it would be of great help if you could "sympathize" with some IT staff or related. The goal here being to be visibly helpful, so it would not be kid's word against principal's words, but that someone else working for the school (and thus someone whose words are more trustable from principal's point of view) can testify to the fact that, for instance, you gave some advice to solve a network or computer issue, that you are involved in helping other's difficulties, etc.

I'm conscious that there is most likely no real "IT people" in the school, the goal here is just to be flagged as a clean, helpful, benevolent and responsible person. If you don't do anything, due to your unusual and misunderstood hobbies, you are flagged as an irresponsible nasty looser by default. It's up to you to try to reverse this flag by choosing which image of yourself you want the other to perceive. This passes by the words you employ and by your visible actions, so choose both well.

At last, you may also begin to build some kind of a CV, it could be as simple as:

A listing collecting where and how you brought your technical help. The more concrete the better: "I'm finding bugs to prevent bad people from exploiting them" does not tell anything to the principal (except that your deal with something related to bugs and bad people), "the website example.com had a flaw allowing anyone to access all user's personal information, I informed the site owner so he was able to correct it": how one can reasonably be against such initiative?
If you participated to some public competitions, no matter the result, such competition would be steps towards the certification exams you will encounter later in your professional life,
If there is any public project in which you were involved. Involvement implies relationship and responsibility, and the links and participation you create now may be useful for you in the future (having participated in a open-source project is always a large bonus when applying to high schools).

Writing and maintaining such listing will be useful for you in the future, and I would definitively not imagine a principal arguing that you are destroying your future if you say that "IT security engineers are effectively needed and largely hired by companies, and I'm studying to become one of them. By the way here is my CV"

To summarize all this in three words, it would be communicate, communicate, communicate. Choose your words, avoid anything which might be wrongly perceived, cooperate with the school administration so they learn to know you a good way, whenever possible use your personal experience for school projects (I remember for a subject-free presentation in English course having presented the basis of reverse engineering to my schoolmates ;) ).


If I send 4mbps of data to a friend with 4mbps connection, will I DoS him?

Assuming you're just throwing data at a closed port, your friend will notice a substantial slowdown in his Internet connectivity and an increase in packet loss, but it will not result in an inability to use the Internet.

Think of his connection as a pipe: you're trying to throw 4Mbps down a 4Mbps pipe, and he's trying to pull additional data down.  Something has to give, and it happens in the form of dropped packets.  The packets to drop are selected randomly, and since most of the packets are your attack packets, they will also constitute most of the dropped packets.  Packets he wants will get through often enough for the connection to be somewhat usable.

In order to perform a bandwidth-starvation attack of the sort you're describing, you need to throw far more data than the target can handle, so that almost all of the data the target wants gets dropped.

(Terminology note: this is a DoS, not a Distributed DoS, since you're only attacking from one location.)


Even with ciphers using 3DES or RC4 an attacker is not able to crack the cipher with moderate costs. And even secret services would probably rather do DNS MX spoofing or simply strip the STARTTLS from the features of the receiving MTA because this is much cheaper than trying to crack such ciphers.

Therefore I recommend that you accept ciphers with RC4 and 3DES in case the peer MTA can have no better ciphers, because bad encryption is definitely better than plain text and in many cases also better than not delivering the mail at all. Of course you should put these weak ciphers only at the end of your list and prefer the strong ones. And you should not use way to weak ciphers like the EXPORT ciphers.

But, if you in an environment with higher security requirements you should configure your MTA to only use strong ciphers and to make TLS mandatory, i.e. no fallback to plain even if the peer does not seem to support TLS. And you should protect yourself against MX spoofing too, i.e. enforce DNSSec. Apart from that you better use end-to-end encryption (PGP, S/MIME) in such an environment anyway.


The replay cache was introduced in V5 and is new in V5.


Key Transparency makes it possible for users to know about all the public keys that are in the user's account, preventing the server from adding public keys to a user's account without detection.  Key Transparency does this by using piece of blockchain technology called a Merkle Tree.

When Bob wants to talk to Alice, he first asks the server for

Alice's latest public key
An inclusion proof of Alice's public key in the latest key-value database snapshot (Map Root)
An inclusion proof of the latest snapshot in a log of global state (Signed Log Root).

This proves to Bob that Alice's key has been publicly committed to and that Alice can see it.

When Alice audits her account she walks through the merkle tree to see all the public keys that have ever been in her account.  If there are any public keys that she does not recognize, she can remove them.

Manual fingerprint comparison still has value because it proves to Bob that Alice has indeed inspected her account for public keys she does not recognize. But for all those times that people don't check fingerprints, Key Transparency helps make sure that everything is still OK.


Yes, there are obvious flaws. Here are some:

You can’t make hashing slow by introducing simple delays. An attacker doesn’t have to evaluate the hash the same way you did; they just need to get the same answer in the end. That means whatever is making the hash slow needs to be a necessary component of the hash — it must be impossible to compute the hash without doing that. In fact, the sleep(1) is the kind of thing you have to avoid, in that it makes legitimate hashing slower than an attacker’s hashing (the whole point of hash design is to minimize the advantage of an attacker).
The number of iterations is the length of the password. This isn’t enough. You want at least tens of thousands of iterations.
The salt appears to be global. That’s not a salt; a salt has to be different for each user.
This isn’t a standard algorithm. That means that it’s not a good idea to trust it for actual use. There are three algorithms with a fair amount of analysis (scrypt, bcrypt, PBKDF2). These have been looked at by actual cryptographers, and seem secure. Use one of them.
The correct way to do a password hash in PHP is with the password_hash function, which handles everything for you (implementing an algorithm yourself is a poor idea for security just as much as creating your own algorithm is).


Could ransomware be stalled while encrypting?

Your suggestion is interesting; unfortunately a generic solution is not possible as there is no combination of bits that would cause an encryption algorithm to "stall".  Encryption is just math, after all.  Perhaps use of a rootkit could trick ransomware into believing that it's encrypting a fake yottabyte-long dummy file handle, or it could have delays built in that hand out the bytes from the file very very slowly, but those kind of approaches are likely to impact normal usage of the computer as well.

There might be specific versions of ransomware that have implementation bugs that you could somehow exploit to make this happen, but that approach has numerous problems.  Malware authors and script kiddies evolve and change ransomware programs all the time, so depending on a bug in today's version is no assurance that you'll be infected by the same version of ransomware tomorrow.  And there are hundreds or thousands of different ransomware programs out there today; no exploitable flaw is going to be present in all of them.

@HameJames approach is one way of attempting to detect ransomware in action, but there's no guarantee that his trap file will be the first file encrypted by the malware and will shut it down in time, or if it's the last file and the shutdown just makes it worse.

Your best defense at this point is still operational security.  Make regular backups of important files and keep them offline.  Don't open unexpected email attachments, or click on phishing links.  Keep your security software up to date, and your systems patched.  All the normal advice still applies.


How to document the Encryption or Hashing Method used in a Document?

You might be interested in RFC 3369, the Cryptographic Message Syntax standard.  It includes the relevant metadata which describes the information you're seeking.


Sending Secret data over HTTPs from embedded system

The traffic between A and B is transmitted over HTTPS and is thus encrypted and authenticated. If properly implemented, it is not possible for an attacker to see this traffic, even with access to the network.

For this to be secure the client device has to do proper verification of the server certificate. Is the certificate properly signed and does it belong to the correct domain?

A typical way to intercept HTTPS traffic is to configure another root certificate to be trusted on the device. You should not allow the user to configure the device this way.


User submitted iframes - what to watch out for?

You would have to validate every part of the input very strictly: input format, tag name, tag format, all attribute names, all attribute values. A single mistake in the validation process might leave you vulnerable to XSS. In your steps for verifying the input you only mentioned a check on the tag name (iframe) and a check on the src attribute. That's not enough because you would have at least to make sure there are no attributes related to JavaScript events: onload, onmouseover, onclick, etc. There are a lot of them. A tag like this would execute JavaScript when it's loaded for example:
<iframe src="https://www.youtube.com" onload="alert('xss')">

Then maybe the style attribute could in some cases become dangerous, maybe by loading external URLs with some trick like style="background:url(...)". I have seen some of such tricks listed in some XSS cheatsheets, and while they might only work in some browsers or in some restricted cases, the fact that such tricks exist tells me that you had better watch out. Google "XSS cheatsheet" and take a look at some examples if you want to see some "scary" examples of how attackers can be "creative" when trying to circumvent filters and rules. And then there might be other attributes that could be used to cause trouble, or maybe new risky attributes will be added to the HTML standard in the future, who knows? We all know that blacklists are not considered secure, and you should validate everything with a whitelist. But at this point it's probably going to be a lot of work for nothing.
All this is probably not worth it for your purposes, and it's easier to provide your own predefined safe iframe tag. You probably only need the ID of the video, all the rest of the information is unnecessary and potentially dangerous. So you could extract the ID of the video, validate it, and then build your own iframe tag safely on the server side.
I read that you are worried about advanced parsing, but you don't need any advanced parsing for your simple purpose. For example, the following regex should be enough to match the video ID in an iframe, no matter what the other arguments are, and even if the tag is malformed (you don't really care if it's a perfectly valid iframe tag, all you care about is the intention of the user to embed a youtube video with an iframe).
/<iframe [^<>]+src="https:\/\/www\.youtube\.com\/embed\/([a-zA-Z0-9_-]+)"[^<>]+>/

Of course you can use an HTML parsing library for this purpose too. You might need to check if other characters are possible in the video ID, because I'm not sure if dots are also allowed, for example. You don't need a separate step for validating the video ID, because it's already validated by the regex (valid IDs can only contain the specified characters). Then you need to remove the iframe tag from the user input, and replace it with your safe tag. Your safe tag will just be static HTML where you only replace the video ID with the one provided by the user. For example, in PHP it could be something like this:
echo '<iframe width="560" height="315" src="https://www.youtube.com/embed/' .
     htmlspecialchars($matched_video_ID, ENT_QUOTES) .
     ' frameborder="0" allow="..." allowfullscreen></iframe>';

Note that I used htmlspecialchars (or you could use urlencode too) even though it was not necessary, because the video ID was validated and can only contain safe characters. I sanitized the variable anyway because I think it should be a habit to do so, no matter if at the moment such a weakness would not be exploitable.
A final warning
I'm not sure where the user is going to put that iframe, and I'm not sure if the user is already allowed to use other HTML tags. If the iframe is the only tag they can use, and that iframe is going to be embedded among other text, then you need to make sure the user won't try to use other tags anywhere else. In other words, special characters like <>& will need to be encoded everywhere in input coming from the user... except that you need to keep the iframe. I'm not sure how you are going to do this. You could remove the iframe code at first, sanitize the output by encoding the special characters, and then only add the iframe back again at the end. Or you could try out something like HTML Purifier if your needs become a little too complex.


What you want is not a collision but a second preimage.

A collision is: find two distinct messages m and m' which hash to the same value.

A second preimage is: given a message m, find a distinct message m' such that both messages hash to the same value.

Second preimages are harder because the attacker does not get to choose both messages at will. MD5 is very broken against collisions (collisions can be generated in less than a second) but not against second preimages. For that, the best known attack is a generic preimage attack which is theoretical only, since it has cost 2123.4, i.e. much higher that what can be done in practice.

So the raw answer to your specific question is: it cannot be done (with existing technology and known attacks on MD5).

(I am here talking only about finding a second preimage on MD5, not about the security of using MD5(salt + data) in any specific context, whether 'salt' and 'data' are known or not. I suspect that anybody who uses MD5(salt + data) actually wants either a password hashing function, or HMAC.)


Why ARP Poising is not working for some sites?

The answer to your question seems to lie within the link you have referenced.

Computer programs follow specific instructions, and in this case the ettercap filter is set to:
replace("img src=", "img src=\"http://www.irongeek.com/images/jollypwn.png\" ");
replace("IMG SRC=", "img src=\"http://www.irongeek.com/images/jollypwn.png\" ");

The character string "IMG SRC =" is not the same as "IMG src=" or "img title='123' src=". If the website developer has used a set of characters different from your filter in any way, then the filter will not work.

  Keep in mind that this filter does not seem to fire off for all images, it's a little hit and miss

This may be so for the logical difference as explained above or a part of a packet congession/load release mechanism that drops some of these packets without filtering.

  Can sites mitigate ARP?

No. These sites have either adopted a different style guide for img tags or maybe they simply don't have one. Like irongeek says, ARP mitigation is most effective through static cache, IDPS, or Arpwatch on the local network.

I would suggest reading a more detailed overview of the ARP, IP and frame delivery protocols for a better understanding of the exploitation and mitigation of this attack vector.


There are several moving parts here and you, admittedly, do not have all the technical details, but it does appear to be 2FA on its face, with a caveat:

The app is associated with the account and the phone, making the phone a factor (but that depends on how the phone is associated with the account)
The login process requires a biometric scan of the fingerprint, making the finger a factor

This process is not unlike a 2FA app on a phone (Google Authenticator, LastPass Authenticator, Microsoft Authenticator, etc.) that requires biometric authentication to open and uses push notifications. In your case, the push notification appears to be done via QR code.
However, this is pretty weak, passwordless 2FA. Since all the relevant factors are contained within the phone, that makes this more of a "1.5 Factor Authentication". The phone's app is the primary factor for the account and the app has its own factor, the biometric function controlled by the phone's hardware. Chaining them like this is not true 2FA for the account. It's more like two "1FA" processes chained together on the same device. This matters because the loss of the device alone puts the whole protection scheme in jeopardy; you are relying on the security of the functions of the phone.
Could it be considered to be "effectively 2FA"? That could be argued. To be honest, I would hedge my opinion and stick with the "1.5 Factor" answer. I know that it is not a clear answer, but the line to be drawn will depend on why you need to know if this is 2FA or not.


is it OK to grant permission for IUSR_ to cmd.exe?

In my opinion, there are two problems here:

Your developer is directly spawning shells to perform operations. This is a sign of poor quality code, a dodgy workaround, or your developer not having enough time / experience to perform the operation himself. You need to find out which it is.
Allowing _IUSR access to cmd.exe opens up some nasty possibilities for shellcode, should your IIS service later be found to be vulnerable to a remote code execution bug.

Ask him exactly what he's launching, and ask if he can find a workaround. If he's running some sort of external task, why isn't he using the Windows Task Scheduler API rather than directly spawning shells? If he's using an existing utility (e.g. xcopy, ping, etc.) as a hacky workaround you should ask him to do it properly, and allocate the appropriate time and resources for him to do so.

Remember that a flat "no" is useless to him as a developer. Explain exactly why it'd be a security issue. If possible, back it up with something from your security policy. Try to be empathetic of his situation - developers usually have 6 months worth of work to get done in 6 weeks, so a workaround is golden. If it's a case of him not having the time to do the job properly, speak to the project manager and see if the scope can be altered.


When is it posible to sniff VPN traffic?

Between two endpoints of a VPN connection that uses a properly-negotiated secure algorithm, one cannot decipher the encrypted traffic. Some things that can keep that from working right (in order of likelyhood):

Your attacker got between you and your VPN or between your VPN and your destination allowing them access to the cleartext.
Your VPN system didn't authenticate the host on the other end. You setup a secure connection to your attacker.
Your VPN system is configured in an insane manner, possibly allowing very weak keys or just encapsulation with no encryption.