FEDEX & Eurosender Portugal: The Story of a "Fraudulent" Service that became a Nightmare #FEDEX #Eurosender

Today I want to tell you a story of corporate mismanagement that caused FedEx and their partner in Portugal, called Eurosender, to drag us into a mess we haven't been able to get out of yet. No solution, poor management in pre-sales, poor handling of incidents, and poor decision-making. All of this because in the 21st century they don't have a system that prevents something completely missleaading: issuing invoices for a service they cannot execute, collecting payments for a service they won't provide, and getting clients into trouble.

Figure 1: FEDEX & Eurosender Portugal: The Story

of a "Fraudulent" Service that became a Nightmare

If FedEx and Eurosender Portugal had an information system that blocked the issuance of invoices for services they cannot carry out, customers wouldn't end up in this mess. But above all, they wouldn't be issuing misleading invoices.

Summary

Let me explain it to you. Imagine you go to a parcel shipping company and tell them you want to send six bottles of wine. The company's agent tells you there is absolutely no problem and asks you to write down exactly what you want to send so they can generate the invoice. You write exactly what you said: that you want to send six bottles of wine. Then, after reading what you want to ship, the agent creates a proforma invoice providing the retail price for sending those six bottles of wine. You pay the invoice, they come and pack the bottles, you write on the box that it contains wine, and you walk away happy because your colleagues are going to love the Christmas gift you are sending them.

Well, as it turns out, the company later tells you that they cannot ship wine, that it is stated in their terms and conditions, and that you have to pick up your package. But of course, to take your package back home, you have to pay—on top of the shipping costs you already paid—the fees of a customs broker, plus €10 for every day the bottles you sent are kept in storage at customs. To top it all off, you don't even know, nor will they tell you, the exact date the package arrived.

This is the story that a friend and I are currently caught up in with FedEx and their partner Eurosender, and I am sharing it with you so you can avoid ever running into these kinds of problems, which are anything but fun.

I've just given you the summary, but now I'm going to walk you through it with dates, invoices, and conversations so you can see how these companies operate—and, of course, to see if I can get my package with my wine bottles back. While I'm at it, let's see if I can raise awareness among some executives at FedEx or the Portuguese regulator to prevent this from happening again.

Sending wine to colleagues  

It all started on Three Kings' Day (January 6th), when I asked my colleague to help me with this. I had previously shipped several individual bottles from Spain to Amsterdam, Belgium, and Germany without a single issue. However, to ship them from Portugal to the United Kingdom, we chose FedEx and their partner company, Eurosender.

First, we called them by phone, and they told us there was no problem, that they could handle the shipment, and that we just needed to fill out the details on the website and they would take care of everything—from pickup to delivery, backed by the FEDEX GUARANTEE. So, that's what we did. We filled out the details and accepted the terms, as you can see in this image of the Proforma Invoice from January 6th: "Yes, we certify that the information is correct." As you can clearly see, the description explicitly states it is wine.

Figure 2: Proforma Invoice.

Nobody is tricking anybody here. If there is an issue entering the UK or leaving Portugal, the company can easily flag it. Moreover, if they simply do not ship those types of products, they should detect it and cancel the order. It's that simple. But no, they reviewed the invoice, and happy as clam, they sent us the corresponding invoice for us to pay.

Figure 3: Payment invoice with reference code linked to the proforma invoice.

As you can see on the invoice, they are billing us to ship Reference Code: 734836-26, which, as shown, goes from Portugal to Great Britain. In other words, they are invoicing us to ship WINE from PT to GB. Everything seemed correct, which is exactly what we intended to do.

The nightmare began

Until they collected the money for the service, everything was smooth sailing. But on January 23rd, more than two weeks later, the worst customer service I have ever seen began with a message stating that the package was supposedly arriving back in Portugal and we needed to go through a customs clearance process for the goods.

 

Figure 4: Email received from FedEx—but which actually comes from Eurosender.

