If signature based AV software is becoming obsolete, what is the home user to do?

Since you can never be 100% sure you haven't been compromised, you need to practice defense-in-depth and just aim for as close to 100% as is practical.

AV software is becoming obsolete, but it isn't there yet.  Keep it around, keep it updated, and run it often.
You already know which files are your most sensitive.  Back them up often, and keep a copy off-site, so that if they are lost (i.e. from having to wipe your system), you can get them back.
If you're flexible about the single-system thing, have a machine that never connects directly to the internet.  Carefully mediate what files move across from your offline machine to the one you use to browse.  You can't call it an air-gap, but it's close.
Disposable virtual machines are your friend.

Defense-in-depth means that if one of your countermeasures fails, another will step in to stop the threat.  The more you have, and the more they compliment each other, the safer you'll be.  Just not 100% safe.


I will try to answer your question as specifically as possible.

I contacted Intel tech support to ask them exactly this question: Is the AES key on the Intel 520 encrypted with the ATA password. After weeks of back and forth, I finally received an explicit confirmation from them. I quote:

  Yes, ATA password is used to encrypt the encryption keys stores on the
  SSD. In other words: The Encryption Keys depends on the ATA password
  to decrypt them. The ATA password is not used in combination with the
  Encryption Keys to encrypt the data.

I also found this Intel white paper http://communities.intel.com/docs/DOC-19512 that claims the following:

  How Self-encrypting drives (SEDs) Work: SEDs, such as the Intel® SSD
  320 Series and Intel® SSD 520 Series, have a drive ... Because the
  disk encryption key is encrypted with the ATA (Advanced Technology
  Attachment) passwords

I summarised most of my findings about SED SSDs in this blog post: http://vxlabs.com/2012/12/22/ssds-with-usable-built-in-hardware-based-full-disk-encryption/


Ars has a decent article on the problem:
http://arstechnica.com/security/2015/06/hack-of-cloud-based-lastpass-exposes-encrypted-master-passwords/

One particular Ars user also posted an enlightening breakdown:

  epixoip wrote:

    vcsjones wrote:
    I feel like LastPass needs to really lay out their security. They tout PBKDF2-SHA256
    with 100k rounds. Sure, that is pretty good. But they also mention doing 5k rounds on
    the client side. What is the relationship between the client side PBKDF2 and server
    side? What about the salt that goes in there?

  rounds = user_rounds || 5000 // the iteration count is user-defined. default is 5k

  encryption_key = PBKDF2(HMAC-SHA256, password, salt, rounds) // this is what unlocks your vault

  auth_key = sha256(encryption_key) // this is what is sent to the server for authentication

  server_hash = PBKDF2(HMAC-SHA256, auth_key, salt, 100000) // this is what is stored in the auth db

  So the full algorithm for the password stored in the database, which is what the attackers obtained, is:

  PBKDF2(HMAC-SHA256, sha256(PBKDF2(HMAC-SHA256, password, salt, rounds)), salt, 100000)

  Ain't nobody got time for that.

In short, you need not bother changing your master password.


How can a browser hijacking attack change the browser's default homepage?

Unfortunately, installing addons is not the only way.  There have been a number of javascript methods over the years, many of which are no longer supported by most browsers.

However there is at least 1 method still possible that works on modern IE browsers: http://msdn.microsoft.com/en-us/subscriptions/ms531418(v=vs.85).aspx

There are probably others.


Is it technically possible to clear WhatsApp chat also on receiver's phone?

This doesn't really have much to do with "hacking". There is a command in the WhatsApp protocol where the sender can send to the receiver "Please delete message X". Whether or not the client honors that command is a different matter (it would be trivial for a client to simply ignore this command), but the official WhatsApp client by Facebook obviously does honor it.

So, there is nothing sinister going on, it's simply the WhatsApp client deleting a message in its own database because it was asked to do so by another WhatsApp client through perfectly normal usage of the WhatsApp protocol.

Note that there is a time limit built into the WhatsApp client, where after a certain time it will not delete the message anymore.

Also note that this will not wipe out the message from existence, e.g. it will still be present in any screenshots you made.


Is it possible to successfully exploit a vulnerability on a router remotely if

The answer is "it depends".

"is locked down to a single IP/Range" -- the first question is how is that enforced.  Assuming the whitelist is enforced by the device itself, there's code on your device that takes data off of the wire and decodes them into packets.  Code almost always comes with the potential for vulnerabilities.

If the layer that examines the packets and does the enforcement is what's vulnerable then the router is vulnerable.  If the IP-block layer is sound and it fronts the vulnerable component then you're okay.

It's also possible that the vulnerability is in a component that's not part of the remote admin stuff and not protected by the IP whitelist.

There's also a chance that someone could bounce an attack off of one of your internal hosts via XSS or a compromised host and circumvent your protection by coming from a host on the whitelist.


Is it possible to provide malware from a router?

That CVE number is totally bogus. The format for CVE's is CVE-[YEAR]-[number], so any CVE issues this year would start with CVE-2019, CVE-2020 won't be around until next year. The fact that you couldn't find the number on Mitre's website confirms that.

Mails like the one you received are scams. They try to make some quick money by threatening to disclose private information. To scare you off a bit, leaked password dumps from websites are used to "prove" that they have information on you. I've seen dozens of them sent to my various personal addresses in the last couple of months. Since I use a unique emailaddress for every website I need to create an account on, it's often easy to trace the mail back to a specific site, which almost always has had a password leak.

Personally, I wouldn't be worried about such threads.

To finally answer your original question: it could be possible, but there are many easier ways to gain access to someones computer and files, mostly through outdated software and tricking people to install something they shouldn't.


What are the pieces of information delivered in a user profile at the end of a OpenID Connect flow?

You were almost at the right resource!  If you click the core link on the page you referenced you'll find all the answers you're looking for.

There is a section on the ID token which contains the claims (attributes) that are defined by the OpenID connect spec.  The only one that matches up to you list is the sub (subject) which is a unique identifier for the user.

So where are the rest?

The spec defines a set of standard claims that match up to the attributes you've mentioned.  In fact, the ID Token is intended to be extensible.  As such you can add whatever claims you like to the token.

Requesting access

