When connecting to a server using ssh but you do not authenticate using a private key, what key is used to encrypt the data that is transferred?

The users key is used for authentication of the user only, similar to the optional client certificate in TLS (which includes HTTPS). Encryption is done with a key created using a key exchange algorithm like Diffie-Hellman but only after authorizing the server to protect against man in the middle attacks. Insofar is SSH similar to TLS.
For more information have a look at Understanding the SSH Encryption and Connection Process.


Why should XSS filters escape forward slash?

Back before HTML 5 came with a standard parsing algorithm, HTML 4 was defined based on SGML.
And its SGML-based syntax had features that differed in terms of browser support and differed in terms of people being aware of them.

One of the more obscure features that you'll be interested in, for the purposes of this question, is Null End Tag (NET).
Have a look at the following code for an HTML page:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title/hello/
<body>
<p/hello/

If you want, try putting it through an HTML validator.
NET specifies that code like <TAGNAME/text/ is parsed into the same thing you'd get from <TAGNAME>text</TAGNAME>.

From here, you may be able to see why it's a good idea to escape the / character when interpolating user-provided data into markup. A / could potentially end up in one of these NET constructions and be interpreted as the end tag, instead of a literal solidus.

Sure no browser now understands the NET syntax, but it's part of the spec, so it's prudent to account for it.


Here are a few tips about encrypting external drives:

use only open-source software - only that way you can be sure (if you check the source code or believe that the community does :P) that there isn't any backdoor + community can fix bugs which could otherwise be critical
consider whether you want to use hidden volumes
use software that allows you to choose the encryption algorithm (such as AES)

TrueCrypt is not being maintained anymore, but its fork, VeraCrypt is being actively developed and features everything mentioned above.

You may want to consider file encryption (not disk encryption) too.

I'd suggest using GPG for that. You can use both symmetric and asymmetric cryptography with it.

These are just my suggestions. Depends on your needs. Choose what suits them best.


Fixing the high-bit problem in PHP's crypt() implementation

Base64 output is limited to ASCII digits, letters (lowercase and uppercase), '+', '/', '=' and newline endings (CR and LF). All of these fit in the lower 7 bits.

Using Base64 encoding has the unfortunate side-effect of enlarging the data by about +33%. Since bcrypt has a size limit of 55 characters, so with Base64 encoding you are down to about 39 bytes.

Also, non-ASCII password characters open up the murky business of code pages (Unicode, UTF-8, Windows-1252...) and Base64 does not solve that; it just pushes the problem under the rug.


I want to be a cybersecurity professional, but it feels as if I am so far behind. What do I need to do to catch up?

Getting the skills in an area like this is 90% personal effort. My courses in Computer Science gave me a basis, networks, coding, databases, virtual machines, setting up simple web services etc.

Coming to security-specific approaches, we had some mentions or some tasks we had to do over some assignments (sql prepared statements, ssl certs, learn how to apply a rule in iptables, etc.). Those little things could give someone a kick-start, but becoming more than a hobbyist needs more. I needed a challenge, something to make me start thinking "how do I use all these?"

I found sites with security challenges and live machines I could attack. I tried. I was failing, googling, failing again, googling again until at some point, I found a solution! 1, 2, 3 times you learn a few tools and create a methodology. You keep on playing and expand it and learn something new all the time. And someone could say "yeah, its a ctf challenge, you don't see those things in real life". True (you usually see even worse). But it's the way to get a grasp on things, so when you join a team or a company you can have a basis to get learning even more technical stuff.

Make yourself a lab, join a few CTF sites and learn how it works.


How to prevent malicious DLL from getting used in LoadLibrary or DllImport (.NET) calls

DLLs and other binaries could be signed (see here for how to check signature).

If they are not, or if you don't want to go that way, but you know what library you are supposed to load, then you can verify the library's checksum before loading. Acquire a read lock on the library and release it only after successfully loading it; this way, you avoid the small chance of a race attack (replacing the DLL after the checksumming but before the loading).

But yes, you need to load the library using the explicit full path, otherwise an attacker can just place a the DLL with the same name in any directory that's checked before the right one. So:

get the full path
lock the file
verify its signature
load the file
unlock the file
lather, rinse, repeat for the other DLLs

One possibility to verify whether Authenticode is trustworthy or not is to supply a tampered library of your own. Try loading it and verify that Authenticode check fails. If it does not fail, you will know that the system has been tampered with, and is not to be relied upon.

Just to be sneaky, you can try loading the tampered library and set a flag, do a bunch of other things, then acquire a lock on wintrust.dll and generate a checksum. Whatever the checksum says, if the flag has been raised, refuse to go on and act as if the checksum was invalid (you could inject the flag's contents into the algorithm to ensure the check will fail).


Private REST API accessible only via SSH?

Regarding the proposed solution

It solves the problem of MITM/DDoS attacks, As long as your HTTP server doesn't serve to non-local requests. However, you are introducing a new attack surface (the SSH port).

A Different Approach (based on client-friendly approach)

Instead of creating another attack surface (SSH),you have other standards to cases like that:

Using SSL+OAuth as you have suggested, doesn't add the new attack
surface, and let's you ignore requests which are not having a
legitimate token. if you decide to implement Oauth based solution -
DON'T DO IT YOURSELF, because it's a complicated protocol, an you might end up with a lot vulnerabilities. Of course, there are
open sourced libraries for that :)
Using SSL + Cookies/Token bearer (such as JWT) - might be even simpler than Oauth.
Using Client SSL Cetrificate - since you have only 5 clients, this might be a great fit, since it's super simple, and doesn't require too much boilerplate code and maintenance. Furthermore, in some web servers (such as in Apache HTTP Server)
you can validate it in the server, instead of running your own code, which could be translated to a boost in your performance.


There are several ways to inject ads or malware into a specific web page:

Inject into the browser itself using DLL injection or browser extensions: How this need to be done is specific for each browser.
Attack the server itself: But then you have only the single server compromised.
Or inject yourself in the connection between browser and server: This can be done be either modifying the proxy settings as in your question. This can also be done by modifying the DNS settings of the system like done by the DNSChanger trojan or even of the whole network by attacking the routers.

Thus changing the proxy is one of the easier ways to inject your ads and malware into all browsers on the system.


How to extract windows event logs from a hard disk forensic image?

Windows event logs are stored in the following locations by default:

2000, XP and 2003

C:\Windows\system32\config

Vista+

C:\Windows\system32\winevt\logs

Event and parameter message templates

The event and parameter message templates specific to each type of log are stored in DLLs (so you can interpret the messages and parameters in context for each log) and their location is stored in the Eventlog key in the Registry, located at:

HKLM\SYSTEM\CurrentControlSet\services\Eventlog

You can also use this key to validate that the event logs are being stored in their default location since an administrator can change this (such changes will be reflected within this key sub-path).

"Dirty" evt logs

When copying event logs off of a live system, for the older *.evt logs (2000, XP and 2003), they have a file status byte that sometimes can prevent reading the logs in standard viewers when it is an odd value. Fixing the logs is well documented, and there used to be a tool called fixevt.exe that made this easier but I don't know of a reliable download source so I'll leave this exercise to the reader to find it (the site where it used to be located indicates the hosting provider account was suspended).


What are the real-time applications of long term digital signature with timestamp

Digital signatures "expire" because a signature is performed with a private key and verified against the corresponding public key. The public key is linked to an identity (e.g. a legally defined individual) through certificates. The usual standard for certificates (X.509) specifies that certificates expire. Beyond the expiration date, the certificate shall not be used any longer; thus, a digital signature on a document expires: beyond a certain date, it is no longer verifiable. Since user certificates typically expire after two or three years, this is a problem for "real-life" signatures, e.g. on business contracts.

Why do digital certificate expire ? There are several answers. The scientific answer is that a certificate "guarantees" exclusive control of the private key by its designated owner, and no Certification Authority wants to make such a guarantee without any limit in time; also, technological advances could make a given key weaker over time, thus warranting a definite end-of-life. The cynical answer is due to Peter Gutman:

  Perhaps Validity could simply be renamed to RenewalFeeDueDate to
  reflect its actual usage.

Either way, signatures expire. How do we solve that ? With another signature ! Namely, a time stamp. The time stamp is a proof that a given "document" (a sequence of bits) existed at some past date; internally, it is a signature computed over a structure which contains the date at which the time stamp is issued, and a hash of the time-stamped document. The Time Stamping Authority is responsible for maintaining an accurate clock and never to sign a structure with a wrong date.

The idea is then the following: at some time T, we take the initial document, the signature, and all the involved extra objects (all certificates, CRL and other elements) which are used to verify the signature at time T. We assume that at date T, the certificates have not yet expired. Then we put all that in a big bag (imagine it as a Zip archive) and we obtain a time stamp from an adequate TSA. At a later date T', we can verify the time stamp to be valid, and thus we make sure that the whole bag and its contents already existed at time T: therefore, we can imagine ourselves projected back to time T, and we can verify the signature as if the current date was T -- even if, meanwhile, some certificates have expired (i.e. at date T', without the time stamp, we would no longer be able to verify the signature).

Since a time stamp is itself a signature (indeed, have a look at RFC 3161: time stamps are a special case of CMS signatures), it is also subject to expiration. So we have to recurse: at date T'', while the time stamp is still verifiable, get the time stamp and whatever certificates are needed to verify it into a new bag, and have an extra time stamp issued for that bag. And so on. This is like old bare-metal buildings like Eiffel Tower: they can last forever as long as you take care to cover them with a fresh layer of paint regularly.

Details are arcane and intricate. For relevant standards, see:

Evidence Record Syntax: a format for encoding the sequence of successive time stamps. Also includes provisions for recovering from cryptanalytic breaks on hash functions, and uses a smart time stamp sharing mechanism with hash trees.
CAdES: an extension of CMS, for signatures with embedded time stamps and provisions for the time stamp layers.
XAdES: like CAdES, but with XML in lieu of ASN.1 (but the certificates are still ASN.1 based, so XAdES is like Chimera -- alas there is no corresponding Bellerophon to slay it).
PAdES: like CAdES, for PDF files (the signature, certificates, time stamps... get inserted into the PDF file itself; that's what Adobe Reader supports).

Summary: time stamps are a time travel device, but the traveller is just a virtual verifier for signatures.


Is keepass random password generator fully secure and trustworthy?

tl;dr: Yes, it's reasonably safe.

When an attacker knows you use KeePass, then they might also assume that you use the standard settings for the password generator. That tells them the length and the character set [a-zA-Z0-9]. This makes it slightly easier to crack than if the length would not be known and if they would expect that you also use special characters. But even with that knowledge, the generated passwords are still far, far too strong to brute-force.

But how exactly are the passwords generated? If it would be a predictable pseudorandom number generator, that might be an attack point.

Looking at the sourcecode of KeePass 2.30, the password generator seems to be implemented in KeePassLib\Cryptography\PasswordGenerator\PwGenerator.cs. It uses the class CryptoRandomStream from KeePassLib\Cryptography\CryptoRandomStream.cs with the stream cipher Salsa20 used as a random number generator.

The password generator works like this:

A random number is genrated (PwGenerator.cs line 65). It uses the standard RNGCryptoServiceProvider from the .NET framework (CryptoRandom.cs).
The generated random number is combined with some additional entropy if available. I haven't bothered to find out where this entropy comes from (usually unpredictable user behavior like mouse movement or keypresses are used for this), but apparently it isn't assumed that entropy is always available.
A SHA256 hash is generated from the random value with entropy (CryptoRandomStream.cs line 114-118).
That hash is used as encryption key for a Salsa20 stream cypher (CryptoRandomStream.cs line 119).
The stream cipher is used as a random number generator by repeatedly feeding its output as its input (Salsa20Cipher.cs line 176-196).

To predict a password, one would need to crack Microsoft's cryptographic random number generator and predict the entropy (if used).

Alternatively, if someone would crack the Salsa20 cipher, one could predict a password from the previous password. According to Wikipedia "As of 2015, there are no published attacks on Salsa20".

Best regards, Irrationally Diligent Software Developer.


How do I sanitize and check large numbers that will be sent to an unmanaged BigNum library like GMP?

A number is a number. When dealing with numbers, there are three steps:

Decode the values from an external representation (e.g. a bunch of bytes which, in your protocol, follow a given convention).
Apply mathematical operations on the values.
Encode the results.

Buffer overflows due to malicious data will occur only in phase 1 and 3, and then quite rarely. During phase 2, there's no issue of that kind (if there is an overflow, then that's a bug in the library itself, but no such bugs is known for existing implementations -- as a rule, developers for mathematical libraries are maniac about tracking and destroying bugs).

As a user of the library, you must take care of the two following things:

When encoding, do not assume that the value "will fit in a given buffer length". Use the library to see the actual length of the value.
When using a lot of multiplications, integers can grow to unbounded sizes, leading to huge memory allocations and heavy CPU consumption. You may want to include checks on the length of integers at various places in your code, to see whether you are dealing with values which are way larger than they should.

I suggest you begin with BigInteger (from .NET) because that's the simplest and it is already there. Envision switching to something else only if you encounter an actual performance issue, duly measured and quantified.

(You will not have any "floating point error" when using integers, by definition. Floating point is quite another domain.)


Do comparative reviews of OS safety exist, which consider the code volume?

The ideal would be to have a main infrastructure of minimal, open-source code that is distributed in a secure, signed fashion, but still be able to run untrusted code. The first thing that comes to mind is something like Qubes. I don't know of a comprehensive comparison, but i do know they take their codebase paranoia extremely seriously.

  Qubes takes an approach called security by compartmentalization, which allows you to compartmentalize the various parts of your digital life into securely isolated compartments called qubes.

  This approach allows you to keep the different things you do on your computer securely separated from each other in isolated qubes so that one qube getting compromised won’t affect the others. For example, you might have one qube for visiting untrusted websites and a different qube for doing online banking. This way, if your untrusted browsing qube gets compromised by a malware-laden website, your online banking activities won’t be at risk. Similarly, if you’re concerned about malicious email attachments, Qubes can make it so that every attachment gets opened in its own single-use disposable qube. In this way, Qubes allows you to do everything on the same physical computer without having to worry about a single successful cyberattack taking down your entire digital life in one fell swoop.

alternatives:

http://www.projectatomic.io/

https://coreos.com/

http://rancher.com/rancher-os/


Because mythical imagined malware that might subtly modify your unique proprietary source code is very unlikely to exist, there are a couple of slightly more real threats you could check for.

If your friend's computer was compromised by a human hacker, the hacker could have copied your code to his computer, studied it, changed it, and uploaded his changes back to your friend's computer.  (This presumes an attacker who knows who you are, exactly what you are working on, how to find it, and has the means and motivation to carry out such an attack.)  As the developers, you are the only people who would be in a position to know this, and a simple code review should easily satisfy you that this didn't take place.

Another remote possibility might be that this mythical malware hid something in an alternate data stream inside your code.  While this could theoretically be possible, there is nothing on your computer that would automatically extract the payload from the ADS and execute it, so it won't simply infect your computer to copy it in.   If it's a known virus, your own computer's anti-virus would detect it.  Even if the ADS contained a virus, it still wouldn't have a way to execute to compromise your system.  If you want to go with full-blown movie-plot paranoia, this mythical malware could have planted some kind of "illegal" data in an ADS inside your files, as part of a complicated blackmail scheme.

Frankly, the only plausible scenario of risk is that the media containing your files could have been infected by this mythical malware.  Are the files now on a flash drive?  Copy them off the flash drive using a Linux machine (which will be immune to Windows executable viruses and autoruns kinds of attacks.)  Don't copy any files other than the valuable source files.  Java source code files are fine, but PDFs, JPGs, EXEs, TTFs, DOCs, and everything else is not. After you have saved the needed files, format the flash drive.  You can then use a tool like sdelete with the -z option to overwrite the bits in the drive, then sell the flash drive on eBay.


IaaS servers use traditional hypervisors you can install on any computer, typically Xen or KVM (or Hyper-V if you hate money). These typically connect to the network using one of:

an internal virtual interface (TUN/TAP), which you can then bridge or firewall or do whatever you want with at the containing host level
programatic in-process NAT (unlikely in an enterprise setting)
network card sharing (managed by the hypervisor)
dedicated network card

The network model is up to the implementor. The TUN/TAP interface provides the greatest flexibility, since the VM's network interface shows up as an otherwise unconnected interface in the host OS. When and if to send packets to the virtual interface is determined entirely by the host server's firewall and routing tables. It can be complicated to set up and get right, though.

The network card sharing system is probably the simplest, and therefore the most likely. To all the world, it looks like each VM has an ethernet interface all connected to the same switch. But in reality there's only one interface listening in promiscuous mode, with the host OS determining whether or not to send packets to a given VM. The security model there is the same as you'd get with multiple servers on a single broadcast network.

Finally, dedicating an interface to each VM is the most expensive, but also the easiest to understand intuitively from a security perspective. Each VM has a network adapter, you plug the correct cable into the appropriate adapter, and there you go. This is highly unlikely to find at scale, though, since changes require manual intervention.

As far as what security models are in play; again that's up to the implementor. Simpler places will typically provide NO network security (your server is on the Internet, deal with it), but if they do provide private networks, then their mechanism for doing so is their own secret. There are only so many things you can do, though, so you probably can guess.


> I saw different key sizes for RSA algorithm (512, 1024,... [bits] for example) but, is this the length of public key or the length of private key or both are equal in length?

It's the length of the modulus used to compute the RSA key pair.  The public key is made of modulus and public exponent, while the private key is made of modulus and private exponent.

> but the online tools for generating RSA key pairs have different lengths output!

The first picture shows public and private key in PEM format, encoded in Base64 (and not modulus and exponents of the key, which instead are shown in the second picture).

The content of the RSA private key is as follows:

-----BEGIN RSA PRIVATE KEY-----
RSAPrivateKey ::= SEQUENCE {
  version           Version,
  modulus           INTEGER,  -- n
  publicExponent    INTEGER,  -- e
  privateExponent   INTEGER,  -- d
  prime1            INTEGER,  -- p
  prime2            INTEGER,  -- q
  exponent1         INTEGER,  -- d mod (p-1)
  exponent2         INTEGER,  -- d mod (q-1)
  coefficient       INTEGER,  -- (inverse of q) mod p
  otherPrimeInfos   OtherPrimeInfos OPTIONAL
}
-----END RSA PRIVATE KEY-----

while a RSA public key contains only the following data:

-----BEGIN RSA PUBLIC KEY-----
RSAPublicKey ::= SEQUENCE {
    modulus           INTEGER,  -- n
    publicExponent    INTEGER   -- e
}
-----END RSA PUBLIC KEY-----

and this explains why the private key block is larger.

Now, why does the private key contain so much data? After all, only the modulus n and the private exponent d are needed. The reason all the other stuff is precomputed and included in the private key block is to speed up decryption using the Chinese Remainder Algorithm. (Kudos to @dbernard for pointing this out in the comments.)

Note that a more standard format for non-RSA public keys is

-----BEGIN PUBLIC KEY-----
PublicKeyInfo ::= SEQUENCE {
  algorithm       AlgorithmIdentifier,
  PublicKey       BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
  algorithm       OBJECT IDENTIFIER,
  parameters      ANY DEFINED BY algorithm OPTIONAL
}
-----END PUBLIC KEY-----