As you can see, my friend received a message stating that the goods are coming to Portugal, and that to get them out, we have to pay taxes for bringing alcohol into Portugal plus administrative costs (duties), and that’s it. In that same communication, they also provided us with the ruling from the United Kingdom, where, as you can see, it states it is WINE and must be returned to its origin.

Figure 5: UK Border Report from January 22nd.

In other words, it turns out you cannot ship wine without a special export process, even if it is a gift. Perfect. Nobody had told us anything, which is what we expected from FedEx, being a world leader in parcel delivery. After a week of not having the details entirely clear, I kindly asked them to explain the process to me step by step—something they should have done before shipping the package in the first place.

The Worst Customer Service Ever: FEDEX Portugal  

As a result of this, they told us we had to pay, but they wouldn't clarify how much. And, above all, they couldn't tell us when the goods would actually be back in Portugal. In fact, the conversation was so vague that we didn't know if paying meant they would send it to GB or not, nor did we know if it had already returned. Then they told us it wasn't there yet.

Figure 6: On January 23rd, the goods were not here.

When we stated that we wouldn't pay until they clarified the process—just to know whether they were going to ship it or not—they threatened to "return it." Return it where? We are supposed to be the destination it's being returned to, and all we want is for them to give us our package and forget about this mess.

Figure 7: Chaos in customer support. One week asking

questions about the process with poor clarity.

When I told her that I didn't understand, that what she was saying made absolutely no sense, and asked her to please explain what was going on, she replied very rudely, saying that "it seems I am very interested in knowing the whole process," and that only the declaration was missing to proceed with the clearance process, after which I would finally get my package back.

Figure 8: After a week, they threaten to return a package that hasn't even arrived in

Portugal yet, which is where we supposedly want to send it. Utterly senseless.

In the end, we filled out the declaration they asked for—which was just a signed Word document stating it contains wine—thinking that with this, we would either be able to ship it or get it back. But it wasn't going to be that simple, as you can imagine.

Figure 9: We submit the declaration requested on January 29th.

After that, on February 11th, we asked our FedEx "Broker," and she told us she had no idea when our package would arrive, even though we had sent the requested declaration back on January 29th.

Figure 10: No forecast from our FEDEX Clearance Broker-Associate

Suddenly, on February 19th, we received a message from FedEx UK stating that the deadline to return the goods they shipped from GB to PT was February 19th—meaning, the very day we received the message.

Figure 11: FedEx UK.

But the funniest part is that the next day, February 20th, we received a message from our FedEx Broker telling us that we needed to hire a broker.

Figure 12: You need to hire a broker.

To which, thoroughly surprised, I replied that we thought she was our broker, as indicated in the signature of every single communication we had with her from minute one.

Figure 13: I thought you were our broker.

But no, she told me that FedEx does not process those goods—the very goods they charged us for, and the sole reason we contacted them in the first place. To make matters more surprising, this person also works for the partner company and sometimes replied to us from Eurosender.

Figure 14: FEDEX PT & Eurosender PT

So, modern problems require modern solutions: instead of a broker, I have hired a lawyer. I am demanding the return of both the package and the money. To this, they replied on one hand that they would try to get it done, and on the other, that they have no intention of returning either the package or the money until we hire an external broker.

Figure 15: 28th of April after hiring a lawyer

So right now, the package must be waiting for UK clearance to see if it enters the country or gets sent back to its origin in Portugal. It might just be traveling for eternity between Lisbon and London, all due to an infinite lack of professionalism and a misleading invoicing system that allows them to charge for services they will never perform.

Figure 16: That´s the big issue of everything

I will keep you updated on this, because I am going to see this through to the very end. As you can imagine, the €200 that the bottles and shipping cost matter very little at this point in the chaos; what matters is knowing whether the law allows a company to have a system that bills and collects money for services it will not provide. I'll keep you posted.

Best Regards,

Autor: Chema Alonso (Contactar con Chema Alonso)  

Una Campaña de Smishing con SMS Spoofing usando a la Dirección General de Tráfico con la Operación Salida de Libro

