Are new Intel CPUs vulnerable to Meltdown/Spectre?

The processors that were already announced and are about to be launched in the near future will still be vulnerable to both Spectre v2 and Meltdown if patches and/or firmware is not applied correctly. Spectre v1 was not entirely fixed with the latest patches. Most recent products have patches available, although not always functioning very well.
You can easily cross-reference the list of affected products to the soon-to-be-launched ones.

To answer your question directly: Intel plans to fix this on a hardware level in 2018. Intel's CEO stated the following in the earnings call for Q4 2017

  Our near term focus is on delivering high quality mitigations to protect our customers infrastructure from these exploits. We’re working to incorporate silicon-based changed to future products that will directly address the Spectre and Meltdown threats in hardware. And those products will begin appearing later this year.

I don't know what "appearing" means in this context (announcement of new products or release of new products).

Conclusion: throughout 2018 anybody who plans to buy a new processor (or a new laptop/PC with a new processor) will have to take some security measures to secure themselves against Spectre and Meltdown IF the accompanying firmware or the OS has no proper protection against these vulnerabilities.

Edit: After the conversation with R.. I rechecked Intel's official statements. All mitigation attempts and patches only target Meltdown and Spectre v2, because:

  For the bounds check bypass methodthat's Spectre v1, Intel’s mitigation strategy is focused on software modifications.

It remains unclear if this will remain Intel's strategy throughout the next product cycle.


Is it a bad idea to share a private key generated from a self-signed root CA?

Yes, it's a bad idea
When you create a Public/Private Keypair, you assign some trust to it. By publishing the Private key, you essentially also trust anyone who is able to download that key.
A better way
Furthermore, it's completely unnecessary. You can create a script which checks if debug.crt.pem and debug.key.pem exist and if not, you generate them. This means that anyone who downloads your code will generate their own self-signed certificate and deploy it themselves.
Will they get SSL errors? Yes, but that's normal and most developers expect them. If you publish your code on GitHub or a similar website, you could add an FAQ similar to this:

Help! I get an SSL error when attempting to run your code!
Yes, this is normal.  automatically generates a self-signed certificate when deployed for the first time. Since your computer cannot verify if this certificate is from a trusted authority, it displays an error.
You can proceed in several ways:

Save the self-signed certificate as a trusted End-Point Certificate
Use an already existing certific


What are the mitigating factors for CVE-2015-5364?

The reason why it's important and not critical is not because there are mitigating factors. The description of Important is:

  This rating is given to flaws that can easily compromise the
  confidentiality, integrity, or availability of resources. These are
  the types of vulnerabilities that allow local users to gain
  privileges, allow unauthenticated remote users to view resources that
  should otherwise be protected by authentication, allow authenticated
  remote users to execute arbitrary code, or allow remote users to cause
  a denial of service.

Which is exactly what this flaw is. It's currently not classified as critical because critical would imply:

  lead to system compromise (arbitrary code execution) without requiring
  user interaction

In case of this vulnerability there is no arbitrary code execution. If you look at the base CVSS metrics: AV:N/AC:M/Au:N/C:N/I:N/A:C There is only compromise to the availability of the machine. There is currently no compromise to the integrity or confidentiality.

Mitigating factors might not be available at the moment on Red Hat itself, but considering you need to send a UDP packet to the machine, you could easily configure your firewall (which you hopefully have in front of your internet facing machines and on your internal network zone demarcation points) to drop UDP packets.


JWT is being sent in cookies, but when I try for CSRF they are not sent

Perhaps the cookies are marked as SameSite, or you are using a browser that has SameSite as default behavior.


Kik | WhatsApp - Encrypted? iOS / Android Message encryption tips

Gibberbot is made by the same project team that created Tor for Android. It's opensource so you can check out it's encryption and see if it satisfies you.


Do file-encrypting software give a false sense of security?

When & How to Properly Encrypt

When deciding where and how you want to apply encryption, it is important to consider what sorts of attacks you're actually expecting to prevent and whether or not the data you're encrypting actually needs strong protection in the first place.

This breaks down into three main factors:

Sensitivity of the data. A database of all your account passwords, specifics about your financial or medical histories, and pictures of your genitalia are all certainly in need of some amount of protection. That funny cat meme that you're going to post to Twitter, not so much.
Likely attack vectors. If you want to use encryption to protect your data, it needs to stay protected no matter where it is. This means keeping it encrypted whether it's on your computer, flying across the Internet, or sitting in some sort of cloud backup. This protects against burglars, state/corporate proxies, and cybercriminals, respectively.
Capabilities of likely attackers. Odds are, most of the burglars and cybercriminals who are going to want a look at your data will be opportunists. They won't likely be well-equipped or motivated enough to mess with trying to break or work around at-rest data encryption at all - they'll just move on to the next target. State-level actors or other APTs might not be so stymied, but they may also have other ways to make your life miserable even if they never get your data.

So, take that all together and here's what you do:

All Data At Rest on Your PC & Removable Media
Encrypt your entire hard drive(s). Don't leave anything in the clear. This protects the sensitive data in its primary storage location, as well as any local system caches or page files that it might get leaked to. As a side-effect, all non-sensitive data on the same drives is protected as well. (At least, until you send it somewhere else.)

All Non-Sensitive Data Leaving Your Control
If you're posting it on a public forum or social media, consider it already compromised and move on. If that thought makes you queasy, don't post it.

Sensitive Data That's Traversing the Internet
Make sure proper transport-layer security (not necessarily TLS, but it generally is) is in place to encrypt the connection between your PC and the remote endpoint. Also be sure that you trust the remote endpoint to properly handle and protect whatever data you're sending to it. If you don't, see the next section.

Sensitive Data Going to Someone Else's PC
There's a lot of ways that you might want to pass data to someone else's computer directly. It is also important to recognize that e-mail and cloud storage reside on "someone else's computer". If it's sensitive, and it's leaving your control, this is where tools like encrypted containers and files (herein referred to collectively as "file-level encryption") come in.

Why File-Level Encryption is Important

With file-level encryption, it doesn't matter whether the data is passing the network over a cleartext protocol or sitting on a computer that doesn't have whole-disk encryption. Regardless of where it goes, an encrypted file will always have a non-trivial layer of protection around it in its primary storage location.

This is not to say that the file's contents cannot be exposed while they sit in a clear cache, page file, hibernation file, or RAM. However, accessing these storage locations is slightly more difficult than simply reading the file from primary storage. It also requires a certain amount of luck, as any data stored in those areas is transient by nature.

Ultimately, how other people manage the computers that contain the data you send to them is beyond your control. This is why you shouldn't release control of sensitive data to people you don't trust to properly protect it. If you must release your sensitive data though, file-level encryption is about the best you can do to make sure it stays safe. At the very least (since the remote party could ultimately just decrypt the data and leave it in the clear) you'll be able to say you've done as much as you can.

A Note on Encrypting External Drives

Keeping all data on an encrypted external drive does nothing to protect it, that couldn't be equally accomplished by file-level encryption on an internal drive. As soon as you go to read that data, it'll get caught up in the same cleartext-by-default locations (caches, pagefiles, RAM, etc) that it would if it were stored on the internal drive. This is why you should apply whole-disk encryption to systems that handle sensitive data wherever possible.

On top of this, whenever the external drive is mounted, the decryption key will also land in those same areas. This is why systems handling data that does warrant encryption should never be put to sleep - only shut down or hibernated - and should have (at least) their system drives fully encrypted.


Is wget'ing a single HTML file basically free of risk?

You are basically correct with a couple bits of complexity.

First, it is still possible that both wget or your text editor might have a vulnerability that the page could be designed to try and exploit. This is unlikely, and the malware author would have to predict that you would use this process and plant an ambush. Unlikely, but it still means that your process is not 100% fool-proof. Just something to keep in mind.

Second, it is possible for the webserver to identify that you are using wget, and serve you a non-nasty version of the file. This is quite easily done, with examples out there, by inspecting the user-agent. Again, this is not something that malicious actors think about, but it also means that you can't use wget and assume that the file you analyse will be the file you receive in your browser.

Yes, there are ways to modify wget's user-agent to lower this possibility, but, it's still something to think about.

So, yes, you are basically correct, but it is not a silver-bullet to secure yourself, and some risks remain.


Just make sure the hashes are in the correct file and path and then
I would recommend you to try the following command:
john --wordlist=/usr/share/wordlists/rockyou.txt –-format=raw-MD5 /root/hashes.txt

or
john --wordlist=/usr/share/wordlists/rockyou.txt /root/hashes.txt

if this didn't work and you're logged in as root, I think there is a problem in the tool it self, delete it and reinstall it


As I currently know, the HTTP Host Header can be viewed in plaintext by anyone monitoring my network (when visiting HTTPS sites) and I would like to mitigate this as much as possible.

This is wrong. The HTTP Host header is part of the HTTP protocol and with a HTTPS connection all of the protocol is encrypted with SSL/TLS. Thus the host header is only visible for the endpoints of the SSL/TLS connection.

But inside the SSL/TLS handshake itself there are several parts which show the hostname in plain text: in most connections the ClientHello contains the name in the form of the SNI extension. The certificate send by the server then contains the name in the CN and/or subject alternative names. And even before the SSL/TLS connection is started a DNS lookup will be done to find out the target IP address and this lookup also shows the name in plain text.

  So my question is: How do I not leak my HTTP Host Header?

The information need to be visible because they are required to establish the connection. The only question is who should see the information. If you fear sniffing by somebody on the way (i.e. ISP) you need to use a VPN, proxy accessed by HTTPS, Tor or similar to encrypt any data from you to some endpoint endpoint so that this specific party cannot see it. Once the connection left the endpoint all parties on the way can again see the information you want to hide so you need to take care where you place your  endpoint.

  An inefficient solution I thought of would be to create an open-source website which supports SSL (say, HTTPHostHider.com) that creates the connection and securely transfers the requested site's public key to the client.

