Best way to encrypt data using php - I am not sure if I doing it correctly

There are at least two problems with this approach.

Your choice of key generation
Your choice of encryption mode

Key Generation

You're doing md5("static password") as your key. This is really bad. First, you're "only" getting 128-bits from MD5 and you're using 256-bit keyed AES, thereby wasting cycles (because AES-256 is slower than AES-128) on something you're not using anyways. Secondly, you password is weak. "pass" is not a secure password and I really hope you replace it with something much stronger for production use. Third, you're using plain MD5 for the password processing (also see our canonical answer on password hashing). This is as bad as it can get, because the ciphertexts could be attacked using precomputed (rainbow) tables and MD5 is a fast hashing function, allowing fast brute-forcing of your password. Fourth: Why are you even using a password!?. There's no logical reason to use a static (human-readable) password instead of a secure, randomly generated key of the desired size. This way you don't have to worry about brute-force, you don't have to worry about using MD5 (which will give bad press) you don't have to worry about your key to be too short.

Encryption mode

While you use AES-256 as encryption algorithm (which is OK), you're using ECB as your mode of operation for AES. This way you have two problems: a) you're leaking which AES blocks (16-bytes) are equal and b) you have to pad your messages to be a multiple of 16-bytes. To fix these problems you need to swithc the mode. GCM is the best option you have. Unfortunaly, this isn't properly supported by PHP until PHP 7.1 via openssl_encrypt() or mcrypt_encrypt() (which you really shouldn't use, because it's slower, no longer maintained and less hardened than OpenSSL). If you already have PHP 7.1, then fine, you can use AES-GCM with openssl_encrypt(), which will protect your ciphertext from being read and / or modified, provided you hand a unique (not secret) nonce over for each encryption. Until you have proper PHP 7.1 AEAD encryption, you have to use an ad-hoc construction. This means, you first encrypt the data using a (random) 16-byte IV with CTR mode and then you calculate the HMAC-SHA256 of the ciphertext and store the resulting tag, so you can verify it upon next read access.


Is the 'SUIDGuard' patch safe to implement?

The first important thing is to think about the meaning of this security hole. This is a local privilege escalation: if an attacker can get to run code of his choosing on the machine, with "normal" privileges, then that attacker can use this hole to obtain more extended privileges on that machine.

In general, for a desktop system, when attackers can run their own code on your machine, they have already won. On a desktop systems, your own actions, as a "normal user", are all done as process running, from the point of view of the kernel, with the privileges attached to your user account. If an attacker manages to run his own code, it will be through subverting one of your applications, or making you unwittingly run a seemingly honest screensaver or something like that. Privileges attached to your account are sufficient to plunder the contents of all your files, display spurious ads, hijack your network connections, and generally steal your whole life. Also obtaining root privileges on the machine does not substantially increase the scope of the disaster, though it may make life easier for the attacker.

Moreover, as a "normal user", you already have ways to obtain root privileges, and you do use them on a regular basis -- e.g. to authorize an update of the Flash plugin. The updater system will ask you for your password and use it to request and obtain root privileges. An attacker who can run code under your name just has to mimic a Flash update to display the popup and obtain the privileges. In that sense, the new vulnerability is irrelevant for a desktop system. Correspondingly, there is no hurry in fixing it.

Privilege escalation holes make a lot more sense on shared servers, where several users who can potentially be hostile to each other share the same hardware, and the  OS must arbitrate between users and protect them from each other. Shared servers are an old model, back when we were talking of mainframes. An information security professional who is now in his forties must have been exposed to that model while he was a student, in the 1980s or 1990s. At that time, computer students were typically using terminals in some shared computer room, and accessing one or a few central servers with a Unix-like operating systems. Privilege escalation was then a much sought after grail.

This rarely applies nowadays. Right now, in 2015, when there is shared hardware, users are granted virtual machines, not simply shell accounts. There still are places where servers are shared in the old way, but they are a vanishing species. If your OS X machines are servers that are used that way, with users that you cannot all trust (or that do not trust each other), then yes, the privilege escalation hole is a big concern. However, chances are that this is not the case.

Assuming that you still want to fix the hole quickly by installing Esser's patch, then you have two points to consider:

You are, basically, inserting in your machine, with "kernel privileges", a piece of code downloaded off the Internet. This entails a rather heavy dose of trust. You must be sure that the Internet persona that appears to go by the name of "Stefan Esser" is trustworthy enough, and that nobody else could alter the patch where it is stored or while you download it.

How would some "guarantee" by another Internet persona, even with an awesome avatar, create some extra trust ?

You could, though, get the source code, audit it, then compile it yourself. But if you feel that you can do that, then you do not need any help from a StackExchange site; you already know enough.
The patch changes the behaviour of the machine, conceptually to make it "better" (or "safer"), but a change is always a change and may break things. It is possible that some application developer, somewhere, had noticed that some DYLD_* environment variables survive through SUID execution, and actually used it for some functionality (without necessarily noticing that this has security implications). While the patch appears to be harmless enough (at least from what I see in the source code -- but can you trust me ?), I cannot exclude the possibility that it impacts the behaviour of some parts of the OS or applications.


How to ensure an email address is not free webmail or ISP address?

It's most likely blacklist-based. You wrote

  I also notice that it does not work with some of the temporary email address services

-- these are, for obvious reasons, a prime target for blacklists, so them being blocked is not a reason why it shouldn't be blacklist-based. Of course, blacklists are never complete, but there are services that provide such blacklists as an API and I'd guess they are pretty comprehensive.

Indeed, they query an online service to validate the address, which will most likely check against a blacklist and appears to perform other checks (e.g. existence of domain, but not if the domain even has a MX record).


PenTesting - Configuring vulnerabilities on XP SP 1/2/3 & Server 2008

I'd recommend combining a search of Metasploit modules with software from Oldversion as being a good starting point for this kind of research.

You can search Metasploit based on exploit reliability and then see if you can find the appropriate software version on the site.

Another option would be to look at some of the pen test/CTF labs for the kinds of exploits they line up.


openssl EVP_aes_256_gcm - what's inside?

The Wikipedia page has some explanations and a nice schematic; and the GCM standard is reasonably clear. To make things simple, the actual encryption is done in CTR mode, but the MAC part uses extra operations (multiplications in a finite field of characteristic 2, and one extra block encryption). If you encrypt 16n bytes, you will use n+1 AES block encryption invocations, n+2 multiplications in GF(2128), and some XOR. It is not required to understand how GCM works internally to use an implementation of GCM; but it helps.

In particular, the IV can have about any possible length, but IV values beyond 96 bits are not really interesting for security, which is why OpenSSL will restrict itself to 12 bytes. The "block size" advertised by OpenSSL is 1 because, thanks to the internal use of CTR, encrypted message size will not be "rounded" due to some padding (there is a fixed size overhead, though, for the MAC).


Create certificate without private key with OpenSSL

As AJ Henderson suggested, the perfect solution would be to have the OpenPGP card sign the CSR. It turned out that is possible with the gpgsm CLI tool. Damien Goutte-Gattat from the GnuPG-user mailing list answered the question:

    Is there any way to create an X509 CSR signed with the private key stored on
    the card?

  Yes, you can use the gpgsm(1) tool for that.

  Make sure your card is in the card reader, then:

 $ gpgsm --armor --output mycsr.pem --gen-key

  You’ll be prompted to select what kind of key you want, choose
  "Existing key from card" (make sure your card is in the reader).
  Then select which  of the card keys you want to use (the signing key,
  the encryption key,  or the authentication key) and the intended use
  of the future certificate.

  At the end of the procedure, you’ll be prompted for your PIN in order
  to  sign the CSR.

  The documentation of Scute has a complete example (it uses
  gpgsm-gencert.sh, a deprecated helper script, instead of the above
  command, but the procedure is almost the same).

So there is no need to circumvent the CSR, you can make a valid X509 cert with GnuPG.


Difference between linux hash sum utilities and online string to hash utilities

Very possibly, the newline.

Try this instead:

$ echo -n "password" | sha256sum

The -n argument to echo tells it not to print a newline.

As you can see, this changes the hash:

$ echo "password" | sha256sum
6b3a55e0261b0304143f805a24924d0c1c44524821305f31d9277843b8a10f4e  -
$ echo -n "password" | sha256sum
5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8  -
$


Site stores cookie name and user id in script tag after login. Is this an issue for either xss or session highjack?

No, including the cookie name or username in the page is not an issue.

The session/cookie name is not secret information, everybody can see it. [Including the content of the cookie on the other hand would be a minor problem, as session cookies are generally supposed to be httpOnly to mitigate some of the risks of XSS].

The users email address also should not be a problem, as it isn't really that sensitive, and can likely be accessed somewhere else anyways (eg via the profile page).

Your main question seemed to be if including these two pieces of information in the page is a problem. Regarding the other question: We can't really answer if you have an XSS vulnerability without knowing how the user input is actually sanitized by the system.


How can an expired SSL certificate make the server and/or client vulnerable to MITM attacks?

If the certificate is expired (say, after two years), this means that a potential attacker had at least two years of time available to brute-force or otherwise attack the key. OK, this means more risk than when the cert is only a few months old, but with good keys there should still be virtually no sudden risk increase at the moment of expiry. Nevertheless, this aspect should not be discarded. (Also, old certs may have been produced in the good old days of less secure signatures)

But more importantly, when a key that is still active is compromised, this fact may be advertised by revocation (e.g., CRL or OSCP). If a key gets compromised after its expiry, this is not done (simply because it would be a waste of resources to track those cases when the certs are invalid anyway by expiry).