La semana pasada me llegó a mi número de teléfono personal un ataque de Smishing para capturar mis datos personales y, por supuesto, mi tarjeta de crédito. El gancho, que la Dirección General de Tráfico (DGT) me había puesto una multa durante la Operación Salida de Agosto y, cumpliéndose el mes, se me acababa el tiempo para pagarla con Descuento.

Figura 1: Una Campaña de Smishing con SMS Spoofing usando

a la Dirección General de Tráfico con la Operación Salida de Libro

El mensaje me vino por SMS, como he dicho, y utilizaba técnicas de SMS Spoofing para que se colara dentro del flujo de mensajes que recibo de la DGT cuando utilizo su app, así que los atacantes prepararon bien la campaña.

Figura 2: El Smishing con el el dominio de Phishing

haciendo SMS Spoofing con el número de la DGT

Ví el mensaje desde el iPhone, sin tener mis gafas a mano y pensé... ¡porras! una multa. El SMS Spoofing, añadido a que alguna vez de eses muy raras he sufrido una "multilla" con mi Malignomóvil, hacía que esa posibilidad estuviera dentro del universo de lo posible. Pero no sólo eso, sino que cuidaron todos los detalles como manda el manual del buen Ciberestafador, como bien nos cuenta Juan Carlos Galindo en su pedazo de libro.

Figura 3: "Ciberestafas: La historia de nunca acabar" (2ª Edición).por Juan Carlos Galindo en 0xWord.

Si me has visto utilizar el iPhone cuando no tengo las gafas a mano, habrás visto que golpeo con mis tres deditos para hacer uso de la lupa. Sí, ver de cerca bin sin gafas no es una de mis capacidades hoy en día, así que uso las opciones de accesibilidad para aumentar el contenido de la pantalla, así que hice clic en el enlace - que veréis que está claro que es un sitio de phishing -, y entré a ver la web.

Figura 4: La web de phishing para mobile

No saltó ninguna protección de Apple Safari para iOS de sitio fraudulento, y la multa describía el hecho el día 1 de Agosto, en plena Operación Salida. Ese fin de semana yo tenía que viajar, que me incorporaba, como ya os conté, al lunes siguiente en Cloudflare, así que viajaba ese día. 

Figura 5: La web de phishing pide datos y los valida

Era fin de mes, había pasado todo el mes de Agosto y caducaba la Reducción del 50% así que decidí que mejor pagarla cuanto antes, pero como no tenía gafas a mano, copie el SMS y me lo envíe por Telegram a los Saved Messages para hacerlo desde el ordenador, a gran pantalla.

Figura 6: Y tras los datos, debes dar los datos de tu tarjeta de crédito.

Si lo haces, te va a salir caro el "descuento" de la multa.

Me puse las gafas, y confiado por todo el proceso, hice clic, y en ese momento me saltó un error de NGINX en el navegador  - Google Chrome para MacOS -, y fue cuando acabó la magia. Ahí ya me fijé en la URL, y como os podéis imaginar, me di cuenta de todo. El Cloacking que hacía ese sitio para evitar conexiones que nos fueran desde USER-Agents de móviles evitaba que se viera el sitio de Phishing desde el escritorio.

Figura 7: Dominio detectado como Phishing en Chrome

Hice las capturas, para contaros esta historia, y a día de hoy el sitio ya está caído, y bloqueado en los filtros antiphishing de Google Chrome, pero me quedé pensando en cuánta gente habrá entregado su tarjeta de crédito y sus datos a una campaña que estaba tan bien preparada. Había hecho.

• Un sitio de Phishing para mobile, con una típica URL de phishing.
• Habían hecho cloacking con el USER-Agent para evitar "curiosos" o "no provenientes del Smishing"
• Una campaña de envío masivo de SMS Smishing
• Habían utilizado SMS Spoofing para meterse en el hilo de DGT de los mensajes
• Habían enviado la campaña a finales de mes con el la urgencia del pago con descuento
• Habían puesto el motivo con algo que podría ser factible: Una multa el día 1 de Agosto.
• Habían conseguido saltar los filtros antiphishing de los navegadores. Apple Safari para iOS lo marca como caído, pero no como marcado.

