Introduction
Telecommunications companies nowadays became huge enough to have millions of subscribers under its hood, those companies are doing their best to digitalize and revolutionize their online services to serve the needs of the mass subscribers, In a result of this digitalization process, many security weakness may appear which could affect the safety of customers data like vulnerabilities which could hit company’s infrastructure or a bug found in their online services will have catastrophic impact on the masses and pose a real risk to the company subscribers.
Today we will be showing a case of how the poor development and missing security best practices of the online services and mobile application of “Etisalat Misr” cloud have lead to some serious problems and security control failures of which we will be listing some of it here in this blogpost but first let us get to know who is “Etisalat Misr”!
Based on Wikipedia article:
Etisalat Misr (Arabic: اتصالات مصر; Egyptian Arabic: Etiṣalat Maṣr) is a subsidiary of Etisalat U.A.E., the sole telecommunications services provider in the United Arab Emirates from 1976 until the arrival of Du in February 2007, and the first 3.5G network operator in Egypt. Etisalat Misr is one of 15 service providers managed by Etisalat in the Middle East, Asia and Africa. Etisalat group currently has access to a potential market of just below 1 billion subscribers and today Etisalat services over 130 million subscribers including the total number of fixed-line, Internet, mobile and television from each of its subsidiaries. In November 2007, Etisalat Misr upgraded to 3.75G which is the marketing term for HSUPA (High Speed Uplink Packet access). The Uplink channel carries information from the mobile terminal to the network such as file uploading, e-mail attachments and user response in interactive games. HSUPA is an enhancement of 3.5G networks that increases upload speeds. HSDPA stands for High Speed Downlink Packet access. A Downlink channel carries information from the network to the mobile terminal such as video and music downloads. Etisalat Misr was the first mobile operator in Egypt to offer Downlink speeds up to 7.2 Mbit/s which is two times faster than 3.5G downlink speeds. Today, Etisalat Egypt’s 2G and 3G robust and high quality network covers and serves 99% of the population in Egypt, with download speed reaching up to 84Mbit/s. Moreover, Etisalat Misr is the first and the only operator in Egypt that has an exclusive international gateway. In order to complete Etisalat Misr’s product portfolio, two well-established ISPs (Internet Service Providers) were acquired and provide broadband services.
Now let’s dive into the technical details of some security issues we found passively without touching the company’s infrastructure assets!
#1 Etisalat Misr is leaking valid user’s sessions on Google search and via unencrypted communications
Story
During our research, we were looking for any leaked information using search engines like Google and other, what we found is that Etisalat is allowing search engines to archive their user’s valid sessions which led to leaking valid user’s sessions tokens using a simple Google search with specific search dorks. This also highlights the very know issue of performing actions using GET requests which i n our example Etisalat fell a victim to it and used a GET-based request to authenticate subscribers which also resulted in archiving those requests by various search engines and using a simple Google search dork like “etisalat.eg AND inurl:param”.
Affected Asset(s)
Etisalat.eg Subscribers and DSL/Hotspot subscriber’s portal, GET requests containing “param” parameter value with a valid session token.
Issue Technical Details
- Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim’s browser use it.
- Using GET-based request for Session management.
- Allowing search engine bots to crawl pages with personal information.
Impact(s)
- Information disclosure.
- Attackers will have the ability to easily log into subscriber’s accounts and perform actions on their behalf.
- Subscribers loosing credit or getting over-charged bills.
Proof of Concept
- Etisalat DSL Session Leak leads to account over-charge and non-secure communications!
- Etisalat Misr Session URL works over other ISPs proving Session Fixation bug
- Actions that the attackers might perform on user’s online services accounts
#2 Etisalat Misr Mobile App is maintaining access of recycled SIM cards
Story
Etisalat Mobile App is maintaining access of a SIM card even after it is being recycled, the whole story begins when i bought a SIM card and registered it on “My Etisalat” Mobile Application then haven’t used the SIM card for approximate of 4 months, what happened is that the SIM card has been recycled which is a normal procedures for an unused SIM card after sometime but i found that i still have full control over the SIM card full operations through “My Etisalat” Mobile Application and i was able to perform actions on behalf of the new subscriber, knowing all the personal information of the new subscriber along with his/her credit, subscribing plan, etc…
Affected Asset(s)
Etisalat Mobile Applications and recycled SIM cards.
Issue Technical Details
- Broken Access Control, Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user.
- Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim’s browser use it.
Impact(s)
- Loosing control over the recycled SIM cards.
- Information disclosure.
- Attackers could perform actions on behalf of the owners of recycled SIM cards.
- Subscribers loosing credit or getting over-charged bills.
Proof of Concept
#3 Etisalat Misr is Leaking subscriber phone number to ANY Third-Party Website violating subscriber’s privacy
Story
Etisalat Misr is using some internal javascript scripts to identify the current user’s mobile number, this works as a helper to some Etisalat services to show information about the user’s plan, credit, and other personal information, but the problem is that those Javascript files are “DYNAMIC” which means, once called, they are being generated dynamically based on the current user’s session including information about the logged in user or based on the internet connection they are using, which lead those information to be hijacked by ANY third-party website.
Affected Asset(s)
Etisalat User Widget
Impact(s)
- Privacy violation.
- Information disclosure.
- Ads targeting and re-targetting.
- Subscriber Mobile Phone leakage.
- Targeted attacks based on subscriber mobile number.
Issue Technical Details
- Dynamic generated Javascript Resources, Modern Web sites frequently generate JavaScript on-the fly via server-side scripting, incorporating personalized user data in the process. In general, cross-domain access to such sensitive resources is prevented by the SameOrigin Policy. The inclusion of remote scripts via the HTML script tag, however, is exempt from this policy. This exemption allows an adversary to import and execute dynamically generated scripts while a user visits an attacker-controlled Web site. By observing the execution behavior and the side effects the inclusion of the dynamic script causes, the attacker is able to leak private user data leading to severe consequences ranging from privacy violations up to full compromise of user accounts.
- Same Origin Policy is an important concept in the web application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page’s Document Object Model.
Proof of Concept
Code:
<html>
<body onload="alert(top.tlbs['msisdn']);">
<script src="http://105.203.255.69:8080/get?time=1565954987928&tlbsip=http://105.203.255.69:8080/&website=www.etisalat.eg&charset=utf-8">
</script>
</body>
</html>
Video:
#4 Etisalat Misr is Injecting its “Etisalat Widget” in ANY unencrypted communications
Story
Etisalat has something called “Widget” which shows the subscriber some information about their own personal information and plan, this widget is simply a combination of HTML, CSS and Javascript files which may look useful from the first glimpse but while using some Mobile Applications (some of them are sensitive banking applications) or visiting some HTTP requests over Etisalat DSL or Etisalat mobile internet we have noticed the injection of Etisalat’s widget which an obvious user privacy violation and also a security issue in ANY apps/websites/services using insecure HTTP communications.
Affected Asset(s)
- Any Insecure Communications/Websites/Services
Impact(s)
- Man in The Middle Attacks.
- Sessions Hijacking
- Information disclosure.
- Privacy violation.
Issue Technical Details
- Insecure Transport, The application configuration should ensure that SSL is used for all access controlled pages. If an application uses SSL to guarantee confidential communication with client browsers, the application configuration should make it impossible to view any access controlled page without SSL. However, it is not an uncommon problem that the configuration of the application fails to enforce the use of SSL on pages that contain sensitive data.
#5 Bonus issue: Etisalat Misr User Portal over Unencrypted Communications on Etisalat.eg domain
Story
While visiting some of the URLs mentioned in issue #1 we noticed that most of those portals are being server over HTTP.
Affected Asset(s)
- Etisalat.eg web portal.
Impact(s)
- Man in The Middle Attacks.
- Sessions Hijacking
- Information disclosure.
- Privacy violation.
Issue Technical Details
- Insecure Transport, The application configuration should ensure that SSL is used for all access controlled pages. If an application uses SSL to guarantee confidential communication with client browsers, the application configuration should make it impossible to view any access controlled page without SSL. However, it is not an uncommon problem that the configuration of the application fails to enforce the use of SSL on pages that contain sensitive data.
Proof of Concept
So what i -the normal user- should do?
We highly recommend Etisalat Misr’s subscribers to perform the following actions:
- Register their SIM cards on Etisalat’s Mobile Applications as soon as you buy or use a new SIM card because somehow this SIM card which you think it’s a brand new probably have been used before by another subscriber and expired and ended up in your phone but the mobile application which owned by the old subscriber still maintain access to its information.
- Do not use Etisalat’s web service until they fix the vulnerabilities in their services.
- Logout from all the web sessions you may did to invalidate the stored sessions in their servers.
- Use VPN to get rid of their Widget injection inside the *Apps* and websites you are using.
- This blogpost will be updated so come back later for further updates.
Resources
- https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-lekies.pdf
- https://www.owasp.org/index.php/Insecure_Transport
- https://en.wikipedia.org/wiki/Same-origin_policy
- https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control
- https://owasp.org/index.php/Session_fixation
- https://www.owasp.org/index.php/Top_10-2017_A1-Injection
- https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication
- https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure
- https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control
- https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration
Disclosure Timeline
- August 24, Initial communication with a third-party person who was an ex-employee in Etisalat Misr to ask for help to get us in touch with security representative from Etisalat Misr.
- August 26, 2019: Initial communications acknowledged by the third-party person who is a personal friend of the representative person of Etisalat Misr and an Email thread started.
- August 28, 2019: I replied the third-party’s email messages acknowledging the initial communications but no reply from Etisalat Misr’s representative person.
- August 31, 2019: Ping due to Inactivity.
- September 2, 2019: Third-party person replied on Facebook Messenger that the representative person told him he couldn’t receive my reply (we have no idea why and we are not sure if he received the third-party initial communications email either)
- September 3, 2019: We received a Facebook Messenger message from the third-party says “The representative person says can you please send him an email to his personal gmail email” because our email didn’t reached him”
- September 3, 2019: We sent an initial communication email to the personal gmail email to the Etisalat Misr’s representative person.
(Usually we are tracking our important emails and we can assure that our messages sent here got some open notifications and link click notifications too) - September 10, 2019: A public facebook post have been made to reach someone from Etisalat Misr’s security team due to inactivity of the representative person.
- September 11, 2019: This blogpost has been written reflects the security vulnerabilities affects Etisalat Misr’s online services.
- September 12, 2019: Communications continues through another third-party person and we delivered a clone version of this blogpost as a report.
- October 1, 2019: We haven’t received ANY feedback from Etisalat Misr hence this blog-post became publicly accessible.
Aftermath
We sent a report with full details of the findings to Etisalat Misr on Sep 12, 2019 and we have not received any feedback or a follow-up about the issues/fixes tracking.
DISCLAIMER
- Those vulnerabilities have been discovered PASSIVELY without performing any active tests hence no harm or damage has been caused.
- This report is subject to Seekurity SA de C.V. responsible disclosure rule #2 which indicates a 5-days-disclosure-deadline due to the severity of the included vulnerabilities in the report. All details mentioned in the report along with any future updates will become visible to the public through our official communication channels in one of those cases (not all):
1. After the mentioned period elapses from the time and the date of sending the report.
2. A patch has been made broadly available.
3. A non-responsive communications state.
A minute if you please!
Building a website, an application or any kind of business? Or already have one? Worried about your security? Think twice before going public and let us protect your business!
Egypt Etisalat Etisalat Misr online Security services Telecommunications Vulnerabilities
Previous Next