A public proxy which can be accessed using HTTPS is mostly related to what you propose here, only that it would actually work. But this still leaves the problem why somebody should setup such a public site, because this way he might get liable for any illegal activity using this site. That's for example a typical problem when somebody is trying to setup a Tor exit node, because Tor is used to hide both legal and illegal activities.


How to use my WiFi to inspect its user traffic and to run MiTM attacks?

I'd like to suggest Ettercap, a free and open-source network security tool for man-in-the-middle attacks.

I recently used its ARP spoofing functionality in an Ethical Hacking / Penetration Testing training, and was amazed how easy it is to set up.

It's included in the Kali Linux distribution.


Theoretically, you could use a tool like Spartan (although I think it's not even around anymore).

Practically, this will bring you absolutely nowhere, unless the .dmg was encrypted with an extremely naive password (like 'admin' or '1234').

Any somewhat decent password will completely rule out the possibility of brute forcing.

(edit) Here's a shell script that will bruteforce passwords following a fixed format:

#!/bin/bash
dmgfile="Your Encrypted File.dmg"

function TryPassword
{
    echo -n "$1 "
    r=$(echo -n "$1" | hdiutil verify -stdinpass "$dmgfile" 2>&1)
    if ! [[ $r =~ "Authentication error" ]]; then
        echo ""
        echo "Found! The password is: $1"
    exit
    fi
}

chars=$(echo {0..9} {A..z})
alphanum=( $(echo $chars | sed -E 's/[^A-Za-z0-9 ]+/ /g') )
letter=( $(echo $chars | sed -E 's/[^A-Za-z ]+/ /g') )
lowercase=( $(echo $chars | sed -E 's/[^a-z ]+/ /g') )
uppercase=( $(echo $chars | sed -E 's/[^A-Z ]+/ /g') )
digit=( $(echo $chars | sed -E 's/[^0-9 ]+/ /g') )

for a in "${letter[@]}"; do
    for b in "${lowercase[@]}"; do
        for c in "${digits[@]}"; do
            TryPassword "$a$b$c"
        done
    done
done

Save this to bruteforce.sh and from the shell, do chmod +x bruteforce.sh once to make it executable, and then ./bruteforce.sh to run it.

This example bruteforces all passwords consisting of one letter (upper or lower case), followed by one lowercase letter, followed by one digit. Edit accordingly to your scheme.

Test first by creating a test .dmg with a password that is attempted first (e.g. Aa0).

Keep in mind that even for simple (short) passwords this will take a VERY long time. Like I said, it's mostly just theoretical.


Dynamic forking of a process in win32 vs modern antiviruses

You're right; it's possible for an antivirus to pause the proceedings and scan executable code that was loaded into memory. The kernel function to hook would be NtProtectVirtualMemory, which changes the protection on a chunk of memory (whether it can be read, written, or executed). If a process suddenly changed a writable chunk of memory to executable, that would be a perfect opportunity to see what might now be run.

If a process set a page to simultaneously writable and executable (so it could write and then immediately jump), that's already cause for concern before anything is even written, because the existence such a page helps open the door for exploits even in legitimate programs. Alternatively, the antivirus could just take note of such pages and spring into action on the next kernel call the process makes from code residing there.


It is not possible to disable them.  They are an integral part of the operating system and heavily used by everything from schannel for secure TLS communications to innumerable third-party applications with various cryptographic needs.

In addition, even if this were possible, it wouldn't constitute any more than a minor roadblock as ransomware could be quickly adapted to ship with its own crypto implementation, making the configuration change irrelevant.


Is malware distributed with pirated software actually common?

Finding statistics for this is rather difficult, but here are some sources that are close (I say close, because most look at platforms that are often used to distribute pirated software, but also to distribute legal software).

The percentage of malware seems to vary greatly based on distribution - eg P2P like Kazaa and Limewire contain more malware than torrents - and type of pirated software.

Moshchuk et al performed a study were they crawled the web and looked for spyware. They classified the websites, and in the category "pirate", 7.1% of the domains contained some malware. Other categories were "adult" (7.5% contained malware), "celebrity" (7.6% contained malware), "games" (20% contained malware), or "news" (0% contained malware). Moshchuk et al, 2006. A Crawler-based Study of Spyware on the Web.

From a paper looking at torrent sites:

  18.5% of all downloads contained malware Berns & Jung, 2008. Searching for Malware in BitTorrent.

Applications like key generation apps seem to be more likely to be infected (which makes sense, as they are smaller, and there is no need to first crack a legitimate program).

I wasn't able to find the original paper, but Bruce Hughes seems to have done research regarding malware in Kazaa:

  Bruce Hughes [...] found that about 45% out of 4,778 files he downloaded with Kazaa contained malicious code Dowland & Furnell, 2006. Advances in Networks, Computing and Communications 3.

Here is a study analyzing Limewire:

  Our results from over a month of data show that 68% of all downloadable responses in Limewire containing archives and executables contain malware. [...]  [I]n Limewire, the top three most prevalent malware account for 99% of all the malicious responses.Kalafut et al, 2006. A Study of Malware in Peer-to-Peer Networks.

From a 2006 study sponsored by Microsoft:

  11% of the key generators and crack tools downloaded from Web sites and 59% of the key generators and crack tools downloaded from peer-to-peer networks
  contained either malicious or potentially unwanted software.Gantz et al, 2006. The Risks of Obtaining and Using Pirated Software

Note the phrasing of "potentially unwanted software", which includes toolbars, which are often bundled with non-pirated software as well.

This report by Microsoft states that 14% of Web or P2P downloads contained viruses, trojans, or keyloggers.

The warez scene sees things a bit differently of course. Here for example is an article which describes how the scene reacted to a group that distributed malware.

It should also be noted that legitimate software may not be free of spyware, especially DRM software may act as a rootkit and may contain backdoors or otherwise make a system vulnerable to outside attacks (see eg Sony BMG or UPlay).


i, I, o, O packet inspection points inside a Check Point firewall

Between the POSTIN (I) and PREOUT (o) inspection points most of the policy processing/routing is done.

So the question is actually what is not done between POSTIN (I) and PREOUT (o).

This includes (not a complete list, depends on version and implementation):

Packet sanity checks - IP options and state checking.
VPN decryption/encryption - Packets are decrypted before processing by
rule base.
SecureXL processing – Packets are accelerated and may
bypass POSTIN-PREOUT altogether if packets were already allowed
through policy and traffic can be accelerated.

The iIoO is only default inspection points. For a full list of the in/out chain running on your firewalls run fw ctl chain from SPLAT.

Also see this old but still good reference document http://www.checkpoint.com/techsupport/downloads/html/ethereal/fw_monitor_rev1_01.pdf.

Hope this helps.


Why do embedded systems store server's public certificate in ROM?

For your question why the server certificate is saved in the ROM:

The saved certificate is checked against the certificate sent back by the server. This is a correct assumption from you. Therefore only one server is trusted at this moment.

You ask why the device does not simple connect to a CA. This would be another way to work. But even then the CA root certificate must be embedded in the ROM. This is needed because else how would you connect to the CA? You need also SSL/TLS to connect to the CA because else all the PKI would be senseless. So at least one certificate must be embedded in ROM.


Whitelist Simulated phishing landing page

Is there a way to whitelist our landing pages with google and the other browser makers, so even though they look like phishing pages, they don't get blacklisted in the future?

I think this would be a pretty bad idea. Just imagine if hackers could white list their public phishing pages this way.

If your control the way your users go into the internet you might use an internal DNS server which returns a different (local) IP address for the phishing domain for internal users. This internal site can then serve the phishing stuff while the external site is innocent. To make even more sure that it does not get blocked you might also try to use a top level domain which does not exist externally and is only resolved by your internal DNS server.


You are using the wrong tool for the Job!
Subdomains are not private. They can't be made private either. The reason why they can't be is because of DNS, or Domain Name System. Without going into too much detail, DNS is a database of all domains and subdomains, and values associated to them. A very simple example:

User: "DNS Resolver, which IP does security.stackexchange.com have?"
DNS: "Hello User, I have the following addresses for security.stackexchange.com:"

151.101.1.69
151.101.65.69
151.101.129.69
151.101.193.69

User: "Thank you!"

What if you wanted to make sure that a subdomain would remain secret? Well, you couldn't, because the DNS database would still need to know about it. How else would anyone connect?
How to design it instead
What you actually want to do is secure a subdomain so that only specific people have access to it. One way to do it is a traditional password-based login, which gives you a session and authenticates and authorizes you to access the protected content.
Another, perhaps more elegant way, would be to use Client Certificates. You can generate a Certificate Authority and sign as many Client Certificates as you need. These Certificates would only be valid as long as you want them to be (e.g. 2 weeks, 1 month, 1 year, etc.) and can be revoked whenever necessary.


Potential security issue with md5 filename

If the possible range of the file's contents were small enough (either because the file is very short, because the attacker knows every part of the file except for a very short piece, or because the attacker knows the file's contents are one of a limited set of things, then the attacker can perform a brute-force search of the possible file contents and check the hash digest of each result to see if it matches the filename.

Note that this vulnerability has nothing to do with the fact that MD5 is cryptographically broken and deprecated; any hash function would be vulnerable to the same issue. If you want to avoid the risk, you need to either avoid encrypting small / predictable files, or you need to not leave each file's plaintext hash digest hanging out in plaintext (the filename) itself.

Another attack that might be possible is if the attacker knows at least some of the files you have stored, and can generate a new file for you to store. Because MD5 is broken, the attacker could potentially craft a malicious file that has the same MD5 as a file you care about, and then when you store the attacker-supplied file you would overwrite your original file because it would have the same name. The use of encryption is irrelevant here (except to the extent that it makes it harder for the attacker to know what files you have stored); this is simply a consequence of doing file de-duplication using an algorithm for which we know how to create collisions and (partial) pre-images. To avoid this risk, don't let a potential attacker know what files you stored, don't store files a potential attacker supplies, and/or move to using a secure hash algorithm such as a member of the SHA2 or SHA3 families.


do different subnet masks on home network provide any security?

Well that's happening because it's probably using NAT for router B. It's not bad but it's not bad practice. Obviously if they can get into router A then technically they can indeed take over the network. So if router B sends traffic router A will see that flow.

Now if you want a good setup, the key is to make several subnets and restrict them accordingly. For instance make three different subnets:

192.168.1.0 management
192.168.2.0 trusted
192.168.3.0 visitors

These networks should be separated and should not route between each other (but you can route from trusted to visitors, but not vice versa (firewall function)). You can then assign a port on your router which has the 192.168.1.0 network configured so you can access the managment interface (this should not be reachable from the two other networks). This prevents attackers from accessing your routers.


If I know the CPU architecture of a target, can I send instructions embedded in an image?

Other answers give a good technical explanation but let me try with an analogy:

  Please send your credit card number to scam@example.com

Did you read it?
Did you do it?

It's more or less the same for your CPU. Reading something is not the same as executing it.


Should I be worried about plugging it in? (Could malware transfer onto my machine?)

You probably don't need to worry, but there's no real harm to being careful either. You don't say which operating system you are running, so it's hard to say much about what risks you might expose yourself to, but given that your system doesn't have autorun enabled, odds are reasonably low that any software-based malware would be able to transfer to your system.

If you have reason to believe that either you or your friend has been directly targetted by an active, relatively sophisticated adversary, then you should worry about things like BadUSB. In that case, however, you would probably know, or at least be able to suspect, that you are.

  Is there a way to safely connect a USB device and sandbox it so it doesn't auto-run anything?

You could download a live Linux distribution such as Tails, Knoppix, Ubuntu or some other alternative. Burn that to a CD or DVD, or copy it to a USB stick (the CD or DVD in this case has the advantage of being truly read only), boot from that (and make sure your computer's hard disk is not mounted, and unmount it if necessary; Tails might be best in this regard), and use it to wipe the iPod.

Again, unless you are worried about direct targetting by active, relatively sophisticated, adversaries, that should be good enough. If you are extra paranoid, open your computer and disconnect the data cable going to the hard drive, but I'd say that even with reasonable suspicion of malware, for 99.99% or more of users, doing so is overkill; simply making sure the file system on the hard drive is not directly accessible will almost certainly be good enough.

  I don't trust torrented files.

As long as they are limited to music files, and you don't attempt to play them, the probability of a compromise through that vector seems very small. Also, malicious music files would probably need to target bugs in specific player software, which points toward plain computer hygiene being a good defense: Keep good backups, and stay on top of software updates.


It seems someone or something is replicating my requets

Your scenario is not described completely and is difficult to understand what is the issue, however you can do the next checks:

Your application should use TLS, so all your requests will be encrypted over the internet, is your application using HTTP?
You should review your application, according your explanation this could be a bug in your application. You should provide more information about it.
On the destination host, you could pcap file the requests and later try to discover what is the issue and where the other IP came from.

Hope it helps


Basically anything that runs without the need to include a separate file.

<script>
document.write('Hi, I am inline');

function myFunction() {
    console.log('So am I')
}
</script>

The reason the paper mentions this is that this piece of code cannot be validated as 'secure', without running it (or perform code analysis). When you only allow scripts by includes (<script src="myscripts.js"></script>) the browser can decide if it wants to load the script based on the response and CSP headers. Same is true for CSS files. This is an effort to prevent malicious code
execution.


I regenerate the key with ssh-keygen -R xxx.xxx.xxx.xxx

This is not a key regeneration! It is key removal from your known_hosts file. If there was man-in-the-middle, the attacker now can be authenticated to your server!

You should check the server keys from your machine and from your co-worker if it gives you the same set (good tool for getting all public ssh-keys from server is ssh-keyscan). It is normal that server has more different keys (and key types), but without knowing what was in your known_hosts file before you removed it, you have no chance to find out what caused the problem.

If you still have the old public key from known_hosts, before you removed it, check what key has your co-worker stored for that server and what are the actual keys on the server (preferably by physical access to the server, but also the ssh-keyscan can help). If it differs somewhere then you should investigate further your infrastructure or your machine and server, because then there can be some real problem.


OWASP CSRFGuard obtains the token via XMLHttpRequest - why?

Are there any vulnerabilities if I change it to include the token directly?

Oh yeah.

Then an attacker could just include that script on their page:

<script src="http://yourserver.tld/yourpart"></script>

And let it run this code:

var token_name = "sample-token-name";
var token_value = "sample-token-value";

Then both token_name and token_value will not be global variables on the attacker's page that can be accessed and used to create the CSRF attack.

The reason they are using AJAX to get the token is that this request would fail if the attacker just includes the script tag because of same-origin policy.

As for why they are using synchronous AJAX, I doubt there is a reason except poor design.


Difference between Hybrid encryption and Diffie-Hellman key agreement?

Hybrid encryption uses public-key cryptography to exchange a secret key, and symmetric cryptography to encrypt the data. The main reason is that public-key cryptography makes the key exchange easy, while symmetric cryptography is faster.

The Diffie-Hellman key exchange is a protocol used along with public-key cryptography. It allows 2 entities to create a shared secret (i.e. the session-key). The DH key exchange will not encrypt your data! It will only give you a key that can be used with a symmetric-key algorithm to encrypt the data.

Basically, the DH key exchange is one of the tools used in the first steps (the key exchange part) of Hybrid encryption.

PS: I found a related question on the Crypto community, you might want to take a look:
"Why is Diffie-Hellman considered in the context of public key cryptography?"


OpenSSL generates 1032bits when I request 1024bits

Try this:

openssl genrsa | openssl rsa -text

Look at each of the fields; the primes, the exponents, all of them. Now try again, and again, and again. You'll notice some inconsistency as to whether an initial zero byte is present. Sometimes it is, sometimes it's not. The pattern is this: if the first bit of the first "real" byte is set -- that is, if the first hex character is less than 8 -- then there won't be an initial zero displayed (or stored), but if it's 8 or higher, then a zero byte will be prepended.

This makes it pretty clear that the problem they're solving is sign interpretation. With signed values, the first bit is the sign of the number; adding an initial zero removes any ambiguity.

To see what's actually stored (not displayed) look at this:

openssl genrsa | openssl asn1parse

You'll see that the while only 64 or 32 bytes are displayed, you'll see l= 33 or  l= 65 indicating that one extra byte is actually stored. That's your initial zero byte you saw earlier.

As for 32-bit DH keys, look at this:

$ openssl dhparam 32 -text
Generating DH parameters, 32 bit long safe prime, generator 2
This is going to take a long time

PKCS#3 DH Parameters: (32 bit)
    prime: 2714658203 (0xa1ce659b)
    generator: 2 (0x2)

So, that looks like only 4 bytes even though the initial bit is set. But let's look at the asn1parse:

0:d=0  hl=2 l=  10 cons: SEQUENCE
2:d=1  hl=2 l=   5 prim: INTEGER           :A1CE659B
9:d=1  hl=2 l=   1 prim: INTEGER           :02

So for this 32-bit prime, 5 bytes are stored even though you only saw 4 bytes displayed.

The reason you didn't see the zero byte this time is that since the stored value is only 32-bits, it can be displayed as a simple unsigned integer, and therefore OpenSSL's display library accordingly shows you the decimal value and the hex value in parens instead of just showing you a string of hex bytes separated by colons. But the initial zero is still there, as we saw in the asn1 output.


Can I trust the Host header received in the request?

No.

It is trivial to change the value of the host header, but, depending on your server set up, this may cause the site not to work as intended. In particular, if you are using name based virtual hosts, the web server will look at the host header to determine which site (of many) to load, and (usually) default to the first defined one if it doesn't recognise the host header.

If you have an internal network, you will presumably have a range of internal IP addresses. It is possible to restrict access to functions based on that, although the specific settings depend on the web server in use. You could also look at having LDAP or similar centralised authorisation, so only requests from internal users who have signed in in some way can provide an authorisation header. This is ideal if you are running with a Windows domain - you may even be able to have automatic login to the administration functions in this case, based on the logged in user on the computer.


How to find vulnerable PHP parameter such as `.php?id=` as found in Kioptrix 3?

I'm not sure what you mean by "it is hidden". Monitoring/testing application routes and parameters should be a focus point in any assessment, plus it's right there in the URL.

You can discover/log URLs/links by browsing the site manually while using Burp Suite, or the "spider" feature, both of which should log all visited links under the "target" tab.

As far as determining if it is "vulnerable", that may take some further investigation. Parameters like that aren't inherently vulnerable, but their existence in CTF problems often signals a SQL injection problem. To determine whether an actual issue exists, you can test it manually or use a tool like sqlmap, which will test all parameters and find vulnerable ones.


Is it safe to give multiple virtual credit card numbers to the same vendor?

You asked,

  Can a vendor guess the real credit card number by having multiple virtual credit card numbers?

The answer is no.

By looking at your temporary numbers, they could determine which network and bank issued the card (from the BIN, the first 6 digits). But they would not be able to tell your various cards apart from any other cards issued for that product by that bank, and there would be no relationship discernible between the temporary cards and your real card based on knowing the card number(s) alone.


The difference between using some hardware backed key store (i.e. TPM, HSM, smartcard ...) and a "pure software" solution like openssl genrsa is not so much about the security of the key generation but about the security of the key storage.
HSM and similar are designed to never actually provide the created private key but only do operations like cryptographic signatures with the key. They are designed so that the key can not be copied to some other medium, that the HSM cannot be cloned with the key inside etc. Theft of the key thus means that the hardware needs to be stolen.
Contrary to that a key generated by openssl genrsa is stored in a normal file, which can be copied without anyone noticing and thus can also be used anywhere else. Theft of the key thus can go unnoticed, since the original owner still has access to the key too. It thus provides less assurance who actually owns and uses the key.


does the --nack command do what I think it does in reaver and why won't it work?

From some reaver documentation, which I found here:

  Some poor WPS implementations will drop a connection on the floor when an invalid pin is supplied instead of responding with a NACK message as the specs dictate. To account for this, if an M5/M7 timeout is reached, it is treated the same as a NACK by default. However, if it is known that the target AP sends NACKS (most do), this feature can be disabled to ensure better reliability. This option is largely useless as Reaver will auto-detect if an AP properly responds with NACKs or not:

  reaver -i mon0 -b 00:01:02:03:04:05 --nack

So regarding your problem:

  The speed at which Reaver can test pin numbers is entirely limited by the speed at which the AP can process WPS requests. Some APs are fast enough that one pin can be tested every second; others are slower and only allow one pin every ten seconds. Statistically, it will only take half of that time in order to guess the correct pin number.

Is it possible that you simply have a really really slow AP?
Or do you get any other error messages/logs?


A) Is there an advantage/disadvantage of conducting reviews of
  binaries over source-code?

Compilers often DO NOT write code expressly as intended in the source.  For example, Return Oriented Programming exploits the fact that compilers will insert many more RET opcodes than the programmer is aware of.  Due to pipelining and other optimization tricks, compilers essentially rewrite your code and can possibly add vulnerabilities of their own.  This means that some constructs in the source code may not be expressed in the binary at all!

This is a class of error that is essentially impossible to catch through manual code analysis... and I suspect the risk would still be there for Java/C# JIT code as well, but this would be obfuscated from a static analysis tool.

Manual source code analysis can help by the fact that most common vulnerabilities can be caught by visual inspection.  And it has other benefits as well, most notably in just decreasing the number of prod bugs in general.  (And thus cost.)  And it helps the social aspect as well:  source reviews encourage people to write as if someone else is watching.  A major disadvantage is that if you're dealing with a dynamically typed language, such as PERL, Groovy, LISP and its derivatives... most data won't be looked at until runtime which means neither static analysis or source code analysis is sufficient.

You can even fool static analysis tools by converting statically typed code into instructions at runtime.  Veracode doesn't like your java construct?  Rewrite it using reflection, and the Veracode bug disappears and no one is the wiser.  As a security expert you also need to assume that the programmers working in your own company are a potential threat.

So in short, there's no way to escape Source code analysis, static analysis, and dynamic analysis in any given application if your hope is an acceptably secure code base.*

  B) Which one provides more coverage/vulnerabilities.