En mi caso funcionó todo, a excepción de que lo que se había convertido en una ventaja para ellos - que no veía bien sin gafas y no me pude fijar en la URL en el móvil - se convirtió en una protección cuando lo intenté hacer desde el ordenador con mis gafas. 

Figura 8: Libro de Hacking iOS:iPhone & iPad (2ª Edicón) en 0xWord de
Chema Alonso, Ioseba Palop, Pablo González y Alejandro Ramos entre otros.

Por ponerle alguna pega a la campaña, le faltó poner un precio mas realista ya que una multa de 35€ no es ni de aparcamiento en España, y si hubieran hecho la versión web solo para links con redirect usando algún parámetro de tracking, as lo mejor hubiera sido más efectiva incluso. Pero estoy seguro de que esta campaña habrá generado más de algún "premio" para los cibercriminales que la lanzaron. Así que, no hay que relajarse nunca y hay que evitar que la vida ajetreada nos haga bajar las defensas, que por quitarnos las cosas cuanto antes, podemos saltarnos alguna comprobación. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Open Gateway: Cómo detectar a un ciberestafador que manipula el GPS con FakeGPS usando el API de Device Location Verification

Las medidas de seguridad informática deben evolucionar al mismo ritmo al que evolucionan los sistemas de las tecnologías de información, y las amenazas que van a apareciendo. Las necesidades cambian y el mundo de la tecnología se adapta de forma dinámica, y las medidas de seguridad deben ir alineadas con los nuevos requisitos marcados por los avances tecnológicos actuales y las amenazas reales existentes. Y por desgracia, las ciberestafas y el fraude crecen en el ámbito digital y, por ello, debemos estar más preparados, aplicar nuevas medidas de fortificación, y ser conscientes de cómo podemos estar más preparados y de qué posibilidades contamos.

Figura 1: Open Gateway - Cómo detectar a un ciberestafador

que manipula el GPS con FakeGPS usando el

API de Device Location Verification

En el presente artículo se quiere hablar del problema de la falsificación de la ubicación y las ciberestafas que se crean. Hay gran cantidad de aplicaciones y servicios que necesitan verificar la ubicación lo más cercana o real posible de un usuario para ofrecerle un catálogo de servicios. O algo más crítico, que alguien se haga pasar por ti, ya que ha extraído o robado tus credenciales y se hace pasar por ti desde una ubicación lejana como, por ejemplo, un país extranjero o una ciudad en la que no vives. 

También para hacer fraude o simplemente para hacer una ciberestafa en una aplicación en la que la ubicación es parte fundamental del servicio, como las plataformas de transportes de personas y mercancías, las de citas, o las de servicios ofrecidos por ubicaciones GPS. También para evitar los controles de rutas hechos por esos servicios basados en ubicación GPS.

Figura 2: "Ciberestafas: La historia de nunca acabar" (2ª Edición).por Juan Carlos Galindo en 0xWord.

Un ejemplo muy claro de protección de sistemas basados en ubicación puede ser la comprobación de la ubicación del terminal móvil cuando se hace uso de una tarjeta de crédito, o comprobar que los accesos a funciones privilegiadas o servicios privilegiados son sólo válidos cuando una persona tiene su terminal móvil con él en una ubicación pre-establecida, como el lugar donde se realiza una compra, o el head-quarter de la compañía. 

Cómo detectar con una línea de código si un terminal está dónde dice que está

Por ejemplo, el acceso a funciones de alta seguridad en una CRA (Central Receptora de Alertas) o un SOC (Security Operation Center) podría ser solo accesible desde la ubicación del centro físico de la CRA o el SOC, por lo que comprobar la ubicación, y comprobar que esta no ha sido manipulada es fundamental. Esto, se puede hacer con el API de Device Location Verification. Vamos a trabajar con Open Gateway y vemos cómo se hace. Para ello partimos del siguiente escenario:

PRIMERO: Yo, como usuario, me encuentro en Distrito Telefónica y lo puedo mostrar con una aplicación como Google Maps. Partimos que estoy aquí. La ubicación es real.

Figura 3: Ubicación real en Google Maps

SEGUNDO: Un atacante utiliza la aplicación FakeGPS para engañar a una aplicación sobre la ubicación que proporciona el GPS del dispositivo. 

Figura 4: Con Fake GPS nos situamos en Málaga

Como se puede ver en la imagen se puede ver como el atacante como la ubicación GPS en Málaga, por lo que cuando la aplicación real haga uso del GPS del dispositivo móvil, ésta recibirá la ubicación de Málaga.

TERCERO: Ahora, en la siguiente imagen, se puede ver que (en este caso Google Maps) se obtiene la ubicación de Málaga. De esta forma si la aplicación hace restricción por ubicación para evitar algo se “bypassea” de forma sencilla por el atacante.

Figura 5: Google Maps nos detecta ahora en Málaga.

Hemos engañado a Google Maps con Fake GPS.

Esto debe ser tenido en cuenta, ya que no podemos fiarnos de dicha ubicación GPS, ya que puede ser modificada y evitar dicha restricción.

CUARTO: Ahora, con la API de Device Location Verification podemos acceder a información real sobre la ubicación, en un radio, dónde se encuentra el dispositivo, y verificar si de verdad se encuentra donde dice que se encuentra. 

Figura 6: API de Device Location Verification en Telefónica

Como se puede ver en la imagen siguiente, a pesar de lo que diga la información GPS, podemos ver gracias a la API de Device Location Verification  que el usuario NO se encuentra en Málaga, que es lo que indica el color rojo.

Figura 7: El API de Device Location Verification

confirma que no está en Málaga.

En otras palabras, lo que nos decía la aplicación anterior que había sido engañada con FakeGPS quedaría invalidado, ya que Device Location Verification nos indica que no se encuentra en Málaga. Para saberlo debemos ir validando diferentes radios que puedan cubrir varias zonas. El usuario tiene un consentimiento explícito en el uso de la API.

Figura 8: Ventajas del uso de Device Location Verification

Por otro lado, si probamos con Device Location Verification (y nuestro querido portal de demos de Open Gateway hecho en IdeasLocas) sobre el Distrito C de Telefónica podremos identificar que realmente nos encontramos ahí, y no dónde nos decía el atacante, como vemos en la imagen siguiente.

Figura 9: El API de Device Location Verification

confirma que estamos en Distrito C.

Es importante, entender que un servicio puede disponer de esta API para validar que un usuario no intenta engañarle con la ubicación, ya sea para abusar del servicio o cualquier intención que exista. Además, es un hecho fundamental cuando se quiere controlar las ciberestafas o el fraude y evitar las acciones sospechosas que se hacen desde ubicaciones lejanas, ya que se puede validar que el usuario no está dónde dice estar. Esto último tiene una clara alineación con evitar el fraude en pagos o transferencias.

Figura 10: Código en Python para detectar el fraude de ubicación.

El ejemplo anterior, con un código en Python, se puede ver cómo se accede a Latitud y Longitud del GPS y luego se verifica con Device Location Verification para detectar el fraude. Además de ese API, Open Gateway tiene la API de Device Status con la que se puede validar si el número se encuentran en Roaming o no. Esto es interesante, ya que permite también sumarle una capa extra de seguridad para identificar que no se encuentra fuera del país.

Figura 11: API de Device Status en Telefónica

En muchas ocasiones, ante un robo de tarjeta, credenciales u otros elementos se hacen uso de ellos desde ubicaciones lejanas (fuera del país), por lo que se puede controlar con Device Status y verificar realmente que la operación no se realiza desde fuera del país.