In fact, it may be the case that the owner did renew the certificate, but what you are looking at is a fake site created by a MITM.

So, yes, you should be sufficiently worried (and worried as hell if that is any site of importance such as a banking site or a shop) and maybe inform the owner.


Mathematically, we assume that the user creates his password using a probability distribution that the attacker knows perfectly. The attacker then generates the passwords to try in order of plausibility. When several passwords have the exact same probability of being chosen by the user, then the order in which the attacker tries them does not matter for the average success rate.

The hypothesis of "perfect knowledge" by the attacker is the only one which allows for sustainable risk analysis. For instance, suppose that you begin in a situation where users choose their passwords at random, uniformly, in a set of N possibly passwords. Attackers then customarily explore passwords in lexicographic order. Noticing that, a user may then say to himself: "hey, I will begin my password with 'zzz' so that the attackers try that last. How cunning of me !". However, this won't last: attackers will adapt, and will begin to try passwords in reverse order. Our witty user will then choose a password which begins with "mzz" or "naa", so as to be in the middle of the range, at a "safe distance" from both kinds of attackers. This will only prompt some attackers to start exploration at the middle of the range too. And so on...

This example shows that the advantage that a user may gain over attackers based on asymmetry of information is, at best, transient in nature, and cannot be reliably quantified, because it depends on the "smartness" and evolution speed of attackers. So we prefer to assume that attackers try passwords in the "optimal" order, i.e. that they already know how we generate passwords.

Under these conditions, the best that user can hope for is uniform selection: when there are N possible passwords, and each password has probability 1/N of being selected, the attack's average cost is N/2. The interesting points being:

With uniform selection, the attack's average cost is always _N/2_; there is no selection strategy which makes it faster or slower.
When there are N possible passwords, for any distribution of probability of selection, the average attack cost of the best attack is always, at most, N/2. This is easily seen by considering that the attacker may try passwords in a random order, and that one will have average cost N/2 regardless of the user's strategy.

To some extent, this in fact means that random order is the attacker's strategy which minimizes the attacker's risks. Exploring the N possible passwords in a random order guarantees an average cost of N/2, regardless of how cunning the user might have been in his password selection strategy. From the point of view of the attacker, using a specific, defined order runs the risk of being outwitted by the user. Attackers are rational beings too: we assume attackers to have perfect knowledge of our password generation strategy because we could not evaluate our risks otherwise; similarly, attackers assume that users could be fully aware of the order of password space exploration and select passwords based on this knowledge, so rational attackers react by enforcing a random order.

All of the above, though, is for a known, finite space of possible passwords. This is what would apply, for instance, to old Unix passwords with the DES-based "crypt" function: the space is the set of all sequences of 8 ASCII characters.