Source-code analysis depends on the reviewers having excellent security skills and since they're human beings, you can't reasonably expect perfect performance.  That's why static analysis tools come in handy.  My preference is to run static analysis tools first and then do the secure code reviews after the discoveries are mitigated, I prefer using STRIDE but there are other frameworks to consider.  This lets humans concentrate on the less mundane security problems that are more logic-related.  But a smart human will beat a dumb static analysis tool any day of the week.

Source-code analysis can help you find where a programmer left behind a back door... static analysis tools aren't equipped to handle that.

So the answer to this question is... "it depends."  What kinds of threats do you want to go unchecked?

*Unless "acceptably secure" is defined as leaving the windows open and the front door unlocked.


I'm generally a fan of not re inventing the wheel because people way smarter than us already did. I did a quick search for you and found the current library you can use: https://code.google.com/p/php-antixss/

Re: your code,  it looks a little too simple to prevent fully. I would use a standardized solution that is used by others and continuously contributed to as new exploits develop.

Hope it helps.


Why not oAuth for Authentication - AKA what is bad about OpenID Connect

Difference Between OAUTH, OpenID and OPENID Connect in very simple term?

Well this was on the side navbar.

It's like this:

If you are authorised to do activity A, you must possibly be the owner that can do activity A. Therefore you must be owner. Authorisation = Authentication. Whereas you could be authenticated but not authorised.