Figura 12: Telefónica Open Gateway: Developer Hub & Partner Program,

Las capacidades de seguridad que ofrece Open Gateway son altísimas, por lo que este es uno de los casos de uso que se puede encontrar. Iremos desgranando más casos de uso y no dudes en probarlo y revisar la documentación que existe. Tienes el Partner Program y el Developer Hub.

Saludos,

Autor: Pablo González Pérez, escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de Telefónica Innovación Digital.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Contactar con Pablo González

Cómo crear una aplicación y protegerse de ciberestafas con el API de SIM Swap

Si eres lector de este blog, seguramente ya habrás leído en más de una ocasión sobre Open Gateway y las enormes posibilidades que ofrece a los desarrolladores. Hoy quiero mostrar cómo crear una aplicación sencilla en Python para comprobar el estado de SIM Swap utilizando las APIs de Open Gateway y aprovechando el Sandbox de Telefónica para hacer pruebas sin riesgo.

Figura 1: Cómo crear una aplicación y protegerse

de ciberestafas con el API de  SIM Swap

¿Qué es SIM Swap?

Vamos a comenzar con una explicación de por qué esto es importante. SIM Swap es un evento de red que ayuda a detectar un tipo de ciberestafa en el que un atacante obtiene un duplicado de la tarjeta SIM de una víctima, mediante un engaño o una portabilidad entre empresas de telecomunicaciones fraudulenta, lo que le permite acceder a su línea de teléfono y recibir tanto llamadas de teléfono como mensajes SMS, lo que le da acceso a los códigos OTP de autenticación de segundo factor (2FA), o incluso realizar llamadas en nombre del usuario. 

Figura 2: "Ciberestafas: La historia de nunca acabar" (2ª Edición).por Juan Carlos Galindo en 0xWord.

Esto facilita el acceso no autorizado a cuentas bancarias, redes sociales u otros servicios sensibles que utilizan el SMS o la llamada como validación de 2FA, además de poder suplantar a la víctima en llamadas de teléfono fraudulentas. 

Figura 3: API de SIM Swap en Telefónica

Con la API de SIM Swap de Open Gateway, podemos verificar si el número de teléfono de un usuario ha sido asociado recientemente a una nueva tarjeta SIM, lo que permite prevenir fraudes de manera más efectiva.

Sandbox de Telefónica Open Gateway

Antes de acceder a los datos reales, es fundamental probar la aplicación en un entorno seguro. Aquí es donde entra en juego el modo mock del Sandbox de Telefónica Open Gateway, un entorno de pruebas que simula el comportamiento real de la API sin comprometer datos de usuarios. Antes de empezar a programar, hay que dirigirse al sandbox para crear la aplicación. Aquí encontraremos las APIs disponibles con las que podemos trabajar, estando actualmente Device Location Verification, Device Status, Number Verification y SIM Swap.

Figura 4: APIs disponibles en el Sandbox de Telefónica Open Gateway

Para la demo, se va a hacer uso de la API de SIM Swap. Tras seleccionar esta API y darle al botón de crear aplicación, se encuentra un formulario para rellenar información sobre esta. Desde aquí se puede seleccionar el modo de trabajo (producción o mock), indicar el nombre que se le quiere asignar a la aplicación, la URL de redirección (si es necesario) y una pequeña descripción.

Figura 5: Formulario de creación de aplicación

El siguiente paso es para aceptar los términos y condiciones de uso.

Figura 6: Confirmación de los términos y condiciones

En el último paso se muestra un resumen con toda la información anterior y el botón para confirmar y terminar con creación de la aplicación.

Figura 7: Resumen de la aplicación y confirmación

Ahora, en el apartado de “Mis aplicaciones”, se puede ver la nueva aplicación creada, aunque podría estar pendiente de validación. 

Figura 8: Información de la aplicación creada

Desde aquí se puede conocer el identificador de la aplicación, así como el secreto que será necesario para autenticarse al realizar llamadas a la API.

