Appropriate response to 2014 Russian Security Breach (CyberVor)

The report is authenticated at Russian Hackers Amass Over a Billion Internet Passwords - NYTimes.com.  But much remains unclear, and even the times didn't note the conflict-of-interest that Hold Security is setting up by speaking in scary but unspecific terms about this, and only offering their own paid services to help victims out, as you allude to.

I'm surprised that there is no discussion of the importance of properly salting and slowly hashing passwords before storing them in password databases, as discussed here at 'passwords' tag wiki.  If a site does that, and the passwords are strong, a hacker couldn't learn the passwords just by downloading databases from the web site.  They'd need to modify the web site authentication code and capture passwords interactively as users log in.  They would thus only slowly get the passwords of active users, and that kind of attack on a site is much more likely to be noticed.

But of course many web applications don't follow even these basic practices, as discussed for example at cryptography - Looking for example of well-known app using unsalted hashes

End-users should use this and other reports of web site hacking to motivate them to be careful about which web sites they interact with, and to be smart about how they deal with passwords.  Using web sites that support the use of a well-protected web sign-on service that requires two-factor authentication is better than working with a less-well-resourced web site that manages their own password database.  See also techniques for dealing in a sane way with a large password portfolio at How to help users manage password portfolios based on risks of compromise? - Information Security Stack Exchange.

If you've re-used passwords for important sites on other sites, you could benefit from changing those passwords, e.g. if the important site is not vulnerable, but another one with the same password has been hacked.  But since many of the sites with problems remain vulnerable, just changing your password now on one of those may not help much.  And as noted in the password portfolio discussion, changing passwords for sites where you really don't have any information or assets at risk is far less important.


When I find a vulnerability for a product that is not handled by a CNA (CVE Number Author), I apply for a CVE before notifying the vendor.

My reasoning to do it this way, is that now I can ask the vendor to make reference to the CVE in the security advisory/release note. And in turn, the CVE can now make a direct reference to the vendors security advisory/release note.

For the second question, I do not believe the confirmation has to come from the vendor in question. If that was the case, one would not be able to issue a CVE for products that are no longer maintained.

Remember, the purpose of a CVE is to uniquely identify a specific vulnerability. Imagine how two different vulnerability scanners would identify the same vulnerability if there was no common reference for it. It would leave you uncertain if you are affected by one or two vulnerabilities.

So any published material that describe or confirm a vulnerability could be used, as long it is capable of providing enough details to uniquely identify it. In contrast, if a vendor acknowledges a vulnerability, it is beyond doubt that the vulnerability exists, without having providing intricate details that could put others in immediate risk.


How to prevent IoT devices from phoning home via the neighbor's wifi?

It's worth noting that most IoT won't have much to phone home about. You mentioned a few devices: TV, pencil sharpener, and mouse. Unless these devices were specifically created with extra mics, cameras, etc as intentional spy devices, the information they would hold about you would be negligible. A mouse records movements on a table, and clicks. It has no context of where you are moving it, and what it is clicking on. A pencil sharpener would know nothing except that it was being used as a sharpener. The TV would possibly have more information, but still limited, unless it takes voice commands or something, and has a mic. If you have top secret things to be concerned about, then create a safe room for those things. Life is too short to be afraid of pencil sharpeners. If you have doubts about what's in a device, take it apart to look.


What type of probing sends GET /" data " to a server?

A GET / may return a default page or a directory listing which can give a lot of extra information to the caller. A default page, in particular, can be used to work out the exact software versions (OS, HTTP server...), which helps in knowing what known vulnerabilities may apply. A directory listing may, in turn, reveal some juicy sub-directories.


What is the correct way to remove bitlocker secrets from a TPM when returning a device for warranty?

Windows Refuses to Part with Bitlocker Secrets it Relies on to Boot

I did not find any official documentation from Microsoft for how to clear bitlocker secrets from the TPM without a copy of the secret being written to the volume in cleartext.  I tried to delete the bitlocker secrets using commands running within the instance of Windows the secrets were protecting.  Every effort I made to do so failed.  It seems you can clear the secret from the TPM, but only once that secret is written to the volume it is protecting in cleartext.  I suppose this is to prevent TPM users from inadvertently ending up in a state where they cannot unlock their bitlocker-protected system volume.

In other words, any given Windows installation refuses to part with the bitlocker secrets it needs to boot.  I really wish I could find some official guidance on how to correctly clear bitlocker secrets from a TPM that is physically attached to the storage it is protecting.  This arrangement is common on many modern tablets and notebook computers, but I couldn't find any published best practice for decommissioning such a device.

It Seems like Another OS Installation Can Clear the Bitlocker Secrets

I did determine that it seems another OS installation that boots on the same computer can clear the TPM.  If that is the case, clearing the TPM of its secrets without them being written to the volume in cleartext should be achievable by booting to another OS and clearing the TPM from there.

Premise and Procedure

Note: I am neither expert at Windows security, nor am I knowledgable enough about the inner workings of TPMs or bitlocker to confirm that this premise is correct or this is an effective procedure.

This procedure is based on the following premise:

When bitlocker is enabled in TPM mode the only copy of the bitlocker secret on the device resides in the TPM.
When an operating system not protected by the TPM is booted on the device, it can clear the TPM without accessing the secret in the TPM.

If the above premise and my reasoning is correct, the procedure to completely clear the bitlocker secrets from the device is as follows:

Boot to the instance of Windows protected by bitlocker.
Ensure that bitlocker is "on" for all drives.  (If bitlocker is not turned on, then either the data on the drive or the secret that can be used to decrypt the data is in cleartext on the drive.  If that is the case, this procedure won't help you.)
Shut down the computer.
Boot the computer to another OS without entering the TPM pin.
Clear the TPM from the OS you booted to in step (4).


How secure is the Ciphersweet library for searchable encryption, and why is a duplicate entry leak not a problem?

Important Disclaimer: I wrote CipherSweet for my employer. Everything that follows should be taken with a grain of salt unless otherwise verified by third party security experts. Even if this answer gets a lot of votes, it must never be accepted. I'm merely attempting to answer some of the basic questions about CipherSweet's design, not answer whether or not it's secure. Trust others instead.

The security model of CipherSweet is essentially a time-memory trade off, which introduces the risk of attacks that are more similar to a crossword puzzle than traditional cryptanalysis techniques (hence, we simply refer to them as "crossword puzzle attacks", although the more formal term "partially-known plaintext attacks" is more likely to find relevant hits in the academic literature).

In this respect, CipherSweet's overall design can be secure, but only if care is taken in designing the blind indexes in your application. There are a few considerations:

How many bits of each blind index will you store?

Fewer bits increases the chances of collisions on a given SELECT query, which means more false positives to filter out after decryption.
However, fewer bits also decreases the usefulness of a blind index.

How many blind indexes will you create for a given encrypted column?

The more indexes you create, the more metadata you risk leaking to attackers.

Of course, the security of this design is only worth talking about if a few other assumptions hold true:

Each blind index has a distinct key.
The hash function (or KDF) used to turn the plaintext into a blind index is adequately secure (e.g. in the random oracle model).
The encryption itself is secure (e.g. AEAD with a security level in excess of 127 bits against all known practical attacks).

To understand how these assumptions are answered, take a read through the CipherSweet internals documentation. But in short, the answers are:

CipherSweet uses distinct per-field and per-index keys, derived from a master key.
As of November 2018, HMAC-SHA384 and BLAKE2b remain unbroken.
As of November 2018, AES-CTR + HMAC-SHA2 and XChaCha20-Poly1305 remain unbroken.

So with that said, the unanswered question is: How do we determine an unsafe level of information leakage?

Obviously, creating a distinct blind index $plaintext[0], $plaintext[1], ... would leak entire plaintexts from the indices.

You wouldn't need to break the encryption in this case. Just study patterns and commit dummy entries and treat it as a very inefficient substitution cipher.

Conversely, a single literal blind index of the entire plaintext, truncated to 16 bits, would almost certainly not leak anything useful for attackers.

Given a sufficiently large dataset, collisions would be very common.
Of course, this almost defeats the purpose of even creating a blind index.

Furthermore, CipherSweet allows you to create compound blind indexes. For example, you could hash together:

The first initial of the person's first name (if applicable)
The first initial of the person's last name (if applicable)
The last 4 digits of the person's social security number
A single letter identifying their sex/gender (if applicable)

This greatly increases the keyspace of possible plaintexts for a given blind index, even if the keyspace of each individual input is limited. This is especially useful for encrypting/searching with boolean fields.

Given all of the above, I don't know if you'll be able to obtain a sufficient answer about whether or not to trust CipherSweet on this website. The unanswered questions aren't exactly straightforward to answer, and will require an in-depth analysis.

That being said: It is certainly possible to misuse CipherSweet in a way that undermines its security goals. It's a tool.

I believe that, unless some deep flaw is discovered in the protocol design, it SHOULD be possible to use CipherSweet securely. And even if it is secure, you will almost certainly want a security expert to double-check how you use it.


PGP Uses both asymmetric and symmetric encryption.
Data is encrypted with a random key using symmetric encryption using on of these algorithms:

As per RFC 4880:

IDEA
TripleDES
CAST5 (128 bit key, as per [RFC2144])
Blowfish (128 bit key, 16 rounds)
AES with 128-bit key
AES with 192-bit key
AES with 256-bit key
Twofish with 256-bit key

And in RFC 5581:

Camellia 128-bit key
Camellia 192-bit key
Camellia 256-bit key

Then this key, called "session key" is encrypted using the public key of the recipient.
Wikipedia: PGP

Now looking at RFC 4880 Section 13.9 for OpenPGP, it says that a variation of CFB mode is used for the ciphers.

CFB Decryption looks like this :

As shown in the image, you start with iv, key and first block of cipher text and as you go forward you have your plain text block by block decrypted.

So in theory it is possible to have the message decrypted part by part but I haven't seen a tool doing this out of the box probably due to lack of use case. But one can go ahead and develop a tool to do this.


Is there a security difference between GPG signing a file directly or its SHA512SUM file?

Most signature schemes already require hashing the data as part of the signing operation. Adding another hash before this shouldn't really be necessary (ie this likely indicates a performance issue in gpg), but as long as the hash used is at least as strong as the one used for the signature it shouldn't result in a reduction in security.

There is a minor difference in that sha512sum will output the filename as well as the hash, so your signature will be over the filename as well as the data.

Note that gpg allows you to specify the hash function with --personal-digest-preferences or --digest-algo, so selecting a different hash may be an alternate solution to your problem.


This is a fairly common practice called a web bug, it is the main reason that mail clients do not automatically load external images (the second being to protect you from viewing unwanted spam images that could be unsettling; e.g., pornography).

Basically when you load an email with external images enabled and a link to an image like  is in the source, their web server will log something like the following (example below is default access log for nginx web server) when your browser/mail client fetches and downloads the image:

10.1.2.3 - - [10/Oct/2012:10:33:41 -0400] "GET /images/53512_58925.png HTTP/1.1" 200 1933 "http://192.1.1.1/images/53512_58925.png" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.81 Safari/537.1"

which gives them:

your IP address of your computer where you viewed the email (10.1.2.3 in this example),
the timestamp of the access by the server's clock [10/Oct/2012:10:33:41 -0400],
the (first line of the) HTTP GET request to get the image (GET /images/53512_58925.png),
the HTTP response code (200 meaning success),
the size of the file being accessed (1933 bytes),
the full URL of the file (192.1.1.1 is IP of email sender's server), and
the User-Agent string of the client (indicating what web browser and possibly OS you are using).

To really track you accurately, they would need to have a unique URL for the image; e.g., the file 53512_58925.png could mean that user 58925 read the email with the ID 53512 or something.  They could also do something with HTTP GET parameters something like  that would also be logged.

I'm not going to comment on the legality of it; laws vary and some countries that I do not live in have recently enacted strict IT privacy laws (e.g., against a similar policy cookie tracking without explicit user consent).  Also this forum is not really intended to provide legal advice.

This has nothing to do with same-origin policy (used for limiting the power of remotely loaded client-scripts in languages like javascript; so going to unsafe-web-page.com shouldn't be able to read/modify browser data in other tabs) or XSS (where attackers exploit flaws inject content in web pages that are not their own).


What is the common practice to encrypt user's personal identifiable information

Encrypting the private key as well really doesn't add much more security - ultimately you need to store some key unencrypted therefore it makes sense for that to be the PK.

Given the email address is encrypted (signed using the PK) you will need some additional information to perform the look up - the recommended solution is to use a public key. The public key is distributed to the clients and sent as part of the requests and used to lookup the PK and decrypt the data.


duplicity list-current-files doesn't ask for password

It turns out duplicity keeps data around in ~/.cache/duplicity. These files are unencrypted manifest and signature files, but not the actual data.

I found something about this in the man page, but it only became clear to me after some further testing and looking at the cache. (See my EDIT of the question.)

So, it seems to me this doesn't represent a weakness like I originally thought.


ADFS 2012 R2 (3.0) JSON web token validation

If I understand your question correctly, the signature is a RSASSA using SHA-256 hash based on the configured Token Signing Certificate.

I've got a Node.js validation example on GitHub and here's a blog post with a few more details.


Is this sufficient text cleaning in a PHP Form?

Calling htmlspecialchars($data) is probably fine if your program is only interacting with HTML, so in your simple example, that's probably ok. But as your programs get more complicated and the data gets passed to different environments, then that won't cut it anymore. For example, the strings which are dangerous in HTML are different from the strings which are dangerous in JavaScript, or SQL, or Bash, or _____, etc. So as the number of environments that you use increases, your cleaners have to become more and more complex. More complex cleaners means more room to make a mistake, or introduce a security vulnerability.

The more general question with text sanitization is "which characters are dangerous?", and that entirely depends on what you plan to do with the data after you've cleaned it. So to answer the question fully, we'd need to know which programming languages / libraries / system calls you're handing that data too.

One general suggestion I can make about text cleaning is that a whitelisting approach is always better than a cleaning approach. Let me define those terms:

A Cleaning Approach is where the programmer says "Let me remove dangerous characters, and then continue using your text". So for example the user input string "<script>malicious()</script>", that would get cleaned to "scriptmaliciousscript", and the program keeps on chugging.
A whitelisting Approach is to ask "does the input string match what I was expecting? Yes? Then let it through. No? Then reject it and return an error.".

99.99% of the time a whitelisting approach is better, here are some potential problems with cleaning that I can think of off the top of my head:

User confusion -- for example, let's say you've decided that underscore is a dangerous character, then a user enters the email address "jim_smith@example.com" and your cleaner silently changes it to "jimsmith@example.com", they will be very confused and frustrated when their login fails.
Cleaners are tricky to write properly -- the more environments your data crosses, the more complicated the cleaner. To see what I mean, think about the cleaner you would need in order to allow a user to enter JavaScript, but detect harmful SQL, not easy. Escaping characters can be another good approach, more on that below.
Hackers enjoy trying to break cleaners -- When a hacker sees that their input is being cleaned and then processed, the game becomes "what can I type in, that the cleaner will make malicious for me? Hackers can be surprisingly good at this game.

Point (2) is a problem with Blacklings blockers too in that you still have to put careful thought into which characters to block (based on what languages / libraries you're passing the data to). But with cleaners, in addition to checking the input for potentially malicious strings, you also have to check the output for dangerous strings because of point (3).

One option is rather than removing harmful characters, is to escape them into harmless text, ex "O'Brian" becomes "O\'Brian", and almost all web-apps will interpret \' as text, avoiding SQLi-type problems. But this gets trickier for things like email addresses and phone numbers since you have to un-escape at the end so you don't try to email "jim\_smith@example.com", or hand your dialer app "\(123\) 456\-7890".

So my suggestion is to decide which sets of characters you're going to accept for each field (keep this list as small as you can get away with) and reject input that has characters outside this set. Generally letters and number are safe in all environments.

For example, for email addresses you only need {Uppercase Alpha, Lowecase Alpha, Numbers, _, ., @}, and additionally you could check for the format ____@___.___.

For phone numbers you only need {Numbers, (, ), 0, +}, and can check for common formats.

For names you only really need {Uppercase Alpha, Lowecase Alpha, space}. Depending on who you're writing the software for, you may be asked to support things like:

Hyphen (-) which is part of some people's names, like "John Smith-Jones", but is dangerous on command lines, as in rm -rf.
Apostrophe (') which is part of some people's names, like "O'Brian", but is dangerous for SQL.
Accent characters
Non-roman character sets

In which case you'll have to do more digging to find out what the specific risks are with each of those.


PCI DSS aside, why would you not want logs on staging.

The logging on stage should be exactly the same as used in live.

Stage by definition should be a clone of live. Setting up logging properly is no trivial task. Using stage to develop the log management processes should be like any other part of development. Get it right there and you are not wasting time and potential errors in live.


Why is Zone Alarm Blocking VMWare Virtual Network Editor?

If ZoneAlarm is preventing your application from connecting to the network you can find the Related logs and when you read the log you can find why it has been blocked and therefore you can find the right solution to solve the issue, here is ZoneAlarm Alert and Logs documentation.
ZoneAlarm has an application control mechanism that should be configured properly to allow your application from execution and data transmission and prevent the malicious program from running, here is also a helpful line to ZoneAlarm application control.
There should be many reason why it blocking your application from connecting to the network but a common issue is that maybe the pattern of transmitted traffic looks suspicious, like too many connections ((Behavioral Detection).


AWS declined to give me details on Multi-Factor Authentication reset procedure

AWS already answered your question about transparency

  Disclosing our processes violate our privacy and security policies.

To avoid being locked out of your root account, backup your two factor authentication tokens. This will be specific to the solution you use.

If you use the Authy app for two factor authentication it can backup your two factor logins, as well as make them available on multiple devices. Authy is protected by a password.

Regarding your question "How to make sure that hacker who broke first layer of authentication is not able to reset MFA?"

Two factor authentication means the hacker can't access your website without your phone or token, or in the case of Authy, without the authy account details.  This is the whole point of 2FA - something you know (password) and something you have (token).


What are the differences between HSM and SE?

A hardware security module (HSM), a secure element (SE), a smart card, a trusted execution environment (TEE) and a secure enclave (SE again) are all computing environments designed for secure execution. They generally have some properties in common:

They are isolated environment with a degree of tamper resistance. They're designed to make it hard to extract data from or crack.
They hold some unique cryptographic keys which allow off-device entities to communicate securely with one specific device. In particular, they can't be cloned.
They either only run code from the manufacturer, or if they allow third-party code, it has to be signed, often not by the end-user of the device.
They offer a limited set of interfaces in order to reduce the attack surface.

The difference between these various types of environments is their form factor. This can influence how much they fulfill the various criteria; for example an environment that is isolated by software can't reach the same level of resistance to side-channel attacks as one that has physical protection. The exact definitions can vary. Typically:

A hardware security module comes in a big box and lives in a server room. It either has its own shelf on the rack or plugs into a PC extension card slot. It has some physical tamper resistance, designed to self-destruct if you try to open the box. It's plugged in 24/7, has a battery inside, and will die if the battery runs out. The physical connectivity can vary; Ethernet, PCI and USB are common. HSM usually have a proprietary communication protocol but offer at least a PKCS#11 interface.
A smart card is a chip which is usually embedded in a credit card-sized piece of plastic. Some are smaller, for example SIM. It takes its power from the device it's plugged into (or the device it's in radio range of, if it's contactless) and sits in someone's wallet while not in use. Calling something a smart card generally implies a ISO/IEC 7816 interface.
A secure element is smaller than your nail and soldered to a board or may even be part of a system-on-chip package. It's fully isolated from other computing environments on the same board or package, but it may or may not be resistant to physical tampering. A secure element plugs in to whatever bus the chip has and has a proprietary logical interface (but often the manufacturer will provide a PKCS#11 interface on top).
Sometimes, if the secure element is inside the same chip package as the main processor, it's called a secure enclave. This is the case of Apple's secure enclave, for example. But sometimes a “secure enclave” is only logically isolated and not physically isolated.
A trusted execution environment or secure enclave is a software environment which runs on the same processor as a less-secure environment. It's isolated by a small piece of software that relies on hardware functionality (e.g. Arm TrustZone, Intel SGX). Terminology and interfaces vary depending on whether you're in the Intel or Arm world.

Once again, keep in mind that what I'm presenting here are typical characteristics, not formal definitions. In a nutshell, if it hurts when you drop it on your foot, it's an HSM. If you carry it in your wallet, it's a smartcard. If it's a non-removable smartcard, it's a secure element.


Preventing jwt replay attacks against the client-side

What you are saying is that you do not want a client to be able to share his valid token with another client and thereby share his session.

You have different options to achieve that:

Use a counter in the body of your token. Every time you exchange the token, increase the counter by 1 on the server side. You remember the current value of the counter for the user on the server and verify that it matches the token you receive back. If another client uses the same token, the protocol will get out of sync and only one of the sessions will stay valid.
Store a client specific value (e.g. the IP address) in the body of your token. Since the token is signed, the client cannot manipulate this value. You can check on server side, if the value matches the client property. So if another client with a different value for this property (e.g. coming from a different IP address) uses the token, you can detect this on the server side. If you use the IP address for this, be aware that this does not help if both are behind the same NAT or use the same proxy. If you use another property, make sure to choose something that cannot be emulated easily be different clients.
Rethink your token strategy. Maybe a classical session management is better suited for your needs than token based authentication. Without further insight into your architecture, this is hard to tell, but you can evaluate this option and see if it solves your problem.


There is not much you can do to prevent an AV signature set from getting outdated. Imagine you would want to create a piece of malware with the goal to infect as many people as possible. You certainly wouldn't want it to get detected by any virus scanners, do you? So what do you do? You let all virus scanners you can get run over your malware, see if they detect it, and when they do you modify and obfuscate your malware until they don't.

Now your malware is undetectable... until the AV scanners find out about it and update so they detect it again.

What do you do now? You get the updated virus scanners and again start to modify and obfuscate your malware until they again can't detect it anymore and you again set it free. Then the cycle repeats.

It's an endless cat- and mouse game between AV vendors and black hat hackers. Both have commercial interests. When one stops updating their product to outsmart the other, they would lose a very lucrative business.


Should I redirect http request to https from my system's application or from DNS or other?

DNS cannot do this because DNS doesn't know anything about the protocol. It just turns a domain name into an IP address, so has no way to know whether the person making the request is using HTTP or HTTPS.
If you don't want to worry about handling this redirect in your application then you could handle it at the load balancer which (depending on the details) can be protocol-aware.
For AWS (which I bring up because it seems like you are using it) this means using an application load balancer (ALB) which can perform the redirect natively without additional infrastructure. It will also act as an SSL termination endpoint for your application.
From a security perspective there isn't much of a difference here - it is mainly about what is most convenient for you to maintain


What makes it difficult to have a hardware antivirus?

If the chip is writable from within the OS, the malware can write to it too, so it wouldn't help there.

Also, anti-malware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the anti-malware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the OS. If we can write to the chip from the OS, so can the malware.

In order to make a secure hardware anti-malware you first have to change the main task of the program. Anti-malware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time.
If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.

The problem is that there is no generally feasible list of OK programs. You'd either have to have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or you'd have to have an enormous list of any programs that anyone would ever want to run.

To generate that list, the easiest would be to add every possible program, and remove all the bad ones, which is equivalent to what anti-malware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.

It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for anti-malware companies trying to sell subscription services.

As for the extra privilege level; sometimes you have to escalate privilege, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.


Device manufacturers make changes to the original Android OS(in some cases, to a large extent). I guess your manufacturer introduced this "feature" to help you auto-complete your passwords.

Or maybe they simply forgot to check for the password field and are simply storing each string in their database.

It is definitely not desirable to have your passwords stored. You should check, if feasible, another model from the same manufacturer, preferably with the same firmware, if it exhibits the same behavior.

It is usually possible to clear the auto-complete data. Go to Settings>Apps>Keyboard, and hit the Clear Data button, it should do the trick.

You can also switch to some another keyboard from Play Store. It would be wise to download it from some reputable vendor.

Also, check for firmware updates in your device. Chances are this issue might have been reported, and they might have fixed in the next firmware.


How to Pass Authorization Header in HTTP Request when using HTML5 Player (Audio tag) for security

You cannot add any custom headers this way.

The established way to add user specific authorization is to have a session cookie. If such a cookie is set for the target URL (i.e. the user is already authenticated against the target) then it will be sent automatically within the request.

If instead the authorization is not specific for the user but instead some application specific access token you can include it in the URL. If you don't like that it is part of the URL and thus visible in the history you might behave as in the scenario above with the logged in user and cookie based session id. Only that you either set the cookie from within Javascript (in case of same-site request) or get a cookie for the target site by automatically "logging in" with your access token using XHR.

Yet another way is if the target sends a "authentication required" (HTTP status code 401) request back with an appropriate WWW-Authenticate header. In this case the browser will prompt the user for the login credentials and send these with each request to the site using the Authorization header.


How to host application monitoring and administration dashboards?

Congrats on finishing an application.

Suggestions:

Hiding vs. Securing
Don't rely on hiding the dashboard.  Instead rely on controlling access with roles and an IP address whitelist.

Role Based Access Control
What happens often is that an administrative page is blocked by access control, but the URL that the page submits to is not blocked, so administrative commands can be made by those who are not admins if they know the back-end URL. A centralized, role-based access control framework in your application is best for this and most web application frameworks have one.  It is easier to configure all this if the admin pages are in a different domain or in a directory like mydomain.com/admin.

Separation of concerns:
Anything that is not the primary purpose of your new application will be better handled by a tool made for that purpose.  For example, "monitoring" sounds like something a centralized log management software is better for.  Maybe your organization already has one of these.

Restrict to Internal Network
Yes, your assumption is correct.  You can bet that large websites don't make their admin dashboards reachable by those not on an internal network. You mentioned VPN.  If possible, make admin dashboards only available on the internal network.


Using TPM with well-known SRK/owner passwords?

Is it okay to use the well-known password of 20 bytes of 0s as the
  owner/SRK passwords? tpm-luks has the options to use those well-known
  passwords to perform these operations so that they can be
  non-interactive. Since the system is locked down, I am assuming no one
  will be able to exploit this?

If you leave the owner and password as default or well-known values you are opening the door to circumventing the entire secure boot process. This is more of a concern in embedded systems out in the field that are meant to be tamper resistant (tampering in this case causes them to either fail to operate or fall into a functionally limited fail-safe mode).

If you use well known owner/password anyone with the experience or knowledge could change the underlying OS image/hardware configuration, update TPM PCR values and still access the file-system keys, bypassing whatever security/integrity measures you are putting in place.

  If not, would it be feasible to keep the passwords on the encrypted
  root partition? The system is trusted by the time the root partition
  is decrypted so it should be safe to store the password there (and
  access it securely)?

Sure, I can see this working, although, once the system is booted and deemed 'trusted' you're still susceptible to someone picking up the keys which would then permit them to remove the drive from the system and decrypting it. So, sure, it's safe to store it there ... while it's encrypted, but post-boot it's a risk. (This could ultimately result in backdoors installed on 'trusted systems')

  Would it be better to keep the passwords at some other safe location
  and send them down to the machine if it needs to perform such
  operations? Not sure if it's any safer than the second option above.

The TPM is literally the best place for you to store your keys.

  Are there any other better solutions to accomplish the objectives
  above (non-interactive storage of keys to TPM NVRAM)?

Sure. It sound like you're looking at complicated solutions for a single, tooling problem: your tools don't let you automate ownership/setting passwords.

I would probably checkout the trousers code repo, get it built and sanity test it, then modify the tpm_takeownership tool to add a non-interactive owner/password prompt option then use that custom binary during your upgrade process.


Can two parties sign each other's certificate and exchange without CA?

Yes, it is possible and even common for two parties to exchange public key certificates of many types, without the involvement of a third party, to mutually encrypt their communication. This private exchange is the basis of the Web of trust (WOT) decentralized authentication model. The most well-known WOT system is Pretty Good Privacy (PGP) and its variants. If each party trusts the other sufficiently to maintain the security level (authorization to access resources) being granted, the WOT model is appropriate. See also Self-signed certificates.

Public Key Infrastructure (PKI) is the centralized authentication model used in commercial and government communications, involving a Certificate Authority (CA) whose purpose is to vouch for the identity of the certificate bearer by performing a certain level of due diligence on the requesting entity. The request is usually delivered as a Certificate Signing Request (CSR)).

Note that there are different levels of certification authority; a number of intermediate CAs could exist between the "root" authority and the final certificate. Some organizations, especially in government and academia, maintain their own PKI root (an internal CA) which issues certificates only within the organization. What separates a "Trusted" root CA from an untrusted one is primarily root certificate installed base. Operating systems, browsers and other applications are bundled with a selection of root certificates for CAs determined to be trustworthy by the vendor or general industry consensus. Certificates issued by these CAs are automatically trusted by the software which contains them, and these certificates are often installed to the local user's keystore, allowing every application the user runs to trust them.

The two models are designed for different levels of trust. Among friends or a private organization, WOT is enough. When dealing with large numbers of people, many of whom are strangers or possible threats, PKI is preferred.


Is EV (Extended Validation) Certificate Green Bar Affected by Available Cipher Suites?

No, it's not. What you have here is a different problem caused by an inconsistent setup of the site in question. Details follow below.

Based on your feedback about the domain names in chat I've checked the site in question with different systems and it shows inconsistent behavior: on some systems it returns a non-EV certificate issued by "GlobalSign Organization Validation CA - SHA256 - G2" and on other systems an EV certificate issued by "GlobalSign Extended Validation CA - SHA256 - G3".

Looking at the difference of these systems I realized that my mobile version was using IPv6 while my desktop was using IPv4 to access the site. And in fact, looking at the report for this domain by SSLLabs gives you an IPv4 and IPv6 address for this site, where the IPv4 address is serving the EV certificate while the IPv6 address is serving the non-EV certificate.

One can reproduce this on an IPv6 enabled system with nmap. For IPv4:

$ nmap -p443 -script=ssl-cert your.hostname.here
...
| Issuer: commonName=GlobalSign Extended Validation CA - SHA256 - G3/organizationName=GlobalSign nv-sa/countryName=BE

While with IPv6:

$ nmap -6 -p443 -script=ssl-cert your.hostname.here
...
| Issuer: commonName=GlobalSign Organization Validation CA - SHA256 - G2/organizationName=GlobalSign nv-sa/countryName=BE

In summary: the green bar is correct because the site does not serve an EV certificate for the mobile system using IPv6 but it serves the EV certificate only when accessed with IPv4.


IPsec uses ISAKMP + OAKLEY + SKEME right?

Current IPsec implementations actually use IKEv2. But its predecessor, IKEv1, was based on these protocols. The introduction of RFC 2409 (IKEv1) puts it this way:

  This document describes a protocol using part of Oakley and part of
     SKEME in conjunction with ISAKMP to obtain authenticated keying
     material for use with ISAKMP, and for other security associations
     such as AH and ESP for the IETF IPsec DOI.

As to your question what OAKLEY stands for: The author, Hilarie Orman, originally wrote it as Oakley in her first draft, which indicates that it might not have been an acronym. Instead the protocol was apparently named after Annie Oakley, which she explained as follows (responding to someone from China asking the same question):

  Orman-Authenticated-Key-Exchange = OAKE Pronounced as "Oak-E" it sounds like a derogatory regional term in the USA. That was not acceptable, so it had to change slightly.

  Therefore, it became "Oakley" as in "Annie Oakley" the name of a female rodeo performer in the early American West. Because I am a woman, and because Annie Oakley was a woman renowned for her excellence in activities that were usually done by men, and because the IETF is mostly men, I thought that the name was an amusing.


Which encryption cypher is used when using zip -e?

You wrote: "I am looking for a cross-platform way to encrypt credentials I need to send to a client."
You do not define what you mean by "cross-platform." Your best solution is *not to use zip.
If "cross platform" means "Windows and Mac," then your best solution is to use Microsoft Word's encryption or Adobe Acrobat's. Both systems use AES in their most recent incarnation.
If "cross platform" means "Windows, Mac and Linux," then use Acrobat.
In either case, you will need to exchange a high-entropy encryption key for the document with your client. That is, you will need to exchange a password in order to exchange your encryption key. Of course, if you can do that, you might as well just send the credentials themselves using this out-of-band mechanism, no?
So what you really want to do is to use public key cryptography. That is, you are probably best off having your client spin up an S/MIME certificate and send your client encrypted mail using Apple Mail or Microsoft Outlook or Thunderbird or any of the other cross-platform approaches for using S/MIME. You'll find details in NIST SP800-177, "Trustworthy Email."
Other people will suggest that you use PGP. I won't, because it's too hard to use. But if you want to use PGP, give it a try!
If all of this sounds like too much work, you could go low-tech and put the credentials in an envelop, sign your name across the back of the envelope, put that in a second envelope, and send it to your client through postal mail.


Heartbleed POC: Is this sensitive information?

Heartbleed results in arbitrary server memory being disclosed. Sometimes this contains sensitive information. In some cases, this is the server's private key, which can be the most sensitive information on the server. In many cases, it can contain information that is intended for a different client. This is probably what you are seeing: certificates, version strings, and other information used internally by the web server.


Should a server be considered compromised simply because a port was open?

From reading the disclosure, it seems what happens is that the open port isn't actually just a random port, but rather it is a port where a certain internal service that had never been designed to be exposed directly to the external world was listening on. If there is a vulnerability in that internal service, that might have allowed a possible attacker to obtain the API key of users that uses their service within the specified period of time.

While they do note that the attack looks like an automated attack rather than a targeted attack, it should be considered that sophisticated attackers often uses a highly visible automated attack to divert the server's and the sysadmin's attention away from another covert, targeted attack that are happening at the same time, i.e. the big DDoS that causes a lot of attention is just a diversion.

A sophisticated attacker could have erased their tracks if they managed to gain privilege into the system to make it look like nobody has compromised important data. This is why they recommend changing your API keys, even though they found no evidence of the data being actually queried. Especially since this is a logging server that was compromised, and since sysadmin would usually use logs to detect compromise, a compromised logging server can hide what's truly happening.

A sophisticated attacker could also have left a backdoor/rootkit on the system to allow themselves to reenter the system at later date when everyone thought things have settled down, so they can do their actual attack at a more leisurely pace from inside the security boundary, which could be highly dangerous. This is why they are decommissioning the machine involved.

Or it could be that they may be doing this as a show to some potential security-conscious customers that are on the fence on buying decisions due to doubts about their security. This might shift the attitude of those potentials customers to decide to take up their service, since they're now reassured that the company wouldn't be keeping mum when there are vulnerabilities that might affect them.

  Is there some reason that simply having open ports would be considered a potential compromise here?

Yes, the open port exposes an internal service that wasn't designed for external use. Services intended for internal use often lacks the security hardening that public facing services would get, because the assumption was that the service is only accessible from trusted machines. For example, an internal service might not use SSL to communicate within the trusted network, or they might not validate their inputs as thoroughly as they assume the trusted senders already does any necessary validations, or they might have administrative commands that can be used without authentication, because it assumed that any necessary authentications have been done by the public facing services.


How to crack `salt + SHA256(salt + password)` hashes with JTR?

as far as I know the --rules option only allows you to define rules for the password the user may be using (foobar, foobar123, f00bar…).

--format corresponds to the format of the hash: there are many predefined rules (http://pentestmonkey.net/cheat-sheet/john-the-ripper-hash-formats), so you can modify your file to the format salt:md5(salt+password), eg : 9e7443:7e97ff201ff38416138a22a7f3adfa3b9c10e947481bd94b16eed7df6b6e2806, and find a format which processes username:md5(username+password) for example.

Another option would be to use dynamic scripts (https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/doc/DYNAMIC_SCRIPTING). This method will be trickier but also more flexible.


Custom fixed header + cookies: am I protected against CSRF?

Any request that is made cross origin, cannot set a non-standard header. Unless you allow it using Cross-Origin Resource Sharing. This technique only works for javascript requests, not for requests that for example come from submitting a form. For the javascript case this technique is recommended by OWASP in the  Cross-Site Request Forgery Prevention Cheat Sheet.
However, one issue that might come into play:
If there is any action that is immediately executed on your page through javascript when you visit it: This action will be executed when the user opens a link to your page.
As this action is executed on your page, the context is not cross-origin and the javascript call will add the header you defined. So make sure something like this does not happen.


What are the weaknesses of this password-generation-method? How can it be improved?

This is a poor method for password generation.

It requires memorizing a very long secret.  This is very difficult for most users, particularly if you want it to have a lot of entropy.
What's the weakest link?  The same as it always is: the human.  The weakest link is the human who is picking the poem (the central secret).  I suspect that in practice, a large fraction of users are going to pick a poem that has relatively low entropy: i.e., is one of a fairly small set of possibilities.  I'd bet that there are at most about 2^20 poems in the world, and a significant fraction of users might use one of those 2^20 poems.  If so, this is a weak method.  Any web site that knows any one of your passwords can recover the poem and then guess all your passwords at all other sites.
Also, an attacker who knows nothing about you and wants to break into your account on some site can just start trying poems, in order of decreasing popularity, and try each password that results.  There are good reasons to think that this will succeed with a depressingly high success rate.  For instance, look at studies of passwords (see references below); you find that a small dictionary of common passwords suffices to break a significant fraction of user's passwords.  I suspect the problem will be even worse with this scheme.  It's bad enough to try to memorize a 6-8 character password; trying to memorize an entire poem would be horrible.
This is trivially defeated with Google.  You listed three examples of site passwords for HOMEPC, STACKEXCHANGE, and EBAY.  Pick any one of those site passwords, and cut-and-paste it into Google.  In each case, the very first response is the Jabberwocky poem.  Thus, in each case, someone who knows a single site password can learn all of your other site passwords.  That's no good.  I would expect this to be a general problem for many users: not specific simply to your example, but one that would be successful against a very large fraction of users.

As always, the hard problem in this space is usability: the scheme has to be designed to work well for a typical user.  I suspect that this scheme ranks poorly on that criteria.

There's a tremendous amount of prior work on this subject.  It turns out that this is a challenging problem, but there are some quite good solutions.  I suggest looking at PwdHash (www.pwdhash.com) and Passpet (passpet.org).  Either one of them is a reasonable solution.  Passpet is probably more secure, but harder to use.  I definitely do not recommend trying to invent your own homebrew solution, especially if you're not already aware of the prior work on this problem.

Alternatively, many browser password managers offer the ability to sync across multiple machines or multiple browsers (using storage in the cloud).  Why not try one of them?  (I don't understand your statements about not being able to use it on another machine.  The good solutions all provide a way to use your passwords from multiple machines.)


SQL Injection in a Web Service URL as a Parameter Value

SQL injections have nothing to do with whether or not your application accepts URL parameters. They work with any input, be it the URL, the request body, a cookie, an HTTP header or even data from your own application (e. g. a string stored in your database). It doesn't matter.

So it's not about the origin of the input. It's what you do with the input. If you take dynamic data and simply insert it into an SQL query, that's a potential vulnerability. And, yes, this happens very often.

SQL injections cannot be prevented by checking the input. They must be prevented at database-level, for example by using prepared statements.


Trying to do a chunked multipart post request, nginx and php both returns 400 error

While transfer-encoding chunked is defined for both response and request in the HTTP/1.1 standard (but not in HTTP/1.0) it is typically only used for responses. It is not universally supported for requests.

Apart from that your first line should only include the path and not the full URL. While HTTP/1.1 (contrary to HTTP/1.0) explicitly allowed the full URL in this place lots of servers don't accept this.


With AES, does key format make a difference to security?

Do these two keys have the same strength, or by leaving the hyphens in
the key am I reducing the security by a partly-known-key attack?
A: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
B: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

These are not different keys. These are only different representations of the same key. It does not matter if one represents a key as binary, hexadecimal, base64, with hyphens or without etc. At the end the key itself gets used for encryption and decryption and not its specific representation. That means to do the actual processing it gets converted from the specific representation to the actual (binary) key.
And since it is the same key it also does not make a difference in security.


Is OSCP qualification considered Junior or Mid?

It is hard to answer this question since the answer is subjective, but I'll try.

OSCP is definitely a well-recognized and respected certification for penetration testing. Mainly because of the way the test is designed, it is meant to gauge creativity and skills required to be a successful penetration tester since it is not for everyone. For example, a good security management professional with a CISSP would not necessarily be a good penetration tester, since penetration testing is more about being creative and having a knack for breaking into things.

When it comes to penetration testing, I would rate OSCP as one of the best certifications you can get and it should score you a mid-level position in penetration testing but ultimately it's hard to say since job offers depend on a lot of things than just a certification.

Some references to gauge the quality of OSCP:

https://ch1kpee.com/2016/10/04/my-oscp-experience/
https://kaizensecurity.wordpress.com/2016/05/07/oscp-blog-post/

You can find more with Google. Goodluck!


When you connect to the wrong server, this should trigger a very noticeable client-side warning, because the server appears to use a key distinct from the key it was using in previous sessions. The client remembers servers' keys. For a classic OpenSSH client, the warning looks like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.

Of course, this relies on your client having already connected at least once to the right server; otherwise, the client will not know the right server key in advance.

Assuming that you did "click through" the warning (i.e. modified your .ssh/known_hosts to bypass it), then you connected to the wrong server. When using key-based authentication, the client computes a digital signature on a string which contains the "key exchange hash", a session-specific value obtained from the key exchange mechanism through a hash function; the server verifies the signature with regards to the expected client's public key (in .ssh/authorized_keys).

In no way is the client's private key ever revealed to the server. Moreover, inclusion of the key exchange hash in that which is signed prevents the receiving server (the wrong/fake one) from reusing the signature to impersonate the user on the right server. Therefore, your client private key is safe; there is no need to change it.

(The key-based client authentication mechanism is described in section 7 of RFC 4252.)


In VMs, do shared folders reduce security effectiveness?

A virtual machine does not access directly the memory of the host in case of shared folders. In reality, the virtual machine uses a special file system driver in the Guest Addition to talk to the host. A shared folder is implemented like pseudo-network redirector.

The only way to be sure a virtual machine won't infect its host is to develop an architecture that isolates the virtual machine from its hosts as if it separates them physically. As long as this has not been possible (AFAIK)  it is not strange to read many cases on the Internet of hypervisors being escaped by malware (IBM X-Force ®  2010 Mid-Year Trend and Risk Report).

When sharing folders between the host and guest, you still have the option (at least with VirtualBox and VMWare Player that I use) to force the guest to access the shared folders in read only mode (you can copy data from the shared folder to your virtual machine but not in the opposite direction).

As for your question's title, no, shared folders do not add any security layer regarding the possibility of infection of your host. In opposite, it may be an additional attack vector especially in the case you create a shared folder with the default read AND write option.


How secure is Stack Exchange's reputation?

Stack Exchange has multiple layers of security preventing this. Captchas and email addresses are required. The email check is easy to beat with a script, but the captchas aren't; you'd need a Captcha breaking service to even get this off the ground.

None of your bots can vote at the start, so you can't accumulate rep just by posting questions; human eyes have to look over your post and manually give you your first reputation. At best your bots could get rep only by other bots accepting answers. After each bot gets an accepted answer they would be able to upvote however.

Once they can upvote you start running into fraud detection; cross voting where a significant % of votes are split between two users are automatically flagged for moderator attention, and serial upvotes (more than a couple inside of a few minutes) would automatically be reversed, so you'd have to be VERY careful in how you implement this.

Even if you surpass the automated fraud detection, which would require significant effort and tools programmed specifically for the Stack Exchange Network, you run into the problem of human moderation. All posts on SE are getting human eyeballs on them. If your bots are asking duplicate questions, they're going to get closed. If they're asking gibberish or spam questions, they're going to get deleted, and deleted posts don't earn rep (certain outstanding circumstances aside).

Basically your bots would have to post actual, new, good questions in order to not be found out and shut down. SE has some okay automatic detection scripts here, but there's no way an army of bots would go unnoticed simply because you'd need an amazing artificial intelligence to actually write enough new questions and answers to pull this off.

Facebook hacking can be a lot easier because no one has to see your bot friends; Facebook profiles can go without human scrutiny, Stack Exchange posts cannot.

I'm not a Stack Exchange employee however, so there may well be additional security measures I'm unaware of, but as a user and moderator those are the significant points I'm aware of.


Email got hijacked or hacked, where to start?

You already changed your password, so the first thing to do would be to enable Two Factor Authentication if your provider has that service (and if it doesn't, I'd highly suggest changing provider).

Another thing is to make sure you use an exclusive password for that account (ideally, you would have a different password for every account and use a password manager to handle them). Many accounts get hacked because they use the same password on different sites. If one falls, all follow.

The last thing would be to thoroughly check your PC for malware (keyloggers and the like), and to make sure your provider always uses encrypted channels when authenticating you (https requests only). Again, if it doesn't, there is nothing you can do but change provider.

EDIT: Your account may also have been blocked due to an activity that appears irregular but is actually normal, like logging from another country/using an unknown device, or sending emails flagged as suspicious by spam filters. You should check with your provider if this is the case.

Side note: never connect to sensitive accounts while connected to a public hotspot. Connections can be spoofed easily if the attacker is in control of the access point.


Is it possible to make a video that is provably non-manipulated?

Trusted Timestamping
I think, if you continue down this line of thinking, you will end up with something very similar to Trusted Timestamping Servers.
The core idea of trusted timestamping is that you submit a file to the server and it signs an attestation saying that it saw the file with hash aabbcc112233 at time X. This is typically used for both proving the initial publication time (and who published it), as well as proving that the file has not been modified since.
You need the trusted 3rd party because if the end-user creating the video is the same person signing it, then there's nothing stopping them from re-signing it after they edit it.

Why not just save the video stream on the server?
That said, I don't think you really need any fancy crypto here; the simplest solution is probably best. Have the student live-stream their cameras to an exam-monitoring website. The website logs the video stream in its database as it comes in, and it can detect and alert if the live stream had any breaks or disruptions long enough for manual editing to potentially have taken place.

Create a blockchain of the video stream
Update addressing comments.
Ah, you have the extra privacy requirement that students do not want their video stored on 3rd party servers (that should have been in the question!).
In that case, what makes this problem hard is that you can't wait until the end of the exam and publish a single hash for the entire video because that gives the student too much time to edit a middle section of the video. The solution that comes to mind would be some kind of hash-block-chaining (not "The Blockchain (Bitcoin)" but "a blockchain"). Either the sender or receiver breaks the video stream into, for example, 10 s "blocks", hash each block as they are produced/recieved, and stream the hash for each block along with the video in real-time. You do "block-chaining" by including in each block the hash of the previous block. In math notation:
h_0 = hash(videoblock_0)
h_1 = hash(videoblock_1 || h_0)
...
h_n = hash(videoblock_n || h_n-1)

This preserves privacy because the server only needs to store the hashes and not the video itself. This is streaming-friendly because you are producing hashes throughout the stream and each hash covers the entire stream up to that point. This is efficient because the server only needs to store the most recent hash (h_n), and that is enough to later verify if a provided video was tampered with at any point in the stream (though to detect where it was tampered you would need to save every block hash).


Key Management for PCI and Payment automation

You CAN use stored keys and DO NOT have to enter keys manually, but you also must rotate (change) keys every quarter, and a separate key for each customer is a good idea, too.


How to (temporarily) disable McAfee Endpoint Security on an enterprise workstation?

I will address the administrative, not technical aspect of this question, because you have specified an Enterprise setting, and you do not seem to be an Enterprise Admin.

You are obviously working in Windows, so I will assume an Active-Directory managed infrastructure, and I will suppose that your McAfee workstation clients are centrally managed.

You should talk to your security people and to your own supervisor.  If you are in security, this should be that much simpler.  You should either be working from a service request or similar, which if assigned to you should cover your butt.  If not, you should get written permission from your supervisor to go about disabling things, and your supervisor in turn should have written permission from security.

If these things cannot be had, then I respectfully submit that you are engaged in a certainly dangerous (to security and to your career) and potentially rogue activity.  None of this means malicious -- I also presume that you are acting in good faith.

Taking the most positive case, let us assume that you are working as directed, and are struggling to get something done which the company agrees needs to be done.  But the implications of cowboying around with security settings can still compromise your environment, and of course your own position.  You may appreciate a piece of advice which I came up with the hard way -- "it is fatal to care more than the company does."

If the company cannot or will not provide you with top-cover and approved tools to accomplish changes, your efforts will likely lead to worse results, not better.

Back to the technical merits of the question: how?  Ask your security people.  They will know whether the clients are centrally managed, and what it takes to disable the service on a particular client.

More likely than not (I boldly surmise), this will involve moving the machine to a different OU (or GPO group, or similar) in Active Directory, or a similar process in your central management tool specific to the endpoint client.

Finally, if I knew how to do this on a per-machine basis, I still wouldn't post it here.


Why does Windows 7 require a password hint during setup?

Because these devices are for mass consumption. Security must fight with dealing with a spectrum of users and usability. It is possible that users will only ever set up the first user. Let's face it, a good hint can be useful if created properly.  However, bad passwords are more common than bad hints.


What are my options for securely printing an OTP Scratchcard?

Tamper-evident systems (like the scratching technology you evoke) are not exactly what you want for an OTP. What these technology offer is a way to make sure a posteriori that the information was not disclosed. If you see the card and it is still unscratched, then you know that the OTP is still "secure" and has not been used by anybody. The security benefit for an OTP situation is indirect at best: it means that the theft of an OTP will ultimately be discovered when the intended OTP user finds the card already scratched -- that is, if he finds the card. The attacker could simply purloin the card, scratch it, use the OTP, then throw the card in a river.

What you want for OTP is something which the users will find easy to keep secure (physically) until time of usage. Using credit-card sized devices is a good idea: the most secure storage system which is available to most users is their wallet. But there is not much to be gained by making them "scratchable".

For an OTP list, you want something where users can easily "tick off" uses passwords. This might be a "tear off"; after all, once used, an OTP is useless to everybody and can be disposed of without any care (except ecological). You could imagine a small stack of stick-up notes, each with its own OTP printed on it.


Yes I can.

IPv4, due to the size of the address pool, has long had a technique called Network Address Translation. In a simplistic view, let's assume you are allocated the (invalid) IP address for your router 256.10.20.30 (I use invalid addresses so people don't go around pinging them etc). Locally, your router is 192.168.0.1 and your host is 192.168.0.2 like this:

/----------\       /-------------------------------\       /----------------\
| Internet |-------| Your router                   |-------| A computer     |
\----------/       | Internet sees as 256.10.20.30 |       | has only:      |
                   | You see as 192.168.0.1        |       | 192.168.0.2    |
                   \-------------------------------/       \----------------/

As such, your router appears to the internet as a public facing IP-address; however, unless you deliberately route connections on ports from the router to a computer on the private IP address range, the computers on the private LAN side are not directly addressable from the internet. The route is performing two functions - both NAT and routing.

In IPv6 there are a lot of addresses. The idea fundamentally is that there are no private IP address ranges (which isn't exactly true; an RFC for that does exist) and as such the IPv6 situation looks like this:

/----------\       /-------------------------------\       /----------------\
| Internet |-------| Your router                   |-------| A computer     |
\----------/       | Internet sees as 2000::...    |       | has:           |
                   | You see as 2000::...          |       | 2001::...      |
                   \-------------------------------/       \----------------/

There isn't really enough space in these boxes to write out the full addresses, but in the IPv6 model, the router performs its routing function (it gets packets to the computers on the LAN) but crucially here it routes both from and to the internet, rather than routing / NATing outwards.

The effect of this is that the default case for IPv4, namely that home computers aren't directly accessible by nature of the fact they have no IP address unless the router knows about the connection goes away. The computer becomes addressable from the internet, much like a server.

Clearly, such connections can still be firewalled, with firewalls denying all incoming (non-client-initiated) connections, however, you've lost needing to explicitly configure your router to route internet packets to you. If the firewall doesn't filter the incoming packet, the client better be able to cope with it. There is, therefore, a slightly increased security risk to home users using IPv6.

I expect (hope?) most home routers will come configured with this firewall setting. As such, while the risk is slightly increased, it is still probably dwarfed by the threat from browser-based exploits (the "outbound stuff").


Exploit by overwriting relative address?

That would be much more difficult because you would need to use an offset each time. Various solutions exist, depending on which technique is used:

If ASLR is used, you don't know for sure where your shellcode is located, but you can still bypass this by spraying. Also only the base address is randomized, not the function offset, and you can return to plt.

nX/DEP also has it's flaws, for example Java requests memory by PAGE_EXECUTE_READWRITE and thus makes it executable.

But generally, for most known exploits to work, the address must be absolute. In a traditional buffer overflow on the stack, the shell code is part of the data which triggers the overflow, so it is in the buffer. The return address is absolute so it is not sufficient for the attacker to know the code of the attacked function; the attacker must also know what is the stack depth at that moment, and this depends on previous application behavior. Without the stack depth, you would have no clue how big the offset is.


the exact cgi script which uses bash as an interpreter

"Using bash as an interpreter" not a precondition for the exploitation of the family of bash vulnerabilities called "shellshock" (the many distinct parsing vulnerabilities based on an environment variable with any name beginning with exactly the bytes () {).

All you need to exploit one of "shellshock" vuln is to run the bash program with one user-controlled value of an environment variable; a shell script with bash as a shell interpreter (#!/bin/bash or #!/bin/sh where /bin/sh is a link to bash) is one obvious way to run bash, but many others exist when /bin/sh is bash: many function calls which run an external program take a string command (not a path and an array of arguments); notably system and popen (unlike the exec* family of functions). These functions taking a string use the default shell (/bin/sh) to parse the command string, so the use of these functions makes the program vulnerable to bash vulnerabilities, unless the environment has been cleaned up from any user input.

So any C program using these functions is potentially vulnerable. And programs written in other programming languages with similar functions.

This is a lot more programs than just /bin/bash scripts.

Of course, a C program can exec an executable file that happens to be a shell script with a /bin/bash interpreter, too.

  exact cgi script which uses bash

Please note that a "cgi script" can actually be any program with the CGI interface; it does not need to be a "script" as in shell script. Often, CGI "scripts" are written in compiled languages, like C.

  Also, does the attacker have to enumerate pages on the vulnerable
  system

Many CGI scripts are in well known, fixed, locations, on most installations.


MySQL SQL injection without stacked queries - what is actually possible without affecting the FS?

First off: I'm not sure i understood your query, but I'm assuming you meant:
How can I affect data outside (the table these queries are about) ?

The most obvious attack would've been inserting multiple queries i.e.
";delete from other_table" but in this case it looks like you can't do that.
    mysql_query() sends a unique query (multiple queries are not supported)

Which means you're stuck with side-effects - doing things within the original query.  It looks like at the very least you can be disruptive with locks:
http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html
in particular, you should be able to make the select's a 'select ... for update';

I can't yet see another way to affect the specific queries you've got.


I assume you need a temp file to feed an external formatting program that only offers a file-based interface (perhaps something like Crystal Reports or Adobe Acrobat, or whatever.)

One general approach might be to limit your exposure.  You could mount the temp file on a separate dedicated partition or drive, and restrict access to that even further.  If you keep the temp partition small as possible, deleted sectors will be more quickly re-allocated and overwritten.  You could use an encrypted partition.

Even better, you could implement that dedicated temp drive with a RAM disk (aka RAM drive) so the bytes never actually hit durable physical storage media.  A power-off or reboot of the machine will ensure it's wiped.


why CVSS give a score of 0.66 for a full impact on CIA?

The scores baseline is relatively arbitrary - if you multiplied everything up so that 1 was the top score for full impact it would just change the resultant number output. It wouldn't change the meaning in any way, nor the relative scoring, which is the only important output anyway. From the nvd website you will see the figures were chosen to give 10 as a top score as that is simple to understand:

  CVSS consists of 3 groups: Base, Temporal and Environmental. Each group produces
  a numeric score ranging from 0 to 10

If you try putting in the scores from a particular example, you will see how it fits with the levels assigned.

The three areas, confidentiality, integrity and availability are often considered as equal value. For some industries availability is the most important, for others it is integrity, and others it is confidentiality - so while a particular industry may not have them all at the same value, on aggregate it is easier to treat them equally.


Why on earth would anyone use the 'top secret' option of IPv4?

The point of classification flags is that it tells routers what they are allowed to do with it.  You wouldn't see classification flags on the open internet as they are handled by private government networks.  What the flags do perform however is allow routers within the government network to determine if a packet should be allowed to bridge to a public or less secure network without having to understand what is within the packet.

Be sure to check out Falcon Momot's answer as well.  It has some excellent additional depth.


Dangers of opening up a wide range of ports? (mosh)

In addition to Justin's answer about inadvertently opening up applications to be remotely accessed, remember that even if nothing is specifically listening for a connection, the operating system is ALWAYS going to be listening -- if only to route/map to the appropriate process or refuse or silently drop the packet.  Therefore, the operating system is still one specific attack vector  which can remain unprotected when a firewall allows traffic to flow to an "inactive" port.

However, all things being equal in this scenario, opening up one inactive port or 1000 inactive ports makes little difference.  But definitely heed the advice of principle of least privilege.


The point of a spray is that you don't always know exactly which block your object was allocated to.  I believe it's because how volatile the heap can be.  At any given time a block of memory could be allocated, and your NOP sled/shellcode could be interrupted.

You see examples with predictable addresses because it makes it easier to learn the concept, but in the wild ASLR will randomize where the heap is laid out.  So you need to be as robust as possible.


How to Intercept into an iPhone having access to same Wifi

No.

Most traffic these days use additional encryption. Things like facebook chat only use TLS between the server and client, whilst WhatsApp uses the Signal protocol for true end to end-encryption. You can not get access to this by intercepting the traffic at the IP layer.


Authy: Does multi-device mode imply that all keys are stored on their servers?

At least in the latest versions of Authy's Android application authenticator tokens, such as your Gmail TOTP, are sent to api.authy.com only after being encrypted using an AES key derived from your backup password and a randomly generated salt using PBKDF2.

According to this source information sent from the API to your mobile phone has the following format:

 {
 "account_type": "gmail",
 "encrypted_seed": "UZNL+UPVK+5RYUoBlhkuQzCcOb3nMdYxKGFmHEZ4TMxTX7MOPJUayQAMDVJ",
 "name": "My Gmail Account",
 "original_name": "Google:someaccount@gmail.com",
 "salt": "N2QqyJrn7cOHBqTY32uY1cL4IHCANm",
 "unique_id": "0000000000"
 },

In other words, your Gmail TOTP secret seed should be safe with Authy even if they get compromised and the database is leaked.


Is it acceptable practice to only increment a number when changing a password?

If an attacker has found out your password, he can access the system up until you change the password. Changing passwords often prevents attackers that already have your password to have undetected access indefinitely.

Now, if your password is secret-may16 and the attacker is locked out when you change your password, he is certainly going to try secret-june16 as the password. So changing the password in a predictable way is not secure.


Moving from a one tier to a two tier Microsoft Certificate Authority hierachy

It is theoretically possible to migrate to the "two tier" approach without having to re-issue the certificates, but whether this is a good idea is not clear.

When some system verifies a certificate, it builds a chain leading from a trust anchor (a "root certificate" which is hardcoded in that system) to the certificate which is to validate (called "EE" as "end-entity"). The basic idea is that each certificate in the chain contains a public key which is used to verify the signature of the next certificate. The root certificate is also signed because the certificate format includes a field for a signature and that field is not optional; however, nobody verifies that signature (the trust anchor is trusted "by definition", not because it is signed) and it is traditional for a root certificate to be self-signed.

The verifier will accept the chain if the signatures are cryptographically correct, and also if the certificate fulfill a horde of properties which are detailed in X.509. To make things simple, each certificate has a subject name and an issuer name; the issuer name should be equal to the subject name of the certificate which issued it (i.e. the previous certificate in the chain). There again, the root certificate has no issuer, so it is traditional (but not required) that the root has itself as issuer (its issuer and subject names are equal).

So you want to replace the root by the combination of a new root, and an intermediate CA issued by the new root. If the intermediate CA certificate contains the same subject name and the same public key than the old root (and the same "key identifier" and other X.509 extensions), then the previously issued EE certificates will be verifiable against both the old root (as they do presently) and against the new root, as part of a chain which begins with the new root, goes through the intermediate CA, and ends on the EE.

I have no idea whether Microsoft Enterprise Root CA will offer a convenient interface for creating that intermediate CA which reuses the characteristics (name, public key...) from the old root. But if it does, then creating such an intermediate CA will do half of the work of the migration, without requiring immediate replacement of existing VPN certificates.

You are still not done, though. The new root must be deployed, i.e. verifiers must be made aware of the new root, and should also forget about the old root (the latter can be slightly delayed). This is the expensive part and it is tricky because the trust anchor is, well, the foundation of your trust system. You do not want to "educate" your users into fiddling with the trust anchors just because an administrative-looking email told them to do so.

Now there is a structural technicality which must be well understood. In a VPN with client certificates, the verifier for the client certificates is the server. However, such VPN probably also uses server certificates, which are verified by the client software. When you change the root CA used to verify client certificates, then the new root must be inserted in the system which does that verification, and that's the server (so, presumably, this is easy). You need to change the trust anchors in clients only when you switch to a new root certificate in the PKI which issues server certificates. Possibly, you used the same root for both sides, but this is not an absolute requirement.

The main reason why you would want to have an intermediate CA is for damage containment. The intermediate CA is the one which signs new certificates, on a daily basis. Thus, it is probably online, possibly duplicated, and thus vulnerable to attacks. If it gets compromised, you can then power the root to create a new intermediate CA (with a new key) and revoke the previous intermediate CA. Thus, you can recover from a compromise without having to change the trust settings in verifiers. You must still issue new certificates to replace the certificates which had been issued by the now-compromised CA.'

In your VPN system, I assume that there is a single server, or maybe a select few servers, which you directly control. Changing the trust anchor in that (these) server(s) ought to be easy and cheap. Similarly, issuing new certificates for the servers is easy. And you do not do that often, so the root for the server certificates can be offline and does not need to scale: it will be executed once or twice per year, no more. There is little need to have a two-tier approach for the server certificates since the intermediate CA can be managed in the same way than what you would do with a root: offline, down most of the time, kept in a safe. As for the client certificates, you issue many certificates, so the CA for those must be up and networked and scalable and thus vulnerable; but if it gets compromised, then changing the trust anchor for the client certificates is not hard: that trust anchor is in the single VPN server. So while you can have a two-tier approach there, that extra level will not buy you much: it will only save the cost of changing the trust anchor in a dozen servers, i.e. a ten-minute job for a sysadmin, at most. The real cost for a compromise of the CA which issued client certificates is that new client certificates must be issued, immediately, and having a two-tier CA changes nothing to it.

"Two tier" PKI with intermediate CA certificates is a good idea when there are systems where both the certificate owner and the verifier are out of easy control by whoever manages the PKI. In a VPN / RDP setup, this applies if you have hundreds of servers, making the cost of changing either the server certificates, or the trust anchors used by the servers, non negligible.

Now I have been overly verbose. To sum up:

Transforming a root CA into an intermediate CA without impacting the previously issued certificates is theoretically possible.
Whether a given PKI system implementation offers an easy-to-use interface for that is another question.
A "two tier" is a good idea in some situations, but for others (including what I assume about a typical VPN installation) it does not buy you much, and since it adds some complexity, it is unclear whether it is worth the effort.
To think about a PKI, you have to identify who verifies which certificates. In particular, the server PKI (the PKI which issues certificates for servers, which are verified by clients) and the client PKI (the PKI which issues certificates for clients, which are verified by servers) need not be the same and probably call for distinct management processes.


When you type the URL in your browser, the browser will mainly do two things with it:

Resolve the host name to get the associated IP address to be contacted, this allow the browser to send the request to the right server,
Put the host name which has been actually typed in the Host HTTP header, this allows the server to send an appropriate reply in case several websites are hosted (each website will be identified thanks to this header).

However, what must be understood is that this Host header is just a plain-text header. A simple test:

Initiate a telnet connection toward you web server:

  telnet example.com 80

Request a web page using such commands:

  GET /my-fake-page HTTP/1.0

  Host: my-fake-host.fake

Then you need type enter two times to validate the end of your input.

Then in your logs you should see an incoming request for the URL http://my-fake-host.fake/my-fake-page.

As per the root cause of the issue, the same problem seem to affect other people with no clearly defined root cause, maybe a DNS server issue somewhere in China possibly related to their national firewall, maybe a DDoS botnet, but there does not seem to be any confirmation.

These requests are not dangerous by themselves. However, in the mentioned thread some people were reporting a significant impact on the performance due to the increased load, possibly causing a denial of service. For some other it was just part of the "Internet noise" appearing in the logs.

As i went through the mentioned discussion, in case of load issue a few solutions were proposed, the one mainly applied being blocking source IP based on the originating country.


The purpose of securecookie package from gorilla

This appears to provide a function similar to that of JSON Web Tokens (JWTs). i.e. a claims based identity token.

It will allow your web application to set cookie values, and to guarantee the integrity of the values when received in future requests.

In addition to integrity checks, securecookie also appears to allow encryption for confidentiality.

What this means

In essence it allows your application to set values and store them in a client side cookie that can't be altered by the end user, with an optional step of encryption to also prevent any reading of the value.

So you could be storing that the user is logged in as an administrator. Normally if you stored User=administrator in a cookie, this would be subject to tampering by a malicious user who has the cookie on their own machine. However, if you use securecookie you can protect this value with a cryptographically secure hash. The hashed value typically includes an expiry date and time to prevent a user from storing the cookie value and then using it at a  later time (say when they do not have administrator access).

It does not protect against Man-in-the-Middle attacks or from attackers that have taken over the box. It simply enables the data about the current user (the claim) to be stored client-side.


I wouldn't go ahead and so much as "show," but rather inform. Find the contact information for their System Administrator and/or security team, and inform them of what you've found, and how you believe it could be used as a vulnerability.

"Doing" anything to "show" a vulnerability, i.e. hacking, regardless of intentions good or bad, is still considered illegal without consent from the individual or organization.


Is my mongodb data safe given that by mistake I left the default port 127017 open on firewall?

If mongodb only binds to 127.0.0.1 as shown for your config then the ufw rule you've accidentally enabled will not cause mongodb to be accessible from outside either. But to make sure that no kind of additional forwarding or binding etc was setup you might enable the ufw rule again and then do a telnet your-ip 127017 from outside the machine.  You should get Connection refused or similar which shows that the database is not reachable from outside even if the ufw rule might in theory allow it.


The standard commercial router you mentioned do not allow any incoming connection from outside to the inside of the network. You need to specify allow the incoming connections through port forwarding. If you want to connect to the PC through the same network i.e. both tablet and PC are connection to the same local area network, you don't need to worry about outside users connection to the PC from the Internet since the NAT device (the router) won't allow it by default.

If you want to access the RDP from outside the network e.g. through the Internet, but want to restrict the access to specific IP address, I don't think the commercial router would be flexible enough for such a rule. However, you can accomplish this through your Windows firewall. In order to restrict RDP to specific IP addresses,

Go to the control panel->Administrative Tools
Windows Firewall with Advanced Settings
Inbound Rules
Remote Desktop (TCP-In)
Go to the Properties->Scope tab
Add the IP (or IP range) in the Remote IP addresses section


Is it safe to publish some internal IP of my company?

It is (mostly) safe, depending on your organization.

IP addresses are not technically meant to be hidden. Security through obscurity is hammered into any security-minded individual as the one true evil. Technically, any IP address on your network can be discovered fairly easily by anyone determined enough to find it.

From a security standpoint, assume that every server on your network is known. Though try convincing your company's security team that is a different story. Ergo, your company policies may be a completely different matter.

The one thing I can see being a problem is revealing your network structure to potential outside attacks. Let's say you worked at Valve on this brand new game called Half-Life 2. You posted a question about access issues with your source code repository, and forgot to obfuscate it. Then someone doing a targeted attack against Valve may be able to access this repository from a compromised system. If you're unlucky, there's no authentication required to access the full source code.

Of course any attacker capable of compromising the system in the first place can very well figure out the repo on his own. In most situations, attackers will be able to figure this stuff out by the time they have any sort of intranet access to your network.


While one can see from the server log that an exploit was attempted using the Shellshock vulnerability it is impossible to say based on this log alone if the exploit was successful.

Your first check should probably be to find out if your system is vulnerable against this kind of exploit at all. This should not be the case if your system has current updates. If your system is vulnerable then you should treat it as compromised, no matter if from the recent exploit attempts or from older attempts since the bug is known and exploited for a long time.


Is there a way to download a PHP file without it being executed?

If the server is configured correctly, you cannot download a PHP file. It will be executed when called via the webserver. The only way to see what it does is to gain access to the server via SSH or FTP or some other method.

This is because PHP is a serverside language, all the actions are performed on the server, then the result is sent to your browser (which is clientside).

If you are afraid to mess with your system, you could use Virtualbox with an Ubuntu VM and open the page from there. If you take a snapshot of the VM after installing, and before doing dangerous things, you can later go back to that snapshot and undo anything the script could have done to the VM.


Clarifications regarding ciphers and Nmap scan

You are asking multiple unrelated questions which is not the recommended way to ask and chances are that the question might be closed as too broad or as duplicate since some part was already answered somewhere else. Still, to give some short answers:

  As per the doc, the Ciphers marked as "E" is the weak cipher and in another way can I consider the cipher marked as "A" as the strong cipher?

It clearly says in the documentation

  The scoring is based on the Qualys SSL Labs SSL Server Rating Guide, but does not take protocol support (TLS version) into account, which makes up 30% of the SSL Labs rating.

The relevant guide can be easily found and it includes an explanation of the scoring at the very beginning. But yes, 'A' means essentially stronger then 'B' etc.

  TLS_RSA_WITH_AES_128_CBC_SHA is marked as "A" here, but in some discussions, I have observed it is mentioned as WEAK. Is it because of the SHA1 usage? if so why this is rated as "A" in NMAP?

Because the nmap script is based on a guide from 2009. While TLS_RSA_WITH_AES_128_CBC_SHA isn't weak it would today probably be graded down to B since it uses RSA key exchange (no forward secrecy). But it is far from weak and I don't know who claimed this (please always add links if you cite opinions from somewhere else).

  ...SSL_RSA_WITH_RC4_128 is not available in the Nmap output, instead, there are ciphers like TLS_RSA_WITH_RC4_128...

These are the same. There are several naming conventions originating from different times or software products.

  Even though I have added the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as a cipher in my server, it wasn't available in the Nmap results, what might be the reason for this?

As you can see there are only RSA ciphers in the nmap output. This is because you are using a certificate with an RSA key. For ECDSA ciphers you would need to use a certificate with an ECC key.


Phone got pick pocketed and I got a huge bill

I will answer this based on a vast amount of experience while working at an ITSP

  What device do the thieves use in order to make hundreds of calls per
  minute?

Toll fraudsters can install mobile to voip based apps which connect your mobile device to a Voice Over IP device. The VoIP trunk is then making making calls under your credentials. It works like this:

YourPhone (via mobile to VoIP app) --> make a VoIP call --> rogue VoIP trunk
rogue VoIP trunk --> generate xAmount of calls --> trunk provider

  How can the organizations who make the calls with the stolen phones
  not get caught? I mean every single transaction is tracked and in
  order for the thieves to withdraw any money they should have to
  provide an identity, and bam they should be easy to track down and get
  charged for the crime?

You're dealing with an international issue of which there is no fix. When a call is made it works like this:

Your carrier --> another carrier --> another carrier --> 1..3 --> end destination

Each carrier acted in good faith to place the call for you. There was no way any provider (except the rogue ones) would know a call was fraudulent. Now, in a most cases that I have dealt with, it worked like this:

Victim's Phone (US) --> another US carrier --> carrier in say England --> carrier in Africa

Our laws don't apply in Africa, so it would be more costly for a carrier to go after someone in Africa being they'd have to sue the carrier in England, and the carrier in England would have to sue the carrier in Africa. It is more cost economic for carriers to "re-rate" the calls and bill you for the amount they stand to pay versus the wholesale amount.

  How can the phone providers (who probably deal with this every day)
  not be able to block transactions of tens of thousands dollars that
  are going from one phone to the organizations keeping? It feels like
  the phone providers are getting paid by the thieves, as long as the
  phone providers let's those transactions through.

Regulatory controls (gotta love them). Years ago, Sierra Leone was a known hotspot for fraudulent calls and engineers worked with many vendors to notify them of this however, there was no mechanism to outright block countries known for heavy fraud. There were too many variables (e911, etc). Some carriers outright don't care to stop it, as some profit off of it at the end of the day.