Why is the diffusion property important in hash functions

It is for the same reason, suggest you have a table with hashes, and you find out that there is one hash (A) that's almost the same as a hash you are trying to break (B). If there is randomization then you have nothing, otherwise you know that the hash you are trying to break is similar to the plain text of hash A. So this would make a bruteforce attack easier since you know it must be a hash of something close to the plaintext of A.

Add to this that you might have 10 hashes that look similar to B, you can start finding a pattern in their plaintext form and reduce your bruteforce span even more.


Unix - Automated MD5 Checksum Verification

What you describe is commonly known as a host intrusion detection system. Have a google and you'll find stuff like OSSEC and Tripwire. Alternatively, 6 shell commands:

 mv currentsums oldsums
 find /var/www/html -iname \*.php -exec md5sum {} \; | \
    awk '{ print $2 "," $1 }' | sort >currentsums
 diff currentsums oldsums

(you may wish to treat this as a starting point)

BTW: Your list of things you've done to make this secure has some esoteric stuff in it but none of the basics for hardening a server.


I would always recommend building a lab yourself at home, and this really is much easier than you probably imagine;

Install VirtualBox (this is free, and cross platform)
Download a Linux CD Image (I would recommend Debian, also free)
Fire up your new Debian virtual machine by mounting the CD Image and running the installation.
Install a database and webserver; apt-get install apache php5 mysql-server libphp-mysql
Add a table and some data to your database; CREATE TABLE, INSERT
Create a vulnerable php page; mysql_query("SELECT * FROM my_table WHERE id=".$_GET['id']);
H4x0r it; http://127.0.0.1/vulnerable.php?id=' or true--

Whole process from scratch, maybe 1 hour plus download times, and you'll have a setup you can really learn from - a huge part of understanding attacks comes from setting up the vulnerabilities yourself, so you can see how they can come about.

This setup will also serve you well if you move onto other types of software exploitation, such as buffer overflows in network daemons.


Warning: This answer contains educated speculation.

"Rings" clearly expresses the "nested set" aspect of protection rings, which were described as "concentric" in early papers describing them.

The earliest citation for rings which I can find is the 1967 paper "Protection in an Information Processing Utility" by Robert M. Graham.  It states,

  We define rings to be ordered, disjoint sets of segments, numbered
  from 0 to some maximum.

The 1972 paper "A Hardware Architecture for Implementing Protection Rings" by Michael D. Schroeder and Jerome H. Saltzer provides more language that reinforces this image (emphasis mine):

  In a system which uses segmentation as a memory addressing scheme,
  protection can be achieved in part by associating concentric rings of
  decreasing access privilege with a computation.

and

  Put another way, the sets of access capabilities represented by the
  various rings of a process form a collection of nested subsets, with
  ring 0 the largest set and ring r - 1 the smallest set in the
  collection.

The concentric circle metaphor clearly correlates to this notion of "nested subsets", in a way that other metaphors - like the OSI 7-layer "stack" model - do not.

The other language that works better with concentric circles is "gates."  Again to quote Schroeder and Saltzer,

  Restricting the start of execution in a particular domain to certain
  program locations, called gates, provides [protection]...

With a ring structure, a gate between two layers is the only clear connectivity point - whereas with a stack, a gate may exist on the line between the shared connection line, but other methods of access may be perceived by traversing the whitespace along the sides.  Again, the OSI model more closely matches that, where layers may be 'leaped' and ignored.  With a concentric ring structure, it becomes clear that every layer of access is cumulative (in one direction, in the case of protection rings.)

While gates do also lend themselves to the medieval castle design of concentric walls with gates between them, I cannot find any historic references equating Multics rings with castles; only modern references drawing the analogy in order to illustrate the concept.


Buy Two sub domain SSL Certificates from different SSL providers for same main domain

Yes, there is nothing preventing you from doing that. As long as you can prove you own the site, you can get a certificate from any provider. You can even have multiple valid certificates at the same time, from different providers, for the same domain or subdomain.


I want trusted SMIME certificates for 3rd parties. Is this a reasonable configuration?

I would recommend using a completely separate root for the external and internal certificates, to prevent any information leak about internal hosts or users, through Root01, but also prevent any implicit trust by broken software. By using 2 separate root for external and internal use, theres no possible for any trust to leak from External to Internal certificates, regardless how broken the software is.

Normally, if we have certification paths that looks like this:

Root01 --> SubCA01 -> Cert01
Root01 --> SubCA02 -> Cert02

And SubCA02 is imported as trusted. In a valid PKI implementation, Cert01 should not be trusted. But as you know with lazy coding, broken software, and hacky parsing of certificates, theres is possible for trust to leak over from subCA02 to Root01 and thus leaking over causing Cert01 to be trusted by someone that shouldn't trust that cert, if the PKI implementation is very broken and, for example assumes any higher cert as trusted automatically. Yes its far fetched, but better account for any broken software by using completely separate roots instead.

I would also add a PathLength=0 Basic constraint, preventing the CA certificate from being used to sign other CA certificates, in addition to the name constraint.

As you might know, there is lots of broken software out there, and a privilegie escalation attack (as you call it when someone manages to sign a certificate in violation with the constraints) can happen, for example if the said PolicyExt01 certificate is used to sign a subordinate CA, that in turn is signing a S/MIME certificate.

Some broken software only checks for example naming constraints "1 level Deep", and adding a Pathlength constraint would then cause longer chains to fail instead of being accepted as trusted.

So I would do like this:

Root01 (Name constraints = Email=@domain.com, PathlenConstraint=0, EKU=Message signing)
Root02 (Internal applications, not trusted by 3rd parties...)

And then sharing Root01 cert with those third parties that should trust it, while installing both Root01 and Root02 in all Company-internal computers.