Ejemplo de aplicación SIM Swap en Python

Para comenzar a crear la aplicación en Python se tienen dos opciones:

• Revisar la API e implementar todas las llamadas para conseguir la autorización y las llamadas a la API de SIM Swap usando alguna librería como puede ser requests.

• Hacer uso del SDK que está preparado para trabajar con el sandbox.

Esta última opción es el que se opta por utilizar en este ejemplo para agilizar la creación de la aplicación. Su instalación se puede hacer con pip, indicando el paquete opengateway-sandbox-sdk:

pip install opengateway-sandbox-sdk

Ahora, se crea un nuevo script de Python  y vamos a definir una función que, dado un número de teléfono, cree una instancia de Simswap con los datos de nuestra aplicación (Client ID y Client Secret que se encuentran en la información de nuestra aplicación creada en el sandbox), así como el número de teléfono (en formato E.164) que se desea consultar. 

Se ejecuta la función retrieve_date() para obtener la fecha del último cambio de emparejamiento MSISDN <-> IMSI, o lo que es lo mismo, la última vez que el número de teléfono (MSISDN) fue vinculado a una nueva tarjeta SIM (IMSI).

Figura 9: Función para obtener última fecha de cambio de SIM

Este sería el código más básico para poder hacer uso de SIM Swap a través del SDK. Vamos a ampliar un poco el código para poner validación del número de teléfono y que se pueda pasar un número de teléfono o un fichero con un listado de número a través de parámetros al iniciar el script. Creamos una nueva función que, pasado un número de teléfono, compruebe a través de una expresión regular que cumple con el formato E.164. 

<->

Figura 10: Función para validar que un

número está en formato internacional

<->
La expresión regular que aparece en re.compile(r"^\+[1-9]\d{9,14}$") está diseñada para validar números de teléfono en formato internacional. Veamos en que consiste cada parte:

• <->^: Marca el inicio de la cadena, asegurando que no haya caracteres antes del número.

• <->\+: Busca el símbolo "+" al principio del número, que es obligatorio en los formatos internacionales.

• <->[1-9]: Busca un dígito entre 1 y 9, lo que impide que el código de país comience con 0 (en números internacionales, los códigos de país nunca empiezan por cero).

• <->\d{9,14}: Busca entre 9 y 14 dígitos después del código de país, representando el número de teléfono.
• <->\d significa cualquier dígito (0-9).
• <->{9,14} especifica que debe haber un mínimo de 9 dígitos y un máximo de 14 después del código de país.

• <->$: Marca el final de la cadena, asegurando que no haya caracteres adicionales después del número.

En resumen, esta expresión regular valida un número de teléfono internacional que:

• <->Empieza con un símbolo +.
• <->Tiene un código de país que comienza con un dígito entre 1 y 9.
• <->El número de teléfono contiene entre 9 y 14 dígitos después del código de país.

Algunos ejemplo válidos para esto serían: “+34600123456” (España) o “+14155552671” (EE. UU.). Y un par de ejemplos de números no válidos podrían ser: “+0123456789” (el código de país no puede empezar con 0) o “34600123456” (falta el símbolo +).

Figura 11: Libros de Python para Pentesters y Hacking con Python
de Daniel Echeverri publicados en 0xWord.

<->Por último, realizamos la creación de una función principal. La función main() se encarga de gestionar los argumentos de la línea de comandos para que el usuario pueda verificar el estado de SIM Swap de uno o varios números de teléfono. Utiliza la librería argparse, que facilita la creación de interfaces de línea de comandos en Python. A través de esta función, el usuario puede proporcionar un número de teléfono individual utilizando la opción -p/--phone, o bien un archivo que contenga varios números de teléfono, uno por línea, con la opción -f/--file.

La función emplea un grupo de argumentos mutuamente excluyentes, lo que significa que el usuario debe elegir entre una de estas dos opciones, pero no ambas al mismo tiempo. Esto simplifica el manejo de los datos y asegura que la herramienta sea flexible pero a la vez fácil de usar. 

