Core: Critical Information Exposure

[alaskanrogue]

.NET Critical Information Exposure

Examination of the binaries of the different .NET Core based Xamarin platforms for the same application reveals that information which might be usable by cyber-criminals for using/attacking web-services is embedded. For improved security and stability of applications and systems, such information should be encrypted in the binaries and decrypted as needed during run time. Yes there may be a performance impact, but minimal as the number of elements needing this added level of security typically is small. Perhaps it should be a build option. Examples:

From an UWP exe:

TAction4https://server.domain.com/AcctTReplyAction


T SupportFaults
Q
 TAction3https://server.domain.com/PIDTReplyAction
Q


From an iOS exe:

TRequestNamespace0https://server.domain.com/TResponseNamespace0https://server.domain.com/TU€†System.Web.Services.Description.SoapBindingUse, System.Web.Services, Version=2.0.5.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3aUse TU€ˆSystem.Web.Services.Protocols.SoapParameterStyle, System.Web.Services, Version=2.0.5.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3aParameterStyle ò
3https://server.domain.com/PID

From an Android APK:

TRequestNamespace0https://identityservices.identitycheckpoint.com/TResponseNamespace0https://server.domain.com/TU€†System.Web.Services.Description.SoapBindingUse, System.Web.Services, Version=2.0.5.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3aUse TU€ˆSystem.Web.Services.Protocols.SoapParameterStyle, System.Web.Services, Version=2.0.5.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3aParameterStyle ò
3https://server.domain.com/PID

Assuming that the hackers obtain a copy of the application and has access to the executables, with that access, simply using Notepad. and in the .exe file, if they search for "http", they can obtain the domain address of a service, e.g. "https://server.domain.com", which represents an endpoint. Additional information which identifies a service's methods is found:

"h t t p s : / / s e r v e r . a z u r e w e b s i t e s . n e t / s u b s c r i p t i o n s e r v i c e s . a s m x A c c t P I D S S N U I C C B A T F V S

They find that there are associated event handlers for the method, "PIDCompletedEventHandler", and associated operations, "OnPIDOperationCompleted". In their analysis of the .dll, they can discover the parameters and their types, e.g.:

Further study reveals the objects, properties and the associated constraints that might be in use:

< E n t i t y T y p e N a m e = " A c c t " > < K e y > < P r o p e r t y R e f N a m e = " I D " / > < / K e y > < P r o p e r t y N a m e = " I D " T y p e = " E d m . I n t 6 4 " N u l l a b l e = " f a l s e " p 6 : S t o r e G e n e r a t e d P a t t e r n = " I d e n t i t y " x m l n s : p 6 = " h t t p : / / s c h e m a s . m i c r o s o f t . c o m / a d o / 2 0 0 9 / 0 2 / e d m / a n n o t a t i o n " / > < P r o p e r t y N a m e = " I C I D " T y p e = " E d m . I n t 6 4 " N u l l a b l e = " f a l s e " / > < P r o p e r t y N a m e = " A N " T y p e = " E d m . S t r i n g " N u l l a b l e = " f a l s e " M a x L e n g t h = " M a x " F i x e d L e n g t h = " f a l s e " U n i c o d e = " t r u e " / > < / E n t i t y T y p e > "

As an application user, they knew the parameters, types and controlling factors of specific actions. Now they know enough to potentially, with some effort and skills, build their own code to access the webservice/api/interface. The example is based on identity use. With Dark Web information, access and subsequent actions could enable criminal activity.

[blowdart]

Thanks for the report, but this appears to be security by obscurity. There are even easier ways to get this information by putting a proxy like fiddler between a client and the servers it calls, this doesn't even need an attacker to acquire the executables. It seems to me that obfuscating text in a binary is a very low hurdle to overcome.

For next time though please report security bugs to [email protected] rather than via github. You may end up eligible for a bug bounty that way.

[alaskanrogue]

Microsoft Support suggested I start a discussion on the issue here for discussion.

Yes, in the unencrypted world, the proxy approach works nicely, but we have been moving away from that for years. From your perception, you only need to lock the front door as the crook isn't smart enough to check if the back door is unlocked. Maybe in your neighborhood that is normal.

We don't need full cyber-security for games, but for business, government and the military applications we do. I didn't say obfuscating. I said encryption which isn't a muddying of the waters. Every piece of information, if exposed, might become the key to opening the door of the safe to those not authorized. That is what cyber-security is suppose to PREVENT. In .NET based applications, the exposure of this type of information is a major implementation flaw.

[scalablecory]

I'm going to close this issue -- I don't think it makes sense for us to implement, for reasons given by @blowdart. Thanks.

[svick]

@alaskanrogue If you're talking about HTTPS, then that secures communication from the client machine to the server machine. But it doesn't prevent somebody with access to the client machine to get to that information.

If you're giving a binary to someone, you should assume that they can understand what exactly that binary can do. No amount of "encryption" (but it is more accurate to call it obfuscation) will prevent that.