Both Root01 and Root02 is then self-signed root CA certificates.

When using Namingconstraint, I would only put a Email=@domain.com Naming constraint, and then put every other naming constraints (IP, DNS, UPN, URI) as wildcard excluded, to prevent a certificate from being used as for example a website SSL certificate, if a broken browser or SSL implementation would be unable to parse the key usage flags.

A good idea is also to test your setup, preferable by exporting the root CA certificate and private key to a secure offline computer, and then attempt to sign "invalid" certificates with this. Then test the "invalid" certificates with common client software to ensure the constraints are kicking in and marking the certificate as untrusted.

I do not personally know any explicit configuration that would cause such a "privilege escalation" attack, but as you know, theres lots of broken SSL implementations and PKI software out there, so better be safe than sorry and restrict the certificates as much as possible, and also use separate roots to prevent any trust leak between the certificates by VERY broken software.


How Anomaly Analysis is differentiating from Heuristic analysis

It's the difference between "weird" and "bad".

Anomaly analysis looks for the "weird". There is no judgement about whether it is "bad". In a lot of contexts, weird = bad, but not always.

Heuristic analysis learns what is "bad" and looks for that, even if it turns out to be "normal".


Application security training for developers

There's a couple of free resources I know about which could be good introductions for this kind of thing.  Security Innovations have a free OWASP top 10 CBT, Security compass have something similar here as do Trustwave

Beyond these basic ones at least two of those companies will have more options that are pay for, but these ones could be a good, free, starting point.


Possibility of spyware on a refurbished router?

How likely is it that someone could buy these routers, install a custom firmware with spyware?

I think no exact answer can be given but there are several factors which might be relevant to decide if one can trust such offer or not.
Given that the potentially untrustworthy seller knows who the recipient of the router is, it is possible that they will install a custom firmware on it to attack this specific recipient. It is less likely that this will be some generic attack which gets installed on many systems, because such attack is much more likely to get publicly known (and thus made unusable for future attacks) since somebody will eventually stumble over suspicious traffic.
Given that creating a custom image specific to a single target is costly the target needs to be worth it. If you are worth it as the victim of a targeted attack you probably know best.
Other factors which might hinder the installation of custom firmware can be the use of signed firmware by the original vendor. If this is done depends on the vendor. And it might not necessarily make it impossible, only significantly harder and thus more costly.
Apart from that it might be easier for a attacker to use a security issue or backdoor in the original firmware of the vendor as a way into your network. It is unfortunately not uncommon that devices are sold with such vulnerabilities - see routersecurity.org for more details.


According to RFC 3986 Section 5.4, this has been specified to be resolved as absolute according to the URL itself.

You can imagine the ramifications of allowing double dots go unchecked until they are used to reference a real server file.

I did a test using wget and the requested URL was converted to an absolute URL.

This obviously relies on the client code requesting the resource and server to resolve URLs before they are used within the server. The server software, which in the majority of cases would be Apache, NGINX, IIS or similar, should never trust anything coming from the client.

$ wget https://www.nytimes.com/section/world/../../section/politics
--2017-08-24 17:05:20--  https://www.nytimes.com/section/politics
Resolving www.nytimes.com... 151.101.29.164
Connecting to www.nytimes.com|151.101.29.164|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 127149 (124K) [text/html]
Saving to: ‘politics’


Is crossdomain policy file required by EVERY web application?

Short answers : 1.) no not a requirement 2.) yes via authenticated client browsers being manipulated.

SilverlightFox is correct in that the crossdomain.xml is not a web application requirement. Per Adobe's website the crossdomain.xml is a policy in the form of an XML file which "grants a web client, such as Adobe Flash Player or Adobe Acrobat (though not necessarily limited to these), permission to handle data across domains"[1].

That said it's more geared toward the protection related to client-behavior and not the servers themselves but client security is important as you don't want a third party bad actor attacking your website via an authenticated client.

Likewise it may be an organizational policy to have one for all webserver deployments just on the off-chance flash is used or is uploaded to the site via some other type of attack but from a purely technology perspective it certainly isn't a requirement to protect the server itself.

The real security concern around the crossdomain.xml issue is when a flash client receives malicious commands from a malicious flash server which could cause the client to make requests from your server using the clients credentials. In this case if you accidentally had a misconfigured crosssdomain.xml file such as

This would allow the commands from a malicious server to be executed as the authenticated client connected to your site giving an attacker access to your server via that users session. If you have sensitive data this would be a problem.

To protect from this it would greatly help to have a correctly configured crossdomain.xml restricting these actions to your domain or a specific host.

The following website goes into this issue in greater detail but as a quick answer to your question yes there is value in this security-wise.

http://gursevkalra.blogspot.com/2013/08/bypassing-same-origin-policy-with-flash.html

Cross Domain Policy File Specification:

http://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/CrossDomain_PolicyFile_Specification.pdf

[1] Quoted Adobe article on setting up a crossdomain.xml policy file:

http://www.adobe.com/devnet/adobe-media-server/articles/cross-domain-xml-for-streaming.html


SAM and SYSTEM file copying to another PC

Well, didn't test yet, but I think it's not possible to do it that way.

There are two possible places to store user's password. SAM file and registry (HKEY_LOCAL_MACHINESAM). Both are inaccessible if Windows is running.

Just to understand your question better, why do you want to have the same password in your own PC, if you dont know what it is?

Why don't you run Mimikatz or Pwdump in the laptop, check the cleartext password, and change your own password to the same?


Effect on PCI compliance of not checking SSL certificate?

Yes, this is wrong, and here is why.  As you mentioned, PCI-DSS requires that communication containing sensitive data be handled over a secure channel.  As a part of this process, certificate validation ensures that the certificate in question is in good order and belongs to the party that you intend to talk to.  If you do not validate the  certificate, the traffic may as well be unencrypted because you have no idea of who is on the other end.  It could be your merchant provider, or it could be a man-in-the-middle who's reading and storing all of the card data you send before forwarding it on to the provider.  Without validation the cert, you can't know who's seeing the data, so your trust level that the transport channel is secure must necessarily be 0%.

So, as I said in the comments, do not accept this condition.  If your merchant provider can't, or won't fix the issues so that you can confidently validate their certificates, find another merchant provider.  In fact, that may not be a bad idea in any case because if they're willing to play fast and loose with PCI and security here, you can't know where else in their system they've taken similar liberties putting you and your customers at risk.


How vulnerable is Windows XP Embedded SP2 as of today?

There are 625 relatively serious Windows XP SP2 vulnerabilities listed:
https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-739/cvssscoremin-5/cvssscoremax-10/Microsoft-Windows-Xp.html

I'm not sure how many are unresolved in the latest available security updates.

Either way using an OS unsupported by the vendor is playing with wet dynamite.


Principal Password in Kerberos KDC database

No. Fingerprint images can be compared with each other, but are not reliably reproducible with all the exactness that is needed for use as a cryptographic key (and passwords are cryptographic keys that just happen to look like characters).


Self-signed certs on LAN shared with others

Your untrusted guests cannot undermine the security from your self-signed certificate just because they got infected by malware. To you to be fooled into accepting a rogue certificate, any attacker have to download the certificate from your server, create another one with the same values, ARP-spoof your computer and MitM your connection to your server. Not something a malware would do for itself.

How to solve that? Create a CA yourself, and add the CA certificate to your browser. This way, even if someone worked the above attack, it won't work because your browser will not trust their self-signed certificate.

This site have a nice guide, check it later for full information. I will summarize bellow:

openssl genrsa -des3 -out myCA.key 2048
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 1825 -out myCA.pem

Now you have myCA.pem, import it on your browser and OS.

After that, create the certificates and sign them:

openssl genrsa -out dev.mergebot.com.key 2048
openssl req -new -key dev.mergebot.com.key -out dev.mergebot.com.csr
openssl x509 -req -in dev.mergebot.com.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial -out dev.mergebot.com.crt -days 1825 -sha256 -extfile dev.mergebot.com.ext

You will now have 3 files, the private key is the .key, the certificate is .crt, and the certificate request is the .csr and you don't need it after creating the certificate. Install the .key and .crt on your servers and you are good to go.


How to safely execute batch file viruses for practice?