Figura 12: Función principal del programa

<->
Cuando se pasa un número de teléfono, este se valida usando la función phone_validator(), y, si todo va bien, se procesa con la función sim_swap(). Si se utiliza un archivo, la función intenta leer los números de teléfono línea por línea, y si encuentra algún error (como que el archivo no exista o no se pueda leer), gestiona las excepciones e informa al usuario. Esta estructura permite que la herramienta sea robusta y manejable, garantizando una buena experiencia de usuario con el manejo de errores y validaciones necesarias para evitar problemas.

Para finalizar se debería realizar la llamada a la función main(), algo que se puede integrar dentro del condicional if __name__ == “__main__": típico de Python. Sólo una cosa más, ¿recuerdas que en la llamada a SIM Swap había que indicar el Client ID y Client Secret? En el código mostrado anteriormente, estos valores aparecían en la función sim_swap() en las constantes CLIENT_ID y CLIENT_SECRET. 

<->

<->

Figura 13: Recuperando las credenciales desde el entorno

<->

<->Como se trata de valores que contienen información sensible, como buena práctica de programación, se recomienda leerlos del entorno. Para ello se puede hacer uso de la librería python-dotenv y almacenar las credenciales en un archivo .env que contiene las variables del entorno. 

<-> A continuación comparto un vídeo de ejemplo del uso de la API de SIM Swap donde puede apreciarse el código tanto haciendo uso directo de la API, como del SDK.

Figura 14: SIM Swap API vs SDK

Las APIs de Telefónica Open Gateway son una puerta abierta para que los desarrolladores puedan explorar nuevas formas de enriquecer sus aplicaciones con capacidades avanzadas, como el ejemplo visto con la detección de SIM Swap. El acceso a estos servicios no solo refuerza la seguridad de las aplicaciones, sino que también te permite crear experiencias más confiables para los usuarios.

Figura 15: APIs Open Gateway estandarizadas

Con el sandbox, tienes a tu disposición un entorno seguro para experimentar, probar e integrar estas funcionalidades en tiempo récord, sin necesidad de comprometer datos reales.  Si buscas llevar tus proyectos al siguiente nivel, esta es tu oportunidad, y puedes comenzar hoy mismo a experimentar con las APIs de Telefónica Open Gateway, explorar todo su potencial y transformar tus ideas en soluciones reales que impacten de forma positiva a miles de usuarios.

<->

<->Developer Hub

<->

Para que empecéis a experimentar, es necesario que os unáis al Developer Hub de Telefónica Open Gateway. La inscripción a este programa no tiene ningún coste, por lo que podréis disfrutar del Sandbox de forma gratuita. En la sección Technical Toolbox del área privada, una vez que os hayáis registrado y logado, encontraréis el acceso y, una vez dentro, lo primero que veréis es nuestro catálogo completo de APIs disponibles en el entorno de pruebas. 

Figura 16: Darte de alta en el Telefónica Open Gateway Developer Hub

Seleccionad aquella con la que queráis trabajar, añadid la información general de vuestra aplicación y elegid el modo que deseéis, ya sea de producción o mock, para empezar con vuestros desarrollos. Probad vuestros desarrollos con estas APIs para llevarlos al siguiente nivel de seguridad antifraude con OpenGateway.

Figura 17: Suscríbete a la newsletter de Telefónica Open Gateway

Y si quieres mantenerte informado con novedades en la iniciativa como más webinars sobre nuestras soluciones, lanzamientos comerciales o nuevas APIs disponibles, suscríbete a nuestra newsletter de Open Gateway.

Saludos y

Happy Coding!

Autor: Álvaro Núñez-Romero, investigador en el equipo de Ideas Locas. Autor del libro "Arduino para Hackers (& Makers): PoCs and Hacks Just for Fun" y del VBOOK de "Arduino para Hackers (& Makers): PoCs and Hacks Just for Fun"

Contactar con Álvaro Núñez-Romero