In many practical cases, the space of passwords is more open-ended, and the attacker will have a rather low success rate: he will crack some passwords, but not all. In that case, the password exploration order does not matter much: for each password, the attacker tries a complete space of N passwords, which either works (the space contains the user's passwords), or, more often, does not. For all cases where the attack does not work, the attacker's cost will be that of N tries, no more, no less -- and this does not depend upon the order in which the attacker tries.

So the practical answer is: it does not matter.


Application Security Input Validation: Validating Environment Variables and Config files

(this should probably be a comment but i's a bit verbose)

  Validating environment variables and config files is a new concept to me

At first this struck me as odd - then I remembered that not alJ2EE applications run in a controlled environment. It's a question of trust. I deal with web applications where I'd put more trust in the config of the environment than in the code itself - here that statement makes no sense. OTOH if I were writing an app to be run on desktop PCs then I'd be a bit suspicious of anything fetched from the local system.

  I would....sanitize it

No.

Validate inputs
(i.e. accept or reject them in their entirety)

Sanitize outputs
(convert them to a representation appropriate to the medium they are going into).

Sanitizing inputs is a really bad idea. You don't know where the data is going until your code looks at it. If it can arrive in your code in a state where it can do something unexpected (code injection, buffer overflow etc) then its too late to fix the problem.


Filling the disk with random data prior to encryption?

There are a few reasons why this is necessary. First, as you stated, it makes cryptanalysis of the data difficult due to being unable to identify the boundary between ciphertext and background noise. This could be defeated by capturing two snapshots of the volume and identifying the locations that change, so it's hardly a concrete security measure in this sense. This issue actually brings us onto a more important one - file systems don't evenly spread their data around on the disk, and often leaves remnant data hanging around.

This is where the background randomness is important. If an attacker can identify old blocks of ciphertext, e.g. from a file whose data was recently updated, he now has access to two versions of ciphertext using the same key (and likely the same IV, too) for two different plaintexts. This can lead to certain attack scenarios becoming more feasible, e.g. differential cryptanalysis. The background randomness makes identifying latent blocks of ciphertext exceedingly difficult.

Another case where background random data is mandatory is when deniability is required, such as TrueCrypt's hidden volumes feature. If an attacker can see that the volume spans over 10GB, but the volume only shows as 4GB when mounted, he can tell that there is a 6GB hidden volume too. By making the entire disk's data completely random, the ciphertext becomes indistinguishable from that background data, making identification of the hidden volume difficult if not impossible.


What mechanism to use for simple and secure HTTP API access?

For mobile clients the potential problem with session based authentication is that you probably have to have very long session timeouts, as users typically don't like entering their credentials every time they use an application.

At that point, whether that's acceptable might depend on how you're restricting the use of the Session ID.  If all it can do is take relatively non-sensitive actions then it might be a reasonable solution (not really that different to an OAuth access token), but one concern might be if an attacker gets access to that token he can take security sensitive actions like changing the users credentials.

At that point you might want to consider OAuth or something similar to restrict the actions that a specific token stored on a mobile device can take.

One other point to mention about HTTP basic or digest is that using them gives you the headache of storing the users credentials on the client.


Remote Registry allows bypass of 2FA enforcement with 1FA

It is by Kerberos design - it verifies Smart-Card on initial logon only for interactive logons. Remote Registry - is not an interactive logon.

Yes, there are 3rd party solutions to enable strong 2FA control on a low level (DC level LSA) by using Subauthentication package LSA plugins - Authlite (hacks LSA on the fly) and Rohos Logon.


why do I get an email with address of Me'.exe'

Normally this seems to look like an error because it is really exposed, suspicious and because it is right in the title of the email. If there is an attachment I do not advise you to open this up in your real enviorment with an antivirus. As a matter of fact do not open it at all.

However this seems some sort of adware according to a specific site, either way if your that curious download a VM and open it up simulating a sandbox enviorment and execute it to see.


The LUKS master key is generated in a truly random manner.  As a result, there is no way to guess it faster than simply trying every possible key, and it provides the full potential strength of the underlying encryption algorithm.

Your passphrase is probably not random (and even if it is, it only provides 197 bits of security, while some encryption algorithms provide as much as 256 bits).  Because of this, trying to guess the passphrase is probably faster than trying to guess the key derived from it.

Note that LUKS Nuke provides no additional security over plain LUKS when faced with an intelligent attacker.  A smart attacker will make a copy of the encrypted volume before trying to beat your password out of you, and giving them the "erase" password will only wipe the copy, not the original.


Average number of exploitable bugs per thousand lines of code?

Any number you get is going to be fairly meaningless -- some factors to consider:

Programming Language - Some languages let you do very unsafe things; e.g., C makes you directly allocate memory, do pointer arithmetic, has null terminated strings, so introduces many potential security flaws that safer (but slightly slower) languages like ruby/python do not allow.  Purpose of application?  What type of coder/code review?
Type of Application - if a non-malicious programmer writes a relatively complex angry bird type game in Java (not using unsafe module), there a very good chance there aren't any "exploitable" bugs -- especially after testing; with the possible exception of being able to crash the program.  A web application in PHP written by amateurs, has a good chance of having various exploitable flaws (SQL injection, cross-site scripting, bad session management, weak hashing, remote file inclusion, etc.).
Programmer expertise at writing secure code.  If you hire a high school student with no past experience to code up some web application, there's a reasonable chance they'll be major flaws.

Furthermore, counting the number of "exploitable" bugs is not a straightforward task either; if finding bugs was straightforward they'd be removed in code review.  Sometimes many bugs only arise due to subtle race conditions or complex interactions among programs/libraries.

However, if you take open-source projects, its fairly easy to find a count of LoC at ohloh.net and a count of "exploitable" vulnerabilities at cvedetails.com (I arbitrarily defined 'exploitable' as CVSS over 7).  I randomly decided to look at some web browsers, programming languages, and web frameworks and found:

Web Browsers:

Google Chrome 380 CVE with 6 239 930 LoC so 0.06 vulnerabilities per thousand LoC.
Firefox 395 CVE in 8 000 969 LoC at rate 0.05 per 1000 lines of code.

open source programming languages:

python with 3 exploitable CVSS>=7)
in 862 830 lines of code at a rate of 0.003
Ruby 13 CVSS >= 7 in 171 122 LoC at a rate of 0.08
PHP with 122 exploitable CVSS>=7 in 3 761 587 lines of code at a rate of 0.03 (factor of ten worse than python).

Web Frameworks:

django with 1 exploitable CVSS >= 7 in 149 292 LoC at a rate of 0.007.
Ruby on Rails 7 exploitable CVSS >= 7 in 156 317 LoC at a rate of 0.05.

So again for these specific major programming projects (likely written by expert programmers) found rates of major exploitable vulnerabilities at a rate of 0.003 to 0.08 per 1000 LoC.  (Or 1 per 12 500 - 300 000 LoC).  I would necessarily extrapolate to non major open source projects.


Is Signal a secure and secret way to communicate via voice calls?

Browsing through the source on GitHub, one learns that it uses ZRTP.
From What are the vulnerabilities of VOIP-specific security protocols? :

Prateek Gupta, Vitaly Shmatikov (2006) Security Analysis of Voice-over-IP Protocols

We also demonstrate a man-in-the-middle attack on ZRTP which disables authentication and allows the attacker to impersonate a ZRTP user and establish a shared key with another user.

For encryption, it relies on Spongy Castle v.1.46.99.3-UNOFFICIAL-ROBERTO-RELEASE
The upstream of Spongy Castle, Bouncy Castle, has the following CVE against its head:

CVE-2013-1624
Summary: The TLS implementation in the Bouncy Castle Java library before 1.48 and C# library before 1.8 does not properly consider timing side-channel attacks on a noncompliant MAC check operation during the processing of malformed CBC padding, which allows remote attackers to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data for crafted packets, a related issue to CVE-2013-0169.
Published: 02/08/2013
CVSS Severity: 4.0 (MEDIUM)

The software uses Speex and G.711 codecs as per source. Depending on the codec, not only metadata, but also the language and contents of the dialogue may be inferred because the Speex codec uses Variable Bit Rate (VBR) encoding (combined with Any Activity Detection and Comfort Noise Generation, to be more precise) (see the linked Q&A for details).
I recommend looking through the source yourself, though, instead of relying on strangers...


SSL - Enabling Forward Secrecy with or without RC4

Should I configure it with RC4 or without RC4?

Definitely without. From Wikipedia:RC4:

  As of 2015, there is speculation that some state cryptologic agencies may possess the capability to break RC4 when used in the TLS protocol. IETF has published RFC 7465 to prohibit the use of RC4 in TLS; Mozilla and Microsoft have issued similar recommendations.

Apart from that you best use the Mozilla SSL Configuration Generator to generate an appropriate TLS configuration for your setup.

  I'm taking it from this article here: https://www.digicert.com/ssl-support/ssl-enabling-perfect-forward-secrecy.htm

While I cannot find any date when this article was written it is a shame that DigiCert has still such an article online which explicitly promotes the use of RC4. At least the information regarding RC4 in this article are outdated and following this article would lead to insecure configuration.


Private generated and encrypted links show up in Yahoo search, but not Google

Is it because Yahoo crawls private emails (seems really improbable)?

That's highly unlikely. E.g., Yahoo surely wouldn't index a password reset link that you get mailed to your private Yahoo inbox.

  Is it because these emails where somehow leaked on the web and Yahoo crawled them?

That's a plausible explanation. It's sometimes hard to reason how exactly a search engine has discovered content but it had to appear somewhere on the public Internet or be made accessible to the search engine. Another possibility that comes to mind is that the framework of the site automatically indexes all content in a sitemap (e.g. at yoursite.example/sitemap.xml) - it's something that Wordpress often does. Also, are you sure the content isn't visible via directory listing or a publicly accessible database dump?

  Also I was thinking, is it possible that clients copied/pasted the URL directly in Yahoo search, and then Yahoo searched for that and kept it?

I don't know if Yahoo automatically indexes the URLs you search for - this surely sounds risky from a security perspective. But I find it unlikely that multiple of your customers would put their URLs in the Yahoo search bar.

If you have request logs available, you could check which documents the Yahoo crawler was accessing in the past (look for a user-agent containing "Yahoo! Slurp").

Countermeasures

To prevent search engines from indexing sensitive content, you can add a Disallow entry to your robots.txt file with a * wildcard, like this:

Disallow: /app/secretcontent.ext?token=*

But note that not all search engines respect Disallow directives and robots.txt is one of the first places that attackers look at for information gathering.

More generally, you might want to let links to sensitive content quickly expire (or even turn them into one-shot links that can be only accessed once, if appropriate).

Another approach could be sending users the link to yoursite.example/secretcontent and the token separately. The site would then present a form where the user has to enter the token. This form would submit the token via POST so that the token is never visible in the URL and hence can't be indexed.


Is phone number verifications with SMS magic HTTP links less secure than OTP?

Your proposal is to effectively use an SMS OTP code - but make it much longer than usual.
Your longer OTP code would be more resistant to brute force guessing, but there are better ways to counteract the problem of brute force attacks, for example:

Make the OTP code expire after a few minutes (and send the user a new one)
Invalidate the OTP code if the user types in the wrong code too many times (e.g. 3 times)
If the user account sees too many OTP input attempts, lock it out for a while

SMS OTP is now looked down upon because SMS has many security weaknesses. The SMS message could be intercepted by someone else (using a SIM swap attack, or some sort of interception while the message is in transit), and if that happens, the longer URL-based OTP code won't offer any additional security.
Usability is the final issue - some people won't want to open the link on their phone (e.g. if they are logging in on a computer). Their phone might not even have a working web browser, or connection to the internet. A short code that they can type in to any device is more convenient.


Each company will use a different scale, but they all will likely be the result of a weighted score considering:

if it escalates itself
the damage it causes
if it disrupts communication
how hard it is to block/remove
how easy it is to get infected
how it gets passed on to other machines

Here is a similar scale:
http://reviews.cnet.com/4520-6600_7-6274750-1.html

Symantec rates malware based on reputation and behavior classification and doesn't use a 'low-high' scale anymore.


Please check that you are sniffing the correct interface. nmap traffic may go on loopback one (using routing information) and you may sniffing the external iface.

If interface is correct and if you are using pcap capture you may want to add '-k none' option to avoid checksum offloading related problem.
Missing alerts often comes because suricata will ignore packets with invalid checksum. And checksum offloading on the card will cause that for locally emitted packets. So when you are using local traffic to test traffic you should take care of that. Solution is to used modern capture method like af_packet or pass '-k none' to stop validating checksum.


Should admin passwords be on a different database than regular passwords

Is there a reason why I would use the same table for both set's of hashes?

Not really. You can use a separate table if you want. From a development perspective it might be slightly easier to use a single table (since you can re-use any stored procedures) but from a security perspective it doesn't increase or decrease your attack surface in any meaningful way.  There is no harm with either decision.

Just be sure you are only storing the password hash and salt, and that you generate a new salt each time.


Based on the MSRPC DCE-RPC IFIDs from the first command output you posted, the target appears potentially vulnerable to MS00-070, CVE-2000-0544, CVE-2001-0662, CVE-2002-1561, CVE-2003-0533, CVE-2003-0818, CVE-2004-0894, CVE-2005-1984 (Nessus 19406 and 19407 as well as CANVAS ms05_043 and CORE IMPACT MSRPC SPOOLSS Buffer Overflow), CVE-2005-2119, CVE-2006-0034/1184 (Nessus 21334 and CORE IMPACT MSDTC Allocation), or CVE-2007-1748. You can get cursory information about some of the IFIDs identified by using the epdump tool or deep information about each IFID by going through the Windows network services internals documentation here:

12345778-1234-abcd-ef00-0123456789ac -- References: samr, samr interface, SAM access
2f5f6521-cb55-1059-b446-00df0bce31db -- References: Unimodem LRPC Endpoint
906b0ce0-c70b-1067-b317-00dd010662da -- References: MS-DTC, IXnRemote operations, Distributed Transaction Coordinator
367abb81-9844-35f1-ad32-98f038001003 -- References: SVCCTL RPC, Services Control Manager
12345678-1234-abcd-ef00-0123456789ab -- References: winipsec and spoolss, IPSec services and Spooler service, winipsec operations, winspool operations
50abc2a4-574d-40b3-9d66-ee4fd5fba076 -- References: DnsServer, DnsServer operations
e1af8308-5d1f-11c9-91a4-08002b14a0fa -- References: epmp, RPC endpoint mapper, Portmapper, Portmapper RPC service, epmp operations
0b0a6584-9e0f-11cf-a3cf-00805f68cb1b -- References: localepmp, localepmp operations
99fcfec4-5260-101b-bbcb-00aa0021347a -- References: IObjectExporter, IOXIDResolver, IOIXResolver operations
afa8bd80-7d8a-11c9-bef4-08002b102989 -- This is the RMI, or remote management interface that allows all of this enumeration to occur without authentication. Generally fixed in XP SP2 but the machine you are targeting behaves more like Windows 2000 or Server 2003.

If you want a pretty GUI that enumerates all of the IFIDs and explains what they are, check out this older tool from securityfriday.com called RpcScan. The download link therein didn't work, so after a bit of sleuthing, I was able to find the tool at a disreputable location -- here -- but I was able to verify the GPG signature contained in the zip file by using '--verify' on the .sig file, using '--search-keys' for the resulting keyid, editing the key to add trust, and finally verifying the signature with the associated executable. You may want to run it in a blow-away guest VM just in case.

Additionally, that first IFID shows that the SAMR is running on 192.168.41.221 via TCP port 49179 because of dynamic allocation. This can be queried using a tool such as walksam from the rpctools utilities bundle.

Read more about rpctools here -- https://web.archive.org/web/20070510223113/http://www.bindview.com/Services/RAZOR/Utilities/Windows/rpctools1.0-readme.cfm

And download the zip file here -- https://web.archive.org/web/20070510223113/http://www.bindview.com/Resources/RAZOR/Files/rpctools-1.0.zip

Query the server using the following technique:

C:\> walksam -p ncacn_ip_tcp -e 49179 192.168.41.221

Also run walksam (against all SMB hosts) without the flags to get more general user information as it walks through the SAM database. TrustedSec also released a tool to perform RID cycling, which is one of the techniques performed by walksam. You can check out rid_enum.py in more depth on its GitHub page.

There are plenty of tools that relate to pivot points from the information you gathered via those metasploit-framework auxiliary modules. Some can be found here -- http://winhackingexposed.com/tools.html -- and are discussed in that book's sections on RPC and SMB Enumeration in Chapter 4. I'd also recommend Chris McNab's work as I gathered much of the information for this answer from his wise books.

The best modern equivalent for this MSRPC toolchain is the CoreSec impacket tools. There is an rpcdump.py, but you may get better use out of their ifmap.py and opmap.py tools. These will lead you towards the other tools, such as samrdump.py, lookupsid.py, and potentially even services.py or secretsdump.py. These are all speaking purely from an MSRPC DCE-RPC perspective, there may be many other pathways into this Windows machine or surrounding environment.


Why use anything other than RSA for transmission encryption?

RSA (and other public key cryptosystems) is extremely computationally expensive, making it impractical to use it to encrypt an entire transaction. So public-key encryption is generally used only to agree on a symmetric encryption key, which is then used to encrypt the rest of the transaction using a symmetric algorithm such as AES or 3DES.

See the accepted answer to this question for more details.


How to uniquely identify / tag client devices to whitelist VPN access?

I'm sorry that we don't know more details about your infrastructure, but basically i would recommend you stay tuned with certificates. Maybe this Video about Client Certificats helps a little.

Another way would be to use Radius Auth or something else (e.g. MSAD)


Should I implement access control on databases inside a trusted network?

Yeah, "designed to operate in a trusted environment" is a fairly common thing for backend servers, though you usually see it as justification for not using TLS between services, or for new nodes to join the cluster with no auth. In the Redis case, they are using it to justify a port with no auth by claiming that an attacker would need to be able to ping the port directly to do any damage. Basically, this is a way of shunting responsibility for security away from the software and onto the network engineers. Maybe you're comfortable with that and maybe you're not, but Redis is being up-front about it so you can decide whether Redis is an appropriate technology for your security goals.

With databases an attacker can sometimes attack the db through your app (for example if you have an SQL Injection vulnerability), so we talk about the Principle of Least Privilege; ie each node has has only the minimum amount of read/write access that it needs to do its job to limit the damage that a compromised node can cause. So do your due diligence and see if the "designed to operate in a trusted environment" argument applies to your scenario, but if I was the appsec engineer responsible for your product, you'd have have a hard time convincing me that it's safe to ignore the Principle of Least Privilege here.


Your company takes on any and all risks associated with any breaches.  You'll find that by signing up for public cloud environments, you'll have to sign a document accepting that provider's Terms of Service.  Among those TOS will be something along the lines of a full waiver of any liability on the part of the provider.

Even in the "compliant" (as in PCI/FISMA/ETC) cloud environments, you'll see that same sort of language, even though in those cases the providers have gone through (hopefully) some pretty significant auditing of their policies, procedures, and security measures.

Nobody keeps critical data in a public cloud.  Until hypervisors are guaranteed to be bulletproof (and they're not at this time), I would never trust a public cloud with any data that required any kind of compliance or regulatory oversight, like Personally Identifiable Information, financial data, medical records, etc.

With a private cloud, you are at least relatively assured that the other users (VMs) in the environment aren't trying to break through the hypervisor to get to your data.  You have full control of the hardware (full stack, not just the servers), hypervisor, VM images, access controls, and auditing and logging.

One thing we're starting to see more of is hybrid environments.  Where the critical data is maintained in a private environment, while portions of the stack that don't host critical data might be in the cloud.

For example, keep your SAN, and your DB servers in the private space, but keep your webservers in cloud, where you can use the elasticity of cloud computing to dynamically grow and shrink the number of servers running at any given time to accommodate changing work loads.  Or maybe just the webservers that serve static, non-PII, content are in the cloud, but the servers people log into are in the private space.

There are a number of ways to leverage the benefits of cloud computing without compromising your security.  People are doing it today.  Cloud computing is arguably the fastest growing segment of IT, outside of IT Security.


Why do browsers or operating systems not have default DNSSEC validation?

The Chromium security team say:

  DNSSEC and DANE (types 2/3) do not measurably raise the bar for security compared to alternatives, and can be negative for security.
  DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pinning to the same effect, and with a much more reliable and consistent delivery mechanism.

(see https://bugs.chromium.org/p/chromium/issues/detail?id=50874#c22)

They've spent quite a lot of time and effort working on HPKP support, and Firefox have been making use of a lot of the tools they produced (e.g. the built in pinning lists). Therefore, they probably don't see much point in supporting a different method, when they have one which they consider better. Microsoft have also been investigating it, but haven't made any particular stand (although they don't appear to have been investigating DNSSEC). That's the main players in the current browser market leaning towards an alternative.

However, HPKP is built on HTTP - it's designed purely for the web. DNSSEC doesn't have that restriction, so can be used for other applications. It can verify that DNS records actually come from the domain owner, which can be useful for mail servers, or for small scale DNS resolvers, ensuring that a malicious actor able to modify traffic can't tamper with the records in an undetectable fashion. Because of this, it's still considered important to deploy - DNS is used for a lot more that just web pages!


How to guarantee only my client application can request a nonce?

A nonce is used in the process of authenticating the client. If you want to make sure that only your client application requests the nonce you need to have to add some authentication first - before accessing a nonce, i.e. authentication of the client application before doing authentication of the user. This might sound kind of silly - and it is not actually not needed.
There is  no real need that only specific client applications can get a nonce. Properly implemented a nonce is cheap to issue and there is no need to restrict who can get one.


Identifying hash format caputred via Metasploit

username::DOMAIN:1122334455667788:stringof32numbersandletters:muchlargerstringofrandomnumbersandletters

Username: username
Domain or NTLM realm: DOMAIN
Challenge: 1122334455667788
LM Hash: strongof32numbersandletters
NTLM Hash: muchlargerstringofrandomnumbersandletters

If you are wondering why you can't pass these hashes in the pass the hash attack, the reason is that both LM and NTLM hashes are not the same as the ones stored in the SAM or Active Directory store. These hashes are concatenated with the challenge and then send over the wire. The reason of setting a static signature 1122334455667788 is to use the pre-computed rainbow tables generated using this challenge.


What is the difference between Simple Power Analysis and Differential Power Analysis?

Simple Power Analysis (SPA) involves measuring variations in power consumption of a device as it performs an operation, in order to discover information about secret key material or data. This is achieved by mapping certain operation types to consumption patterns. For example, a series of exclusive-OR operations exhibits a different trace on an oscilloscope to a series of multiplication operations.

A good example of this is RSA, which has to perform large multiplications, and therefore leaks information about the internal state of a large integer multiplication via the pattern of operations it performs.

Another trick involved in SPA capitalises on the fact that digital signals are represented physically by high and low voltages, and therefore a 1 being signalled uses more power than a 0, for the time period that that bit is being transmitted. If accurate enough analysis can be done, we can compute statistical models that predict the contents of a bit-stream within a reasonable margin of error.

Whilst relatively simple single-purpose systems (e.g. smart cards) are usually only performing a single operation, more complex systems are usually performing several operations at once. A modern desktop computer uses technologies like DMA, which allow hardware to access system memory directly, without interrupting the processor. All of these signals run in parallel, generating a huge amount of noise. On top of that, mechanical hard drives contain components that generate various current spikes, adding to the noise. Trying to identify the statistical patterns of a single 133MHz+ data signal in such a system is exceedingly difficult!

This is where Differential Power Analysis (DPA) comes in. In order to improve the chances of success, DPA involves analysis of power consumption when normal non-cryptographic operations are being done, then further analysis during the cryptographic operations. The two statistical models are compared, in order to "subtract" the noise from the signal. This technique is actually common among audio engineers, who sample background noise (e.g. hiss) on its own, do an FFT analysis of it, then produce an EQ-like filter model that reduces the levels for those frequencies. It's more complex in DPA (often FFT alone is too primitive) but the principle remains true.

Of course, this is still a very difficult model to compute, but even a 51% successful prediction rate is useful when dealing with cryptographic keys; bruteforcing a 128-bit key is orders of magnitude easier when you can prioritise higher-confidence predicted bits -  a 51% success rate gives us an effective expected key space of 125.5 bits instead of 128 bits.

FPGAs can't really be attacked with SPA because they're "parallel" in nature. They don't really work like a normal microprocessor, instead they're a series of parallel logic gates that all operate in unison on a single common clock signal. As such, SPA can't identify separate "signals" because every internal component does the same thing on every clock cycle. Microprocessors, on the other hand, often have separate internal die sections that can be independently clocked, and which route and multiplex signals in real-time. This is all somewhat of a generalisation, since some more modern complex FPGAs do have microprocessor-like internals alongside the static logic, which may be vulnerable to SPA.


It seems like this may just be probing for vulnerabilities, error messages, difference/changes in response size and result.

For example by providing all the different values to your backend system may provide the end user with for example:

Maybe looking for information disclosure. A too verbose error message. It may reveal datatypes, names of columns and what not.
Unintended use of the script. For example exploiting logic flaws in your script by say trigging multiple IF statements or something similar.

The attacker may be looking at the result coming back to see if any drastic changes has happened to the webpage or size of the result (in kilobytes).  Often when doing very many requests against one page it is easiest to distinguish changes based on the result size. If any of the GET parameters has triggered something the developer did not think about, the mission may be successfull for the attack.

I am sorry I could not provide a definite explanation on what this attack may be all about, but this is what I think it is.


How can multiple receivers decrypt message with public key

Public key is meant to be namely public, means it should be available to everyone. I suppose that by saying that you put it to the server you mean you make it possible to download public key from your server.
Everyone who wants to decrypt your message will download public key from your server, where you put it, and will decrypt the message.
I'd suggest you to check the what you are trying to reach by such scheme.

Confidentiality? Everyone will be able to decrypt such messages. That's why you cannot reach confidentiality by using such scheme. If you need confidentiality, i.e. if you want that nobody except the receiver is able to decrypt the message, then you can use other scheme: Use public key of receiver-1 to encrypt messages to receiver-1. Then nobody except receiver-1 will be able to decrypt them. Messages to receiver-2 encrypt with pubic key of receiver-2. I don't go on details about hybrid encryption here.
Non-repudiation? It might be used for non-repudiation, because no one could produce such encrypted messages except you, the owner of the private key. Where as the idea is basically correct, a direct implementation would be insecure. See details here: encryption+decryption vs. signing. Instead of encryption+descryption use standard algorithms for digital signature like ECDSA.


Migrate a x509 key using KSP (CNG) to CSP (CryptoAPI) in Windows

It can be done using openssl. The procedure is as follows:

convert the source PFX to PEM
convert the PEM back to PFX

Example:

openssl pkcs12 -in mycert-cng.pfx -out mycert.pem
openssl pkcs12 -export -in mycert.pem -out mycert-cryptoapi.pfx

On my machine (Windows 8.1, openssl 0.9.8zf), the resulting pfx referenced the "Microsoft Enhanced Cryptographic Provider v1.0" CSP. openssl pkcs12 also provides an option to request a specific CSP (-CSP "CSP name").

Windows binaries of openssl can be downloaded e.g. from here.


SHA256.DB30.com listing of email account

I also found my email address listed on db30. After a bit more research I found out that my address and password had been harvested during a Gmail security breach in September. Try checking your address at haveibeenpwned.com to checked if yours is listed in any of the major security breach lists.
Also it could be a good idea to change your passwords for your email and any other sites that you use eg.online banking, shopping etc.


I'm only speculating, but yes the N's are for the initial buffer overflow.  You'll notice that %u9090%u6858%ucbd3%u7801 is repeated over and over.  These are 8 bytes of unicode values in hexidecimal.

%u9090 is most likely a NOP (no operation) machine instruction.  In hexidecimal for Intel x86 then this instruction is one byte, 0x90.  So it repeats these 8 bytes 3 times.  The purpose I'm guessing is to overwrite the return address with its own address.

Then you have %u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00.  Which seems to me that this is the shell code needed to gain execution.  If you remove the unicode designatore %u you get a stream of instructions.  Using radare2 you can run the following command on 90909090819000c300038b00531b53ff00780000

rasm2 -d 90909090819000c300038b00531b53ff00780000
nop
nop
nop
nop
adc dword [eax + 0x300c300], 0x1b53008b
push ebx
inc dword [eax]
js 0x13
.byte 0x00 1

Now I could be wrong about the first 3 repeated values.  Maybe they're part of the shellcode.  So lets just run the same command on the full byte string:

$ rasm2 -d 90906858cbd3780190906858cbd3780190906858cbd3780190909090819000c300038b00531b53ff00780000
nop
nop
push 0x78d3cb58
add dword [eax - 0x34a79770], edx
sar dword [eax + 1], cl
nop
nop
push 0x78d3cb58
add dword [eax - 0x7e6f6f70], edx
nop
add bl, al
add byte [ebx], al
mov eax, dword [eax]
push ebx
sbb edx, dword [ebx - 1]
add byte [eax], bh
.byte 0x00 1

To learn more about how buffer overflows work; check out Why are buffer overflows executed in the direction they are?, and Security implications in neglecting trailing NULL byte.


The reason onion-routing is called onion-routing is because the encryption has many layers around each other, just like the many layers of skin of an onion.

Image Source: Wikipedia

Every node adds an additional layer of encryption. When you send a message (let's assume non-https for now) via the routers 1, 2 and 3, you encrypt it with the pubkey of router 3, then you take the encrypted message and encrypt it with the key of router 2 and then you take that and encrypt it with the key of router 1. Each router can then "peel off" its layer of encryption, finds another encrypted message and the address of the next router. It then forwards the message to that router. The final router sends the clear-text message to the final recipient. The final router must know the clear-text, because the recipient doesn't expect encrypted communication.

When you additionally use HTTPS, the message itself will also have an additional layer of encryption between you and the recipient. In that case the final router does not learn the true content of the message.

But how do the routers know how to sent the message back? This is only possible when the exit-node also knows the public keys and addresses of all the nodes of the circuit. But in order to encrypt the response, it doesn't need to know the identity of the source. Only the entry-node needs to know this.


On the surface, it's pretty silly: if you don't want traffic inbound on a given port, then just don't listen on that port. As such, host-based firewalls have traditionally been largely ingored. But recently (as in, last 20 years) the practice has picked up quite a bit. Here are a few common reasons:

Because you can't control what's listening on your computer
Host-based firewalls have been the traditional mechanism for controlling the behavior of Microsoft core services, such as port 135 and 445. In the interest of simplicity and ease-of-use, Microsoft traditionally did not allow those services to be at all controlled, which meant that a firewall was the only way to control access.

Because you want to restrict but not prevent access
Firewalls allow you to filter traffic based on more than just the listening port number, which means that you can do fancy things like allowing access only from a given range of IPs or other criteria. While not a foolproof security measure, it does eliminate the vast majority of malicious traffic, allowing you to focus your attention on the more advanced attackers.

Because you might already be compromised
This is probably the most commonly-cited reason, but also probably not the most valuable. The idea is that if you block access to additional ports beyond what you're already expected, then it's more difficult for an attacker to leverage an initial compromise to gain more complete access to the server (e.g. by binding a remote shell to an additional port). While it's true that this does make it more difficult, any average-skilled attacker can work around this restriction, so the incremental security it provides is minor.

To enforce policy
The idea here is you have a specific set of applications that are allowed to listen on the network according to your security policy, and you don't want an admin to add to that list. In the unlikely scenario that the rogue admin knows how to install software but doesn't know how to reconfigure the firewall, this would stop him.

Looking at this list, it's clear that all of these scenarios (except perhaps the first) are best met using an edge firewall as opposed to a host firewall, since filtering at the gateway cannot easily be changed by someone with admin rights on the host.

Still, just because it's better to do at the edge doesn't mean you shouldn't also do it on the host. Remember that a truly secure network is one that remains secure even without perimeter protection. Layering your defense will help keep you protected even when parts of that defense fail.


Avoiding the race condition between time of release and time of update

This is where the concept of Defence in Depth comes into it's own.  Yes, patch regularly and properly, but account for the fact that in any non-trivial
system you will have vulnerable components.

Your first line of defence, as XSS is sometimes exploited via phishing, training your end-users about how to spot and avoid phishing attacks.

If the user had implemented a Web Application Firewall; then whilst the XSS may still exist, attempts to exploit it can be detected and blocked.

If the webserver is configured with standard same-origin policies, the likelihood of an xss being sucessful is reduced. Even if the WAF doesn't detect it.

If your software uses proper session management, and relies on e.g. re-authentication for critical transactions, then the impact of an XSS attack can be significantly reduced, even if it's successful.

If you ensure that data is properly encrypted, users have access only to that which they need, and that sensitive data is only stored when it's absolutely necessary, exploiting that xss vulnerability will cause less harm, even if they give an attacker full access to the vulnerable system.


Does Outlook "trusted domain" actually do any sort of checking?

It appears from Microsoft's documentation that the "Mark this domain as trusted" is a simple regex on the sender's email address, including the account name. So, it would appear that there is no analysis of the headers, MX records, SPF records, etc. on the client-side.

That means that a spoofed allowed email address from a blocked domain could be treated as an allowed email.

But this is the client-side of things. Header analysis should be done on the server-side, checking the SPF records, matching account domain with server domain, etc. By the time it gets to the client, all that should (that's a big 'should', I know) be required is a simple regex on the email account ("I don't want to hear from Bob").

I do a lot of phishing analysis and attack simulation, and I have successfully used a client's internal Exchange server to spoof internal employee's email from my own custom application. So, I know that hoping the server will do everything is a vain hope. But, my point is that the client really isn't designed or supposed to do this level of checking for you, protection at this level is expected to come from the server.


Personal digital certificate how to verify

The purpose of a certificate is to bind a public key with an entity and this is the responsibility of the PKI's Registration Authority to ensure that the entity identity in the certificate matches the key holder entity (e.g. for SSL certificate an entity can be a server, the identity is the domain name).

The procedures describing how this match is performed by the RA can be found in a public document published by PKI and named the Certificate Policy.

This is the responsability of the user of a certificate (for encryption of signature validation) to read the CP and decide how trustworthy the Certification Authority which issued this certificate is. Of course you do not put the same confidence in some PKI which declares that only the key holder's email is verified and a PKI which delivers the certificate on a smartcard, directly in the hands of the key holder, with an offical ID check. But sometimes verifying the email may be sufficient.

Actually the most important questions to ask are:

which data in the certificate have been checked by the RA?
did these data collected in a trustworthy way?
according to your needs (email signing, electronic signature of a contract...) can you trust the certificate?


They are safe,  but is very good practice escape or convert them

This will allow you avoid being:

script injected
Face a browser text incompatibility ( have you seen    those sites
with unicode like chars? )

And Probably more

See it as a standard way to represent a text as it should be in different languages and codifications,  like some strict  utf8 will show a bad formatted text if you don't escape them, because some special chars with acute or tilde, etc will be not recognizable  to the end user when showed up.


Love the suggestions you gave so far, I'll be keeping them in mind for future reference!

My #1 suggestion would be to attack your own employees. I don't mean you should run around with an axe all "Here's Johnny!" style, screaming at people about proper security practice, but rather stage cyber-attacks and judge their responses, then explain to them what they did right / wrong. People learn through experience much better than they learn through reading an email.

One of the easiest and most effective methods to try is an external website containing a login screen, with the company logo. Send out emails to employees from an external account, claiming to be the sysadmin, saying you've got a new staff portal. Every time a user logs in, have it direct to a page explaining what they just fell for and how they can recognise it in future. Include your phone number and email address in case the user wants to know more. Every time a user calls you up to ask if it's safe, or to report it as a security issue, tell them they did the right thing and make sure their line manager is aware of their success.

Next one to try is a more direct one. Send out an email (again, from an external mailbox) saying that the database is having problems and you've got to re-enter everyone's passwords. Ask them to send their passwords to a "secure password update mailbox", and wait. Every time someone sends a password, explain to them that they just fell for a phishing attack. Downside of this attack is that you'll have to reset a lot of people's passwords!

Just one word of advice: get authorisation to do this before you start the project! ;)


You need to perform an incident response, you can hire a firm like Trustwave, but my guess if you don't have the funds for such a large investment.

Since you are using a popular open CMS system, its going to be a target of attack. It is also built upon other open source components, so those may be affected.  Of course, there are a number of other vulnerabilities that are possible given any number of third party, built-in, or home brew components. You can find a list of recent exploits and bugs at the NIST CVE database listing of Typo3 Vulns.

There are a few things that could be resulting in a massive infection that seems indiscriminate. If the permissions of the files and directories are not set correctly, or if the file and directory ownership is misconfigured this could be the first problem. There may also be some script or piece of software which is vulnerable and has the ability to execute arbitrary code, and thus can write and append any files it finds. If it has the ability to arbitrarily execute shell commands, then its easy to search for all php file and inject the code with a few lines of code.

Another possibility might be a flaw in another tool you are using, maybe a web-based management console for hosting or a helper application like phpMyAdmin or some other random code is vulnerable.

At any rate, the first place to start your investigation is by reviewing the activity logs. I'd start with your ssh access logs to determine if anyone logged in directly when you do not think you did. Next, you should look at your server access logs. If there is a flaw in some web application, they probably had to issue a command against your page. They may have googled for a certain common HTML source string in google and the target all sites they found broadly. Is so, they are probably re-running their attack every so often to reinfect you if you didn't find the hole. Look for log entries that seem to have SQL injection or XSS. This could be labor intensive process, but if you think you know the timeframe of when you got hit, that should help limit your search.

Another check is that you have removed any installation or other files they recommend you remove that could allow an attacker to reset defaults, etc. Also, be sure you are using strong, unique passwords. After an attack, I would always recommend changing your passwords as a precaution.

Lastly, there are often clues in the exploit code itself. Did they infect it to redirect to a certain site, do they have "greetz", or anything else that you may be able to google and find someone else talking about on a forum? Unless the attack is against your custom code, its likely someone else got hit in a similar way as well.


The answer to denying brute force is to deny a large number of attempts, where large is defined by your key space and risk acceptance.

Each situation is going to have different solutions.

Meat Space

Doors are reinforced against brute force damage.
Crashing through a door is mitigated by chance of alerting the police.
Keys only have around 5 variables, but it takes resources to have one of each key (easier to attack the lock in other ways that aren't brute force)

Computers

Automating brute force attacks means you need to rate-limit in some way.  With a rate-limit, you can absolutely know your upper band of attempts over a certain amount of time.
Monitoring:  If you can limit brute force attempts to a certain rate (500 / day perhaps), then monitoring and alerting can let a person know to take a closer look at what is going on.  How many attempts will it take to reach a certain level of unacceptable risk?
Large Key space:  Having complex password requirements can greatly increase the number of attempts required for a certain probability of finding the password.
Two factor authentication: brute forcing the password isn't enough in this case

All of the solutions also have trade-offs like everything else in life.

Rate limiting: can DoS legitimate users, not effective if attack is breadth first - one attempt for each account before trying a 2nd time
Rate limiting by IP: Not effective if it is a distributed attack
Password complexity:  Is usually a tradeoff in usability meaning users will write down their passwords - decreasing security by a greater amount than the brute force threat
Two Factor: might be seen as expensive, can lose tokens


Can unprotected SSH be an issue if port 22 is open locally but not externally?

Yes, frankly. If you get a compromise in your network, one of the first things a worm-type malware will do is scan the local network for SSH.

Alternatively, if your webserver is compromised and the nature of the vulnerability means that the attacker can get network access, they might try to connect to the ssh port from the web service and get higher privileges.

But then it all comes down to what you mean by "unprotected". While I might not go crazy with firewall rules (although I might lock down the webserver's ssh to just your normal computer that ssh'es to it, if that's possible), having a very strong password or key-based authentication is advised.


When you are sending the URL of the captcha image to the client, the client will download that image. This is how viewing images on websites works.

The client now has the image in memory. They can do with that data whatever it wants, including sending it to a captcha solving sweat shop. The sweat shop doesn't receive the original URL, just the raw image data. When they solved it, they send back the response and your client can forward that response to you.

From the perspective of your application, the client is a completely black box. Sorry, but there is no way to tell if they solved the captcha themselves or outsourced it to a different party.

But if you are a low-value target for spammers and bots, then there is an alternative solution with which I achieved quite good results in the past: A simple context-based text question. I once administrated a forum about a video game. The forum was really adored by spam bots. We tried different captchas, but none worked. Then I added a simple question to the registration form: "Enter the name of the game this forum is about". Then the spam was gone. The question of course accepted a large variety of possible misspellings and conceivable abbreviations and shorthands to make sure that no legitimate human user was blocked by it.

Note that some spam bots (or their human captcha solvers) have evolved to be able to answer very trivial questions. What's 2 + 4 or Enter ''I am not a spam bot'' here don't work anymore. But if you ask for some domain-knowledge which every legitimate user should know but which is unclear for someone (or something) which looks only at the login form, then it's a useful deterrent.

But this of course only applies to low-value targets. When you are a target which is valuable enough to spend an hour or two on to figure out how to automatize account creation, they will figure out the answer to your question and hardcode it.


What you need here is properly called randomized hashing: conceptually, a family of secure hash functions, out of which you pick members at random and use those to hash the message.  Typically these are implemented as two-arguement functions that take a "key" or "salt" as first argument, but it's important to understand that this "key" is (potentially) not meant to be secret—they may be revealed to adversaries.

MACs in general don't make good randomized hashes, because the standard MAC security goal is for secret keys—keys that are known only to honest parties, and not adversaries.  But HMAC in spite of the name is more than just a MAC—it's built on a secure hash function, so it can be used both as a MAC and as a randomized hash function.

So the short answer is yes, but don't be confused by HMAC's name in this case; HMAC works here because it's a good hash function, not because it's a good MAC.  And if you have a good hash function you don't need HMAC for this—hash(salt || msg) should work just fine.  I'd use HMAC, nevertheless.


Where to find complete Kali image for docker with all the tools?

Use Kali Linux Metapackages after setting up a Kali Linux Docker Image. In 2019.3 there was a Major Metapackage Makeover, changing the names. To combine this information:
apt-get update && apt-get install kali-linux-large

Previously, kali-linux-full was the default metapackage, which has
been renamed to kali-linux-large with a redirect put in place.

When you download a Kali Linux ISO, you are essentially
downloading an installation that has the kali-linux-full
metapackage installed. This package includes all of the tools you are
familiar with in Kali.
Installation Size: 9.0 GB

apt-get update && apt-get install kali-linux-everything

Depending on how you use Kali will determine which metapackage would
suit you best. This is the power of metapackages. For example:

If you want a core set of tools, stick with kali-linux-default (designed for assessments that are straightforward ).
If you want a more general and wider range of tools, select kali-linux-large (useful if Internet access is permitted but slow).
If you want to be prepared for anything, go with kali-linux-everything (great if you are going to be doing
air-gap/offline work)

In order to keep our ISO sizes reasonable, we are unable to include
every single tool that we package for Kali and there are a number of
tools that are not able to be used depending on hardware, such as
various GPU tools. If you want to install every available Kali Linux
package, you can install the kali-linux-all metapackage.
Installation Size: 15 GB


You can't create an application in a way it's not vulnerable to MiTM attacks because these attacks happen an a lower layer than your application works on. You can only secure the network which is used by the clients. There are several countermesures available. First you need port security which will prevent many of these attacks. Then you could add a net based IDS/IPS which is capturing the monitor port of your switch. But all of this wont come for free it will cost you some money and a lot of time.

//
The more practical solution is to use encryption to ensure that someone who performs a MiTM attack isn't able to read the data he captures. But even this won't give you 100% security. The main problem here is that you dont have a server.

Async encription (SSH like)

On both sides you create a RSA key pair and then use this to encrypt and decrypt messages. When the first connection is established between two hosts you save the key of that host to identifiy this host in further sessions. The problem here is that a MiTM-Attacker might interrupt the first session. He is then in a position where he can inject his own certificates to perform a MiTM attack anyway. This will also lead to a sitiuation where in further sessions that aren't interrupted by the attacker the connection will be recognized as insecure because the saved key of the opossing host is in fact the one of the attacker.

Your problem her is that you don't know the key of the opossing side until you connect for the first time. Many companies solve this issue when it comes to ssh by syncing the ssh_known_hosts via a trustworthy server. You dont have such server because of that you can't do this here and you are kind of insecure at the first connection.

Pre-Shared-Key

You can implement encryption with a pre-shared-key but the problem here is always the useability and the user behaviour. When you generate a PSK for every connection then the key must be exchanged. Always remember: People are lazy. They will send the PSK via mail which is potentially unencrypted. Also many people might say "ohh thats to complex I will use another software that is easy to use" and this is how people end up with easy to use but totally insecure software.

// Also none of the described proceedures will prevent a MiTM-Attack they will only prevent the attack from being successful in the way it was ment to be.


What is a Truecrypt alternative with deniable encryption for linux?

TrueCrypt 7.1a has been forked into other projects, such as VeraCrypt, which just like TrueCrypt offers hidden volumes.

I can't comment on whether to trust TrueCrypt/VeraCrypt or not (since TrueCrypt's sudden discontinuation), but both are open-source so you can figure it out yourself, and there has been an audit on TrueCrypt recently (as of writing).


If they are already in your network, just adding a honeypot may or may not be effective - you don't know what they already know of your network.

Do they know the IP ranges for HR, finance, data storage systems etc?
Do they have access to your change management system and would spot a new addition to the network?
Have they already backdoored the servers with the data they want?
Have they already got the information they need?

At this stage if the data is important, you may find it more useful to change access and remove them from your network, rather than try and track them.

Alternatively, if you know where this important data is, you don't need a honeypot - what you need is to closely monitor all activity and see whether any unusual connections are being made.

What has inspired your suspicions? If it was seeing something odd on your network logs, that would be a good place to start.

Generally, honeypots are useful before an intrusion, as they stop or slow an intruder before they get to your data, giving you a chance to identify or block them.


Php parameters (username, password) in link

There is no direct threat from sending the credentials in the query string. Technically, for the server it doesn't matter whether the form data is sent in the request body or in the query string.

So it means that your initial assumptions are all wrong:

  I think now i know which parameters they store in php code.

First, such a knowledge will give you no advantage.
Second, you can see in the browser's console ALL parameters sent to the server, no matter what method is used - the request body parameters are shown in the console as well

  can this lead to a sql-injection?

Of course not. SQL injection is related to SQL, not HTTP which you are talking about.

The only threat here is a chance to expose the password to a third party. First and foremost, it will be stored in the server's access log. Or it can be stored on some proxy server along the way (however, in case the site is using HTTPS, it won't happen).

So in the end, you aren't likely going to gain any advantage in this case but it's better to use the POST method anyway.


Typically, you do not protect forms that are accessible without authentication.   The purpose of a CSRF attack is generally for an attacker to manipulate an authenticated user to perform an action on the site at with the attacker's data and the victim user's authenticated session.  Forms that do not require authentication generally aren't vulnerable to being manipulated in this way.

So, CSRF mitigations are typcially framed using language that assumes/requires the user to be authenticated in order for the vulnerability to exist.  Lumping unauthenticated forms in changes the threat model to one that may be valid for a given interaction, but is non-standard.

Your approach

Form a security perspective, your approach looks fine.  It eliminates the ability to generate a POST or PUT without a preceding GET, but for a browser-based interface that shouldn't generally be an issue, and for this specific threat model, is exactly what you need.


How to secure VPN credentials on end-user devices?

What's the best method/solution for protecting the integrity and identity of end-user certs?

Install an HSM on their devices and use keys stored within it for VPN.  Expensive and difficult to set up.

  I want to make sure that users only able to use VPN with company provided devices.

Then instead of trying to control the keys, which is difficult, use VPN Posture Checking and disallow devices that don't match your required profile.  Depending on your VPN vendor, this may include things as explicit as Domain membership - for example, here's how to do it with Check Point.


Gmail's "View and manage your mail" access

The developers will be able to read your email via the app. If through no other way than to put this "feature" into their application, as you read your emails they can make their application send your emails to them.

No they wont be able to login to https://mail.google.com as you, but they wont need to.


Data deleted after encryption - recoverable?

The data can be recoverable.

The factory reset should delete all data, accounts, passwords and content from your Android device. The problem is, this is only partially true.

Cambridge University researchers tested a range of Android devices running Android and found that in all cases they were able to recover account tokens – which are used to authenticate the 1st time you enter a password (Google, Facebook and WhatsApp). In 80% of cases, they were able to recover the master token, which practically is the main key to the device. Once the master token is recovered, the user’s credential file can be restored and all your data re-synced to the device: that means e-mails, cloud-stored photos, contacts and calendars. So you just offered access to everything!

Devices with built-in encryption are not safe from such a problem because they don't provide the required software to fully correctly wipe flash storage.

Also, it is possible to create an image of your phone’s internal memory and the mount it and dig into it as long as you want.

What you can actually do:

encrypt your phone with a strong password that contains a mixture of upper/lower-case letters, numbers, symbols and is long enough
after reset, fill the device with useless data to overwrite anything sensitive like the tokens and crypto keys left in flash storage and you should do it without re-registering with Google. You can do this fill by copying something or just by recording a video for as long as you can, at the highest possible resolution, until all your available space is full.
finally, reset again


I would recommend looking into how niktohelper accomplishes the same task. In this case first you can run an nmap scan across a range, then parse the output (thus knowing every web port that is open, and which ones use https) and run nitko appropriately.

Doing this yourself your essentially reinventing some nmap functions that are really great. Plus what about non-standard(ish) web ports such as 8000,8080,8181,8443 etc ?


Is it okay to use random OpenVPN config files?

A VPN endpoint is able to read and manipulate all your traffic (a Tor exit node too). Thus using some .ovpn file you just found on the internet means that you offer all your traffic to some unknown party for easy sniffing and manipulation. This includes sniffing passwords, injecting advertisements or injecting malware.

  Is it okay ... ?

If you are used to just use any random free WLAN you can find then there would not be much more of a problem to use some random free VPN endpoint too. I myself prefer it to be more secure but others might prefer that it is free.


Its in general up to the pentester, the context, and your abilities...you can check those links for hints:

Network Penetration Testing Checklist
Web Application Penetration Testing Checklist
Pentest methodology


You appear to be thinking that actions have universal goodness or badness. This is not true.

A white hat hacker, or a security manager, has permission to do what they do. That is the biggest and most fundamental difference. Without permission, it is no longer "white" and it is no longer legal, in many jurisdictions.

NSA hackers have permission from the US laws to do what they do, but they do not have permission from Russia to do what they do. This means that they are not white hat hackers. They are attackers. It's the same for any country.


Why does malware periodically check google.com

Most likely, it's just trying to check if there's a working internet connection.

The malware authors assume that:

Google (or other Alexa Top-1M sites) will be up 99.999% of the time.
Traffic going to common productivity sites like Google will not be flagged as unusual.
You (or your network administrator) will be unlikely to have blocked these sites at the gateway.

As such, Google is a good candidate.


Possible to find out the last person to open a file on Windows without specialist tools?

Well, AFAIK there are two options that do not require activation, nor specialized tools:

Open C:\Users\user name\AppData\Roaming\Microsoft\Windows\Recent Items, and see if the file is listed there.
Open regedit.exe, and navigate to the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs section. You will see values, structured by extension, that have recently been opened by the 'current user' (last 10 files of that extension).

Note that option 1 will only list files that have been modified, whereas option 2 will also list files that have been opened and closed, without editing or saving the file.


Can Jasper files be used as shells to attack java web apps?

Why limit yourself to this attack vector? Being able to write XML which is in turn parsed by another application is often enough to execute code, read or write arbitrary files (XXE attack) through xml, xpath or xslt injection, depending on the configuration of the parser.

I would imagine the most likely attack to take place would be upload jasper that writes a malicious XML file which reads /etc/passwd, if any password hashes are stored in /etc/password these can be cracked to gain authorized access to the server.


Airmon-ng confliciting with network manager in Kali

This is because NM is set to control all your interfaces. So when you kill NM you kill all the interfaces.

You have two approaches, disable NM completely and manually configure your interfaces individually or allow NM to control all the interfaces apart from the wireless one you want to use with airmon.

Depending on the distro depends on how you do this. If the distro is red hat based then typically you just put
NM_CONTROLLED=no in the interface config file at /etc/sysconfig/network-scripts/ifcfg-wlan0.

But as your distro is Kali and debian based then add the wlan interface to/etc/network/interfaces. config file and NM will ignore it.

For example;

iface wlan0 inet static
        address 10.10.168.1
        netmask 255.255.0.0
        gateway 10.10.168.10

Then restart both the networking and network manager daemons with sudo /etc/init.d/networking restart && service network-manager restart

Or you can configure network manager directly to ignore the interface by editing /etc/NetworkManager with the following.

[main]
plugins=keyfile

[keyfile]
unmanaged-devices=mac:*your wlan interface mac address here*


What other evidence can I obtain regarding this key-logger?

You can look in the events logs for looking for entries which describe the date of the eventual installation of the keylogger. For your research, you can search around the created/modified date of the file.

If you want to know how this malware has been downloaded or copied on your harddrive, you can look the history of yous web browsers and in the registry to know which USB-key has maybe been plugged on your system.

If nothing of all of that helps you, youcan search all files has been modified at the same date of the keylogger, maybe it will help you to find and understand the process of his execution.

Good luck for yours investigations.


Q1: Yes. The link for MagStripe reader and encoder 1 does exactly that. Can read credit or debit and write it to a new blank card and can also erase data on an existing card. the MSR605 comes with software to do all of this. These machines can clone ANY card with a mag stripe. Gift cards, hotel cards, rewards cards, credit cards, id cards, etc.

Q2: Yes. you can skim a debit card and if you have a pin you can go straight to ATM and get cash. The PIN is NOT provided in the skimmed data. Using skimmed cards at gas stations for example might also require you to type in a zip code associated with the card.

Q3: The only failure in skimming cards is if the machine is broken or card is damaged. Every card with a mag stripe is the exact same and every mag stripe reader can skim any and every type of credit card or any card in general with a mag stripe. If the card has a black strip on back then it can be read. They all use the same technology. The success rate of skimming a card with a black stripe through a Mag Stripe reader is 99%.

Real-life Scenarios and Scam

GIFT CARD SCAM: At Walmart you see stands with Gift cards on them. Let says the criminal takes 10 $50 Walmart gift cards(unactivated). He goes to the bathroom and skims the data off all of them then puts them all back on the shelf. He then will check the card numbers everyday on the website to see if they are activated. When a customer comes in and purchases that gift card, it gets activated and the criminal already has the data and can use it right then and there.

FAST FOOD SCAM: Another popular scam happens at Fast Food Drive-Thrus. The cashier has a skimmer next to the register. When you hand them your credit or debit card through the window, they will swipe the card through the register and then swipe the card a second time through the hidden skimmer. (Happened to me at a Taco Bell lol)

GAS STATION SCAM: There is practically a universal key that opens up any gas station pump. Criminals will open them up as put a device that will record all credit cards that are swiped. Use gas pumps that are close to the door, criminals usually install them on pumps out of site. Also look for a sticker on the pump where the pump door would open, if the sticker was peeled off to open the door it will say VOID VOID VOID across the sticker, that means some one went into the pump.

MOST PEOPLE DONT KNOW: Skimming a card with the machine is not only way to get skimmed data. A lot of cards have RFID chips inside
of the even if you do not ask for them. If your card has one you will see a symbol on your card that looks like a signal or wifi symbol with the 3 bars. There a RFID machines that clone this data. Someone can walk around the mall with this RFID handheld device and all they have to do is get less than a foot away from you and it will skim the data from the RFID chip. It can skim it right through your pocket, wallet or purse.

Funny example of what you can do with a skimmer. You can clone you credit card onto a hotel key card. Then go to McDonald"s and use your hotel key card to pay for food.

Prevent RFID skimming: You can buy a special sleeve or wallet to block the RFID signal. But i recommend just having your bank reissue you a new card without it.

Prevent MagStripe skimming: Use cash at drive thru windows or any business that uses your card out of your sight. - Change card numbers every 3 months because most criminals skim your card and sell it to others which means they could be holding onto your information for many months before selling it.

Experienced Skimmers: The best of the best will buy blank Visa or MasterCard gift cards. Then they will clone your card to it and use a embroider to actually punch in the actual name and card number onto the card(most gift cards have numbers that can be wiped off that are not embroided). They will also make a fake ID in case cashier asks for identification.

Hope this helps.


Why is email often used as the ultimate verification?

This seems like a very wrong medium to send such information via.

Email is used for the same reasons Social Security Numbers get re-used as account identifiers in the US: Ubiquity.
Not everyone has a Facebook account.  Not everyone has a Twitter account.  But almost certainly, anyone with Internet access has an email account.  It is a reasonable expectation that customers can provide an email contact for businesses to use.

And I don't really know if this matters, however you never really see
these email services sending you "encrypted" email with your pgp key.

Because pitifully few people have a PGP key, and even fewer are set up with an email client that integrates encrypted email.
I once wished to purchase software, and the vendor would only sell to people who communicated with them via PGP email.  I tried sending the PGP-encrypted blob as an attachment, I tried inlining it, and I tried add-on software that integrated PGP email into my mail client - none of them passed muster with the vendor.  I never purchased the software.  PGP email is neither ubiquitous nor, it seems, trivially interoperable.

Also, quite often it is mentioned that email is inherently insecure,
or not designed with privacy or security in mind.
However it keeps being used for that.

And it will keep being used for that until something better comes along and something better is available to everyone to use, trivially.


From a layman point, Yes its a design flaw and yes the signals are boosted to unlock the cars from far far away. This is knows as Relay Station Attack(RSA). Some of the ways to mitigate such attacks are:

measuring Group delay time to detect illegal high values
measuring Third-order intercept point to detect illegal
Intermodulation products
measuring Field strength of the Electric field
measuring response time of 125 kHz LC circuit
using a more complex Modulation (i.e. Quadrature amplitude
modulation) which can't be demodulated and modulated by a simple
relay station
putting a physical on/off switch on the key

I don't think these mitigations can be used by the car owner themselves as there is quite technical detail behind it.

Taken from wikipedia. Smart keys and Security requirements


When you make a revision of rules on a firewall, how do you add credibility/customer satisfaction to your final consideration?

I've never felt that I needed to legitimize my reviews of firewalls with some call to a "higher power". While I have had clients come back with responses like, "Show me where it says I can't have the wire transfer application on a shared laptop that's used for webcast presentations," firewalls are a bit easier to justify. The rule is: Anything that isn't legitimately required is a risk, and your increased expense to mitigate this risk is negligible as all you are doing is adding a rule to your existing firewall system. Your cost to do it is less than your cost to argue with me ;)

In any case, unexpected traffic is either a misconfiguration or a compromise. If I need to justify every rule on its own without that principal, why do you (as my client) have a firewall in the first place?

I'm starting to think I'll ingrain in people that they should start with a Fort Knox system and peel off what is too expensive for the benefit rather than start with an patch of grass and start building walls as they see fit. When I start that, I'll cite this question (and you get a +1 on it).


Can viewing an email message in Outlook 2013 install malware on my computer?

Malware in an email can theoretically compromise your system even if you don't open it. Every mail that comes in is processed to some degree, and vulnerabilities in the email program could be used my embedded malware. This has happened in the past IIRC, several years ago, and I believe it had to do with image processing.

Currently there are no published vulnerabilities in outlook that could lead to a compromise as you describe that haven't had a patch released. That does not mean there are no zero day vulnerabilities that are being used quietly, or have yet to be discovered.


OpenSSH: Is setting a long ForwardX11Timeout better than ForwardX11Trusted?

I am not sure what is the exact problem you are talking about, but:

  Is setting a long ForwardX11Timeout better than ForwardX11Trusted?

Each of these options solves different problem:

ForwardX11Trusted exposes you local X server so potential evil admin on the remote server can do whatever he wants (screenshots, input, keylogging, ...)
ForwardX11Timeout does not prevent anything from above. It just refuses X11 connections after some time. Settimg that to long time will basically "disable" it (well ... who is running ssh sessions 596 hours?). This option assumes that when you need to run X11 application, you start it soon after the connection is established. It is basically preventing the attack being performed on the idle connections without users notice (after 20 minutes by default).


Are there bruteforce programs that use letters of other languages? Arabic? Greek?

Yes. In offline attacks, any password-cracking software that either treats inputs as raw bytes or can handle UTF8 natively can handle wordlists and some rules/appending using multibyte characters.

For pure bruteforce attacks, options are a little more limited, but it's still possible. My answer here describes how to use multibyte bruteforce with hashcat. That answer was a German-specific walkthrough of Rurapenthe's method. His post demonstrates an Arabic-specific approach.


Some questions about protecting recovery seed for Trezor/Nano S

it likely they could brute force your passphrase

Depends on the passphrase. "Monkey" would be nano seconds. WelcomeToBoomTown would be significantly longer. BoomTownis100%redonculous would be computationally infeasible to brute force.

  How many guesses can there be made per second

Online attack scneario: 1,000 / second.
Offline (fast) : 100,000,000,000 / second
Massive cracking array: 100,000,000,000,000 / second.

  Could hacker with the most computer power hackers use brute forc [sic] passphrase

Again, depends on the passphrase. If the passphrase was a GUID, the earth would have long been engulfed by our red giant sun, and the universe reached maximum entropy before you'd get through it with modern day computing power.

If the passphrase was on a common password list, seconds.

  How strong should passphrase be to protect against it?

At least 17 characters long.

  What if recovery seed would get posted on bitcoin forum and people would try to brute force it, would they be able to do it?

See all answers above.

Also, play with the password haystacks.


Encrypting USB traffic: Is RSA necessary for AES session key exchange when using pre-installed secret keys?

It depends.

If A and B are configured with secret AES keys, then A and B's previously intercepted communications can be trivially decrypted after the AES key comes to light (B is pulled out of the trash can your SO threw it in next year).

If you use secret RSA keys, then it's very similar, though each intercept must have the packets containing the cryptographically randomly generated AES key for that "session" to decrypt data previously intercepted from that session.

If you use something like TLS-DHE-* or TLS-ECDHE-*, then retrieving the device later does NOT help decrypt previously intercepted communications; this is the big deal about forward secrecy using ephemeral keys.


What is the proper server-side mitigation for the Lucky13 vulnerability (CVE-2013-0169) on a Windows server?

As suggested by @StackzOfZtuff, this was a false-positive of the testssl.sh tool.

Confirmed here: https://github.com/drwetter/testssl.sh/issues/789.


I think that you have to use a SIEM (Security Information and Event Management) software. This kind of software is great for analysing security incidents (but they require plenty of your time).

There are commercial and noncommercial SIEMs. HP Arcsight and Splunk (http://www.splunk.com/en_us/solutions/solution-areas/security-and-fraud.html) are really great.


Restricting a new WiFi device to WPA2 only

Open and WEP are enabled on personal consumer devices because the maker has no control over how the device will be used or what networks it might connect to.

Device manufacturers who can and do control how the device is used will certainly make a risk assessment and a benefits assessment to restrict the device to only the functions that are required and restrict the functions that it simply does not need.

So, the question is not about "state of the art", the question is only about how it will be used and the benefits/risks assessment about which functions it needs to have for the device to accomplish its goal.