You can run it in a virtual machine. A virtual machine emulates a computer on your computer. You can give it a limited amount of resources (CPU's, memory) and the environment on the virtual machine can not access the computer it runs on. Popular software to run virtual machines are VirtualBox and VMWare.


I believe the flag that you're looking for would be max-parellelism

TIMING AND PERFORMANCE:
 Options which take <time> are in seconds, or append 'ms' (milliseconds),
 's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
 -T<0-5>: Set timing template (higher is faster)
 --min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes
 --min-parallelism/max-parallelism <numprobes>: Probe parallelization
 --min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies
     probe round trip time.
 --max-retries <tries>: Caps number of port scan probe retransmissions.
 --host-timeout <time>: Give up on target after this long
 --scan-delay/--max-scan-delay <time>: Adjust delay between probes
 --min-rate <number>: Send packets no slower than <number> per second
 --max-rate <number>: Send packets no faster than <number> per second


What possible use does an iFrame have for security?

It is a security measure, as the description in the code implies. The iframe serves as a protection mechanism against XSS exploits through browsers' own measures against these very same attack types by preventing JavaScript access to frames and iframes when they're not published on the same domain. It isn't really necessary to write this part of HTML directly in the document, as it could as well be written by the same JavaScript that is latter manipulating its contents, but the developer of this solution probably wanted to make it clear to future developers that some external script is verifying the log-in form before it's posted and that the browsers XSS prevention mechanisms are used to achieve better end-user security while signing-in. This is also strongly implied by the lack of an ID for the iframe, which would make referencing it so much easier.

Developer would then attach a JavaScript script element to iframe DOM with a code that would look something like this:

window.onload = function () {

    var iframe = document.createElement('iframe');
    iframe.width = "0px";
    iframe.height = "0px";
    iframe.style.visibility = "hidden";
    iframe.id = "noXSSframe";
    iframe.setAttribute("src", "about:blank");

    document.getElementById("formID").appendChild(iframe);

    iframe.addEventListener('load', function (e) {
        var myElement = document.createElement('script');
        myElement.setAttribute('src', '/content/test.js');
        myElement.setAttribute('type', 'text/javascript');

        iframe.contentDocument.body.appendChild(myElement);
    }, false);

}

This is just an example and is not necessarily the exact same method your developer chose, but should serve good enough for demonstration purposes.

This external JavaScript file that's just been attached to the iframe would then be written in such a way to account for being run through an iframe, referencing parent document object in a way that only a script located on the same domain is permitted, while any XSS injections replacing the called script with a script hosted outside of the parent document domain would clearly be denied access by browsers themselves. The only way to prevent browsers to enforce same origin policy for XMLHttpRequests is by attaching additional headers to the server's HTTP response and explicitly allowing cross-origin resource sharing (CORS). This however isn't something XSS injections alone can tamper with.

In short, it's an elegant way to make sure the JavaScript that's responsible for manipulating, verifying and ultimately posting a log-in form (preparing and initiating a HTTP request) is indeed loaded from a file hosted on the same domain the log-in form is on, effectively preventing simple XSS injections. At the same time, it also prevents phishing sites from reusing this log-in form and sending log-in requests to another domain, if the iframe script does some additional verification, attaching unique response values that can be verified server-end to the form's POST request.


Can I check who can decrypt my GPG message after I encrypt it?

You can't necessarily tell who can decrypt a given GPG file by looking at it, but assuming nobody has any knowledge aside from their own private keys and the encrypted file itself, it is possible tell how many people can.

When you encrypt a message, GPG generates a random symmetric key, called a "session key", and uses it to encrypt the message.  It then makes a bunch of copies of the session key, and encrypts each one under a different public key, one for each recipient.  It then packages all of these encrypted "key packets" along with the encrypted message using the OpenPGP container format.

The important thing is that if all you have is the encrypted file, you have to be able to decrypt at least one of these encrypted session key packets in order to get to the message.

You can list all of the packets in an encrypted file using the gpg --list-packets command:

$ gpg --batch --list-packets myfile.gpg
:pubkey enc packet: version 3, algo 16, keyid 0000000000000000
        data: [2048 bits]
        data: [2046 bits]
gpg: anonymous recipient; trying secret key ABCDE123 ...
:pubkey enc packet: version 3, algo 16, keyid 123ABCDE0987654F
        data: [2048 bits]
        data: [2046 bits]
:encrypted data packet:
...

(The --batch flag prevents GPG from asking me for my passphrase, so that it can't decrypt anything.  If you're running a GPG agent, it'll take more than that.)

Those "pubkey encrypted packets" are encrypted session key packets that were read from the file.  The one with "keyid 123ABCDE0987654F" is a normal recipient; the key ID is a hint to tell you which key can be used to decrypt the packet.  The one with "keyid 0000000000000000" is an anonymous recipient: you don't know which key will decrypt it, but you know it's there waiting to be decrypted by something.  If your gpg was modified to add Eve as an anonymous recipient, this is what you would see when inspecting the .gpg file using a clean gpg binary.  It's also what you would see if you added an anonymous recipient on purpose.

If Eve's a little more clever, though, then there are a couple of ways to further hide recipients:

The listed keyid value could be a lie.  The all-zeroes keyid is just a convention, and the normal keyid is just a hint: there could be anything there.  Eve could label her encrypted key packet using Bob's keyid, and replace Bob's legitimate packet with hers.  It would look like a packet for Bob, but if he tried to use it, the decryption would fail.  Only Bob would be able to check this.  The --try-all-secrets flag is somewhat related, and could be useful if the keyid was accidentally wrong.
Eve doesn't have to put her key packet into the file, or even create an encrypted key packet for herself at all.  Try out the --show-session-key and --override-session-key flags on a dummy file with no sensitive data.  These will let you handle the session key directly instead of keeping it hidden away in encrypted key packets.  If Eve has replaced your gpg binary, she could (for example) have it email her the session key of every file you encrypt, along with a hash of the encrypted data for easy identification.  This violates the "no prior knowledge" assumption from earlier, but I felt the existence of these flags made it worth mentioning.


Where and how do operating systems save passwords for user accounts?

Windows stores its passwords in what is called the Security Accounts Manager database, or SAM database. This is a file that exists in the registry and access to it is tightly controlled whilst windows is running; however, local administrators who can run processes as NT AUTHORITY\SYSTEM can access it - see where does NT store the SAM database?.

As for the hashes used, they are either the LM or NTLM hash. Various attempts have been made to break NTLM; however, LM is known to be broken, so Vista does not use it by default although earlier versions of Windows do. Microsoft also apparently encrypt the database to make it harder to analyse offline.

The key to password security on operating systems is reducing their chance of intercept, so it is also worth studying who and what can access this. In terms of Windows, LSASS, or Local Security Authority Subsystem Service is responsible for verifying and creating user credentials. Thus, any attempt to hook or replace LSASS is an attempt to grab password input.

In terms of the Login screen it used to be possible to redesign it using GINA DLLS - many people did this to support fingerprint authentication, for example. However, custom GINAs are amongst many things quite hard to write and pose a possible security risk, so Microsoft rebuild that in Vista: see the credential provider framework which removes the custom code 1 level away from the GUI objects, which is much safer (Vista did contain improvements, for all people's criticism).

Now, Linux. It's probably better to start with the architecture of Linux authentication - most modern linux distributions use pluggable authentication modules which can be configured for various databases, remote, local etc. These can be configured to be optional, or mandatory, or "one of many options" if you like. The default pam module validates users whose meta data exists in /etc/passwd (so that any program can query it read-only, for example to find the users' home directory) and the passwords are stored separately in /etc/shadow. Directly from wikipedia (shadow password):

  /etc/shadow usually contains the following user information:

  User login name
  salt and hashed password OR a status exception value e.g.:

  $id$salt$encrypted, where $id is the hashing algorithm
  used (On linux, $1$ stands for MD5, $2$ is Blowfish, $5$ is
  SHA-256 and $6$ is SHA-512, see the crypt(3) manpage.
  "NP" or "!" or null - No password, the account has no
  password.
  "LK" or "*" - the account is Locked, user will be unable to log-in
  "!!" - the password has expired

  Days since epoch of last password change
  Days until change allowed
  Days before change required
  Days warning for expiration
  Days before account inactive
  Days since Epoch when account expires
  Reserved

So as you can see, what you can use for your hashing algorithm on Linux is entirely optional. The security of the /etc/shadow database depends entirely on whether you can become root, since the root user is granted access.

Both operating systems essentially hash passwords using a variety of techniques (crypt() in default DES mode I think was one of the first to repeatedly apply a hash to make checking hashes slower) - this is critical, as encrypted passwords could be trivially reversed by finding the encryption key. Clearly, in both cases, the security of the entry of the passwords depends on your ability to penetrate highly privileged areas; thereafter, the passwords are hashed and must be cracked using hash reverse techniques such as rainbow tables, which the hash design is built to counter.


Does Git usage raise a valid security concern? If so, how?

Aside from the fact that git is a program, and any program can have bugs, the only issue I can think of is the fact that git uses SHA-1, which has been recently shown to be vulnerable to a collision attack, which has some impact on git. The transition away from SHA-1 to a more secure and modern algorithm is being discussed. However, collision attacks against SHA-1 are still incredibly difficult to achieve. Furthermore, existing collisions can be detected, as GitHub currently does.

Overall, I would say that the senior developer either does not know what he is talking about, or is of the opinion that git makes programmers "lazy" (a somewhat common but misled opinion). Or it's possible that he is under the incorrect impression that SHA-1 is vulnerable to preimage attacks.


"Digital" signatures on real life objects

You are not actually asking to apply a signature to a real life object but you are only asking how to create a signature which can be associated with you and with nobody else. What then happens with this signature is another thing: you can attach it to the object you own or you can attach it to an object you don't actually own. Others can remove the signature, copy the signature, put it somewhere else or destroy it. Thus the actual use of such a digital signature in real life is limited.

Still, you can create such a signature if you have a digital identity based in public key cryptography and where the identity is accepted by others. This can for example be a smartcard, a PGP key, an S/MIME certificate etc. All these allow you to sign something and that's actually all you need: for example you can sign a description of the item with it.

But again, real ownership cannot be proven this way. It would be different though if the items you want to mark already have a unique identification, like a serial number you can find in car chassis or bike frames. In this case the act of ownership transfer could be digitally signed, i.e. the vendor digitally signs a contract which transfers ownership to you and if you give the item away you also sign such a contract for ownership transfer. This way nobody can just claim something as its own but must actually prove how they got it by showing the contract. In reality this gets way more complex than that but this is the basic idea.


Shortcut files (technically .lnk files) are mostly text and can be read using any program that tries to open the file rather than invoke ShellExecute on it. The text will contain the embedded command. The lack of closing parens, the incompleteness of the New-Object cmdlet, and so on probably mean you're fine so long as the shortcut is in fact truncated; if it isn't, you should probably assume the machine is compromised.

Out of curiosity, what shitty program transferred a .LNK file to you while hiding the extension? Very nearly all programs that hide the .LNK are aware that shortcuts can be malicious and will warn you, rename them, or outright block them. Did it suddenly get really twentieth-century in here? Anyhow, you should definitely report that as a security bug in the program (assuming, of course, it both did hide the .LNK and did not warn you).


Risks of using HTTP when I trust the local network

Assuming your local network is secure, the average script kiddie / hacker with minimal resources would not be able to tap into the connection even when using plain unencrypted HTTP. That doesn't mean using plain HTTP is risk-free. Your data could still be captured and logged or freely modified by:

Your ISP and your own government
ISPs and governments in countries your traffic is routed through
Anyone capable of launching a BGP route hijacking attack

And, of course, any of the above could share the data with third parties of their choosing, or even give these outside parties direct access to your network traffic.

A few examples:

Some ISPs are known to inject JavaScript into HTML pages. This could be additional advertising or tracking, or custom notifications like in the case of Comcast recently.

I live in Finland, and a lot of the Finnish internet traffic is routed through Sweden. In 2009 Sweden passed a law allowing the Swedish intelligence agency FRA to monitor all internet connections that cross the border. This means Sweden is both technically and legally able to use mass surveillance on Finnish internet users. FRA has also been reported to co-operate closely with NSA and GCHQ, and they are likely to share data.

In 2013 the surveillance software company Hacking Team orchestrated a BGP hijack in co-operation with the Italian government and a hosting company. Similar route hijacks could easily be used to tap into HTTP connections from anywhere in the world. BGP hijacks or "leaks" are not rare. The @bgpmon Twitter account, among others, tracks and reports these types of events. Often the events are attributed to misconfigurations and human error, but in most cases it's not possible to know for sure. Quite often the culprits are individual ISPs in China or similar countries, and there's no guarantee that the ISPs themselves weren't the target of a hack.

Besides security, there are other reasons to use HTTPS. SPDY and HTTP/2, which are new versions of HTTP with less overhead, are only supported over TLS in most implementations. Many JavaScript web technologies are also only available to HTTPS websites, e.g. Service Workers and the Location API.


Is it an security issue to have php change files?

Rely on path for security sounds weak to me (they can be cached by proxies), as relying on .htaccess (they can be ignored if admin fails the configuration when rebooting the server).

If the path & content written to HTML files are using the DB, and the PHP cannot alter it, then it sounds less attackable, but it could still be:

• If the wrote HTML file is the same as the read one (in-place file changes), then cascading calls may have unexpected results (ie: multiple string replacement/decoding)

• If one access the FTP, they can write anything to HTML files. That's normal. But here, when one access the DB, then they can write anything to HTML files too (and maybe to any file). So you made a new entrypoint, so new security challenges.

Why doing so online? There, you should do your trick on a local network, take the resulting files back, and push them to the real prod server. You won't have any risk of someone calling your build-script from the Internet. Otherwise, rely on non-homemade solutions. Take open-source ones, which will still have the same kind of flaws, but already analyzed & fixed by hundreds of people.


Why does the CVSS3 score increase when the confidentiality impact decreases?

I sent this to FIRST and I got this response from the their team.

We agree that this is a problem, and we plan to address it in a future
revision to the standard. We used a set of test cases to ensure intuitive
scores for all inputs during the creation of the CVSS v3.0 formulas, but we
missed this case.
I don't believe people often set CR, IR and AR to High, so I don't think
the problem often causes issues in practice.
Thanks for taking the time to ensure we knew about the problem.

Attached the mail image.


Is there a privacy concern if I'm using shared IP from VPN?

Well, it depends, ads are mostly not based on IP but more on cookies and logged in accounts. As an example, if you are logged in to your Google account and you are visiting some website that provides ads from Google and at the same time, one from your friends is doing the same thing you two will see different ads (this relies on your browsing history (i.e. targeted ads)). But if you are somehow anonymous on these websites you are visiting and also your friend is the same you will be seeing ads related to your IP (Time of year, area, etc.).


NoMoreRansom (link here) will help you with ransomware identification and relevant decryption steps. Here are all of their decryption tools: https://www.nomoreransom.org/en/decryption-tools.html

If you are sure that it is the Dharma ransomware then they have the steps to decryption listed here for that particular infection: https://www.nomoreransom.org/uploads/RakhniDecryptor_how-to_guide.pdf


Tracking down Malware within home network

To identify precisely what's happening, the capture over time using Wireshark (and add maybe a little bit of logging on each network node) will make you know quite precisely what's going on. "Quite" because, knowing the attacker is attacking your ISP, we can assume the malware might have spread in your home network, gaining safe and quiet places to hide for some time.
Let's follow some crisis methodologies (or a light version of it!)

Deny the attacks, limit the spread

Maybe an IDS/IPS can help you to snort the malware, and block the malicious communications on the network bridge. Add some firewall rules: I'm currently thinking about destination IP filtering, but you can add some rules based on the use of each of your machines. That may isolate it, that's a good beginning.

Eradicate

Then, eliminate may be harder and the solutions are quite evident: antivirus scans might work or disk wipes will do.

The few IoT objects may still be difficult to deal with, as the device can be locked/proprietary.


Security issues with concurrent sessions in iOS app and Safari browser

No security issues will be caused due to two concurrent sessions on same device. As far as your server is concerned, the two sessions are two client endpoints it serves, doesn't matter where.


Should I give developers admin rights or leave as power users?

I am a developer doing database and web applications with no administrative rights.  I thought a great injustice was being done when the policy was first implemented however I have come around to the idea because I can appreciate the security considerations.

chances of infecting your machine with some web exploit while you are surfing for an answer:  much reduced
chances that the cool add on you thought would help out crashes your machine: much reduced
it does bring clarity to your development process.  If you really need "it", then you ask for it and you have to document why you want it.
it helps ensure that everyone is working on the same install.  A certainty that sysadmins enjoy if you have to work up a new image for a developer.


Why can RSA-OAEP padded mail be decrypted using OpenSSL 1.0.1e?

OpenSSL 1.0.1 supports both OAEP and PSS padding modes, it is the cms tool that doesn't. Using cms to decrypt with OAEP padding works in 1.0.1 incidentally because the decryption function cms calls automatically determines the padding mode. The function called to verify a signature doesn't do this and defaults to PKCS1, so it fails.

The cms tool was updated in 1.1.0 to, among other things, allow the -keyopt option so that padding can be specified when encrypting or signing, and to determine the padding type when verifying. This change was backported to 1.0.2.


Mac OS X from an IT Security Practitioners' Perspective?

First there was one...

Below is a shot of the network management table at Shmoocon this year. That one IBM? That's my work-issued machine that was powered on for an hour because I needed to get some things done while away. It didn't do anything else all weekend. Every single one of us did the rest of the work on macs.

Why do all the security guys have a Mac?

Let's back up a step and say, "Why Unix?" That's what it's really about. We're all the type to have an ssh terminal running and live in bash prompts. The Mac suits both of those pretty well. I think you'll find that most of the folks would likely run a Linux desktop but when it comes to laptops, which now dominate the market, it becomes a question of hardware and convenience. Yes, I can get a laptop from another manufacturer and load Linux on it, or even pre-order. But the Apple will do most of what I want without the extra time and effort. It's also a known product from a predictable vendor with a lot of locations where I can bring my machine in and get it fixed. Believe me, no laptop survives me without a few trips in for service.

So, Linux may be home, but my OS X laptop has most of what I need, works smoothly from day to day, and handles a few commercial-only things that I need too like my scanner and Office. It also doesn't grate on me when I want to live in terminal land, work with text files, and not reach for the backslash key. Sure, I can find a way to make the scanner work in Linux and I can run Office in a Windows VM or fight with OpenOffice, but the fact is if my clients want it that way, they'll get it that way.

Why all the InfoSec use?

I think most people are in a similar spot to me. Also, the tools drop into it fairly nicely too. Nmap? Native. If I want BackTrack, it fires up in a VM. Since it's now my primary OS on my laptop. My laptop is my primary machine rather my more powerful desktop is used far less often. In fact, it's across the room while I leisurely type away from my desk.

Besides, I don't have to deal with Ubuntu and the Unity fiasco. I want a simple and comfortable interface, and I get it without hassle. The world where I live, the console, is the same for all purposes. It's not ideal, but it comes with a few positives and few negatives... not enough to get me to format the machine and work on Linux. In fact, now that I think back, I've been on OS X for 8 years now. I wouldn't have crossed over if it weren't for native Bash terminals.

So yeah, as a security guy it's a great general use machine that can play double-duty.


Any Alternative to Ngrok for constant Connection?

I run https://serveo.net/. It provides a stable subdomain as you require, and as an added benefit, it uses SSH port forwarding, so you probably don't even need to install anything—just use your SSH client.

Use it like this (where localhost:9000 is the address you want to forward to):

ssh -R 80:localhost:9000 serveo.net

Or, to make sure you get a particular subdomain:

ssh -R magis:80:localhost:9000 serveo.net

(Where magis is a subdomain you were previously assigned.)


Should iPhone backups be encrypted? Is this in-scope for Corporate IT if the device is linked to a home pc?

I certainly think it would be useful to mandate that devices are backed up in an encrypted format, if the reason for using local encryption is that you intend the data to be encrypted ;).

On the iPhone side, you would implement the security policy using Apple's iPhone Configuration Utility to create configuration profiles that control how the device is set up. Part of that configuration profile is that you can mandate encrypted backups. That doesn't mean that it will only back up to encrypted media, it means that the backup is stored in an encrypted form with a supplied password. Interestingly, files encrypted with NSFileProtectionComplete are re-encrypted with a key derived from that password, so you can restore the backup with knowledge of the password not necessarily the hardware key. That's useful if you have to remote-wipe a device or replace it, but still want to restore the data from a backup.


How to remove yellow tracking dots from a document?

There is a paper regarding yellow dots and also tools for their removal or retrieval.

DEDA Tools

Paper


This is really just a partial answer, so hopefully someone will come by with more details, but I wanted to give you something to get started.

https://www.wordfence.com/blog/2016/03/attackers-gain-access-wordpress-sites/

Wordpress hacks are a pain.  We typically avoided wordpress altogether, but if we had a client that really wanted to run a wordpress site, we would put them on their own server for just this reason.  How did they get in?  That can be very hard to determine.  Log files and lots of digging will be your friend.  The core wordpress software itself is usually fairly secure these days, so long as your wordpress installation is up-to-date.  However, you should audit your third-party modules with an extremely fine-toothed comb.  When some of our wordpress-hosted sites were compromised in the past, it was almost always because of security weaknesses in third party modules that someone installed.  Check for any security warnings related to any third party modules you have installed, especially the more popular ones.

It sounds like you caught it right after it happened.  That is good because it will mean that you have far less logs to look through.  Dig through them in detail until you find anything suspicious.  It's hard to be much more specific then that.  Once you figure out how they got in, Nuke it from orbit!, restore from a known-good configuration, and patch the issue that let them in in the first place.


A WiFi card in monitor mode will (given the right circumstances, id est in range of the client, the AP and the attacker) pick up the repeated third step of the handshake.

A filter rule could find such packets and trigger an alert.

There’s nothing in (usually configured) logs or otherwise persistent to the attack itself.


Is the OMS system and its network in PCI scope because it is reaching
  out directly (no proxies) to the processor's APIs?

No, it is not in scope.  The processor will be using a combination of network firewalls, application security firewalls, and restricted APIs to provide segmentation between their PCI-scoped network and you, the consumer of their services.  Segmentation is what limits the spread of PCI scope.

That is, of course, assuming the processor is PCI compliant... Page 12 and section 12.8 of PCI DSS 3.1 lays out that you are responsible for vetting the compliance of providers that process on your behalf:

  A service provider or merchant may use a third-party service provider
  to store, process, or transmit cardholder data on their behalf, or to
  manage components such as routers, firewalls, databases, physical
  security, and/or servers. If so, there may be an impact on the
  security of the cardholder data environment.

  ...

  Additionally, merchants and service providers must manage and monitor
  the PCI DSS compliance of all associated third-party service providers
  with access to cardholder data. Refer to Requirement 12.8 in this
  document for details.

Validating your processor - In general, the flow in PCI is documentation upwards, certification downwards.  Assuming your processor is a Level 1 Service Provider*, they must be listed at Visa's Service Provider listing or MasterCard Compliant Service Provider list.  Looking the provider up is the preferred method of validating their compliance, as it goes to the gated central authority which makes timely updates (e.g., revocation). They will also provide you with a copy of their AoC upon request, which is a short document from the auditor saying "We came, we audited, we found them compliant (and that finding is point in time only!)".  No details in the AoC.

They will effectively never share their RoC with you - they are not required to, and it contains information they don't want disseminated.  I believe I have seen ASV scans shared with a merchant on an exceptional basis, but that's certainly not normal practice, and I would expect most processors to decline to do so under ordinary circumstances.

On the other hand, everything the merchant has - ROC/SAQ, ASV scans, AOC - must be made available to the processor (and the acquiring bank, and the card brands...) upon request.  It's an asymmetric relationship.

If you read through the subsections of 18.2, you'll see that it basically says "You must know who you're in a relationship with, what PCI-related data is exchanged in the relationship, and verify that their validation is up-to-date."  You are not expected (...or allowed...) to see the data used to conclude that they are validated.

So - circling back to your specific question - you are not expected to receive data from your processor which proves that their configuration properly limits PCI scope.  The fact that they were validated (by an audit, for Level 1s) is proof that they are properly containing the flow of cardholder data.

(Actually, it's more nuanced than that.  They may have two service offerings - one that uses tokenization and other magic to limit your scope, and another in which you transmit and store CHD yourself.  Both can be provided in a PCI-compliant manner... it's your responsibility to know the difference.  If you choose the offering where you get to see the CHD, it's your SAQ or RoC which must reflect that fact.  If you say you're using tokenization but use the other offering, you're out of compliance.  Your auditor or whoever reads your SAQ is, in part, going to review your assertions and ask for evidence - show them you have tokens; show them you don't have cards.)

.* A Level 2 Service Provider may SAQ and therefore not be listed.  I've no idea how they prove their compliance to merchants, unless they share their SAQ, even if only to your auditor.  The QSAs I've talked to tend to dismiss Level 2 Service Providers and I'm sure being in a relationship with one would open your organization to more audit scrutiny than might otherwise be the case.


There are two ways in which these lookups may be ~safe for your privacy.

First, these lookups should be encrypted via SSL.  Assuming a good SSL implementation (i.e. assuming nothing like Heartbleed) and a client that quickly revokes rogue certs, this means that third parties cannot directly see your data, so you merely have to trust the lookup server.

Second, the lookups should be hashed.  Because these hashes cannot be salted, somebody with access to your lookups could note what you have in common with others, but won't be able to identify sites for which they have only hashes.

I can't speak to the setup at Eset or Bitdefender, but Google Safe Browsing does both.

An additional protection, which may require some legwork to configure, would be to tunnel connections to this lookup server over Tor or some other network connection (e.g. a proxy) that is decently uncorrelated to the rest of your network activity (which e.g. uses your VPN).  One complication:  some VPN setups won't let you make any network connections that don't pass through the VPN.


Is it PCI compliant to write down credit card information on paper and store it in unattended boxes?

IANAQSA, and this is outside my personal experience, but here goes:

  In this day of credit card fraud and theft, I'm dumbfounded that this
  is happening. Is this legal?

Legal?  Depends on where you are, but... probably, yes.  Note that even in the TJX breach, where 45 Million cards were compromised, the legal charges against them were for PII, not for violation of card numbers.  There's generally no laws about that, only Card Brand requirements.

  Doesn't this violate credit cards companies policies of safe credit
  card storage?

Yes, this violates the PCI DSS 9.5:

Now, the DSS is generally only thought of for business with computers and networks.  Since IANAQSA, I can't speak to whether the business you describe would be expected to hew to it.  That being said, I've no doubt that whatever contractual language they sign in order to be allowed to process cards invokes similar cautions because, as you state, they're pretty basic.

  Also, is there a way to report this?

You can report it to their processor, if you can determine who that is, and that may or may not have any effect.  You can also complain to the card brands (form for Visa, form for Mastercard) and there's still no guarantee that'll have any effect.

You can also vote with your feet.  Ask them to destroy your card, watch them do it, and don't go back there again.


Nmap from Kali Linux and from Amazon EC2 instance - vastly differing results

There are a number of differences between your EC2 scan and your Kali scan:

Most significantly, your Kali scan is performing a SYN scan (start to open a connection, listen for an "ACK" packet, then abandon it), while your EC2 scan is performing a Connect scan (fully open a TCP connection, then shut it down cleanly).  Try a Kali scan in Connect mode (nmap -sT) to see if the results change.
Your EC2 scan is using version 5.51 while your Kali scan is using version 6.47.  This shouldn't make a difference for a simple "open ports" scan, but the older version won't have the same software and OS version detection that the newer one does.
Your Kali scan shows dropped probes, meaning there's traffic congestion or a firewall between you and scanme.nmap.org.  This shouldn't be causing false "open" results, though it can cause false "filtered" results.

My suspicion is that something is going wrong with your Kali scans, since my results for scanme.nmap.org are identical to your EC2 results.


How to get clients mac address for aireplay-ng

1.First choose the Access Point:

airodump-ng wlan0mon

2. Retrieve client's MAC Address from the chosen Access Point:

airodump-ng -c 9 --bssid 00:14:6C:7E:40:80 -w psk ath0

Where:

-c 9 is the channel for the wireless network (channel 9) . It is important to note the channel of that AP so you must specify the same channel as the AP else it will display an error that the AP is on different channel

--bssid 00:14:6C:7E:40:80 is the access point MAC address. This eliminates extraneous traffic.

-w psk is the file name prefix for the file which will contain the IVs.

wlan0mon is the interface name which can be different for yours. You have to check first what is your wireless interface name after setting your card to monitor mode to avoid network interface name error.

The output of this command shows the BSSID which is the MAC Address of Access Point and the Station adjacent to it lists the client's MAC Address.

Source


How exactly is the used cipher decided when using TLS (mail)

An important point to make is that the machine and software that the other company uses to send emails is not necessarily the same as the machine and software that is used to receive emails. And even when they are the same, the SSL configurations for "client" and "server" roles may be distinct.

If you want to infer the cipher suites used by a given server, you have to talk to it in its server role, with a scanning tool that will connect repeatedly and make handshake attempts to work out how the server reacts; one such tool is TestSSLServer. Two caveats here:

If the SSL/TLS is done after an explicit STARTTLS command, then the tool will need to send that STARTTLS, and more generally handle the bit of SMTP protocol before the handshake. Not all tools do that (TestSSLServer, right now, does not).
You should not scan machines other than yours. Be sure to obtain the other company's consent to do that.

In any case, to answer your specific question: in SSL and TLS, the client sends a list of supported cipher suites, ordered by preference. Then the server chooses. How the server chooses is entirely up to it. Some servers are courteous and follow the client's preferences. Other servers enforce their own preference order. Still other servers do a kind of mix between the two, e.g. they will enforce AES over 3DES (regardless of what the client claims to prefer) but would follow the client's choice for key size (AES-128 vs AES-256).

There are other parameters to take into account, too. For instance, an SSL client may announce, along with its support of cipher suites that do ECDHE, a list of elliptic curves that it can handle for ECDHE. The server might also support ECDHE but elect not to use it because it does not support any of the curves implemented on the client side.

Notably (and this seems plausible, since you observe a DHE cipher suite being chosen, not ECDHE), I have observed the two following things, which may match your situation:

Some clients do not send the supported elliptic curves extension and/or the supported point formats extension.
Some servers, when faced with a client that does not send either or both of these extensions, will conclude that no elliptic curve cryptography is possible with that client (regardless of the claims in the list of cipher suites), and fallback to non-EC cipher suites, e.g. some with DHE.