The mechanism for adding various claims to the provided ID token is done (as you've suggested) using scopes.  Most authentication servers allow the creation of rules that govern which claims are requested by each scope.


How does VPN provider hide traffic from different users

Other clients on the same VPN service don't share your tunnel to the VPN. Your connection to the VPN is encrypted with a key that is only used for your communication.

After your traffic reaches the VPN, it is no longer encrypted by the VPN tunnel. The traffic (in your case a plain text HTTP request) is forwarded to the host you're trying to talk to (example.com).

The hosts response is then returned to the VPN and returned to you over the VPN tunnel.

For economic reasons (and potentially some anonymity) many VPNs use shared IPs. This means many users traffic is sent from the same IP address.  Even in this case, other users can't intercept your traffic.

Essentially VPN users are just trusting a third party to forward traffic in their behalf.  Even though you may see a private IP on your system, traffic from private IP to private IP (VPN user to VPN user) is typically disabled on most VPNs (although there are some setups where that is the purpose of the VPN)


Securing APIs from Rogue/Fake iOS or Android apps?

If you're running a web service, you must always assume that the client-side of your service can never be secured against user tampering. Everything you send to the user can be reverse engineered, it's just a matter of time.

The solution to this is to do your security checks on the server side instead. In your example of spamming Instagram posts, they likely prevent this by rate-limiting calls to their API. For example every user is only allowed to post, say, 2 pictures per minute, and any API calls attempting to post more than that would result in a failed post, and return a 400-series HTTP error.

So in your Instagram example, they really cannot prevent anyone from sending their own API requests. Therefore they must be doing server-side validation of the API requests that they receive to make sure they are all legitimate and that the API is not being abused.


Can you submit a CVE for a closed source not mentioned platform?

Different vendors require different steps to be taken in order to get a CVE ID assigned for vulnerabilities.

If you check the MITRE CVE ID Request page here then you can follow the instructions to request an ID after locating the correct CVE Numbering Authority.

If the vendor is not specifically mentioned in any of the tables and a relevant CNA is not listed then you have to contact MITRE directly to request a CVE ID by filling out the form here.


OpenSSL version causes PCI Compliance failure

Until you can either get a clean scan or have your PCI-QSA sign off on proof that you are compliant the responsibility is on you to meet compliance requirements regardless of real-world security implications.

Compliance does not equal security and security does not equal compliance.

That said, typically an organization will document both vendor proof that a certain CVE found on a scan is addressed by a specific patch/application sub-version as well as proof that all systems in a PCI-Zone have that version of code applied (depends on what the remediation actually involves).

The QSA can then attest that the ASV scan finding is actually a false-positive.

Your question is also leading into another issue: What if there is a major known vulnerability and the vendor won't patch it? When this is the case you may have to come up with your own remediations to address the vulnerability. You also run into the case where someone could argue that yes your distro's latest version may only be X but the latest version of OpenSSL (or insert application here) is Y. In this scenario, you are responsible for the application level patches staying current in addition to the operating system patches. Therefore by not bringing the individual package up to date, you are out of compliance.

Per compiling OpenSSL I think you'll find it's not particularly hard but do test it on another system first (not production).

Ultimately you still need to consult your QSA (assuming you have one) as they can provide very specific guidance that may help you. A good QSA can save you time here too. The card processor may not want to advise you in the event there is a lawsuit later. Again, ask your QSA.

From a strict security standpoint ignoring all the compliance stuff: Always make sure your attack surface is tightly patched to the most current patch release and where possible add additional controls for defense in depth. Tools like Fail2Ban might be your friend here. Likewise, keep in mind that patching doesn't solve your security problems you really need additional controls to protect your data. Likewise, meeting any given compliance standard won't give you good security architecture. You really need to design security deep into your solution and not just try to meet a basic compliance guideline or vendor patching levels.

Keep in mind that whether you are the data custodian or the data owner you have direct responsibility to keep the system protecting this data (or access to it) as secure as reasonably possible. Just relying on patching isn't enough.

Security and compliance are sometimes competing goals. Sadly these two are not always aligned and it's not uncommon to see money spent by businesses taken away from things that would actually secure data and have it spent on things that make an organization "compliant" (sometimes this process even increases risk). Be careful not to confuse these two goals. You have a compliance problem AND a security problem these are not one in the same. If you keep these two goals separate you'll come up with good solutions for both easier than if you try to solve both with the same solution every time. It's great when one solution fixes them both but this won't always happen the way you want it to.

Finally, DO address this with your distro provider too. Adding pressure on them to keep up with security patches where possible will help prioritize security efforts.


What security controls should be in place for online updates of user's correspondance address?

Certainly, one can ask an extra question that's not normally asked in the regular online banking process. That will provide some measure of protection.

I think the best defense, though, is to ensure that a change of address triggers mailing a notification to the old address. Then delay any mail to the new address for a week. If the change was fraudulent, this gives the user a reasonable opportunity to respond. Automated phone calls to the former phone number of record may also be helpful.


Socket.io creates a WebSocket,  and WebSockets follow the normal Same-Origin Policy rules.  However,  it is possible to make a WebSocket into a cross-origin resource using the Access-control-allow-origin HTTP header, which commonly known as CORS. If for some reason CORS was being used to create a cross-origin WebSocket,  then it is possible that this WebSocket could be hijacked by an untrusted domain.

Additionally,  a WebSocket is like any other API in that it exposes application logic to attackers.  Make sure you address common web application vulnerabilities like the ones found on the OWASP Top 10. Of particular concern is Insecure Direct Object Reference, Injection Attacks, and Broken Authentication and Session Management.


Heartbleed: revoke or replace ssl certificate?

If you did not use your certificate, there is no need to of revoke it or re-issue. Seems to be CA is making more money with Heart Bleed.

If you have used certificate following things could be exposed with exploiting the HeartBleed.

long-term server private keys
TLS session keys
confidential data like passwords
session ticket keys.


There are a great number of assumptions to be made because you do not give a lot of details. But, yes, if you change the keys it uses, then it encrypts/decrypts it's own unique set.


As @Arminus said in a comment, this is not session fixation. Session fixation is actually relatively rare today, because it relies on one behavior now (thankfully) widely recognized as insecure/stupid: when you log in, the server preserves the old token (JSESSIONID, in this case) rather than generating a new one. An attacker can abuse that by knowing the old token value (for example, because they were the last user) and then logging out and waiting for a new user to come along; when the new user logs in, they keep the old token.

A security vulnerability requires that somebody do something that they are not authorized to do. In your scenario, how the heck does the nonAdmin user find the Admin's JSESSIONID? If they're the same person, then the user is (presumably) already authorized to log in as an Admin - they did so on the other machine, after all - so no security bypass has occurred. If they aren't the same person, either the nonAdmin stole the Admin's JSESSIONID (in which case the security vulnerability is in how they stole it, which might be your fault or might be because the Admin user's computer has spyware), or the Admin user shared the JSESSIONID with the nonAdmin (which means the Admin is, essentially, deputizing the nonAdmin as a temporary user of the Admin's account).

Authentication tokens (JSESSIONIDs, in your case) have a number of critical properties. The following list is in no particular order. The relevant ones here are highlighted:

They are securely generated (i.e. don't use java.util.Random, which has predictable output; use java.security.SecureRandom). Some implementations use encrypted user-info strings instead of random tokens; this has some pretty bad security risks.
They are long enough that they can't be brute-forced (64 bits is generally seen as borderline; 128 bits and up is good).
They are never re-used, so an attacker who sees an old one can't use it to get somebody else's session. Since keeping track of all the old session tokens is infeasible, the solution is again to use a long-enough (random) token that the odds of a collision are infinitesimal (and if you express the odds against it happening using words like "billion", it's not infinitesimal enough).
They must be checked in a constant-time manner (otherwise brute-forcing a valid token becomes linear in its length, rather than exponential).
They must not be shared across privilege levels, or sessions for a given user. Any time a user re-authenticates, the old token must be invalidated and a new one used instead.
Token invalidation must occur on the server. If a user logs out or their session expires (or otherwise ends), the server must no longer recognize the token as valid. Simply deleting the token off the client is not sufficient.
Tokens must never be sent in a URL, only in headers or if necessary in message bodies. Even over HTTPS, URLs tend to leak (they may be recorded by proxies, included in referrer headers, or saved in browser history, among other risks). If a secure value absolutely must be sent in a URL, it must be single-use only and invalidated after the first attempt to use it, whether or not the user completed their action, and should also time out very quickly.
Tokens must never be sent over insecure connections. If your site supports HTTPS, then the token must never be sent over a non-HTTPS connection (an easy way to ensure this is have the token in a cookie, and set the secure flag on that cookie). If your site doesn't support HTTPS, then treat sessions as convenience only; there is no real security there. (Yes, looking at you, SE default post-authentication behavior...)
I'm probably forgetting some, but a comprehensive list is not the core point here. Still, as you can see, there are a bunch of things (some related, some independent) required for a secure authentication token, which is just one component of a secure site. You have to do them all; one weak link is usually enough for an attacker to get in.


How can we know which debian package correct which CVE

PTS/QA

You go to the package's QA page. For this, you either use the source package name (here "bind9"):

http://packages.qa.debian.org/bind9

Or you use the binary package name (e.g. "bind9-host"):

http://packages.debian.org/bind9-host

If you used the binary one, click on the package in a distro (e.g. oldstable)¹, then on “Developer Information (PTS)” on the “Debian Resources:” box on the right, which redirects you to the QA page.

① This page conveniently has “[ Source: bind9  ]” in the upper-left corner, which tells you the source package name for the binary package. You will need that below.

Once on the QA page, you see the “news” box in the centre of the page. This will have the changelogs for each individual upload. You click on “[2013-08-10] Accepted 1:9.7.3.dfsg-1~squeeze11 in squeeze-security (high) (Salvatore Bonaccorso)” and get redirected here which shows CVE-2013-4854. All changes of prior versions also apply, normally.

Security Tracker

Finally, there's the security tracker where you can search for source package names. (If you have only the binary package name, see above.) Entering “bind9” redirects you to…

https://security-tracker.debian.org/tracker/source-package/bind9

… where you, again, have all the CVEs and DSAs. Clicking one (either of them) will show an overview page where you see which packages fix the problems in which distros.


Can a laptop be monitored when booted from external drive?

While it is technically possible to do so, it would require modifying the device firmware to spy on the running operating system. The chances that your employer would do this are astronomically low.

It is feasible that some laptop manufacturer could design (or has already designed) firmware with a feature to log information about each booted machine, in which case you would need to disable that feature. I suggest you check your BIOS/UEFI to make sure you see nothing like that.


For the practical answer, what's best for security is to avoid reinventing the wheel. Designing a secure protocol for data transport is a daunting task (it's easy to make it work, it is hard to know whether it is "secure"). There are already a few known protocols which have been studied a lot, and are available as ready to use library. Foremost of which is SSL/TLS. You might want to use DTLS if you want to protect individual packets (DTLS is to UDP what TLS is to TCP).

For the scientific answer: when it comes to encrypting some data and protecting its integrity, best idea is to use an encryption mode which does both (GCM and EAX are the usual suggestions). If you have to rely on separate algorithms for the encryption and for the integrity check (what you apparently call a "checksum" but is better known as a MAC), then the correct way is to encrypt first, then compute the MAC on the encrypted data (not forgetting the IV and some other stuff, as explained in this question).

But let me point out that this is only part of the protocol. Doing encryption and a MAC on a "payload" assumes that sender and receiver already share a common high-entropy secret value which they can use as key for the encryption and MAC. You also need some more features to avoid replay attacks, and, more generally, defeat attackers who would try to drop packets, duplicate packets, and reorder packets. Authentication (one-way or mutual) is yet another tricky area.


CIS recommendations - disabling ip forwarding

Is there a bigger reason to do what the recommendation says, other
  than to make sure the default parameter is set?

Similar to configuring firewall ACLs, the best practice is to explicitly configure the settings you want and not rely on the default (which may be different from device to device. For example, ACLs should end in deny all and log.

There are many reasons for being explicit in your configurations:

Not all systems have the same default value
Setting the desired value explicitly aids in accountability
Audit Requirements


How would I prove a windows executable is not a false positive?

I do believe this question is related to https://reverseengineering.stackexchange.com/ rather than security forum.

This is an extremely indepth sort of question to answer. For example, what is this application? Native or byte-code language e.g. Java, .NET etc.

So, I'll make some assumptions that it's an x86 executable.

You'll want to download:

Process Monitor - An really handy tool to see what process is for file, registry, network and threads/processes.

IDA PRO - An extremely powerful debugger/dissasembler/decompiler so you can actually breakpoint known API from what the false positive is doing. You'll require an understanding of windows internals. If you provide me with what the virus is believing to do, I can give you an list of APIs to investigate under the debugger.

API Monitor - An handy tool for just checking what it's executing over the time to see if anything stands out. For example, OpenProcess, WriteProcessMemory, ReadProcessMemory is usually used in injection code into other processes and an general application would not require these APIs.

Ideally, you'll want to learn into reverse engineering to review code as bypassing AVs and false postive are extremely common.


How can i protect myself from tor vulnerability on windows

The vulnerability was in the bundled Firefox browser. It has since been patched, so updating it would fix the problem.

In general, there are several ways to protect yourself:

Update Tor Bundle to the latest version, which isn't vulnerable to this specific attack.
Enable NoScript globally, and only whitelist sites when you've FULLY checked that they're not serving dodgy JS. Remember that FH got popped, so all FH sites were infected.
Always keep your OS, AV, firewall, apps, etc. up to date.
Install EMET and configure it to provide additional protection against exploits.
Do your browsing in an isolated session, e.g. in a VM or via Sandboxie, in order to minimise the risk of future exploits. This won't stop you from being identified via out-of-Tor comms, but it helps prevent your box from being popped.


hardware required for wifi security system

A quick glance at the lockitron web site answers both questions.

The hardware setup involves replacing existing locks with their WiFi connected locks; and they support NFC but not plain RFID.


Generate variable length wordlist with ! character at the end?

I'm fairly sure you can not create a word-list of variable word length and a fixed terminating character. Be sure to denote a specific word library if you have one, I'm using the default in these examples.

You have two options:

Run Crunch 3 separate times, once for each word-length (in total) 4 alpha with an appended '!', 5 alphas with an appended '!', etc... Also note, you need to make sure you escape the exclamation with a backslash. You can also establish parameters on the word-list file size, or number of words compiled.

./crunch 5 5 -t @@@@/! -o filename.txt
./crunch 6 6 -t @@@@@/! -o filename.txt
./crunch 7 7 -t @@@@@@/! -o filename.txt

Note the above word-lengths 5, 6 and 7. This corresponds to a word containing 4, 5 or 6 alphabetical characters, with an additional fixed special '!' character. The commands ./crunch 4 6 and/or ./crunch 3 5 will not create words of correct length.
Run one instance of Crunch to generate only the nonfixed characters,

./crunch 4 6 -o filename.txt

Write a basic script to retroactively append the '!',


Does pressing a car remote many times offer denial of service attack for rolling codes?

it is possible to render a key fob useless by pressing the button at least 256 times while out of the range of the car.

Not useless, but desynchronized. Any car will allow you to re-synchronize, and one example of a typical procedure is:

Turn the ignition key on and off eight times in less than 10 seconds. This tells the security system in the car to switch over to programming mode.
Press a button on all of the transmitters you want the car to recognize. Most cars allow at least four transmitters.
Switch the ignition off.

  yet I have never heard of anyone performing it

You don't have any 3-year olds around?

My older daughter did that... She got the garage door remote when we were putting things on the car, and after driving 10 minutes without her complaining about anything, I saw her pressing buttons on the remote... Got home to a desynchronized remote.

Three-year-olds can be dangerous, relentless attackers, so take care with the physical security of your key fobs.


Is there a civilian friendly indicator of stored password safety?

Financial cost is also not a good metric. Moore's law can be used to derive that chip performance would double every 18 months. This results in greater computational power at the same price, hence it might cost $1000 per password today, but it will be $250 per password in 3 years time.

In my opinion, time is still the best metric because it can be tied to your organization's password policy. If your observations are that the current password strength would require 10 years to brute force, and you are 80% confident of the accuracy of your estimate, then perhaps you might want to force your users to change their passwords at least once every 8 years. Even if your observation turns out to be incorrect due to hardware advancements and the password is cracked within the margin of error, your users are still safe since the passwords have long been changed.


Assuming that your $_SESSION['id'] is a random long string that cannot be guessed (that would be a security issue) you need to validate at server side when a POST request comes in that it has a VALID session ID and the account is authorized for the functionality.

Now someone can bypass your authentication with Parameter tampering as you most likely only check if an ID is present and not if it is authorized for the action.

Check the following links and do some googling:

OWASP Session Management Cheat Sheet

OWASP authentication cheat sheet


For PCI compliance, does every request need to be logged regardless of how it affects system performance?

Let's try to tackle two problems at once. First of all yes you will take a performance hit, especially if you are logging onto the same machine. The idea is that you do not log everything locally but instead use an encrypted syslog connection (or similar) to log every request to a seperate logging server.

This will relieve the webserver from being busy with the logs. Normally this shouldn't be too difficult as normally you should have some sort of SIEM implemented (right?) where you can immediately log towards to. This will also allow you to write specific SIEM business rules for realtime allerting (or you can use the logs for statistics). Depending on how much money you have you can either go with Splunk or go for something more affordable like logstash with Kibana.

Log rotation and analysis in case of breach are also a lot easier when you've already imported logs into a similar database as they are extremely good at allowing fast log aggregation, correlation and searching. When you have a breach the last thing you want to be doing is spending tons of time importing logs into similar tools to analyze them.


How to test for the BEAST attack if server isn't Internet-connected?

Background. To learn more about how to mitigate the BEAST attack, I recommend reading the following two blog posts: Rizzo/Duong BEAST Countermeasures and Mitigating the BEAST attack on TLS.  You'll quickly learn that there are no really great solutions.

What to scan for. Right now, the only known server-side mitigation is for the server to force use of RC4 by refusing to accept any other ciphersuite.  A similar variation is to place the RC4 ciphersuite as the highest preference; this is almost as safe, as it ensures that any client which supports RC4 will use RC4.

Thus, when you scan a SSL server, if the server prioritizes any block cipher based ciphersuite higher the RC4 ciphersuites, then it can be considered vulnerable to the BEAST attack.  If all the ciphersuites it accepts use RC4 (or if the RC4 ciphersuites are prioritized before any block cipher ciphersuite, except for TLS 1.2-only ciphersuites), it is probably safe from the BEAST attack.

Determining the server's priorities on ciphersuites can be tricky, and may require multiple connections to the server with a different set of ciphersuites each time.  However, in this case one simple method may be to have your client connect with a list of ciphersuites that starts with all of the (non-TLS-1.2-only) block cipher suites, and then end with some RC4 ciphersuites.  If the server picks any block cipher ciphersuite, then the server is probably vulnerable to the BEAST attack.

Ideally, the server would support TLS 1.1 or higher.  If both the client and the server support TLS 1.1, then the BEAST attack becomes much harder (it requires a man-in-the-middle attack).  Therefore, if the server doesn't support TLS 1.1, you might want to output a warning/advisory suggesting that the server admin upgrade to provide TLS 1.1 support.  However, apparently supporting TLS 1.1 on both endpoints is not an absolute guarantee of security, due to the possibility of downgrade attacks if a man-in-the-middle is present, so I would suggest listing this merely as a warning/advisory, rather than a critical failure.

More on SSL server scanning. You might want to consider using the SSL Labs service for scanning a SSL server.  It is a great way to test for many possible configuration vulnerabilities.  It will also test whether the server is vulnerable to the BEAST attack, but it will check for many other common and serious problems as well -- which is probably more useful than just looking for the BEAST problem.


Correlation between server request and response time and built-in php functions

That's not possible I think. The response may change because a lot of factors: server hardware and resources, server load, connection status, etc.

I think is not possible even in the extremely case of reproduce exactly the same script in same hardware. You'll never get the same miliseconds of response. Maybe even micro electric variations can affect.


Should self signed wildcard certs be used?

Should wildcard certs be used?

Generally not, and here's a good list of reasons why.  Subject Alternative Name (SAN) certs provide most of the functionality without the same level of security drawbacks.  Wildcards had turned mostly into a lazy shortcut for people who didn't care about security, which is why they're discouraged these days.

Should wildcards be used in SAN names?

The RFC you've quoted says that you're welcome to use wildcard characters in a SAN name, but that they are not reserved to mean "wildcard", so the interpretation is up to the client.  If you're writing your own client to use your own service and your own certs, hey, go wild.  But nobody else's browser is likely to play.

Should self-signed certs be used?

Depends on what you're using them for.  Internal resources where you control the trusted root store for the client browsers?  Sure.  Cheap web hosting of your kitten pictures?  Sure.  Otherwise, use caution.  There are plenty of good questions on this site if you want to learn about the nuances of self-signed certs.

Does self-signed have anything to do with wildcards?

No, not particularly.  As per my comment above, you may have confused SAN and self-signed.  Wildcard certs should be avoided equally for self-signed and CA-signed certs.  The potential negative impact is somewhat less when self-signed, due to the limited client trust of the self-signed CA, but that doesn't make them a good idea.


Do you think that's possible or are aware of software that's capable of doing this? Or maybe another way to accomplish unrestricted internet access under these cirumstances?

If you are in control of a server reachable by the service you mentioned then you could built your own tunnel, because

you can send data through the tunnel to the server (via the URL of the request)
and you can receive data through the tunnel from the server (via the response)

Which means all you have to do is write yourself the appropriate local and remote handlers to translate between your tunnel protocol and HTTP request/response.

I'm not aware of any existing software working within your specific restrictions (httptunnel is probably outside your restrictions), but it is possible to write something like this and to help you to actually circumvent specific security policies would be outside the scope of this forum anyway.

And always remember that security policies are often there to protect something and that you might get into trouble when you try to circumvent these policies, like loosing the job or maybe even get charged for hacking attempts. And such tunnels can be detected because they show abnormal usage behavior.


It is not possible to determine either the length or certain characters of the password. You can read more about the authentication protocol here to understand why: https://en.wikipedia.org/wiki/IEEE_802.11i-2004.

For your second question, yes, they will be included in the attack. You can check the manual of crunch to see examples of how it can be used by running: man crunch (I suppose you're using linux)

Your password is pretty strong. I believe it will take forever for any moderate attacker to crack it.


What methods can be used to prevent the browser (IE11 specifically) from storing credentials / autocomplete

It is true that most major browsers now ignore the autocomplete value if set in the web application.  However, IE11 only ignores this setting on password fields, it should still honour the autocomplete setting on CC fields.  As Xander suggested, it could be worth checking the input type for your CC payment field.


I think your client needs to update their threat model.  Online password guessing is not the only thing which should drive password complexity.  The client needs to understand how  how password cracking works.   If your password hashes are ever compromised (via SQL injection, improperly stored database backups, etc), an attacker is going to try cracking those passwords offline with a tool like hashcat, rather than guessing them against the website itself, where account lockout could come into play.  4 digits is NOT enough security for any system.  Even the slowest hashing algorithm can complete that work in under a second with a modern video card.
If there are concerns about usability regarding passwords, I would suggest that users use a password manager. If that's too much effort, all modern web browsers can also save the user's password if portability is not an issue.


it depends on how you plan to use the answers.

If you expect to do strict automatic checking then treat them as passwords and apply key-derivation function such as bcrypt/scrypt. (But remember, that BCrypt uses only first 72 characters of string for the hash. is that enough for your case?)

on the other hand, if there is a chance of phone-based support and you want call-operators to interpret users answers you need to store strings as-is

p.s. using plain hash-functions (such as md5,sha) is not the answer to this problem in any case


Custom JavaScript injection allowed in DOM of other origins

It sounds like what you're saying is that an app development framework supports injecting arbitrary scripts into webviews displaying arbitrary origins. This is nothing new; they all do this. While a malicious app written using such a framework could potentially steal sensitive information, there are several things you need to consider:

By default, the app won't have access to any sensitive data. Because the user would install an app that is independent of any other app (such as a browser), the app would start out with no cookies, stored passwords, or other credentials or session tokens. A user might choose to enter their credentials, but in that case the user is making an explicit choice to trust the app with those credentials. Whether or not the application is "browser-like" doesn't really matter here.
This is definitely not a vulnerability in the framework. Indeed, it is essential functionality for a huge number of apps. In a browser (or browser-containing) app, it might be used for ad and tracker removal, password and form auto-fill, and integration with other non-web app functionality. In a non-browser-type app, it could provide a bridge between web-based and "native" UIs, or simply be used to (legitimately) obtain the session token after a user completes an OAuth login flow (which may be the only browser-based part of an app).
Yes, it could be used maliciously, but so could any code you run (heck, there's websites that will use your browser's JS engine to try to mine cryptocurrencies for the site owner). There's no reason to privilege this particular case of "could be used maliciously" over others. Ultimately, it is the responsibility of the user to not install or run malicious apps, not of the framework developer to make it impossible to write untrustworthy apps on that framework (which is, again, impossible).


Deploying a campus WiFi network that authenticates against an AD LDAP

Most places use radius in combination with a backend authentication system.

Freeradius could do the job and integrates with Active Directory: http://wiki.freeradius.org/FreeRADIUS_Active_Directory_Integration_HOWTO

Cisco ACS can do the job and also integrates with AD, though in my experience this can be cludgey.  It supports policies and of course can be used to provide TACACS AAA services for cisco devices as well.

Microsoft has been pushing NPS with their Network Access Protection http://msdn.microsoft.com/en-us/library/bb892033(v=vs.85).aspx it has the whole "call microsoft" benefit and negative.  It's supports policies similar to ACS and you can send people to get trained on it and does the RADIUS job too.

Really if you're in the EDU space you can get Microsoft licenses cheaper than a ream of paper I'd recommend going that way.  Cisco and Microsoft basically give you the same "one throat to choke" even if they're not perfect, they do allow you to easily receive vendor support.

In the same vein I'd say if you're in the private space stick with ACS and save your money.  As long as you've got a robust ACS infrastructure it's a single place to manage it all, and you've already got the license.


How to become Intermediate Certificate Authority?

To become an intermediate CA you must find a CA who is willing to deal with you. But, it is not possible to restrict the domains an intermediate CA can deal with, so any intermediate CA is as trusted as the CA who signed it and can issue any certificates it wants. Therefore you will probably not find any CA which will sell you the intermediate CA you want.

See also https://serverfault.com/questions/605643/getting-an-intermediate-ssl-certificate for a similar question.


What are easy checks to identify malware in Python code?

Short of reviewing the full source / binary you can never know for certain without executing the code - at which point by the time you realize it may be too late. Sure a string manipulation library calling "import http" might be easy to grep for but there are endless ways for a malicious developer to obscurify it.

If you are concerned then the best approach is to try to sandbox the execution environment to restrict the package only to have data to access / APIs it would be expected to use.

With regards to general PyPI packages you need to perform some risk assessment when using a package. If its a major package from a well regarded developer then the risk is low and the chance of someone having detected it if something malicious was there is high. If you are one of 10 people installing the only package posted by a developer then you may want to take a closer look at it.


Permissive CORS - Arbitrary Origin Trust, Remedial Action?

Thanks to Soufiane I was able to find the answer, links are provided below:
https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/
https://stackoverflow.com/questions/12458444/enabling-cross-origin-resource-sharing-on-iis7
Here is other research I did and they also provide fixes for other server variants such as Apache, Nginx and so forth.
https://stackoverflow.com/questions/1653308/access-control-allow-origin-multiple-origin-domains
https://stackoverflow.com/questions/24795268/how-to-allow-multiple-origin-domains-by-access-control-allow-origin-in-web-confi


Best router/s for timely updates and decent security?

It is not so much about the router as it is about the firmware which is running on that hardware. You can buy any device which is supported by DD-WRT - just check the list.

DD-WRT also pushed a fix for the latest vulnerability known as KRACK.

http://svn.dd-wrt.com/changeset/33525

The thing is that you should go with better maintained firmware.


Not really a direct answer, but it is way too long to be comment.
In the end, your question will boil down to: who is responsable for the security of a user password? And you fall in a quasi religious war... Many system admins think (know?) that most user do not care at all about the security of their password and they do their best to invent rules to improve that security (minimal length, forced or forbidden patters, maximum lifetime, minimal differences between consecutive passwords, etc.) And some other security actors think of that like a bandage on a wooden leg. Because it leads to users forgetting their passwords and secure password recovery is hard. And because in the end users just write down the password on a paper (post-it) sticked on the screen. So for those other people the only way to obtain security is to educate users so that they are aware of the risk involved by poor security practices, including poor passwords. Additionaly, they say that most of the rules actually (slightly) lower entropy which is bad, and tend to let the system process the plain text password longer which is also bad, specially is it leads to keeping plain text copies of previous passwords.
So if you tend to believe that the admin is the one that knows about security and that trusting users is stupid, then you should avoid any solution that let the end users choose their password without control. If you think that the users should be responsable for their own security and all that you can do is informing them of best and poor practices, then SPR is for you.

Apart from religion, I must aknowledge that some objective things can matter, mainly who the users are (corporate users, users interested in IT or security, or just anybody), and what is the sensitiveness of the application and its data...


Is possible to force a file to generate an specific MD5 signature?

Sort of. But it would take a very long time.

Being able to create a file which has a specific known hash is known as a pre-image attack. An example would be me asking for a file which hashes to beefbeefbeefbeefbeefbeefbeefbeef. The only way to do this, theoretically, is to try calculating hashes for every possible input to MD5 until you find an input which gives this hash. There is no guarantee that this input exists (although it's likely to) and it's entirely possible that finding this would take universe scale time, even with the speed of MD5 hashing on modern processors. There is a known attack which weakens the MD5 pre-image resistance from 2128 to 2123.4. That's going from 1022 millenia, with one hash per microsecond, to 1020 millenia, so still not particularly practical!

Creating another file with the same hash as an existing one is known as a second pre-image attack. This is a special case of a hash collision - normally, you just want to find two strings which have the same output hash. There are a few of these known, and you can even generate your own!. However, in your case, you are leaving the first input untouched, and looking for a second input which both contains the first input, and includes some other specific content. That massively reduces the potential set of inputs to the hash function, meaning that you're looking for something that might not exist at all within a subset of the inputs. And the only way to find it is to try hashing every single valid value, until you find one.

In theory, you might be able to find such an input, but it may not exist at all, and finding it might take longer than the universe has existed. It's probably not worth worrying about!

Incidentally, this is why MD5 is fine for use as a checksum for downloads or similar - being able to generate a distinct file with the same checksum as a fixed original would be a computational coup, and be a bit wasted if merely used for tampering with downloads. It's usually a lot easier just to modify the MD5 strings listed for the downloads.


Why no SSL certificate with multiple subdomains

Certificates for *.example.com are only valid for one subdomain level.

If you want a certificate valid for x.x.example.com you need a certificate with x.x.example.com or *.x.example.com , it's how it works.


Responsibilities as a Junior Information Security Analyst?

The term 'analyst' is a very, very broad term that can cover very basic and very advanced tasks. In short, there is no way for us to tell you what you will be doing or how to prepare for it. Your company and your boss will define your responsibilities and job description.

Also, the term "Information Security" is a very broad term. It could cover secure code review, firewall administration, penetration testing, forensic analysis, or pre-sales security engineering. And lots more. With what you have told us, we cannot even point you in a direction of study. As a shot in the dark, you could look at the Security+ certification as a base.

It is sometimes a great idea to ask your boss what they expect you to accomplish within the first 90 days of being in your new position. This goes beyond your job description or your daily duties. By asking this question, you get to know what your boss "really" wants you to do, and you can meet your boss' hidden needs in a direct way. Along with this, you could also ask what security certifications they expect you to achieve and which ones they will help pay for. This will help you know what to study for in a way that meets their needs.


Is Gmail showing images by default a good idea for privacy?

Their motivations are to increase the value of their service, based on cost-benefit analysis of the problem space and their solution.

Pros: Better email experience, most threat vectors of loading images defanged.

Cons: Threat vector of identifying read activity ('read receipt' or 'live email detection') via unique images.

Mitigation: Most of the people who would abuse the remaining con are spammers.  Google also filters spam, lowering the likelihood you'll be confronted with an email that would benefit from this new system.  Also, as long as they provide opt-out, they cover people like (presumably) you who aren't happy with the tradeoff.

Heck, this is Google.  They could load and cache every image from every email upon arrival, negating the remaining con - the attacker finds that every image is loaded, without regard to the status of the inbox or the reader's interest.  Sure, it would take bandwidth and disk, but see step 1, "this is Google."


Help Prevent Videos From Being Downloaded or Hotlinked ~ OpenLiteSpeed Server

Forget point 2. You can't stop a user that can watch a video from downloading it - because watching implies downloading.

What you can do is to check referer. This will provide mild security, effectively stopping anyone from embedding your content in their web page. It will not stop any attackers.

An more advanced version, that is marginally more effective, is to use some kind of authentication to validate the origin; this may for instance be by signing the URL with a HMAC or similar. But it will not stop someone from copying your video.

So in short, I would probably implement referer checking. That will stop embedding in other sites, which would be my big concern - as this would cost me bandwidth. It's trivial to implement, and has almost no overhead, except having to maintain a list of allowed sites.


The mobile application cannot currently be validated or considered a compliant payment application. Guidance on security and compliance in mobile applications has been issued by the SSC here: https://www.pcisecuritystandards.org/documents/Mobile_Payment_Security_Guidelines_Merchants_v1.pdf

As your environment is receiving and transmitting cardholder data, you are correct in your assertion you should complete SAQ-D. SAQ C would be more relevant if you were processing data in a payment terminal in an IP environment. There are lots of things you need to do to be compliant in addition to the scanning you reference above. The following is not an exhaustive list:

Firewall ruleset reviews at least every 6 months.
Server hardening in line with industry standards (CIS, NIST, SANS)
Anti-virus installed, running scheduled scans, generating logs
Systems patched and up to data Software development lifecycle - secure coding, peer review, separation of dev, test and production environments and separation of duties between those environments
Change control for software modifications and deployments
Access control with documented authorisations for Role Based Access Control
Two factor authentication for remote access
Password policies
Physical security of the in-scope environment (CCTV, badges, visitor controls)
Centralised logging
Consistent NTP configuration with internal peering and external sources
Quarterly internal/external vulnerability scanning
Annual internal/external penetration testing
IDS/IPS File Integrity Monitoring
Lots of policy and procedure documentation

Note that if the payment data was transmitted directly from the mobile application to the third party payment service provider, your systems would never handle cardholder data and PCI would only be relevant to the due diligence performed to validate the third party is PCI compliant and accepts their responsibilities.


How to calculate the risk rating of a feature?

I would abstract out the 'impact' rating for your users of this rating system. The resulting system needs to be clear, simple, and unambiguous. It also needs to result in an auditable output (something someone else can check).

I have done this by reducing the complexity of analysis to the data and the data systems the feature interacts with. Use your existing data classification and data risk model to define the characteristics of the various data types you have (personal, financial, payment card, health, sensitive, etc.) and define what protections those data should have (encrypted, certain access levels, etc.). You probably already have some level of understanding of the impacts of the various data you have, so just borrow it instead of re-inventing the wheel.

Then you can classify the protection/risk level of the data that the feature touches, either directly or via calls to other features/systems.

Example:

The data the feature processes has:

* names or personal identifiers
* payment card data, bank details
* health information
* internal financial information
* internal configuration
* passwords, crypto keys
* ...

The feature interacts with:

* users
* Database A
* Database B
* 3rd party service C
* payment processors
* external researchers
* ...

The result is simple: the dev checks the characteristics of the data the new feature processes and the systems it interacts with, and your checklist should return the classification of the feature. Auditors/peers just need to review that the data indeed has those data characteristics.

All in all, the resulting system is fast, simple, and easy to understand. What makes it work is all the work done previously in identifying the risks and protections required by certain types of data (either by internal risk ratings, laws, regulations, etc.)

If you do not already have a data classification and data risk understanding, it would actually be simpler to create that first, rather than re-inventing that wheel every time you have a new feature to assess. It would also make it easier to update this rating system when things change, like laws or the risk tolerance of the company (three cheers for abstraction and encapsulation!)

An added bonus to the data characteristics inventory approach: if a regulation changes you have a pre-built inventory of data characteristics, so you know the flow of that data through your systems. It's like an up-to-date, organic data flow diagram.


CORS accepting arbitrary origin with GET but not with OPTIONS

Q: Is it safe to say that does not pose a vulnerability, but is just bad practice?

Since it's an API and assuming it requires Authorization header for all requests, it's safe to say that it doesn't pose a vulnerability. The behavior, however, limits communication to same-domain.

It's worth noting that not all requests are preflighted. Please refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests for more details.

An API expects, if properly configured, a proper Content-type header and an authorization header which in most cases is Authorization. If a request sets a "forbidden header name" or an unsafe Content-type, it's always preflighted. And as such, no other domain would be able to send an authenticated request at all.


Is it possible to get data from database server if you are on the application server?

In short : Possibly

On the one hand yes, this is a very real risk. With many ordinary application installations and database deployments, this vulnerability will indeed let you access the data.

On the other hand, no, an attacker can be blocked even at this stage. There are a number of techniques to mitigate this risk. For example:

Limited Privilege on OS. The arbitrary commands the attacker is executing on the application server must be executed with a particular user's credentials; if the user account has been configured in accordance with the Principle of Least Privilege, the user account may not have the authority to execute those arbitrary commands. Ideally, the user account will have permission to run the application but do absolutely nothing else.
Note: SELinux is a powerful technique for further limiting access to OS resources.
Limited Access to DB. Even if an attacker discovers the database credentials, they may not be much use. The database may be configured so these credentials are only valid for that application; so they cannot be used to connect to the database via any other tool. Or, the database may be configured so these credentials are only valid from this one client address; so all the attacker's db connections have to be tunneled through the database server, instead of from the attacker's own system.
There are no stored DB credentials. An application may be designed so that the user enters their credentials at login, for example, and these are used to access the DB. In this situation an attacker on the application server could not connect to the DB, no matter how much OS-level control they have.
DB credentials are stored elsewhere. An application may be configured so that it fetches the DB credentials from a separate service at runtime; this separate service may not allow connections except from the application itself.

Further note : these techniques are not exclusive, so combining them may be a powerful way of limiting an attacker's access. However, each one of these techniques require sophisticated non-default configuration, and a naive deployment is likely to miss out every single one.


Is using both client side certificate and JWT for IoT device redundant?

Only reason you need the additional JWT is if there are going to be different claims and identities being used with the devices that require seperate privileges.

Now as this is IoT do you have a way to revocate and update certificates? Are you able to handle all the required certificate operations?


The server should never even attempt to decrypt the message.  If the HMAC keys are different between the server and the client, the authentication should fail (the server won't be able to create the same MAC from the ciphertext and the server key, since the server key is not the same as the client key, and the process should abort.

Now, if you're doing something sub-optimal like MAC-then-Encrypt, or MAC-and-Encrypt, you have other issues, but you still won't be able to authenticate the plaintext since neither the plaintext nor the MAC will match, and you should know at that point that you have a problem.


Is it safe to use the free Cloudflare SSL certificate since it's shared with other domains?

The web application hosted on mydomain.com or at app.mydomain.com (also secured with its own SSL certificate) can be somehow be in dangerous by the owner of malicious.com because he has access to the same SSL certificate shared by mydomain.com?

The owner of the malicious domain has no access to the private key certificate served by Cloudflare and neither do you. The certificates for the free accounts are owned by Cloudflare and only Cloudflare has access to the private key of the (shared) certificate.

It is also not a problem that you share the same certificate and/or IP address with a potentially malicious domain. The same origin inside the browsers only cares about domain names, not certificates or IP addresses and thus it is not possible to get access from the malicious domain to your domain. The usual CSRF, XSS... attacks of course still work, but these are not related to same certificate or not but to security problems of a specific web application.


Is this a serious vulnerability? Semi Information Disclosure

You are right in that is an information disclosure, someone can easily discover valid usernames and then try and crack their security. If I was the site owner I'd like to know about it. Ideally you would notify the site owner, they may have an email address for that or a contact us link you could use.

The one caveat is that some places have misguided anti-hacking laws which make even ethical hacking illegal. Germany is an example although in practice they don't seem to be chasing people for performing helpful acts. It's highly unlikely that any negatives would come from this, and who knows, they may even send you a t-shirt or pay your a bug bounty.


How to justify a Vulnerability Research function at a company

Seeing as you work at an infosec company, one word; prestige. Blog posts about discovered vulnerabilities are gold in the sphere of commercial information security.

The root cause analysis gives the company the ability to showcase their expertise in one of the most respected areas of the field. Also, as someone who has found a few inconsequential  CVE's, I'm inclined to say they work wonders for the credibility of the finder when it comes to approaching customers. If a restriction is that vulnerabilities found on company time must be disclosed under the company name, it will provide invaluable proof your company is on the frontier. For a Fortune 500 this is highly desirable, and others are doing it too. Businesswise the impact of the CVE is not that important; the people that hire you might know what a CVE is, but they're ususally not the type to say "oh this is just small game". So throw some obscure debian package into AFL, some obscure media format into Peach, hone your gdb/WinDbg skills and make a name for yourself.


Why are Let's Encrypt certificates accepted by default by browsers?

I think you are misunderstanding what a SSL certificate actually certifies, and what it is designed to protect against.

A standard certificate only certify that the owner of the certificate actually controls the domain in question. So a certificate for g00dbank.com only certifies that the owner controls the g00dbank.com domain. It does not certify that the owner is a bank, that she is good, or that the site is in fact the well known Good Bank Incorporated.

So SSL is not designed to protect against phishing. Just because you see the green lock up in the left corner does not mean that everything is well. You also need to verify that you are on the correct website - that you are on goodbank.com (as opposed to the phishy g00dbank.com) and that goodbank.com is in fact the website of Good Bank Incorporated.

To make this easier for the average user, there is something called Extended Validation (EV) certificates. These also verify that you are the legal entity that you claim to be, by requiring you to do some paperwork. Most major browsers highlight them by displaying the name of the owner in the address bar.

So to get an EV certificate the phishers at g00dbank.com would have to start a real business (thereby leaving a paper trail), and even then they would probably not get one because their name is to close to a sensitive target.

Lets Encrypt does not issue EV certificates. They issue ordinary ones. But the phishers you encountered could have gotten a certificate from anywhere. In fact, as IMSoP points out in comments, the method Lets Encrypt uses is employed by many of the established CA:s as well, the only difference being that Lets Encrypt is more efficient and cheaper. So this has nothing to do with Lets Encrypt specifically, and blocking them would solve nothing.


How vulnerable are passphrases with grammatical structure?

The major finding of the paper you linked is that grammatical sentences do not have the entropy you'd expect from sentences of that length. A reasonable response to that would be to just not count the words you're adding to make the sentence 'correct'; choosing one of your examples a harpoon might expertly staff our ratios should be considered about as strong as harpoon expertly staff ratios.

If you're looking for maximum password strength; you should also avoid words that follow grammatical rules, from the paper:

  Grammatical structures, or tag-rules, split the password search space unevenly; the size of the search space of individual tag-rules are diﬀerent e.g. the size of “Noun Noun” is greater than the size of “Adjective Noun”.

Implying that you should avoid 'adjective noun' to maximise your entropy. This is true even if your algorithm generates them randomly, as the structure functions to compress the password. It's also worth noting that the paper didn't look for pairs that made sense together (watery scissors would have been tried).

The point in the paper of choosing common words first wouldn't decrease its effectiveness against random, but approximately correctly formed, sentences; you can always design your dictionary to distribute words randomly by frequency. It's not so much that they try common words first, but that they try groups that are often seen together, together.

There has also been some research on the Markov model you suggest; it may be worth running that sort of analysis over the password you generate before presenting it to the user?

You may find the answers in this related question of interest.


A firewall is just some device or software which filters the network traffic. This can be done at the packet level (usually called packet filter firewall (PFL) or layer 3,4 firewall) but also at the application level (usually called application level firewall (ALG), secure web/mail gateway (SG, SWG...) or similar). You'll often find both PFL and ALG technologies in modern firewalls, i.e. some filtering is done at the packet level and some at the application level.

With a packet filter the filtering is done based on properties of the packet at layer 4,3 or even 2 (i.e. Port, IP, Mac). With application level firewalls filtering is done on the content of the application layer, i.e. URL, type of the content etc. For example pure packet filters cannot block malware by its content while application level filters can do it. But pure packet filters can block download of the malware if the IP address (not hostname!) is known to propagate malware and thus communication with this IP address can be simply denied.


Would Qubes still be secure on an untrusted machine?

In a theoretical sense, no, if you can't trust the computer then you can't trust Qubes. Just as an example of theoretical attacks the computer could record your keystrokes, your screen, mouse clicks, install infected version of qubes rather than the one you supplied, manipulate Qubes (via the same input channels you would use) and so on. On the practical side your biggest concern would be something like a hardware logger, where the keylogger is a piece of hardware rather than software. I have not personally seen malware that can survive an OS wipe and continue to monitor Qubes.


E-Mail privacy proxy for hiding real e-mail?

In GMail, you can use disposable emails of your own by just adding "+" and any string following it.

Eg:

john.doe+newsletters@gmail.com
john.doe+forums@gmail.com


How can I make sure that my Python code cannot be accessed by the user of my web app?

If you want to protect the program, then running it as a service, rather than distributing the code is a normal way to go about that.

Make sure you know how to properly secure the service though and that you properly secure the data in transit, and consider availability issues (performance due to load/distance from the user; what happens if it does).

There is a lot more to protecting a service than throwing it on a server somewhere and making it available very a a RESTfull/SOAP interface. If I had more background I could give you a better suggestion on what you would need.


How does iOS 10.3.3 know when a scammer calls?

https://www.payetteforward.com/iphone-scam-likely-why/ has a good explanation.

"Why Does My iPhone Say “Scam Likely”?

Your iPhone says “Scam Likely” because your wireless carrier introduced a new feature called Scam ID or Scam Lock that automatically changes the caller ID from the phone number to “Scam Likely” if the number calling is a known or suspected scammer."


What's the point of providing file checksums for verifying downloads?

It allows distribution of the bulk data through untrusted channels.
For example, you could give me an USB stick and ask me to download it for you over night using my cheap DSL connection, while you get the checksum off the webpage (that you pulled up on your laptop with an expensive metered connection). I recognize the file name, look into my "large files I have downloaded already" folder, and there it is, so I copy it onto your USB stick.
You get the file instantly, and you don't have to trust me for this to work.


Dual Code Signing: Should SHA-1 signature have a SHA-1 or SHA-2 timestamp?

What the correct answer is depends on your threat model.
If you consider SHA1 to be secure and are worried about compatibility you should use two SHA1 signatures and two SHA256 signatures.

This will allow a verifier to check your SHA1 signature while your cert is valid and check the SHA1 signature of the CA if it is no longer valid.

However, if you are worried that the SHA1 hash might be forged it might make sense to use SHA1 with SHA256 for the extra signature. This way when your certificate becomes invalid the stronger SHA256 signature will be required.

Note:

I'm not sure what the correct term for this kind of additional CA signature is. "counter signature" seems weird to me.
This scheme means that if you revoke your certificate because you got hacked the extra signature will still attest that at the time of signing your certificate was valid. I'm still not sure how you would revoke the signature in this case.


If what you describe is true, your chat room is designed badly.

The view of the server and what packets it receives should be forwarded to other users should be independent from whatever packets are coming in or going out.

Manipulating the traffic on a client should only interfere with that client's view of the chat room, never with other clients.

If you designed that differently, you are trusting on the clients to behave correctly.

You should never do that.

Misbehaving clients (those not behaving according to your rules) may create even bigger problems for you than people not being kicked. Here are a few examples of things that may happen without proper input validation:

Users may impersonate other users, leading to massive trust and confidentiality breaches
Users may gain rights they otherwise wouldn't have, being able to hold your service for ransom

Side note here:

There are many web clients for IRC that are easy to deploy and many IRC networks that let you host channels for free. Have your pick and rely on a thorough platform for chats.


Proxy not rejecting illegal host header when coming from my VM provider's network

$host will be set to $server_name if the client does not provide a Host header value in the request. You should use $http_host to access the pure Host header.

See this document for details.


Let's say you want to be able to SSH into your server from anywhere.  But you find that if you leave SSH listening on port 22, systems all over the Internet are regularly trying to log into it and filling up your logs with auth failures.  You are offended by this.

So you set up port knocking.

Your firewall blocks access to port 22 - but if packets come for ports 1234 and 5678 in the space of one minute, your firewall will open access to port 22 for a brief window.  Therefore, your SSH server is safe from random people (who won't know how to "knock" to open the port) but you can get in whenever you want by sending a couple of special packets before connecting.

In this scenario, ports 1234 and 5678 aren't listening, there's no service running there - the special bit is that the firewall notices attempts to reach those ports and does something accordingly.

As security goes, this is minor; it's a form of security through obscurity, and only offers incremental benefits.  It can be useful in cutting down noise from automated attackers, though.


Sub-domains TLS certificates and wildcard certificate

It is more relevant how much the private key for a certificate is at risk than if the certificate contains multiple domains (either as subdomains or as wildcards) or only a single domain.

For example, if you have multiple machines with each machine having their own subdomain, then the risk is lower if you have separate certificates with their own private key on these machines instead of using the same certificate and private key on all these machines. If instead you only have a single machine serving all these domains then it does not really matter.

Using wildcard certificates by itself is a larger risk since more subdomains are affected if the private key is compromised. But apart from that it is similar to single vs. multiple subdomains per certificate, i.e. it mainly matters how well the private keys are protected.

If instead your private keys are kind of easy to get stolen in the first place then having only a single domain per certificate can considerably limit the impact of a stolen private key. But if such easy compromise is possible then you should probably start improving the security of your private key first.


What are the only possible cases for DB injection?

It would suffice to say - as for both of your case no. 1 & case. 2 to be that of input sanitisation problem. Pre-liminary to that of input sanitisation, there's input validation - this could be white listed or black-listed. The black listed approach is not preferred.

Now let's narrow down to the answer, it's just not data conversion, parsing of data, transformation of data or just rendering of data from another source which's the point here; the other sources could be data manipulation where you confuse the logic of the data handler.

Some examples could be basic authentication bypasses, others still could be LDAP variants of injections. Possible causes of DB Injections in your case should be lack of input validation, lack of input sanitisation, lack of escape sequences, lack of string-concatenated SQL queries, also lack of access control through policies which accesses various tables.

This could happen from different perspectives to gain an escalation; Let's discuss about some:

Internal domain controlled SQL Databases - internally invoked which is due to lack of policy set-up.
Externally targeted web applications due to lack of input validation on top of input sanitisation.
At the handler tier of the DB-driver itself where-by an attacker confuses the db-handler to think it's the authenticated user & privileges are granted.

Some myths are:

Whitelisting will be hack-proof - it won't be as letting end-user supplied input be elevated to the same level as the command structure. Consequently, while whitelisting is part of any viable defense-in-depth approach to security, it's still not sufficient enough to protect against SQL injection on its own.

Stored Procedures will make it really hack-proof - while the proper use of stored procedures provides fantastic protection against SQL injection, there's nothing magical about stored procedures that prevents them from being used incorrectly or unsafely; developers make implementation mistakes.

Strict Input Validation, Escape Sequences & Input Sanitisation would suffice - combinations of encoding tricks, escape routines, homoglyphs, and uncommonly used Unicode and ASCII characters as a means of trying to compromise overly simplistic string-replacement routines defined by developers who don't think like hackers will fail, repeatedly.

Basically user input is the root problem set & hence command language is properly separated from data or user input & there you will be clearly be making a strict standard for SQL DB's to be safe.


How do I determine the algorithm used on an encrypted string?

The string you've posted is UTF-8, which translates to 24 09 16 38 12 16 46 29 in hexadecimal or JAkWOBIWRik= in Base64 encoding.

Now that you know the binary data in Base64, you can refer to this answer by Thomas Pornin which explains it rather well.


How to Choose and adopt information security model

I would suggest that you have a look at the ISO27000 series - these documents act as a framework for information security.


What are some strategies to detect and prevent vulnerabilities
introduced by third party libraries?
How would you demonstrate to a customer why it is important to fix
reflective cross-site scripting flaws?
How would you demonstrate to a customer why MD5 is not appropriate
algorithm to use when hashing passwords?
What scripts or tools have you written to assist you in pen-testing
applications?
How would you advise a customer to fix a CSRF issue that you found?
How would you get around a web application firewall that is blocking
your attacks against a vulnerable application?
Your customer hasn't noticed any of your intrusion attempts.  What
would you advise?


The default settings for most VMs will be sufficient for keeping everything isolated, that's what they're designed for.

The specific settings might be a little different depending on what software your're using, but here's a few things you can check in your VM's settings to keep your computer safe:

Disable file sharing, shared clipboard, and Drag'n Drop
Set a cap for memory and processor usage, and virtual hard drive size
Make sure your network settings are set to disconnected or NAT
Make sure all your serial and USB ports are disabled/ not shared
Check that printers and other wireless devices associated with your PC aren't shared


Questions

  If an attacker manages to get hold of a JWT, will this not enable them to use the API as if they were the user that had originally authenticated?

Yes. Same thing as if an attacker manages to obtain a users session id. However, this is why you want to limit the lifetime of JWTs.

  I was thinking of including an expiry timestamp in the payload so that the user had to log in occasionally. Is this the correct way of expiring the JWT?

Yes. Plus you might want to add a revocation mechanism. This article provides a good introduction on the subject: https://stormpath.com/blog/token-auth-spa/


You can use window.opener to exploit this (fiddle):

test

Or if you can escape the attribute value context, you can start a new script tag or a new attribute like onMouseEnter.


signatureAlgorithm vs. tbsCertificate -> signature

Both fields should be identical. The redundancy was apparently meant to defeat an obscure attack vector relying on weaknesses that existing signature algorithms do not have, and for unspecified goals. As Peter Gutmann says in his X.509 style guide, when talking about the signature field in the TBS:

  There doesn't seem to be
  much use for this field, although you should check that the algorithm
  identifier matches the one of the signature on the cert (if someone can forge
  the signature on the cert then they can also change the inner algorithm
  identifier, it's possible that this was included because of some obscure attack
  where someone who could convince (broken) signature algorithm A to produce the
  same signature value as (secure) algorithm B could change the outer,
  unprotected algorithm identifier from B to A, but couldn't change the inner
  identifier without invalidating the signature.  What this would achieve is
  unclear).

A sane implementation of X.509 certificate validation will use the outer field (signatureAlgorithm) to verify the signature, and will just check afterwards that the inner signature field matches the outer field (but failing to do that last verification will not actually harm security).


Is the range of the s2k-count parameter in GPG still adequate?

The default today is half the minimum recommendation from 20 years ago.*

The specific key strengthening algorithm used is Salted and Iterated S2K, which combines the input password and the salt and repeats it numerous times, hashing the concatenation. The actual count value you are using is the number of bytes to continue hashing, so the highest possible value hashes only around 65 MB of data. The default of 65536 is indeed fairly low. Each SHA-256 hash block is 64 bytes in size, and PBKDF2 uses the HMAC construction which calls SHA-256 twice for every iteration (processing 128 bytes), so the default strength is equivalent to only 512 invocations of the hash function! Obviously any KDF that uses that few hash iterations is not going to be particularly secure. The maximum value of 65011712 is equivalent to more than 500,000 hash iterations, which is better.

The problem is not only that the value is too low, but that it is not memory-hard. This means that it's very easy to massively parallelize cracking attempts without running into memory limitations. This is the same issue that PBKDF2 has. A proper alternative would be a memory-hard function like Argon2, but GnuPG does not support that. It is unfortunately limited to S2K. You must use a stronger password.

* I am comparing PBKDF2 and S2K. The minimum recommendation of PBKDF2 iterations was 1k in 2000. If each iteration is equivalent to two 64-byte SHA-256 hashes, then we can consider the S2K count divided by 128 to be approximately equal to a single iteration of PBKDF2. As such, 65536 / 128 = 512, about half the recommendation from 2000.


Is there a secure way to run a bat file from a Java program without command injection vulnerability?

I'm not really familiar with Java but I've seen the same problem with other languages. The issue is that when exec is called with a string the OS shell need to be involved it needs to parse the command string into the command and arguments. Although this is not done by letting the OS shell do the splitting as in many other languages like Perl (thanks for dave_thompson_085 correcting me) it nevertheless can have unintended results since the splitting is done simply by white-space and does not care about quoting or escaping. For example if the intended argument in constructing the command is a user defined filename, the user might provide a filename containing spaces which will be split into multiple arguments then although it was intended as a single one. Depending on what is actually executed this might also lead to unintended command injection. This is similar to SQL injections which can happen when constructing SQL statements from user input or with XSS and other kind of code injections.

The solution is thus the same as with parameter binding to defend against SQL injection: make sure that no parsing need to be done by the shell to extract the arguments by providing the relevant parts already parsed. With exec this means to not give a command string but instead a command array, i.e. something like this (nur sure if the explicit cmd.exe and /c are actually needed):

String[] cmdArray = new String[3];
cmdArray[0] = "cmd.exe";
cmdArray[1] = "/c";
cmdArray[2] = "C:\\batFile.bat";
Runtime.getRuntime().exec(cmdArray);

See also Stackoverflow: How do I run a batch file from my Java Application?.


This depends on model you use for group chat:

Peer-to-peer: You need to encrypt each message with the recipient's puiblic key and send it to each user separately, and create the "illusion" of a group chat.  This will prevent new group joiners to see previous messages.
Client-Server: You upload the messages "signed" to the server, and encrypt them to each user.

Alternatively, you create a key pair for this "group" and send a copy of the private to all members of the group, but I'm sure you see the problem with that already.


You can check the implemented data protection of any application yourself.
on a jailbroken phone use cycript to attach to SpringBoard (or any other process)
eg:

cycript -p SpringBoard

and run the following script inside:

A cycript script to list the FileProtection class of every file in a given path

?expand

var path=@"/var/mobile/Library/Preferences/";
var fm = [ NSFileManager defaultManager ];
fin = [ fm enumeratorAtPath:path ];
ps= [] ;
while (name=[fin nextObject] )
{
 fPath=path+name;
 pClass=[[ fm attributesOfItemAtPath:fPath error:nil ] objectForKey:@"NSFileProtectionKey" ]
 pName=name
 ps.push(""+pName+":"+pClass+"")
 }
 ps.toString().replace(/,/g,"\n");

on a 5.1.1 iOS i got these results for Stocks application and for youtube application:

com.apple.stocks.plist:NSFileProtectionNone
com.apple.youtube.dp.plist:NSFileProtectionComplete

On a 6.1.2 iOS device things didn't look different:

com.apple.stocks.plist:NSFileProtectionNone
com.apple.youtube.dp.plist:NSFileProtectionComplete

you can try running it on your device and see what has changed on other versions

@_coreDump


Should an access token reflect the current user roles?

There is not necessarily a right answer to the question. It is really easy to say "of course they should" and somewhat harder to make it happen.

Given that you set a token with claims rather than just an identifier there is an assumption that you do not want to contact the authorization server every time the token is received. This means you have to respect the validity / expiry of the token.

If you don't mind contacting the authorization server with every request then you don't need to set the claims in the token, you can get them from the server every time and they will always be up to date.

OAuth is usually used between multiple parties and you might control between 1 and all of them. How many you control may affect what you can and can't do. Token revocation is not possible without an additional request to the auth server


Certificates are signed and the cryptographic signature is verified; if the signature matches then the certificate contents are exactly as they were when the certificate was signed. This, of course, does not solve the problem, it merely moves it around. The complete structure is called a PKI. The certificates which are preinstalled in your computer (came with the OS or the browser) are the root CA certificates, i.e. the public keys that you know "a priori" and from which you begin all the signature verification process.

To make the story short, if some hostile entity could insert a rogue root CA in your computer, then you lose. Of course, under the same conditions, the same hostile attacker (e.g. a virus) could alter the code of the browser and hijack your data from that, or log all your key strokes, or more generally completely bamboozle you in a zillion ways. When a virus executes on your computer, you are already beyond redemption.

Inserting a fake root CA is, in fact, a rather poor way to attack people, because they may notice it. Injecting a data snooper right inside the entrails of the browser does not require much additional effort, can be done within the same conditions, and results in a much more complete and discreet destruction of your security.


Secure REST API and Single Page App by using external OAuth 2 Authorization Code

Firstly, and to be very clear, OAuth 2 is not an authentication protocol. If you wish to know the identity of the user, there are other protocols designed to solve this problem, such as OpenID Connect. If you intend to use OAuth 2 for the purpose of authorizing access to your protected resources, continue reading.

To answer your direct question: you appear to be using the Authorization Code Grant flow:

 +----------+
 | Resource |
 |   Owner  |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier      +---------------+
 |         -+----(A)-- & Redirection URI ---->|               |
 |  User-   |                                 | Authorization |
 |  Agent  -+----(B)-- User authenticates --->|     Server    |
 |          |                                 |               |
 |         -+----(C)-- Authorization Code ---<|               |
 +-|----|---+                                 +---------------+
   |    |                                         ^      v
  (A)  (C)                                        |      |
   |    |                                         |      |
   ^    v                                         |      |
 +---------+                                      |      |
 |         |>---(D)-- Authorization Code ---------'      |
 |  Client |          & Redirection URI                  |
 |         |                                             |
 |         |<---(E)----- Access Token -------------------'
 +---------+       (w/ Optional Refresh Token)

This flow is optimized for confidential clients: clients which can keep a secret from the end-user and any third-party that might be trying to gain access to the protected resources. In the case of a javascript application running in the client's browser, you cannot keep a secret - all the code is there and simply breaking into it with the browser's debugger reveals all the secrets.

Instead, there is the Implicit Grant flow, specifically optimised for clients like yours. The RFC even uses JavaScript running in a browser as its example of a client intended to use this flow.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier     +---------------+
 |         -+----(A)-- & Redirection URI --->|               |
 |  User-   |                                | Authorization |
 |  Agent  -|----(B)-- User authenticates -->|     Server    |
 |          |                                |               |
 |          |<---(C)--- Redirection URI ----<|               |
 |          |          with Access Token     +---------------+
 |          |            in Fragment
 |          |                                +---------------+
 |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
 |          |          without Fragment      |     Client    |
 |          |                                |    Resource   |
 |     (F)  |<---(E)------- Script ---------<|               |
 |          |                                +---------------+
 +-|--------+
   |    |
  (A)  (G) Access Token
   |    |
   ^    v
 +---------+
 |         |
 |  Client |
 |         |
 +---------+

You should read the RFC for details of how this flow works, but the general concept of the flow is to no longer require the use of an authorization code; instead the client is directly given the access code.

This comes with the drawback that when the code is no longer valid, the client must request the resource again - there is no way to "remember" the authorization grant for a client which is unable to keep a secret. This is an intentional decision made by the OAuth authors to improve the security of clients of this nature.


This could be achieved in a relatively secure manner with two cookies.

One has the Secure Flag set, and will contain your HTTPS session details and is used through out the checkout process when making a purchase. The Secure Flag ensures that the browser only sends the cookie over connections protected by SSL/TLS (i.e. use the HTTPS protocol).

The other does not have this flag set, and will store the HTTP session details. The session details stored on the server side could be items viewed, or if you have previously logged in it could tie your session up to an account. This is what would be used when the site says Welcome John when you return without logging in.

For this to work, there should be no way of determining the secure session cookie value from the insecure one.

The insecure cookie could be used up to the point of entering the checkout or the account details pages, where a login over HTTPS is then required where the secure session cookie is then set. This would stop a MITM attack from obtaining the cookie, as if an attacker stole the insecure cookie the worst they could do is alter the browsing history of the user, or add/remove things from the basket. If it was implemented in this way it would be assumed the user would check that the basket items copied to their secure session are the ones they actually wanted to order before completing checkout (or that they read their confirmation email and cancel items later).

It is not clear from your question whether your instructor is referring to the sending of plain text cookies carefully using good practise like the above, or as a bad example of how not to do it. If the latter, many websites do in fact only protect certain pages such as login and card details pages with HTTPS, but then go on to use the same authentication or session cookie over HTTP pages too, not realising that this cookie value is sent in the clear and can be read by a suitably placed attacker.


Can standalone malware survive on current mobile devices?

Yes. Just about every security feature of mobile operating systems is implemented in software. Complex software like that can will have bugs. Some of these bugs will be exploitable to give unauthorized access. This applies to any sufficiently complex software, because programmers are no more superhumanly perfect than anyone else.


Why stack is not at the same address when exec running in GDB

The difference is very likely due to differences in the environmental variables of the process when the program is run with gdb  compared to when it is run outside of gdb. Since environmental variables are stored on the stack, this can affect the memory locations.


1: You should scan everywhere a wireless client in-scope may reach, but also everywhere near all locations that are in-scope. Outdoor scans is not neccessary if you don't also have wifi clients operating outside, like in-scope workers being on the outside locations with their laptops and surfing. But a scan along the inside of the perimeter of the PCI DSS zone is a must, but also somewhere in the middle regions so you don't miss out a AP that transmit weakly in the middle.

This effectively means you also need to, if you have remote workers:

Implement a mandatory VPN or encryption, that cannot be turned off by the remote workers, that will take the airspace out of scope. Note that its not enough to just enforce VPN/encryption while working with card data, as a malicious individual might insert malware while the computer is off-VPN. This method will mean captive portals will not work. (WLAN encryption does not count)
OR, Programmatically disable the wifi card on remote workers using some device management, while they are off-site.

Else, every location that the device visits, effectively becomes in-scope. Good luck enforcing PCI DSS for a hotel lobby or hotel room.

However, self-service locations as you say, does not neccessary need to be scanned. If you make the solution P2PE (Point-to-Point Encryption) and UPT (Unattended payment terminal) approved, and ensure the personell at the self service location does NOT have access to encryption keys, you have taken the local end of the self-service location off-scope, and no Wifi scan is neccessary. However, the actual P2PE/UPT terminal is still in scope.

You need to think "What happens if someone puts a rogue access point here - eg a malicious access point, that either distributes malware, or steals data, and tricks a machine or human to connect to it, perhaps by having the same SSID". Same with a malicious individual that inserts a access point in the in-scope network.

2: A PC with decent wifi will work, but you also need tools that allow you to record or monitor the MAC adress of the AP, and also watch all access points reachable (eg multiple access point with same SSID should not be consolidated into one). You also need a decent antenna, as a built-in antenna in a laptop might be not enough to detect APs far enough away.
You need to prepare for the worst, like a worker putting a decent antenna and accesses a rogue access point.
The solution must also be able to record P2P access points, so a Android mobile is not sufficent, as viewing P2P access points on a android requires root.

And to elaborate your question/answer too:

You also need an action program, IF a rogue or unauthorized AP is found. For a unauthorized AP, its easy as just tracking it up and then disconnecting it from your network. (unauthorized AP = a AP that is connected to a network without authorization from the network admin, regardless of SSID)

A rogue access point (which is defined by a access point having the same SSID or MAC as an "authorized" access point, but may be located anywhere) is a bit more difficult to deal with. As a rogue access point might not be in your network/facilities at all, it might be at the neighbor's facilities, you may need to resort to legal actions to get rid of that. You could begin tracking it, and when its rough location is located, send a cease and desist letter to the manager of that building, and even send FCC or Police on that location.

Naming a AP same as a someone involved in payment cards, in an effort to get those to connect to that, its a clear computer misuse violation and could be classified as fraud too.

Another solution may be spoofing deauth packets for that rogue access point (some rogue AP scanners can do this automatically after detecting a rogue one) to prevent a authorized in-scope client from connecting to the rogue one, but this may have its own legal complications, as you are interfering with equipment you don't own or have authorization to operate.


SSH most common symmetric encryption algorithm in 2018

It's an unknowable question as asked. There are too many servers in too many data centers to know the most common. You could guess and even take an inventory of every ip on the internet based on defaults and even query the servers themselves. But that excludes internal systems - of which there are many many thousands.