More info here.

BTW, since you just posted a screenshot of the private key I strongly hope it was just for tests :)


Can any web proxies differentiate between JScript and Javascript files?

According to Wikipedia (https://en.wikipedia.org/wiki/JScript):

  [Microsoft] did not want to deal with Sun Microsystems about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues

So to answer the question in your title, they are the same thing.

Edit: Per comment below from @dandavis, Jscript is actually worse.

I don't know anything about Windows/IE, but I believe you can configure IE to not execute JS (or only for certain sites) - which should mean you could potentially only allow JS to execute for trusted sites, which should limit the attack surface.

If a bit of Javascript was being download by something other than a browser, you could check what the User-Agent for the request is (although you should expect it to be spoofed).

I think (but again, not really my area) things like EMET might be of some assistance, as would something like application whitelisting (I think the functionality is part of AppLocker, but I don't know to what extent it can help).

Realistically, I don't think you would be able to globally block Javascript, because it would break a fair number of sites that people may want to be able to use.

Edited to account for extra info in comment below:

OK - for that case (thanks for specifying), I think there are two ways:

per https://social.technet.microsoft.com/Forums/ie/en-US/11f13026-fbe2-4002-b190-3cc4521247ec/disable-shell-handler-internet-explorer-11?forum=ieitprocurrentver, it seems possible to disable shell extensions, which I think does what you want.
I would expect (but do not know) that either EMET or AppLocker would have something in their options to block Wshell calls (I think I would check EMET first)

If you had a proxy that could do content introspection (and not have to deal with TLS-protected data), you might be able to block specific scripts that contain calls to wshell, but as you say, that is almost certainly going to be a long game of whack-a-mole that only ever mostly works.

Edit: Another thought occured to me, which was to try and force users to select the download dir for all downloads - I assume most would at least pause when seeing a .JS download. Unfortunately, per https://superuser.com/questions/250057/is-there-a-way-to-make-internet-explorer-9-always-prompt-for-download-location#261007, this is no longer possible for IE. It seems to be for e.g. Chromium (https://support.google.com/chrome/a/answer/2657289?hl=en), but that probably doesn't help. It is also a fairly weak protection - and may for that reason be a bit of a dead end.


How to verify which for domains (if any) is this certificate valid for?

First you need to decode all the HTML/XML entities like &#45; etc. Once you've done this you get something like this:

-----BEGIN CERTIFICATE-----
MIIGsjCCBZqgAwIBAgIQCTaYT9gNC0RFj3x3zaPxZDANBgkqhkiG9w0BAQsFADBw
...
-----END CERTIFICATE-----

  which domain(s) it is valid for?

Then you could use openssl x509 -in yourfile -text which gives you the details of the certificate including the domains this certificate is for:

...
Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA

...
X509v3 Subject Alternative Name:
  DNS:*.stackexchange.com, DNS:stackexchange.com, DNS:stackoverflow.com,
  DNS:*.stackoverflow.com, DNS:stackauth.com, DNS:sstatic.net,
  DNS:*.sstatic.net, DNS:serverfault.com, DNS:*.serverfault.com,
  DNS:superuser.com, DNS:*.superuser.com, DNS:stackapps.com,
  DNS:openid.stackauth.com, DNS:*.meta.stackexchange.com,
  DNS:meta.stackexchange.com, DNS:mathoverflow.net, DNS:*.mathoverflow.net,
  DNS:askubuntu.com, DNS:*.askubuntu.com, DNS:stacksnippets.net

  if this certificate is trusted

To check if this certificate is trusted you need to have the trust store you want to check against. And you probably need to get any intermediate certificates. Once you have this see the detailed description in Use openssl to individually verify components of a certificate chain.


Can I develop SSH-based tools within United States?

Most strong-crypto export restrictions have been lifted, but not all. You can't sell to "rogue states" or terrorist organizations for example.

Wikipedia: Export of cryptography in the United States

As always, though, consult a lawyer, not the Internet, with respect to legal advice.


What key attributes indicate candidate potential for future success in a security career?

Generally, you can't expect domain knowledge of a fresh graduate in any field, so you're looking for someone who can solve problems, shows interest in /your/ problems, and will be pleasant to work with. For example, cryptography isn't even common on Computer Science courses, and it's not only CS graduates who will be applying for jobs.


Spyware on Sony Xperia z3 compact ? comand: adb reboot bootloader results in error device not found

I haven't got a SEZ3 but I suggest that you try these actions

Check the same on someones phone to confirm if this issue is with your phone only (it will help if they have same firmware version etc)
this Post shows 3 methods for How to Enter Fastboot Mode on Sony Xperia Z3
Unlock your Bootloader - Sony Official method or Bootloader Unlock/Relock/Flash firmware/CWM Recovery/Root by XDA Developer. Second option will allow you to use unlock/root/flash etc.
If every thing fails then you have no option but to get it repaired by Sony (Who I think are just going to flash the phone with new firmware)

In my humble opinion I doubt that its a malware, it is a case of Sony locking down access to bootloader to access fastboot feature as @Robert Mennell suggested in his answer.


Is Nokia's "institutional MITM" of SSL traffic vulnerable to CRIME attack?

In the system used by Nokia, the Nokia server runs a man-in-the-middle attack (Nokia denies it because they really do not like the term "attack", but this is still, technically, a MitM). Their servers obtain, even so briefly, the decrypted data. Therefore, if Nokia is the attacker, then Nokia wins, and has no need of playing elaborate games like the CRIME attack. Therefore, in this answer, I assume that Nokia is an honest player and that their servers are not hacked into. The question is: can an outsider run a CRIME-like attack on the mobile browsers without hijacking Nokia's servers ? This depends on several things.

But first, we must note that Nokia's browser has been updated and the new version (as of January 11th) no longer runs a MitM on HTTPS connections. This is probably in response to the news items about their use of MitM, which are "bad public relations" and thus needed fixing. Therefore, all I say below must be understood with an implicit past tense: this does not apply anymore.

Also, note that I do not own a Nokia phone, and I am here making inferences based on what has been described "on the Web", in particular Gaurang K Pandya's blog.

1. How is the interception performed ?

When doing a systematic proxying of Web traffic, there are several ways to do it. One way is to define your own protocol between browser and proxy, possibly quite different from the usual Web standards (HTTP and HTML). This is what Opera Mini does: the page rendering is done on the Opera server, and the result is sent to the browser.

Apparently, Nokia's browser does not work like this. Instead, the network traces obtained with Wireshark show that the connection between the browser and Nokia's server is a perfectly normal SSL/TLS handshake. Moreover, the proxy generates a fake server's certificate, issued by a special CA which the proxy controls. That the proxy even bothers with building a fake certificate means that the browser will validate that certificate as if it was a normal certificate. Analysis of the DNS queries shows that the browser does not try to obtain the IP address for the target server, but only for Nokia's server, which the browser knows under its true name. This strongly hints at the following setup:

The browser is a "normal browser" and does not implement a special proprietary protocol.
The browser is configured to use Nokia's server as a generic proxy (with the CONNECT method described in RFC 2817, sections 5.2 and 5.3).
In the set of "trust anchors" known by the browser, to validate server certificates against, is the "special CA" controlled by Nokia.

This kind of setup makes sense, economically speaking, because it allows reusing existing protocols and software; and, to a large extent, it allows switching back to non-interception on the server without changing anything on the clients. (That Nokia actually pushed an upgrade is a bit weird; apparently, they now tunnel SSL through HTTP with a yet unspecified protocol; this deserves further investigation.)

2. What kind of compression ?

Assuming that the browser is a "normal browser", then it would make sense that the use of compression follows a standard scheme. There are two standard ways to apply compression on HTTPS traffic:

Compression at the HTTP level. The body of requests and responses can be compressed with some algorithms, usually "deflate" and "gzip" (the latter being a very light wrapper over the former, they offer almost identical compression ratios -- see RFC 1951 and RFC 1952).
Compression at the SSL level. This one applies on every applicative byte sent through the tunnel; in particular, in the case of HTTPS, it covers both request headers and bodies. There again, "deflate" is used.

SSL-level compression is both simpler to implement (because you do not have to parse HTTP headers for that, you just compress the bytes -- and usual SSL libraries already support it out-of-the-box) and is likely to yield a better compression ratio (because, contrary to HTTP-level compression, it can exploit repeated sequences between successive headers and bodies), I deem it plausible that Nokia used SSL-level compression.

It could be verified by anybody with a Nokia phone (i.e. not me)(and not a phone which has been upgraded in the last few days). SSL-level compression is activated during the initial steps of the handshake, so it would suffice to have a look at the ServerHello message from the server: there is no encryption yet at that point. Wireshark can do that.

Of course, plain SSL-level compression is exactly what the CRIME attack needs.

Thus, my tentative conclusion is that it is plausible that the Nokia MitM/compression system leaves the browser vulnerable to the CRIME attack (actually, left it until two days ago, when they changed their system).

3. Can the attack be really executed ?

The CRIME attack relies on the ability for the attacker to insert some hostile Javascript in a page which the client loads, and to observer the data streams that emerges from the victim's browser and is directed towards a target server. This usually means that the attacker must be close to the victim or close to the target server. In our case, the SSL-with-compression is between the mobile phone and Nokia's server, and we assumed Nokia's local network to be honest and clean. Thus, the attacker must act in the vicinity of the victim.

Gaurang K Pandya uses WiFi: his phone acts like a basic laptop computer or tablet. Many smartphone users use WiFi whenever possible, because it is cheaper (WiFi usage does not count towards the monthly 3G quota), often faster, and possibly lighter on the phone battery. Thus, many smartphones can be configured to look for open WiFi networks, and/or WiFi networks for which credentials are known, and to use the 3G network only as a fallback.

WiFi is known to be susceptible to the redirection tricks that CRIME builds on. This is especially easy here: the attacker just runs an open WiFi hotspot. Phones in the immediate vicinity will see that hotspot as having a very clear signal, and will connect to it. If all data packets go through the attacker's hotspot, it becomes easy to intercept an HTTP page load, insert the hostile Javascript payload, and then run CRIME. Endgame.

If the smartphone uses 3G, things become harder. Javascript payload insertion can be envisioned with various tricks (e.g. with a HTML email or things like that). The part about observing the SSL-encrypted stream is harder, though. 3G connections are encrypted, normally with the KASUMI block cipher. An important point is that CRIME is all about the length of encrypted data. It is not strictly necessary to see the SSL records; the attacker just need to know the length of these records. The fact that the records will be encrypted with KASUMI does not hide their length (especially since, in UMTS, KASUMI is used in counter mode which means that it preserves the length of the data which is encrypted, with bit-level accuracy). Trickier would be the frame granularity: radio networks split data into individual, atomic frames, which hides part of the length information that the attacker needs. It can be repaired, though, with phasing: the attacker alters the length of his hidden requests so that the compression is at a threshold (that is, compression success, meaning one more cookie byte guessed, implies a SSL record which uses one less frame). Fine tuning would probably be a matter of delicacy.

Also, 3G interception means using a scanner and recognizing the target smartphone packets within the noise. Phones hop frequencies very frequently, and following one specific phone entails knowing where it will jump next, and that information is encrypted. I do not know enough about 3G to know whether this would be surmountable in the context of the CRIME attack.

4. Conclusion

Was Nokia's "institutional MitM" vulnerable to CRIME ? Probably.

Did their recent upgrade fixed that ? Probably.

Is Opera Mini also vulnerable ? Probably not because it is an off-loaded rendering, which means that Javascript does not run on the browser itself, but on the server. But a CRIME variant might still be applicable.


Input-element value-assignment via console isn't enough to complete form submission

I tried to dispatch a change() event per each field but it doesn't change the situation.

I think the problem is indeed that the JavaScript on the page expects some event. If you enter text normally you would trigger keydown, input and other events. Any of these events may copy the value of the textfield to some JavaScript variable. If you change the value of the textfield but don't trigger the event, the JavaScript won't notice the change.

Inspect the input field with the debugger tools in the browser, and list the attached events. That will give you a clue to which event to use. Then, trigger that event like this:

element.dispatchEvent(new Event("input"));


If the action attribute of the form has https://, the data will be encrypted before it is sent to the Hush Secure Forms server.  So the issue here is not the encryption.

There is however an issue with the fact that the hosting medical site does not use SSL.  When an end user views the form, he has no way of knowing whether he is looking at the correct form from the medical site or is instead looking at a form that was rendered by a malicious third party involved in a MITM or phishing attack.  The third party could provide a page which looks just like the medical site but perhaps with a different action on the hush form (e.g. https://HackersServerInNigeria.net).  In this case their private data would be sent not to a Hush Forms server but a server of the hacker's choosing.

Also, mixing secure and non-secure content on the same page may trigger browser warnings.


Tacacs+ scenario: can I permit user to configure only for one interface and deny others

I'm sure there is relam for this but what can I remember from my days as new guy that priveleges are based upon command sensitvity not port wise. What command is executed is where you define control.
 It make sense as where user x an configure interface IP or speed and do the same for 100 interfaces it's the same trust level.

As for config-if  works in inheritence fashion it automatically inherets all priveleges for config level.

 default service = deny
 cmd = interface { permit [faFAgiGI].* }

This would make users to have access to issue "interface Gi."
or "interface Fa.". I do not want them to have the ability to issue "interface Te.*".


HTTPS iFrame embedded in HTTP page - PCI implications?

Using an https iframe in an http webpage only protect against passive attackers.

It is not a good solution because:

It doesn't protect against active attacker (they can rewrite the url of the iframe, see sslstrip)
The browser can't display a padlock for https (because the main page is not secure)

The only way to handle data securely is with HTTPS on the full webpage:

Everything is encrypted to even an active attacker can't read the data or modify it (including links)
The user get confirmation from the browser that everything is encrypted (with the padlock)

Note that having that page using https is not enought:
The links to that page should be protected to (imagine if the http home page show a an https link "donation", an attacker can rewrite it). So to really protect a website that handle sensitive data (note that by European law, personal data must be protected) the whole website should use HTTPS.

Using HTTPS + HSTS on the full website is the best way to protect a website that must protect some data, even if it is in a few webpage.

(Sorry, I know it doesn't answer about PCI conformance, only about security.)


Database table name prefixes and security by obscurity

Most modern databases store metadata in regular tables (Information Schema) so if there is an SQL injection the attacker will eventually find out every necessary information for exploitation, including your naming schemes.

In case of Wordpress and other popular software custom settings may help dodge some automated attacks, as primitive exploits may assume that standard names are used. However if the attacker uses a bit more advanced tool like SQLmap, the custom naming will be revealed almost instantly.


Sqlmap tested parameters might not be injectable

It means that sqlmap has not found any sql injection on parameters you tested.
From my experience there is a chance there might be sql injection but you will have to test it manually as not tool is as good as humans brain. Or if you want to continue with tools try sqlninja or havij or any other automated sql injection exploitation tool.

Good luck.


Is it safe to remove these groups from the Local Security Policy area?

What you are looking at is called an SID (Security Identifier). It is a unique and immutable value used to identify a security principal (includes machines, domain computer accounts, users) and security group in Windows OSs.

Below is the structure of an SID:

Common SID’s

MS Developer Page lists these SIDs as non unique.
From your example, it looks like it's listed under the NT autority, 21 signifies that the remaining subauthorities identify a domain and the RID signifies that it was not created by default (has an RID > 1000)(@ Iszi) & src)

Use the powershell function to match the number to the {name} of the domain member:

  get-sid “{name}$"
  (src)

To aid you in your search you could use you could also use the PsGetSid tool from the Windows SysInternals Suite.

Classic .NET AppPool is a synthesized account related to a mode of the Internet Information Server(IIS) 7.0 system. When an application pool is in Classic mode, IIS 7 and above handles requests in the same way as in IIS 6.0 worker process isolation mode. ASP.NET requests first go through native processing steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the managed runtime. Finally, the request is routed back through IIS to send the response.(z) If you delete this it will be gone. I would suggest running TaskManager to see if any application are running under this pool before doing that. Also, ensure that you are not using an older web application built on IIS 6.x and older.


Which chain of the iptables receives the sniffed packets

Without ARP spoofing, the packets with an ethernet destination different from host C’s own address will not reach any chain of netfilter.

When you use wireshark, it sets the ethernet NIC in promiscuous mode, to see packets with other destinations, but they are still not handled by the kernel and netfilter.


Verification of certificate trustworthiness (e.g. in JWS and Client Certificate)

By 'Client Certificate' do you mean in SSL/TLS and (thus) HTTPS? If so, 8446 (for TLS1.3) references 5280 for cert validation, although earlier versions were not explicit, and libraries generally implement this (or at least its predecessors; in OpenSSL for example the cert validation code didn't change much from about 2000 to about 2015). Typically a server wants you to configure one or more trust anchor(s) for the client certificate(s); while (often) this can be (an) individual cert(s), it can also be a cert for the/each CA that issued the child cert(s) (or usually its root) -- as long as you consider that CA reliable, i.e. you trust it adequately ensures the certs it issues (and does not revoke) are legitimate. Often this will even say something like 'tls-client-ca'. But a definite answer depends on the specific server: apache? nginx? haproxy? tomcat? Jboss/Wildfly? Liberty? other (custom) Java? Or C or C++? Or rust, or go, or whatever comes next? Or python, or nodejs, or perl, or ruby?
JWS also specifies 5280, in 7515 4.1.6, but implementations can vary a lot.

Added for comment:
(1) Okay, this is for Azure Gateway. Their documentation is confusing, inconsistent, and bloated, as typical for Microsoft. They use "client certificate", "client CA certificate", and "client CA certificate chain" in various places as if they were the same which they certainly are not. In https://docs.microsoft.com/en-us/azure/application-gateway/mutual-authentication-portal the "Before you begin" links back to its parent page https://docs.microsoft.com/en-us/azure/application-gateway/mutual-authentication-overview#certificates-supported-for-mutual-authentication which actually describes server certs not client, so is useless. However "Configure mutual authentication" step 5 (and the parent page also) says you should use https://docs.microsoft.com/en-us/azure/application-gateway/mutual-authentication-certificate-management
which describes a way (only for Windows) to get the intermediate and root CA certs for the client cert, not including the client cert itself. This is consistent with the option described (at length) on related pages for them to check/require that a client cert is directly issued by a configured CA, e.g. "Verify client certificate issuer's DN" on the portal config page; that direct issuer will usually be an intermediate CA thus for this option to work they need the intermediate not just the root which would be enough for normal validation. (It's not clear if they actually need intermediates other than the first/lowest when multiple intermediates are used; the example doesn't show that case, and they don't really explain or precisely specify. They also don't show the direct-root case, which is rare, although I'd expect/hope submitting only the root works.) Although they give you the procedure only for Windows, the format they show is a sequence-of-PEM, a common standard you can easily create with other systems and programs.
(2) "the origin of a root public key" -- well, the origin is the root CA. But what matters is how you get it onto your system(s) in a way that is trustworthy, so that you are certain it is not tampered or faked.
For public CAs this is normally handled by the root-CA programs of various software suppliers: Microsoft (Windows) and Apple (MacOS and iOS) each has a program to provide (and update) trusted roots as part of their systems (which are secured overall to prevent lots of attacks not just SSL/TLS certs); Mozilla has a program created for and used by Firefox and Thunderbird, which many Linux distros and some other software (e.g. curl) also use; Oracle-formerly-Sun has one used by their builds of Java while other (OpenJDK, IBM, ?) builds can use something different depending on the builder. I don't know what dot-net does on non-Windows platforms. There are undoubtedly others that are less known.
For other CAs it may vary. If you work in a business or organization that has an internal CA they will usually have a process to get you the correct root; for domain-managed Windows systems they can do this automatically so you may not even be aware of it. If you 'join' http://cacert.org (not https!) you are expected to handle these details yourself.
(3) The verify logic described in the OpenSSL man page is basically standard, although it doesn't automatically fetch CRLs or use OCSP (or caIssuer) -- which are not strictly required but very useful and some other software does. The truststore format OpenSSL uses (a file and/or a directory using subject hashes in the names) is an implementation detail and typically (though not necessarily) the same for https servers (and others) that use OpenSSL, but often different on other software or middleware. E.g. Windows used locally has its own 'machine' store or may use/share the domain controller; since Azure is cloud we don't really know what it does internally, only what the input (or output) is like.


Is using HOTP only authorization considered weak?

Am I forgetting something important?

Yes. The HOTP scheme is not ment to be used as a single factor.
You need to ask yourself, if the "possession" of a smartphone can be seen as a strong possession factor.
When evaluating 2FA or - in your case - 1FA you should take a look at the possible attacks.
One way @Ry already pointed out, being simply the odds/percentages.

  Is google-authenticator (or other OTP scheme) fundamentally flawed somehow?

The google authenticator is not an OTP scheme per se. It is an implementation of HOTP and TOTP. Google combined a scheme that was defined in 2006 (RFC4226) with a QR Code (invented in 1994) and put it in smartphones, that have been there later. You should get the impression that OATH HOTP and TOTP was never ment to be used with smartphones.

The Google Authenticator has one major flaw (besides storing a symmetric key in an insecure device like a smartphone) being the enrollment process of a plain text secret key in the QR Code. I wrote a blog post about it a while ago.

  If viable, what are pitfalls (if any)?

When doing 2FA (or 1FA with an OTP device) you need to carefully design your processes - enrollment, revocation, token replacement...
You have done this with passwords. You defined the length and the contents of the passwords and the period when passwords need to be changed. You probably have  a process to reset a forgotton password.
You need all such processes, too, when doing 2FA or OTP authentication.
The risk (or pitfall) is that you easily think - "oh I am doing OTP or 2FA, now - everything is good and better."

It is not, if you are not aware of your processes.


Sadly, it will probably never be completely safe to plug your computer into strange things.  Even without DMA access, there are many other theoretical attacks.  As known vulnerabilities are patched, their existence suggests others may be possible.

The facilities at Google are likely well protected from any hardware tampering (or any other burglary/theft/espionage).  At a hotel, there is probably no protection at all.

Using a VGA/DVI/HDMI cable for a projector would be much safer than plugging a strange thing into the equivalent of a pci-e connector.


ARP and TCP/IP are different layers in the networking technology stack. If you have read about the OSI model, that applies here.

ARP is a protocol at layer 2 dealing with connecting the host to the local network.

TCP/IP are protocols dealing with connecting networks together.

iptables deals (mostly) with TCP/IP and higher layers. arptables deals with the ARP layer.


PCI-DSS compliance for business with only swipe terminals

I am not an auditor, and no one but an auditor can give you valid answers.  That said, the PCI Data Security Standard is reasonably direct on these matters:

  The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data.

Therefore, storage of card data is not required to put you in scope; transmission is sufficient.  Your terminals will be transmitting cardholder data, and so are "in scope" for PCI requirements.

  Network segmentation of, or isolating (segmenting), the cardholder
  data environment from the remainder of an entity’s network is not a
  PCI DSS  requirement. However, it is strongly recommended as a method
  that may reduce:

  The scope of the PCI DSS assessment
  The cost of the PCI DSS assessment
  The cost and difficulty of implementing and maintaining PCI DSS controls
  The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations)

In other words, any system connected to the network with processing terminals on it is "in scope", and will have to be scanned and audited as well.  You only have to segment it if you don't want to attest that it's up to PCI security snuff every year!  (That being said, it's probably cheaper and easier for you to segment it than to subject everything on your network to PCI requirements).

The PCI DSS Self-Assessment Questionnaire outlines the different types of businesses and what their broad requirements are.  Based on your description, you're SAQ "C", outlined on page 11.  I've quoted part of it below and highlighted the bullet stating that, yes, they want you to segment your network:

  SAQ C merchants validate compliance by completing SAQ C and the
  associated Attestation of  Compliance, confirming that:

  Your company has a payment application system and an Internet connection on the same device and/or same local area network (LAN);
  The payment application system/Internet device is not connected to any other systems within your environment (this can be achieved via network segmentation to isolate payment application system/Internet device from all other systems);
  Your company store is not connected to other store locations, and any LAN is for a single store only;
  Your company retains only paper reports or paper copies of receipts;
  Your company does not store cardholder data in electronic format; and
  Your company’s payment application software vendor uses secure techniques to provide remote support to your payment application
  system.

The good news is:

At the low-volume merchant level, you're pretty much only required to fill out a form and sign it saying that you're compliant, so you don't have the expensive audit to deal with.
There are many PCI rules which seem silly.  This is not one of them.  Network segmentation, or lack thereof, has been repeatedly shown to be a significant factor in card data breaches.
If the shop is that small, then this is not expensive to fix.  Buy a SOHO firewall with a integrated 4-port switch, make sure it has wireless turned off, connect your two terminals to it and then connect the WAN interface to your LAN.  You're done for less than $100.


Lost CVV number automatically virus related?

Call your credit card company and ask them whether the CVV number was supplied as part of that transaction.  (I don't think Amazon has ever asked for mine.)

Even if it was, that doesn't necessarily imply a virus or other malicious software on your computer.  That number could have leaked from another merchant, or even from someone to whom you presented your card in person.  That said, if you don't have anti-malware software, you should correct that today.


How much can I trust the "factory restore/reset" on a(n) (potentially compromised) android?

Might be a dup, see this answer: https://android.stackexchange.com/questions/6541/can-a-factory-reset-fix-malware-problem.

The short answer is that factory reset may not be enough to unroot your system if it has been rooted.


How can American Express Serve login be PCI-DSS compliant?

start typing characters., Once the password is valid, the red text goes away, indicating a valid password.

This kind of behavior doesn't necessarily violate PCI DSS requirements.

If the site works the way you describe, it's not very good from a security point of view because it makes brute force attacks more difficult to detect -- but that doesn't make it non-compliant.

The reason it's not very good from a security perspective is that there is no difference from the system's point of view from a user typing a 10 character password to a user trying 10 different passwords, so any type of request throttling or account lockout would have to account for the "attempts" made while entering the password.

How can this be PCI DSS compliant?

Many of the PCI-DSS password requirements do not apply to customer logins - only to "non consumer users".

For example,

  8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts.

does not apply to the "customer user":

  Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through
  8.1.8 are not intended to apply to user accounts within a point-of-sale payment application that only have access to one card
  number at a time in order to facilitate a single transaction (such as
  cashier accounts).

So even though this is not good security, there is nothing that prevents PCI compliance.

Standard disclaimer: I am not a QSA, and even if I was I am not your QSA, therefore my opinion would not affect yours (or anyone else's) compliance.

Alternatively

As Ian Cook notes, the site appears to be simply checking the password meets strength requirements, not the password itself. Therefore my answer above reflects the site behaviour as stated in the original question. If the site is only checking password strength, then the site will have no problem detecting and responding to any brute force attacks.


How should I select an antimalware solution?

AV-test and such should be taken a bit lightly.

The tests they do, not always match your needs, and the malware they test aren't always real-life situations

each antimalware solution has a different engine, and usually detect differently, but on really widespread casessuch as conficker, or other worms, all (or most) AV companies share information.

for instance, the 0-day that attacked RSA were on VirusTotal for a long time, only no one thought of checking it. The real competition between AV makers is who will block "it" first. But in most cases it won't affect you unless your internet usage is not so good..

as for G-data, I haven't tested it, most people will say "I had AV type X and never had a virus". Well, either the malware bypassed the AV and they never know they were attacked, or their surfing habits aren't risky enough to get attacked.

I use at least 2 or more (currently looking for a 2nd AV) antimalware solutions. I currently have ESET installed, which I'm quite pleased with in addition to Spybot, which also monitors registry changes.

I plan on testing many AV to see what works best.

So far, I've tested Panda Cloud antivirus, but it really slowed my pc and surfing so I had to uninstall it..

Bitdefender seems best according to av-test:

http://www.av-test.org/en/tests/home-user/

also, my advice is to incorporate some type of sandboxing such as sandboxie to help mitigate risks


The list of nodes provided by the authorities is signed by all 8 authorities, the public keys of which are embedded in the tor client.

You could prevent the client from booting, but it won't accept your list of nodes.

(https://www.torproject.org/docs/faq#KeyManagement) :

  Coordination: How do clients know what the relays are, and how do they
  know that they have the right keys for them? Each relay has a
  long-term public signing key called the "identity key". Each directory
  authority additionally has a "directory signing key". The directory
  authorities provide a signed list of all the known relays, and in that
  list are a set of certificates from each relay (self-signed by their
  identity key) specifying their keys, locations, exit policies, and so
  on. So unless the adversary can control a majority of the directory
  authorities (as of 2012 there are 8 directory authorities), he can't
  trick the Tor client into using other Tor relays.


Now with the PMK data encryption using AES can take place. Is what I understood correct?

I believe you are correct, though I did not look deeply into the protocol.

  Also, I have read that SAE provides forward secrecy, so, how is that achieved? Is a new PMK generated (i.e. key renovations) each time a message is sent (so does SAE run every time a message is sent)?

It's not SAE itself that provides forward secrecy, rather SAE enables WPA3 to support it. In previous encryption protocols, the password used for authentication was also used for encryption. One way or another, the key used used to encrypt the raw traffic was derived from the access point password. This meant that someone who had recorded traffic and only later discovered the key could retroactively decrypt content going far back, even as far as months or years.

WPA3 is a little different. Because SAE dissociates the password from the encryption key, the device is free to use public key cryptography to exchange a completely random symmetric key. This key is different for each connected device, and changes each time you connect. It is possible that it also rekeys itself periodically, but that is not strictly necessary for forward secrecy. The end result is that an attacker who somehow finds out the key (e.g. by connecting a debugger to the router's motherboard and reading memory) would only be able to decrypt the current session, not past sessions.


List of all available nmap script arguments

Accordly with the nmap documentation in "Example 9.2. script help", the nmap's parameter that displays help about the script is:

nmap --script-help <filename.nse>

Namely:

nmap --script-help http-sql-injection.nse

If you look at NSE documentation written by own Nmap's creator:

  3.1. description Field

  The description field describes what a script is testing for and any importantnotes the user should beaware of.
  Depending on script complexity, the description may vary from a few
  sentences to a few paragraphs. The first paragraph should be a brief
  synopsis of the script function suitable for stand-alone presentation
  to the user. Further paragraphs may provide much more script detail.

Fyodor explain that the "description" field is used to describe everything about the complexity that the script itself might have. So, go ahead and look deeper into how the script was made:

 $ vi /usr/share/nmap/scripts/http-sql-injection.nse

...

 11 description = [[
 12 Spiders an HTTP server looking for URLs containing queries vulnerable to an SQL
 13 injection attack. It also extracts forms from found websites and tries to identify
 14 fields that are vulnerable.
 15
 16 The script spiders an HTTP server looking for URLs containing queries. It then
 17 proceeds to combine crafted SQL commands with susceptible URLs in order to
 18 obtain errors. The errors are analysed to see if the URL is vulnerable to
 19 attack. This uses the most basic form of SQL injection but anything more
 20 complicated is better suited to a standalone tool.
 21
 22 We may not have access to the target web server's true hostname, which can prevent access to
 23 virtually hosted sites.
 24 ]]

This explain why the http-sql-injection.nse script do not shown "usage options" whether that's what you expected to see.

The NSE scripts has a tradition to include "usage options" inside a comments. Such thing that was documented on the section "8.1 The Head":

  Next comes NSEDoc information. This script is missing the common
  @usage and @args tags since it is so simple, but it does have an
  NSEDoc @output tag:

---
--@output
-- 21/tcp   open     ftp       ProFTPD 1.3.1
-- |_ auth-owners: nobody
-- 22/tcp   open     ssh       OpenSSH 4.3p2 Debian 9etch2 (protocol 2.0)
-- |_ auth-owners: root
-- 25/tcp   open     smtp      Postfix smtpd
-- |_ auth-owners: postfix
-- 80/tcp   open     http      Apache httpd 2.0.61 ((Unix) PHP/4.4.7 ...)
-- |_ auth-owners: dhapache
-- 113/tcp  open     auth?
-- |_ auth-owners: nobody
-- 587/tcp  open     submission Postfix smtpd
-- |_ auth-owners: postfix
-- 5666/tcp open     unknown
-- |_ auth-owners: root

Since the documentation does not explicitly show the use of "@usage", look yourself in /usr/share/nmap/scripts/:

$ grep -iR -A5 "@usage" /usr/share/nmap/scripts/
/usr/share/nmap/scripts/ajp-brute.nse:-- @usage
/usr/share/nmap/scripts/ajp-brute.nse--- nmap -p 8009 <ip> --script ajp-brute
/usr/share/nmap/scripts/ajp-brute.nse---
/usr/share/nmap/scripts/ajp-brute.nse--- @output
/usr/share/nmap/scripts/ajp-brute.nse--- PORT     STATE SERVICE
/usr/share/nmap/scripts/ajp-brute.nse--- 8009/tcp open  ajp13
...


Why can't an n-bit hash be cracked by hashing every single n-bit plaintext?

Yes, you are right. Although you would expect (statistically) to find a collision already after about 2^32 tries.

If you have a hash of 160 bit length you would have to try 2^80 combinations (on average) to find a collision. But still, with today computing power trying 2^80 combinations will take too long for you to become old enough to see the collision :-)

That's pretty much all about it. Making the bits so many that it just takes to long to try all necessary combinations out.


Is a salt necessary for PBKD when the hash is used as an encryption key?

Updated answer based on new info:

Passwords/Passphrases have low entropy

Humans aren't very creative when it comes to password. This makes these passwords a poor choice as seeds to generate encryption keys (which should have a high entropy). Quoting from a study:

  Burnett did an analysis of 6 million username and password combinations last year, and found that 91 percent of users had used one of the 1,000 most common passwords—with 99.8 percent using a password from the 10,000 most common. And "password" was the leader of them all, in use by 4.7 percent of user accounts.

Dictionary (and not rainbow) attacks are what you should be worried about

Given the statistics above, its likely that you are dealing with a very miniscule subset of total possible encryption keys ( a couple thousands or millions!). A 256 bit AES key has a address space of 2^256. In such a case, you should be worrying about the dictionary attacks.

Consider a following PBKD function:

The PBKDF above uses does c iterations of a hash function H over the (password||salt) combination

Also, consider a password dictionary of 1M passwords and that our application has 100 users

Without salt

When there is no per user salt, the PBKDF function above reduces to:

All attacker needs to do is to calculate a dictionary of 1M AES keys corresponding to each password in the dictionary.

The number of times a user needs to run the KDF function = 1M.

With salt

Now that each user has a salt, a generic 1M list of AES keys will not work. An attacker will now need to do 1M KDF operations per user to create a specific set of possible AES keys for that specific user.

The number of times a user needs to run the KDF function = 100M.

PBKDFs, like bcrypt and scrypt, are deliberately slow functions just to ward off dictionary attacks like these.

Finally

It is advised to use a salt with PBKDF functions to make sure that the resultant keys have more entropy and an attacker needs to compute a dictionary per user to do a dictionary based brute force attack. Since PBKDF functions are designed to be slow, creating a per-user dictionary list is a order magnitude slower than a single list.

Old Answer

Salts will be useful in the scenario where two different users have same passwords and the same data. If a deterministic encryption is used, the resulting cipher texts will be same (since the encryption keys derived using PBKDF will be the same) thus opening up vectors for cryptanalysis. If passwords are salted, the resulting cipher text will be different in the aforementioned case.

Salts are not a secret. You don't have to encrypt/hide the salts. They should be unique for each user though.

Also if you don't have a concept of users/passphrases, then you don't need to use PBKDF to generate keys. As Lucas mentioned, you can use a secure random number generator to create random keys directly.


What are the security trade offs between the different methods for encrypting a guest VM image?

Your mindset is backwards.  In a hypervisor scenario where you want to use both the host and guest(s) as usable machines, the most secured 'machine' must be the host.

To try and drive this point home:

if your 'more-secure' VM is a guest and you use the
host to surf the internet, then any compromise of your 'less-secure' internet surfing host provides automatic access to any and all guests.  Encrypting the VMs disks only protects the disks when the VM is offline AND that assumes the attacker doesn't know how to pull the keys out of memory (which they would have access to since they would be attacking from the host to the guest)
if your 'more-secure' machine is the host and you surf the internet from the guest, then an attacker would have to either attack over the network or through the hypervisor--both that are considerably harder than having implicit rights to manipulate the hardware of the VM.

And while this doesn't answer your question directly, if you choose to flip the route you're taking, just drive encrypt the host's hard drive and all others are automatically included (assuming they're all on the same disk)


File authentifications via PGP versus via unique file hashes

If an attacker can manipulate the file you download, surely they can also manipulate the text file with SHA256 checksums. Unless they have access to the PGP key, they cannot create a valid PGP signature for any file or message, and so a signed message which contains the SHA256 checksums or a valid detached signature for a file is guaranteed to be written by a person who is in possession of the key and who vouches for the authenticity of the signed content.

A cryptographic signature is tied to the contents it signed as well as to the signing key, and will no longer be valid if the contents are changed.

When this happens, you can't know the reason off hand -- it could be that the file or message has been tampered with, or it could be an innocuous bit flip because you downloaded it over an unreliable connection. But in this scenario, you do know that the file's or messages integrity has been compromised, and can no longer be trusted.

Users who are not in possession of PGP or who don't want to spend the time on validating a signature can only get a much weaker integrity check, but making sure the SHA256 of a downloaded file is identical to what's communicated in a different place at least guarantees that both sources agree.  This -- for many users, much cheaper -- guarantee is enough to validate that the download isn't corrupted, for example.

(You could argue that as long as some users check the signature, and will probably raise hell if it fails, this should be sufficient as a mechanism for "herd immunity"; but obviously, unless you have a good indicator that this is in fact the case, it is basically just speculation.)


If you are transmitting the credit card details to your payment gateway via HTTPS, you are not transmitting in plain text, you are using SSL/TLS cryptography.

Once you don't store the details in your systems willingly (using databases, etc.), your only concern would be your system's logs, because they can store this informations without your knowledge, so make sure that no log is storing the credit card details.

We can have another issue that an attacker can use to steal your client's credit card details before he sends it to your server, this issue is called Cross Site Scripting (XSS), be aware.

Edit:

Be careful!

I am not saying that you don't need to pay attention in tons of other possible vulnerabilities.

I am just saying that if an attacker gain access to your servers, he will not be able to steal old credit card details if you follow the above rules.


How will Gmail be able to detect SPAM and display ads when emails are encrypted end-to-end?

The answer to the first part of your question is the current Gmail spam filters would not be as effective, they could read the header information and block certain sender addresses but they could not read the actual message. Your assumption that all the encrypted spam message bodies would be identical is incorrect, every individuals public key would produce a different message body even though the original message content is identical.

As far as advertisement is concerned the ads served to you would not be as individually tailored to you, there is already an option to opt out of user specific ads. If the client where configured to send back keywords to Google to serve up individual tailored ads it would be a major privacy violation, hopefully the extensions/plugins they promote are open-source and open to scrutiny.


Does DNS-based blocking protect against ransomware?

Yes this will block it. Using a hardcoded IP address for anything as a cracker is an awful idea as it ties you to a single point. If you're a cracker you want to stay mobile, moving, and in such a way they can't find you. Being tied to a single, static IP address makes you REALLY easy to find. Otherwise you would first have to send a new version of the malware with the DNS for tomorrow, and then that pattern could EASILY get you found once someone just connects manually, get the new malware, pulls out the DNS, finds the IP registered for tomorrow, goes and lies in wait, and then you're caught.

This problem gets solved on their end by using a DNS to keep floating IP addresses tied to their domains. This DNS needs to be contacted to "phone home" to a server that will send the botnet a command. OpenDNS logs these malicious botnets, and blocks them on a DNS level, so the OS and infected computer has no idea that it can't even reach the botnet. It just thinks that the cracker isn't doing anything right now, and so it doesn't join the botnet. To do this OpenDNS just prevents access to those servers.


How I can encrypt Windows if I use a SSD and HDD?

Requests for product recommendations are off-topic on this site. However, taking the narrower question of "is Bitlocker safe", yes it is if you use it correctly. (Same caveat applies to Veracrypt, any other reputable full-volume encryption utility, and for that matter any reputable encryption utility of any sort at all). While it's true that it's closed source, it has been extensively audited by both internal and external (under NDA) security experts, and Microsoft stands to lose a tremendous amount (both directly monetarily, and indirectly due to lost trust) if the promises they've made are false.

With that said, there are limits.

If you use Bitlocker with a PIN/password but without a TPM or other secure key store, then an attacker could potentially brute-force the PIN/password. This is a problem shared by literally every system that doesn't have a secure place to store the key. Microsoft applied the standard mitigations - the key derivation algorithm is extremely slow and computationally expensive so brute-forcing is also slow and hard to parallelize, and there's a default minimum length on the PIN/password which can be made even longer - but if you use a weak password there's no software solution in the world that can save you.
If you use TPM-only mode (also known as transparent mode) - where the key is stored in a hardware security module and only "unsealed" when the machine has booted up following the expected code path (so, no booting from a live CD or flashdrive or whatever) - then the security boundary becomes the Windows login screen, and somebody who steals your whole computer can potentially steal the disk encryption key out of RAM using a hardware attack after the machine boots up but while it's sitting at the login screen.
If you store the recovery "password" - a long and random string that is used as the last-ditch unlock method if the machine can't be booted otherwise - somewhere that is protected by a weaker password (such as in a cloud storage provider) or somewhere an attacker can physically access it when stealing your machine, they can potentially obtain the recovery password and then just enter it and have full access to the disk.
If the attacker steals your machine while the decryption key is in RAM (because the system is either running or in suspend/sleep mode), the same kind of hardware attacks used against TPM-only/transparent mode can be used. You need to configure the machine to hibernate (not sleep) so that the key is purged from memory, and ensure it does this quickly enough that an attacker can't walk off with the machine while it's running.

Also, for what it's worth, Veracrypt does support automatic mounting of volumes (such as your data drive) after login. See https://www.veracrypt.fr/en/Favorite%20Volumes.html for more details. I haven't tried this myself, but it looks like it might work for you.


On Linux kernel 3.3, this is done with the hidepid= and gid= mount options for /proc (to be added in /etc/fstab). See this answer. Possibly, some distributions which use older kernels may have backported the patch.

On FreeBSD there is a sysctl flag for that, called security.bsd.see_other_uids. See this documentation (search for "see_other_uids").

I am not sure whether other Unix-like systems have similar features. Apparently, back in 2011, there was nothing of that sort in OpenBSD (that's what I infer from that discussion).

One may say that such things matter only if you let hostile people run their code on your machine, which is the traditional "Unix mainframe" concept, but increasingly irrelevant nowadays. In 2014, when people who don't trust each other share the same hardware, they actually run virtual machines which don't see each other.


Not Asking Email Verification on Account Creation

The answer to your question likely depends on a couple of factors.

Can the e-mail address used for registration be used for password reset. It would be a mistake from a security and usuability perspective to do this where the e-mail address was not validated during registration as a typo during registration could effectively lock you out of your account, if you forgot the password (absent any other password reset mechanisms).  Also if you register using someone elses e-mail address (for whatever reason) they can effectively steal the account from you in this case as they can just trigger a reset and take control.
Is there some real world consequence to someone using an e-mail address that they do not own.  For example if a user fraudulently registers as billgates@microsoft.com would that achieve some security relatd goal where they could mis-represent themselves as being Bill Gates?

So the consequences of this very much depend on the nature of the site in question and are hard to be precise about in the abstract.


How should software respond when Captive Portals or Untrusted SSL certs prevent connectivity?

Not just OSX but most platforms now will request a known URL and see whether the content is replaced or tampered with to detect hotspots.

Windows 7+ :

  NCSI performs a DNS lookup on www.msftncsi.com, then requests http://www.msftncsi.com/ncsi.txt. This file is a plain-text file and contains only the text Microsoft NCSI.

  NCSI sends a DNS lookup request for dns.msftncsi.com. This DNS address should resolve to 131.107.255.255. If the address does not match, then it is assumed that the internet connection is not functioning correctly.

Source: http://blog.superuser.com/2011/05/16/windows-7-network-awareness/

Android 4.2.2+:

  http://clients3.google.com/generate_204

Source: #1 & #2

Most of these URLs can be changed if privacy is a concern.

The solution for your application would be to make a HTTP GET request and see if that gets tampered with.

On most of the hotspots I use, I see either a failing SSL/TLS session due to the site being signed by the hotspot provider rather than the one I was attempting to visit (they don't have the certs for the site I'm attempting to visit) which your TLS/SSL hostname checking will flag up... or they just block the connection until they see a HTTP GET to a site they can MITM... which would look like a timeout.

An advantage to having a http://yourapp.com/status style URL rather than re-using either Microsoft's or Google's is you can attempt to provide more helpful information on the health of your application if your status URL reports that the service is healthy but the user's network isn't letting them connect to your TLS/SSL endpoint over if the http://yourapp.com/status page is down then perhaps your application is down too.


Where to download thousands of virus samples for AV testing?

A quick Google search turned up this post which links to a number of malware sample databases:

Contagio Malware Dump: Free; password required
KernelMode.info: Free; registration required
Malshare: Free
Malware.lu’s AVCaesar: Free; registration required
MalwareBlacklist: Free; registration required
Malware DB: Free
Malwr: Free; registration required
Open Malware: Free
SecuBox Labs: Free
theZoo aka Malware DB: Free
Virusign: Free
VirusShare: Free
@MalwareChannel: Free

However, the problem with most of these is that the samples tend to be quite dated, anywhere from a few weeks to years old. Thus while they're still useful for analysis purposes, they might not be as useful for testing the real-world effectiveness of antivirus programs. Detecting old malware is rather simple compared to keeping up to date with new malware, and most new samples that are widely distributed don't last more than a couple days before they are flagged by nearly all antivirus programs.

If you want to perform a more realistic test with new, just-discovered samples, you'll probably need  a live feed rather than a database. PCMag uses a feed supplied by a company called MRG-Effitas in their AV software testing, for instance. Google also turned up the Cyveillance Malicious URL Data Feed. Unfortunately, it seems these feeds are provided as a commercial service and not generally offered to individuals, though it wouldn't hurt to try contacting these companies.

If all this sounds like too much trouble, you might want give the third-party test results another look. By referencing results from several labs you can usually get a reasonably good idea of the effectiveness of any AV program you are considering.


How does Widevine, FairPlay, and other DRM's work under the hood?

If the above is the case, I assume that an attacker could simply edit the binary for the CDM to access the key or the file after is decrypted.

That's why a lot of DRM systems are not implemented on Linux systems ...

To be able to run a DRM, the player must be "certified" by the DRM provider and must provide some secure way for this set key/decryption process.

On mobile device, it's often done using the TEE (Trusted Execution Environment), the SecureZone or whatever that is able to act as an crypto oracle on the system.
For Windows, other mechanism are used, probably anti-debug at binary level, TPM, or something like that.

It doesn't mean that you won't be able to get the encryption key, just it will be quite difficult.


The whole purpose of an architecture with DMZ is to limit direct access from external network to sensitive components of the internal network. Your question itself is self explanatory and it is perfectly normal to allow database communication between webserver situated in DMZ and database server located in internal server farm. From a security perspective it limits the exposure of database server to the public.


How to edit a Hex code without corrupting the file [in bypassing av]?

AV signatures are usually based on a hash form a particular file.  They are either known goods, or known bad files.  If it's a known bad file, you can alter a few bytes here and there (for example the "cannot run in dos mode" string), you can have a binary that does the same functionality, with a different hash.

But, most modern AV's / Anti-Malware programs look at a few things; this could include code signing, behavior, etc.

  What should i know for a successful binary editing in bypassing av?

This is exactly what code signing tries to solve.  If you edit the program, the signature will no longer match, and will not be "blindly" trusted.

Bypassing AV is a large subject which is well researched with often insightful techniques.  You can either have an "untrusted binary" which do legitimate things long enough, so that it gets trusted.  Or, have a legitimate binary (ex: something that's shipped with the OS, etc) and try to abuse that to perform something it's not intended to do.


GHOST: which services are vulnerable, ssh, web server?

One can reasonably conclude (see below) that it will require some detailed analysis to determine if an arbitrary software package is vulnerable, and what configuration or mitigations may apply. Any service which performs name resolution could be at risk (patch, and be safe!).

Qualys have already provided a list of software using the affected functions which they cannot exploit at this time:

  apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,
  nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,
  pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,
  vsftpd, xinetd.

Right now, only Exim is confirmed exploitable.

The CVE details site keeps track of vendor details for vulnerabilities, it's not up yet but it should appear shortly here fully complete yet, you can find it here: http://www.cvedetails.com/cve/CVE-2015-0235/
(see the recent Shellshock CVE-2014-7169 page for example). The oss-sec email list is a good way to keep track of breaking news.

The Qualys POC (GHOST.c) indicates only if the glibc is affected, what should accelerate the process is the upcoming promised Metasploit module from Qualys (though I suspect there will be others scrambling to develop modules).

(I don't buy the OpenSSH "mitigation" linked to, UseDNS causes a reverse look up of the IP address of the TCP connection, which of course cannot be sufficiently controlled by the attacker. I'll update this when I have a chance to verify the steps taken. Reverse DNS in OpenSSH or OpenSSH+libwrap is not exploitable.)

The original advisory is rather long, and the audience is expected to have a better than passing knowledge of libc and C programming. Much space is devoted to code and programs which are not vulnerable by way of explanation of the various complexities. The "publicity page" here is rather more digestible, and contains the nowadays obligatory vulnerability artwork.

Because of common programming idioms, and the very specific code paths to the vulnerable code, many programs are not vulnerable. To be clear, there is a problem affecting a handful of DNS related functions in glibc(<2.18), and DNS is an excellent way to get attacker controlled data into a system, though it's not a great way to get arbitrary data in. But, unlike some recent high profile issues, simply using the library or using those functions does not automatically make a program vulnerable.

That said, this is a newly publicised issue, other ways to trigger the issue may be found, there is no excuse to put off patching. The gethostbyname* functions in question are considered "obsolete" since they do not support IPv6 notations and have been replaced by functions that do, but they are very prevalent.

This non-trivial exploitation of the vulnerability is explained in detail in the advisory, take the example of the (not-exploitable) mount.nfs in §4.2 : a setuid-root binary on most distributions, so a good opportunity for local privilege escalation:

  Similarly, mount.nfs (a SUID-root binary) is not vulnerable:

    if (inet_aton(hostname, &addr->sin_addr))
            return 0;
    if ((hp = gethostbyname(hostname)) == NULL) {
            nfs_error(_("%s: can't get address for %s\n"),
                            progname, hostname);
            return -1;
    }

The above calling pattern of inet_aton() before trying gethostbyname() is the common idiom referred to above. Given an arbitrary string in hostname, first check to see if it can be treated as a valid IP dotted-quad via inet_aton() (cheap, and low-latency), otherwise see if it is a DNS host name via gethostbyname() (not cheap, and potentially high-latency. See section 3 - Mitigating factors of the advisory.

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH.

If your OpenSSH is built with libwrap, then the sshd binary will have some symbol dependencies for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is in HP-UX specific code where the X DISPLAY need contain an IP rather than a hostname, not relevant here.

In the general case, since conforming DNS data cannot contain problematic long/malformed IP addresses, reverse look up and forward/reverse checks are not an attack vector. Where hostnames/dotted-quad addresses are part of a higher protocol (e.g. the SMTP EHLO name, as used exploiting Exim) then you might have something. For OpenSSH this would suggest host names in port-forwarding. Close, but no cigar, even if OpenSSH did use gethostbyname() directly:

      if (strlen(host) >= NI_MAXHOST) {
            error("Forward host name too long.");
            return 0;
      }

where NI_MAXHOST is 1025 in versions I've checked so far. This would be a less severe post-authentication attack vector in any case.


After you have validated the certificate is real and valid, you can then use the public key on the certificate to encrypt your communications. Since the server is theoretically the only party with the private key they are the only ones who can decrypt your message. The message you send back usually contains information to set up a more permanent two way encrypted channel.

So, if an attacker takes the stream of bytes that is Google's certificate, and presents it to you - you may indeed think that they are Google. However, the attacker won't be able to continue communication with you - they won't be able to understand your reply because they don't have the means to decrypt it.

The servers private key can also be used to digitally sign content which can then be verified with your public key. So, you can be sure that content you receive was validated by an owner of the certificate (ie the server) at some point for some purpose - an attacker can still take the whole signed content and present it to you but won't be able to change any details or the signature won't match. Often content signed like this has dates included and/or other methods, such as intended recipient, to ensure the effectiveness of doing the above is reduced or eliminated.


For JPG images it is possible to use a tool called Stegdetect to identify images which are suspicious to bare the steganographic content and identify a tool used to hide the message. It can even try to decode or bruteforce some of the algorithms. Original site of the tool disappeared from internet, but you can still download the tool from some trustworthy archives like Debian - https://archive.debian.net/etch/utils/stegdetect
Here is guide how to install on Kali linux - http://rfc.red/installing-stegdetect-in-kali-linux/
http://freecode.com/projects/stegdetect/

Some more tools:

steghide - http://steghide.sourceforge.net/
stegui - GUI for steghide - http://stegui.sourceforge.net/steghide.html
JPHide - http://linux01.gwdg.de/~alatham/stego.html
Outguess - stego tool from the same author as stegdetect

https://archive.debian.net/squeeze/outguess
http://web.archive.org/web/20150508205355/http://www.outguess.org/download.php

OutguessRebirth - http://www.outguess-rebirth.com/
OpenStego - https://sourceforge.net/projects/openstego/
Camouflage - http://camouflage.unfiction.com/
and probably many more:
https://github.com/search?utf8=%E2%9C%93&q=stegano


Relevant? Absolutely. Most tools don't just go out of relevancy (unless they're replaced/upgraded). They all have a place in a wider methodology hence why it is in the PWK materials.


How to store encrypted notes in a public git repository?

The simplest answer would be to use a symmetric cipher (e.g. AES).

You are the only user, so you only have to keep the AES key securely stored.
Symmetrical algorithms are generally faster than asymmetrical ones (but probably not by much for text though).
You use only one operation at encryption/decryption time.

Now for your questions:

  Is this safe?

AES is still considered safe, but you have to take care with its mode and size. Regarding your use case, you should go with AES-256-CBC, as it might be easier to use than AES-256-GCM and more common than some recent ciphers.

  What key algorithms should I use?

Well, as I said, symmetric only should do the trick.

  I do not know if I should use gpg2 or rage?

OpenSSL could be use for AES (or many other ciphers), some example here.


Does YubiKey with LastPass influence encryption?

With LastPass, YubiKey is only used for authentication purposes to be able to download your vault and/or login to your LastPass account on their servers.  YubiKey is not however used for encryption purposes, so the use of 2FA with LastPass (or YubiKey) does not influence the encryption of the vault.  It just makes it harder to potentially compromise your account by logging in as you, so 2FA should be enabled as a best practice.

The LastPass database itself is encrypted locally using AES-256 with your master password as a factor to generate a PBKDF2-SHA256 hashed key.  That key, stored locally (not your master password) with symmetric AES-256 encryption is your master password. But, essentially,  your master password is this key and could be used to decrypt files locally -- so if someone copies your local lastpass vault and has the master password, regardless of YubiKey, it could be compromised.

References:

https://lastpass.com/support.php?cmd=showfaq&id=6926
https://lastpass.com/whylastpass_technology.php


What are common security problems pen testers find?

A general strategy and list of issues was spoken about in this thread -- https://security.stackexchange.com/a/68666/140

You should check out the MITRE CAPEC work. In 2015, colleagues and I have been seeing a lot of web-layer command injection or varietals of command injection, such as spoken about in Andrew Wilson's (of Bishop Fox) Toorcon talk, "if you like it then you shouldn't put a ring3 on it". For mobile apps: unobfuscated keys, static passwords, or other static configurables are common. When performing social engineering, the most common vector is local Administrator account privilege escalation to a Microsoft Forest and associated domains, as seen in Matt Weeks' (of root9b) talk at CanSecWest on "Credential Assessment: Mapping Privilege Escalation at Scale".

If you want to take a look under the hood, I recommend that you acquire the following toolchains:

For remote-command injection, get a license for Burp Suite Professional and leverage the metasploit-framework with tools such as sqlmap, NoSQLMap, commix, and liffy.
For mobile app penetration testing, check out the BLACKBUCK, idb, Lobotomy, and dtf toolsets, as well as Frida (and analogues or prerequisites to those such as adb, lldb, Xcode, usbmuxd, multcprelay, cycript, Drozer, Xposed framework, libimobiledevice, otool, optool, Android emulator strace, kdv, iosbinpack, et al).
For attacks against Microsoft Forests, be sure to check out the tools from Adaptive Red Team Tactics such as PowerSploit, Empire, Veil / PowerTools, ntlmv2_capture_hashcheck, root9b Orkos, FuzzLabs, Immunity Security ImmDbg, INNUENDO, CANVAS, and Cobalt Strike.