Looking over that, it does NOT appear to be anything special. They're essentially just tricking a user into installing a modified version of the original application in order to steal the user's credentials FOR THAT application. It does NOT give them access to any data from any OTHER application aside from data that is accessible based on granted permissions. The part that makes it a slightly novel approach is the fact that they're embedding the original unmodified version of that application into the modified application rather than putting in the work to reverse engineer parts of the original application in order to patch their new functionality into it.
The solution to this problem is simply to not install software from sketchy sources. Ideally, verify the apk signature with the vendor prior to installing.
The real solution is that Android needs a better system for package signature verification. Right now, original installation of packages relies on whether or not you trust the installation source (i.e., play store, f-droid, etc.) -- a lot can be done to make this system more robust, like publishing public keys for signature verification on DNS and verifying those signatures on installation by querying the package name from DNS to retrieve the public key. Obviously this introduces an additional point to verify (which IMO really should be verified ANYWAY), which is whether or not the package name is connected to a trustworthy domain. Fortunately, that is usually pretty easy to verify through a combination of public trustworthyness lists and simply presenting the domain name (package name) to the user. Trying to install CIBC bank application, package name com.cibc.android verifies against DNS for android.cibc.com --> checks out, BUT package name casino.freemoney.com.cibc.android against DNS for android.cibc.com.freemoney.casino --> Huh? Signature verifies correct, but Big red flags because that domain is a steaming pile of WTF.