TOP
Autores
TOTAL
LecturasSET 28
97135 visitas
- Contenidos - SET Staff
- Editorial - Editor
- La Hoja Rasca - FCA00000
- Bazar de SET - Varios Autores
- MUDs (bazar) - Alicuencana
- Algo acerca de los logs - blackngel
- Seguridad fisica - blackngel
- Cracking desde 0 - D4rkM4s3r
- Proyectos, peticiones, avisos - SET Staff
- Cinco horas con Fred - Lindir
- Moviles - 2 - FCA00000
- Monitorizacion de software - n3LsOn
- Relational Data Base Management System - FCA00000
- 2do articulo publicado por SET en @RROBA - SET Staff
- Virusbuster - Madfran
- Llaves PGP - SET Staff
La Hoja Rasca
5906
Autor: FCA00000
-[ 0x02 ]-------------------------------------------------------------------
-[ La hoja rasca ]----------------------------------------------------------
-[ FCA00000 ]-------------------------------------------------------SET-28--
La hoja-Rasca (NdB.1)
(Nota del Biografo. Este articulo esta repleto de referencias literarias.
Cuando lo considere oportuno introducire una anotacion del tipo NdB.1
que quiere decir 'Nota del Biografo. 1'
En este caso, hace un juego de palabras con la obra de Gabriel Garcia
Marquez - La hojarasca , y el tema principal: los cartones de rascar)
Saludos, lector
Voy a contar una historia. Es posible que estes cansado de que te cuenten
historietas, pero quizas esta te resulte interesante. Se dice que parte
de las historias son contadas para beneficio del lector, y otra gran parte
se narran para satisfaccion del autor. Si esta consigue despertar tu interes,
me sentire recompensado.
Esto trata sobre la creacion de scratchcards, que son esas tarjetas de carton
con un cuadro gris que se rasca con una moneda y muestran un numero que
escribes en tu movil con tarjeta pre-pago y te proporcionan mas saldo para tus
llamadas telefonicas. Asi que si no te interesa el tema, ahora es el momento de
parar de leer.
Mi nombre es... pensandolo bien, el nombre es uno de tantos hechos
circunstanciales que no definen una vida, y, todo hay que decirlo, yo no tengo
nombre.
Lo que me diferencia de los demas es mi numero: 15212055
No te dice nada? Y si te digo que es un NSCR te aclaro algo?
Bueno, ya veo que tendre que empezar desde el principio.
Para que estes prevenido, alguna de la nomenclatura que usare es en idioma
frances, ya que es en este lenguage en el que fui creada. Y algunos terminos
son en danes, o en ingles, para acabar de completar mi bagaje. Toda explicacion
llegara en su momento apropiado.
Yo soy una tarjeta de recarga de tarjetas telefonicas de pre-pago y naci en una
empresa telefonica que llamaremos TelCo para mantener el anonimato.
Tecnicamente se llaman scratchcards, pero yo prefiero llamarlo cartoncillo, dejando
el termino 'tarjeta' para la tarjeta SIM que se usa dentro del telefono movil.
Para que no te pierdas, esto es un esquema del largo camino que he recorrido.
Los numeros serviran para referencias en el texto con el formato *xy*
12 17
13 01 11 TARJETA MODULO
KEY:SI Secuencia KEY:SC-->-SEGURIDAD-<->-SEGURIDAD
14 | | CREACION CNET: MSc
TARJETA | |
SEGURIDAD | 02 |
IMPRESION +-BLDTK----\ 04 05 |
| +-15212051.HDR->-NCSR->-CREATION.EXE-<->-API
18 v 03 / CNET CNET
MODULO / |
SEGURIDAD / |
CNET: MSi / |
| /08 v
^ / |
| V |
v / |
20 | / 07 06 |
DESCRIFRA.EXE---<------<------<--tickets.CHI (NSCR & CS)
CNET |
| v
21 v 23 |
IMPRESION------->-------->--------ACTIVACION----------+
TARJETAS 24 | |
| v |
22 v ____ | 25 |
ENTREGA AL __/ \__ BASE DATOS |
DISTRIBUIDOR /54 IN \ TARJETAS |
| \ /\ | 26|
v \________/ \53 ^50 v
30 | \ | |
CLIENTE-----<----SMS---<--------TRANSACCION |
| CONFIRM. _/ | | |
| 52 43/| ^ v |
| / | | 51 27 |
32+--IVR->-\ FTP/XML v +----->----ARCHIVADO
31+--SMS->--\ 41 | 42 | |
33+--WEB->---\ ^ GEM 44 v
| \ 40 | DRIVER 56 |
| FIREWALL->-+ ^ DATA_WAREHOUSE
34+--ATM-->---/ | 15
35+PAGO_SEGURO v KEY:SV
45 | 19 | 16
API MODULO TARJETA
CNET-<->-SEGURIDAD-<-SEGURIDAD
CNET: MSv VALIDACION
Lo primero que yo recuerdo es que el departamento de provisionamiento informo
que el stock de tarjetas de recarga de 15 euros estaba cercano a agotarse y
era necesario crear nuevos cartoncillos. La persona encargada del proceso de
generacion consulto *01* en un ordenador un numero correspondiente a la ultima
secuencia que fue seleccionada para crear tarjetas de 15 euros, y este numero
llamado TK15 resulto ser 2161. Incremento el numero en 1 para obtener 2162, y
averiguo que el numero de serie de la ultima tarjeta de 15 euros generada era
15212050. Asi que lanzo un programa llamado BLDTK *02* con los parametros
BLDTK 2162 15212051 25
Esto genero *03* el fichero 15212051.HDR con las siguientes lineas:
Activation information for batch 2162 with external \
serial numbers: 15212051 - 15212075
Credit: 1
Expiration date: 31-12-2005
Logo: front15.gif back15.gif
Esto es bastante facil de entender: genera un fichero en el que se archiva el
numero de tarea, los numeros de serie *04* que van a ser generados (yo entre
ellos, la 4 hermana de 25) y la fecha en la que dejaremos de ser validas. Un
poco cruel, saber la fecha de tu muerte, no?
Despues introdujo en un lector de tarjetas GEM GCR4000 una tarjeta
microchip con un algoritmo de seguridad.
Para generar esta tarjeta, alguien de TelCo (lo mismo pasa con Amena o
Telefonica o Vodafone o Telecel), junto con alguien de la empresa que
fisicamente imprime los cartoncillos (imprentas Perez) , contactaron con
alguien de la empresa fabricante de tarjetas chip (Schlumberger o RegieT o
Oberthur o Microelectronica Espaniola o DeLaRue o GemPlus en mi caso) y cada
uno eligio una semi-llave *11*13* aleatoria de 16 cifras para obtener dos clave
publicas, y sus correspondientes privadas, las grabaron respectivamente en
sendas tarjetas, y se volvieron a sus oficinas.
El responsable de TelCo se queda con *12* la tarjeta MSc, Modulo de Seguridad
de Creacion, que sirve para que el operador de servicios genere los
codigos cifrados.
Por su parte, el de la imprenta se queda con *14* la tarjeta MSi, Modulo
de Seguridad de Impresion (un poco si' que impresiona, la verdad) que le
permite descifrar el codigo para imprimirlo en los cartoncillos.
Tengo que decir en este punto que en realidad se crearon 2 tarjetas
identicas con el codigo MSc, y otras con el MSi ; por seguridad, supongo.
Dias mas tarde, el de la imprenta fue con otro encargado de TelCo, pero del
departamento de tarificacion, e hicieron algo parecido, esta vez re-usando la
misma semi-llave de la tarjeta de impresion pero otra semi-llave *15* para el
encargado de seguridad de TelCo.
Con esto, el chico de TelCo obtuvo *16* una tarjeta MSv, Modulo de Seguridad
de Verificacion, que permiten al servidor de pre-pago verificar la validez
de un codigo introducido por el usuario del cartoncillo (scratchcard).
TelCo mando hacer 12 copias de la tarjeta de verificacion para poder usarlo en
varios ordenadores. Notar que la creacion de codigos en un proceso bien
planeado (cada 2 semanas, en funcion de la demanda) pero el uso de nuestos
codigos puede ocurrir en cualquier momento.
'Eu nao si cuand iste fado ya andaba pel seu pe' (NdB. Fado portugues
llamado 'Coracao bateu tres veces'. Saludos para los vecinos peninsulares).
El algoritmo *17*18*19* para crear estas claves es propiedad (secreta) de la
CNET, que es una empresa del grupo de FranceTelecom establecida en el poligono
tecnologico ANTICIPA ubicada en la ciudad de Lannion, en la Bretania francesa.
Si es necesario se pueden volver a generar las claves sin mas que usar de nuevo
las semi-llaves anteriores. Por eso es imprescindible que ninguna de las partes
conozca las otras semi-llaves, ni mucho menos al que ha sido testigo de estas
transacciones: el encargado que trabaja en GemPlus. Seria catastrofico que
alguien metiera en el ordenador del pobre Gilles Mxxxxxx un troyano que
capturara estas claves cuando esta grabando las claves para los algoritmos en
las tarjetas chip.
Este algoritmo no se puede saber ni siquiera consiguiendo una de las
tarjetas chip porque son del tipo microprocesador. Es decir, tienen un
puerto de transmision de datos pero no es posible acceder a la memoria
interna; solamente llamar a funciones de su EPROM.
O pensabas que no se impondria ninguna medida ni se limitarian las metas?
(NdB. Werther. Fausto. Momentos despues de firmar el pacto con el diablo)
Estas semi-llaves se almacenan en un lugar seguro en las respectivas empresas.
Pero sigamos con la historia mas reciente. Como iba diciendo, el operador
de TelCo mete su tarjeta con el codigo SC en el lector GEM GCR400,
tambien conocido como GemPC400.
A continuacion se lanza *05* el programa CREATION.EXE con los parametros
CREATION.EXE <nscr> [nbr_cert] [tickets.CHI]
donde
nscr es el primer numero de serie (15212051)
nbr_cert es la cantidad de codigos que hay que generar (25)
tickets.chi es el fichero *06* en el que se guardan los datos. Tambien
llamado Key File.
Este programa CREATION.EXE pregunta entonces el puerto serie en
el que esta conectado el lector de tarjetas.
Esto quiere decir que, para mayor seguridad, el programa no puede
generar los codigos por si solo. Si fuera asi, cualquiera que
consiguiera el programa podria generar los codigos, aunque no se
si le serviria para algo. Volveremos sobre esto mas tarde.
El programa usa librerias PC/SC para hablar con el firmware GemCore
que constituye el Sistema Operativo del microchip insertado en la tarjeta.
Este GemCore no es mas que un subconjunto de PC/SC para T=0.
En detalle, escribe los digitos de las semi-llaves en la llamada zona de
aplicacion, luego escribe mi NSCR, invoca a la funcion para obtener un numero
unico CRCHI mediante el correspondiente APDU (Application Protocol Data Unit)
y al final lee ese numero de otra zona de aplicacion.
Mas informacion en la guia del programador de GemPlus Block Protocol, que
es muy buena y explica todo muy clarito.
Asi, en tickets.chi nos encontraremos los numeros de serie NSCR, Numero
de Serie du Code de Rechargement) y unos codigos cifrados correspondientes a
cada uno de nosotras, llamado CRCHI en frances: Code de Rechargement CHIfree.
Algo asi como un checksum.
O sea, que CREATION.EXE sigue este proceso:
-contacta con el lector de tarjetas
-toma el primer numero NSCR (Nume'ro de Se'rie de Rechargement)
-lo transmite por el puerto serie
-el lector de tarjetas recibe el numero y lo pasa a la tarjeta chip
-la tarjeta chip toma la clave MSc de su memoria EPROM
-con el algoritmo secreto de la CNET, genera el CRCHI
-devuelve la respuesta del lector
-se devuelve la respuesta al programa
-se escribe una linea
-repite el bucle hasta llegar a nbr_cert
Cada linea de este fichero tickets.CHI es de la forma
__NSCR__ ______CRCHI_____
donde
NSCR es el conocido numero de serie de recarga, de 8 caracteres
CRCHI es el checksum del NSCR con el MSc. Mide 16 caracteres 0-9a-f
Por ejemplo:
15212051 0473a25f34cf4369
15212052 988e5d240f583904
15212053 8e3c3d7558a4c8c1
15212054 ec5ebb7c4314cd59
15212055 2006f0aafab2e3e1 <- este soy yo, y mi CRCHI :-)
15212056 3ea91dbfd76a9b77
15212057 ac83a61fa1e80ac0
15212058 867684b29fbf67b6
15212059 e973a6efc9ba529e
15212060 4140a96d4312d2ab
15212061 9595861dc28135c9
15212062 04283f03a9a78ae2
15212063 058631367d6cd092
15212064 71e274fb54322b12
15212065 a67836bece7002bb
15212066 11d8dc99f4ca9a7a
15212067 4c3adac480521ca1
15212068 d282ffb796f82cfb
15212069 6e1f8bd30441a7e4
15212070 4003ed236881406b
15212071 c1c2846fd0822a4a
15212072 af943481c222a429
15212073 adb948928993286b
15212074 c03461e96493304c
15212075 ad45eb2305ae53c4
Ahora mis hermanas y yo viajamos *07* en este fichero hasta el centro
impresor de los cartoncillos. Ya que el fichero va cifrado con la clave
privada de TelCo, el impresor puede validar que no ha sido alterado durante el
transporte. Pero como ademas va cifrado con la clave publica del impresor,
solamente este es capaz de descrifrarlo.
Asi que el metodo de transporte no tiene que ser extremadamente seguro.
Junto al fichero tickets.CHI tambien se incluye *08* el 15212051.HDR para
que el impresor sepa el logotipo que tiene que imprimir.
Alli se dispone de otro lector similar. El operario inserta su tarjeta
con *13* la clave SI, y ejecuta *20* el programa DESCRIFRA.EXE
DESCRIFRA.EXE [tickets.CHI] [tickets.txt]
que genera el fichero con nuestros codigos de recarga CR=cifrado_de(CRCHI+SI)
siendo SI es la clave privada del impresor.
O sea, que el CR es un codigo de 14 cifras que depende de mi NSCR (8 cifras)
y del CS (6 cifras) de TelCo, llamado Certification de Se'curite'.
El fichero tickets.txt tiene lineas de la forma
__NSCR__ ______CR______
Por ejemplo
15212051 93173315351389
15212052 05896547629373
15212053 04594573188781
15212054 52578139228235
15212055 34486099807180 <- yo y mi CR
15212056 20641924779614
15212057 27265102941052
15212058 77252813875000
15212059 43139429899575
15212060 57997726163756
15212061 15316677348969
15212062 59367855905272
15212063 83320479763941
15212064 33740343554093
15212065 12539147294601
15212066 83389286361786
15212067 59410246187835
15212068 30397282743583
15212069 77720196088271
15212070 54497437840091
15212071 16424947727102
15212072 22043037428193
15212073 00529361704611
15212074 30722895604436
15212075 25207789615235
Este CR es el que merece la pena. Vale su peso en oro, mas o menos.
A continuacion imprime *21* los cartoncillos con un disenio basado
en front15.gif y back15.gif, que resultan ser la cara y el reves
con el anagrama de TelCo y un valor de 15 euros, con
unos huecos para imprimir los codigos. Al combinarlo, resulta asi:
+-----------------------------------------------+
| |
| 34486099807180 |
| TTTTT |
| T 1 55555 |
| T E L C O 11 5 |
| T 1 5555 |
| 1 5 |
| SMS:969696969 111 5555 IIIIIIII |
| VOZ:969696966 15212055 |
+-----------------------------------------------+
Aunque el formato puede cambiar, seguro que aparece mi CR. El resto de los
datos dependen de la operadora telefonica. Por ejemplo, conozco primas segundas
mias en las que el CR aparece en dos casillas: una con 8 digitos y otra con 6,
para dar 14. Aunque mide lo mismo que el NSCR + CS, no es lo mismo; no te
confundas. En mi caso, tambien aparezco yo misma. No por nada, pero para darme
un poco del reconocimiento debido.
En este cartoncillo tambien aparezco yo, aunque esto no es necesario. Al fin
y al cabo, la informacion util -lo unico que transmite el usuario- es el CR.
Justamente encima mio aparece un codigo de barras IIIIIIII que es siempre
el mismo para todas las tarjetas hermanas. O sea, que hay 25 tarjetas con
este mismo codigo de barras, que, como podeis suponer, incluye el
numero 2162 (la secuencia unica, para los olvidadizos). Yo se que todos
hemos ido a parar juntos al mismo distribuidor, asi que no me he separado
de mis hermanas hasta que no he sido adquirida por un ansioso comprador.
Esto tiene un simil con los hogares de adopcion que prefiero no recalcar.
Otras primas lejanas mias aparecen tambien con un codigo de barras individual
y unico para cada uno de ellas. Seguramente forman parte de alguna elite.
El codigo de barras puede estar en formato code39, 2of5 interleaved, EAN8
o EAN13, para que nos puedan leer con un lector de codigo de barras. Esto
es util cuando somos vendidas en los supermercados; asi saben que tienen
que reponer existencias, con lo cual otras primas salen a la luz.
Supongo que huelga decir que el dibujo impreso es el de 15 euros, que
son precisamente los 2 primeros digitos de mi nombre. No es casualidad.
Otras de mis parientes fueron impresas en cartoncillos junto con otro
codigo diferente: NSTE , Numero de Serie de Ticket Externe. No esta
relacionado con el NSCR ni el CR, y su utilidad responde a las necesidades
de gestion del proveedor de servicios. Permite identificar cada cartoncillo.
Se compone de 8 cifras, aunque para imprimirlo se le anteponen 3 cifras 'ytn'
siendo y codificacion del generador del ticket: 1 para GEMPLUS, 2 para RegieTt
tipo de ticket: 0 para 15 euros, 1 para 30, 2 para 50 version: 1 para antes de
1998, 2 para despues de 1998
Para generar estos NTSE se toma un numero secuencial que simplemente se
va incrementando, pero en el fondo lo unico que hace falta es que sea unico.
Para mi, este codigo es 14980126 para dar 1014980126.
Me pregunto si de verdad se han generado 14.980.125 tarjetas antes que yo.
Asi que ya estoy fisicamente impresa en un cartoncillo, con una capa de pintura
plateada recubriendo el CR secreto, y envuelta en un plastico transparente
sellado. Lo siguiente que recuerdo es que nos metieron en una caja oscura, y
cuando vi la luz de nuevo estaba pasando a *22* las manos de un distribuidor
dentro de una tienda de articulos de informatica y consumo.
Pero antes de continuar debo explicar que tambien segui otro camino: en algun
momento, posiblemente cuando estaba siendo empaquetada o enviada a la tienda,
el responsable de la imprenta *23* notifico a TelCo que habiamos sido impresas.
Este intercambio se produjo a traves de un fichero con el formato:
TYPE_REG (2) tipo de registro; siempre 20
COD_OPE (3) codigo identificador de operacion efectuada:
110=creacion
112=re-creacion
210=suspension
211=restablecimiento tras suspension
310=retrasado
311=supresion
312=utilizacion
313=fin de validez
NSTE (8) numero de serie externo de cartoncillo
NSCR (8) numero de serie de codigo de recarga
DATE_VALID(6) fecha YYMMDD de fin de validez
TYP_TR (3) tipo de ticket de recarga : ytn
STAT_TR (3) estado del ticket de recarga
NUM_CLI (10) numero fiscal de empresa cliente (TelCo)
NUM_APP (10) numero fiscal de empresa proveedora (impresor)
DATE_CRE (10) fecha YYMMDDHHMM de creacion del cartoncillo
Por supuesto que no le comunico los CRs, pues eso romperia totalmente la
seguridad, pero como TelCo ya tenia tambien nuestros NSCRs, esto le sirvio
de confirmacion que nos habian impreso satisfactoriamente, asi que nos
metio *24* en el sistema a partir de la primer columna del
fichero tickets.CHI, introduciendonos en *25* la base de datos de tarjetas.
Es decir, que me converti en un registro en la tabla cardstable, que
tiene la siguiente estructura:
serial_number(CHAR 8) -> el NSCR, no se porque no usan su nombre real
reloading_code(CHAR 14) -> en principio vacio. Cuando me usen, valdra el CR
validez_dt(DATETIME) -> fecha de validez
credit(INTEGER) -> cantidad de euros que recargare
validez_periodo(DATETIME) -> periodo de validez que extiendo el telefono
operacion(INTEGER) -> lote, logo, y operacion comercial
status(INTEGER) -> 1-disponible 2-expirado 3-anulado 4-usado
msisdn(CHAR 10) -> numero del subscriptor que me ha usado
reloading_dt(DATETIME) -> fecha de recarga, cuando me usen
Esta tabla contiene siempre la informacion mas reciente de las tarjetas para
poder consultarla en cualquier momento. Asi se explica que tanto los
campos serial_number como reloading_code sean unicos.
Con esto tambien *27* se registro la transaccion en el archivo, que es otra
tabla llamada cardslog, con la misma estructura. Esta tabla mantiene todos
los hechos sucedidos a una de nosotras. Esto explica que normalmente aparecemos
en 2 registros: uno con status=1 y otro con status=2, 3, o 4. El registro con
status=1 tiene vacios los campos reloading_code y msisdn, mientras que si
status=4 entonces esos valores tienen datos.
Pues ya estamos listas para ser usadas.
No hube de esperar mucho tiempo para que me sacaran del envoltorio
con el objeto de cumplir *30* con mi cometido.
El propietario del telefono con tarjeta de prepago rasco el codigo
secreto, edito un SMS con destino 969696969 en el que yo (bueno, mi CR) era
el unico y principal protagonista y me envio *31* en mi nuevo viaje.
Al aterrizar en un SMSC (Short Messages Service Center) fui metido en una
maquina muy grande de Nokia en la que coincidi con otros muchos mensajes, pero
como yo iba dirigida a un telefono especial interno de TelCo
no me dejaron ir muy lejos y fui exportada a un fichero de texto en el que
se indicaban la fecha de recepcion, el numero de telefono MSISDN del usuario
que envio el SMS, y la informacion que habia escrito: si no se habia
equivocado al teclear, este seria el CR adecuado.
Alli me encontre con primas mias y cuatro hermanas, esperando a ser procesadas.
Me contaron que habian llegado por otros medios.
Por ejemplo, mi hermana 15212052 dice que su propietario habia llamado *32* al
telefono 969696966 donde una voz mecanizada IVR (Interactive Voice Response)
habia indicado que dijeran los numeros secretos, y el usuario
dijo, uno por uno: 05896547629373. Menos mal que le pidio confirmacion, porque
las 3 primeras veces habia algun numero que el sistema no habia identificado
correctamente.
Su historia de como habia ingresado en la red inteligente (IN-Intelligent
Network) era apasionante, sobre todo la comunicacion con protocolo SS7 entre
el SSP y el STP y el SCP. Si tengo tiempo la contare mas tarde.
La otra hermana 15212053 me dijo que su usuario tambien la adquirio en
la tienda pero como el telefono no lo tenia alli sino en casa de su
padre habia decidido *33* conectarse a la pagina web de TelCo para
escribir el numero de telefono y el numero secreto 04594573188781.
La seguridad que ella vio por el camino durante la Internet le
parecio bastante baja, pero ella lo unico que deseaba era llegar al destino
y reunirse con nosotras; la seguridad intermedia solo tenia que garantizar
que su NSCR y CR llegaban y nadie los modificaba o detenia.
El momento de ser verificada todavia no habia llegado, asi que el unico
riesgo que habia es que un usuario metiera numeros aleatorios para ver
si alguno funcionaba. Mas tarde nos enteramos que esto resulto fatal para
otro usuario que lo intento antes.
El procedimiento de recarga a traves de *34* cajeros automaticos ATM no usa
scratchcards ni codigos de recarga CR asi que no se como funciona, aunque
seguramente sigan otro proceso diferente hasta el final, cuando el importe
es aniadido al saldo del usuario, ya que no es posible inventarse un CR.
Lo mismo sucede con otros metodos *35* de pago seguro en los que solo es
necesario una tarjeta de credito. Mencionar que existe y esta alojados en un
servidor propio de TelCo, pero no usa de codigos para los CR asi que se sale
del ambito de mi vida.
Una vez juntas todas *40* en un fichero de texto dentro de esa maquina
dedicada con formato propietario de Nokia, apenas esperamos unos segundos
para que *41* una sesion FTP nos transfiriera a nosotras hasta otra de TelCo.
'At rejse er at leve' (NdB. Viajar es vivir. Dicho popular en Dinamarca
debido a H.C.Andersen)
Hay otra posibilidad *42* para pasar a la red interna, y es usando HTML/XML.
Para ello la maquina de Nokia se conecta *43* a odin.telco.com al
puerto 8006 y empezar a hablarle en el lenguaje que entiende: XML
El formato DTD para recargar se llama ODINXmlReq.dtd y es (parcialmente):
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT ODINXmlReq(Login|Reload)>
<!ATTLIST ODINXmlReq
TransID CDATA #IMPLIED
UserID CDATA #REQUIRED
>
<!ELEMENT Login EMPTY>
<!ATTLIST Login
LoginID CDATA #REQUIRED
Password CDATA #REQUIRED
>
<!ELEMENT Reload EMPTY>
<!ATTLIST Reload
MSISDN CDATA #REQUIRED
CR CDATA #REQUIRED
>
Por ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ODINXmlReq SYSTEM "ODINXmlReq.dtd">
<ODINXmlReq UserID="root">
<Reload MSISDN="630303030" CR="34486099807180">
</ODINXmlReq>
Y el DTD de la respuesta se llama ODINXmlRes.dtd y es:
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT ODINXmlRes(OK|ERROR)>
<!ATTLIST ODINXmlRes
TransID CDATA #IMPLIED
>
<!ELEMENT OK EMPTY>
<!ELEMENT ERROR EMPTY>
<!ATTLIST ERROR
ErrorCode CDATA #REQUIRED
ErrorText CDATA #REQUIRED
>
Por ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ODINXmlRes SYSTEM "ODINXmlRes.dtd">
<ODINXmlRes >
<ERROR ErrorCode="1023" ErrorText="Codigo de Recarga ya usado"/>
</ODINXmlRes>
Los codigos de error son:
0099 TimeOut
0100 Usuario invalido
0150 XML mal formado
0155 XML no valido
0160 Error comunicando con IN
0170 Incapaz de procesar comando
0190 Privilegios insuficientes
0191 Usuario desconocido
1001 MSISDN invalido
1005 Cantidad invalida
1010 MSISDN desconocido
1011 Imposible incrementar cantidad
1021 Cuenta prohibida
F=retenida (Frozen)
D=en espera (Dormant)
A=Activa
S=suspendida
1022 Codigo de Recarga ya usado
1023 Codigo de Recarga no activado
1100 Error general
Ya sea por un metodo o por otro, la cosa es que por fin habiamos traspasado el
firewall, siendo succionadas hacia la intranet. Que diferencia de trato, chica.
Si en el mundo exterior todo eran barreras y confirmaciones, en la intranet
pasamos a un ordenador con Linux 2.4.57 (puedes creerlo?) llamado
odin.telco.com -juego de palabras entre el dios escandinavo y 'Output Driver
for Intelligent Network'- que tenia *44* un programa Java que leyo las lineas,
aislo mi CR y lo mando por el puerto serie mediante *45* protocolo PC/SC a un
lector de tarjetas que tenia insertada *15* la tarjeta con la clave de
verificacion SV, y el programa *19* grabado en el microchip interno a la
tarjeta verifico que el checksum era correcto, extrayendo a su vez el NSCR, que
el programa Java le devolvio al Linux, en un proceso similar al que tuve cuando
fui creada o me imprimieron.
Por fin estabamos verificadas y autorizadas!
A partir de ahora el proceso es sencillo, pero muy importante:
Usando de un driver JDBC usamos una cadena de conexion del tipo
"jdbc:oracle:thin:@10.0.0.1:1521:SCRATCH;User=SYSTEM/MANAGER"
para engancharnos *50* con la base de datos ORACLE de todas las tarjetas
donde se actualiza la tabla cardstable:
UPDATE cardstable
SET
reloading_code='34486099807180',
status=4,
reloading_dt=SYSDATE,
validez_periodo=SYSDATE+180,
msisdn='609696969'
WHERE
serial_number='15212055'
AND status=1
y similarmente inserta *51* un nuevo registro en la tabla cardslog.
Esto hace que se envie *52* un mensaje al cliente propietario del telefono
en el que se le indica su nuevo saldo, y la validez: 180 dias mas.
Otras bases de datos obtendran la informacion replicando esta tabla. Pero
no les esta permitido actualizarla.
There's always something left behind... never mind.
(NdB. Cancion 'My favourite dress' del grupo 'The Wedding Pressent')
Lo que pasa es que el importe total de credito del usuario esta en otra
base de datos mucho mas importante: la base de datos de facturacion.
Pero yo no llegue hasta esta tabla final; considera que yo soy solo
un incremento del credito, y el valor total esta relacionado con otros
procesos; por ejemplo puede incluir ofertas y campanias especificas que
hagan que el incremento sea mayor que los 15 euros iniciales.
Asi que ya toda la informacion esta registrada en la organizacion de TelCo.
El ultimo punto *53* es decirle a la red inteligente este nuevo saldo.
La IN tiene *54* unos nodos llamados SCP (Signal Control Point) con unas
bases de datos en los que se almacenan unos cuantos numeros de telefono y
el saldo disponible. El SSP (Signal Control Point) es un switch telefonico
que se encarga de originar, terminar, o intercambiar llamadas. Esta
equipado con SS7 (Signaling System 7) que es el protocolo que le permite
conectarse con otros nodos de la red inteligente para procesar los servicios.
Cuando el usuario pretende efectuar una nueva llamada el SSP recibe la
notificacion y se comunica con el STP (Signal Transfer Point) que enruta el
mensaje (intencion de establecimiento de llamada) hacia el SCP, quien en
ese momento averigua el saldo disponible (quizas preguntandolo a otros
SCP, si no posee la informacion de ese subscriptor concreto) para
permitir la llamada, o devolver un mensaje de denegacion del servicio, quizas
consultando con otro SCP cual es el mensaje que hay que decirle al usuario.
La red inteligente esta constantemente comunicada con la base de datos masiva
que se encuentra en los ordenadores servidores principales de TelCo.
A traves de CAMEL-2 (Customized Applications for Mobile network Enhanced
Logic) otras redes de otras empresas telefonicas nacionales e internacionales
pueden saber si la persona puede establecer llamadas y recibirlas estando
en Roaming. Tipico ejemplo del camello que sube al tranvia en Grenoble
y este le muerde la pierna. (NdB. Superlopez 20)
Ya casi al final de todo este proceso, los datos de creacion de mi NSCR, la
impresion de mi cartoncillo, mi adquisicion, mi activacion, el MSISDN del
usuario, el IMSI , las fechas de recarga e incluso los datos de las llamadas
realizadas y SMS enviados van a parar *56* a un sistema enorme de DatawareHouse
que analiza los comportamientos de los clientes para ofertar otros servicios,
evitar que huya a otro operador, creacion de planes nuevos, analisis de tiempos
y cualquier idea que se le ocurra a los directivos que velan por el negocio de
TelCo.
Durante mi larga vida he pasado por situaciones de riesgo en la que pensaba que
si alguien me robaba o me duplicaba seguramente el sistema se volveria loco al
ver que estaba siendo usada varias veces. Veamos cuales han sido estas ocasiones
y lo que los chicos de TelCo hacen para evitar estos intentos de fraude.
Lo que siempre hay que tener en cuenta es que la propia TelCo tiene
que generar los NSCR y activarlos en sus bases de datos y meterlos en
la red inteligente. Existen muchos codigos validos desde el punto de
vista del checksum (CR), pero solo algunos de ellos estan activos en
la base de datos. Se llama a esto la barrera de activacion interna
en la empresa (IHAW, In House Activation Wall).
El otro aspecto que no hay que perder de vista es que el numero de telefono
esta controlado en todo momento por TelCo y cuando sospecha algun fraude
puede impedir/cortar la llamada y otras cosas peores. Acojonao? Pues
espera que ahora te detallo lo que pueden hacer. Esto se denomina
sistema de activacion retroactiva (BAS, Back Activation System), aunque
la mayoria de las veces se usa para des-activacion.
Solo por curiosidad, vamos a ver lo que puede hacer el BAS. Esta
informacion ha sido obtenida por comentarios informales asi que
no pude verificar si estos procedimientos se aplican o no.
En todos los casos se genera una alarma que mas tarde una
persona puede -o no- comprobar.
Caso 1) Un usuario intenta usar un CR que no verifica el checksum.
No sucede nada.
Caso 2) Un usuario introduce un CR incorrecto por tres veces.
Se asume que no ha escrito bien el SMS pero se empenia
en mandarlo. No sucede nada. Ya llamara a TelCo si quiere.
Caso 3) Un usuario usa en pocos minutos distintos CRs incorrectos.
Posiblemente se trata de alguien que quiere pasarse de listo.
No aguantaremos sus insolencias, te lo prometo. (NdB. Romeo y Julieta.
Primera frase: 'Gregory, on my word, we'll not carry coals').
Se lanza otra alarma, y se puede:
1) Anular todo su saldo - posiblemente sea poca cantidad.
2) Cancelar su numero de telefono (que , por otra parte, ha
sido otorgado por la propia TelCo)
3) Dado que es un telefono pre-pago, quizas no existan otros datos
del cliente tales como direccion, nombre, ... ; pero en el caso
de que existan, se contacta con el usuario advirtiendole.
4) Como tambien se conoce el numero de serie IMEI del
telefono (no solo de la tarjeta SIM), se introduce en la base
de datos mundial de telefonos fraudulentos y nunca mas se puede
volver a usar ese telefono.
5) Mediante la triangulacion definida por las antenas, y aplicando
un simple calculo de GIS (Sistema de Informacion Geografica) se
averigua con una precision de 2 metros donde esta el sujeto en
todo momento, aunque este radio es mayor en zonas con menos antenas.
Deja volar tu imaginacion para imaginar lo que puede pasar.
Incluso dias mas tarde del intento de fraude.
(Particularmente no me creo que TelCo llegue a este extremo)
Caso 4) Un usuario especifica un CR que ya habia sido usado. Una o mas veces.
No sucede nada. Se asume que alguien ha encontrado un cartoncillo
por la calle y esta intentando usarlo otra vez. Pobre diablo.
Caso 5) Varios usuarios usan el mismo CR en un corto periodo de tiempo.
El primero funciona pero para los siguientes el CR ya ha sido usado.
Esto es un claro ataque. Se aplica el caso 3 a todos ellos.
Caso 6) Un usuario utiliza CR incorrectos que se distinguen en 1 o 2 cifras.
1) Si se intenta menos de 3 veces se asume que es un usuario torpe.
2) Si se intenta mas de 5 veces se asume que es un ataque
de prueba/error y se aplica el caso 3.
Caso 7) Un usuario usa distintos CR correctos en un corto periodo de tiempo.
Aunque esto es perfectamente legal, resulta sospechoso que haya
comprado varias tarjetas, en vez de comprar una con el precio total.
Caso 8) Un usuario carga una cantidad excesiva de dinero.
Aunque esto tambien es perfectamente legal, levanta sospechas. TelCo
no quiere que nadie tenga demasiado dinero en una tarjeta pre-pago.
Por cierto, el limite real esta en 99.999.999 unidades. Si la unidad
es centimos de euro, el limite es casi 1.000.000 euros.
Caso 9) Si las tarjetas han sido robadas en la tienda, los CR se marcan
con status=3 (anulado). El uso de cualquiera de estas tarjetas dispara
una alarma que conlleva la anulacion inmediata del numero de
de telefono, al igual que BAS.3.2
Otros factores que disparan alarmas son:
-medio de uso: las alarmas provenientes de intentos a traves Web se analizan
con mas detenimiento, por ser cuna habitual de individuos peligrosos. Algo
habran hecho para merecer ese castigo, mi Senior. (NdB. Don Quijote. Replica
de Sancho cuando don Quijote pretende liberar a los galeotes)
-ubicacion geografica: los intentos fallidos desde zonas deprimidas
economicamente son mas propensos a recibir mayores castigos.
Como nota curiosa, los intentos realizados en areas incluyendo centros
comerciales tambien son de alto riesgo, mientras que las zonas
residenciales son de pefil de bajo riesgo, y, por consiguiente, las
sanciones son menores.
-el momento del dia: por lo que oido, durante la maniana se producen muchos
mas casos del tipo 1 y 2 y 6.1 que en otros momentos del dia, porque las
amas de casa van a recargar sus moviles, y se equivocan al teclear.
Si quieres te lo crees.
Voy a detallar los momentos en los que algun hacker de los que hay por el
mundo podria haber corrompido los datos y las medidas que evitaron que
tuviera exito.
El primero sucedio cuando se generaron las tarjetas chip con los codigos.
Aunque las semi-llaves hubieran sido robadas no se podria hacer nada porque
no se sabe el algoritmo que se usa para generar los NSCR.
Si asaltante supiera el algoritmo y ambas semi-llaves seria capaz de
obtener un CR a partir de un NSCR. No le serviria inventarse un NSCR y
generar su CR, pues esto chocaria contra el IHAW, pero aun asi el ataque esta
claro: ir a una tienda, solicitar una tarjeta como yo que tenga el NSCR
impreso.
Me mira pero no me compra, aunque memoriza mi NSCR. Vuelve a su guarida
para calcular el CR, y usarlo. Cuando un comprador legitimo me compre
resultara que el codigo ya ha sido usado, y posiblemente el ingenuo
se estrelle contra el BAS. Incapaz de saber que ha sido victima de un
fraude seguramente formara un caso 4. Si consigue convencer al servicio
de atencion al cliente de TelCo -al fin y al cabo, el usuario posee
el NSCR y el cartoncillo original- le devolveran el dinero y al autentico
defraudador le aplicaran BAS.3 ; quizas BAS.3.4
Una alternativa a esta es comprar un cartoncillo, y suponer que los restantes
que han quedado en la tienda tienen NSCR secuenciales con el que ha
adquirido. Pero esto es BAS.7
Otro momento de panico sucedio cuando se ejecuto el programa CREATION.EXE
para generar la lista. Supongamos que el programa tiene un troyano que
manda la lista de NSCR y CRCHI a un malvado. Sin los CRs no valen de mucho.
Mas interesante seria si incluyera en tickets.CHI siempre un NSCR
constante, del que el atacante supiera el CR. Por supuesto que alguien
notaria que la lista tiene un numero que no va en secuencia, pero
ademas el sistema no podria introducir en la base de datos un NSCR
que existia, de cuando tickets.CHI fue generada anteriormente. IHAW again.
Mas tarde viajo en el fichero tickets.CHI hasta el impresor. Si alguno
de los codigos fuera alterado por el camino, el impresor no podria
descifrarlo con la clave publica del MSc y sabria que algo raro
estaba sucediento. Bondades del sistema de claves publicas y privadas.
Si el impresor decidiera imprimir alguna tarjeta con un CR que no
pertenece a ningun NSCR de la lista, simplemente no estaria en la
base de datos. De bruces contra el IHAW. Otra cosa seria si usara un codigo ya
impreso anteriormente, o duplicara una tarjeta, usando una para su propio
provecho. Alguien sufrira un BAS.5
Notar que los CR que se pueden usar nunca esta en poder del MSc , y solo
llega hasta el MSv cuando alguien me intenta usar.
El ataque que definitivamente funciona es interceptar los CR cuando estan
en las oficinas del impresor. Esto incluye desde el momento en que
DESCRIFRA.EXE genera mi CR hasta el momento en que se recubre con
pintura plateada la zona del cartoncillo en la que esta impreso el CR.
Por ejemplo, un operarios que trabaja en la fotocomposicion. BAS.5
Y es que el siglo veinte es un despliegue de maldad insolente.
(NdB. Referencia al tango 'Cambalache'. Un saludo para los portenios)
Pero esto forma parte del procedimiento fisico de seguridad que tenga
establecido el impresor dentro de sus oficinas.
El ultimo ataque fuera de la zona No-Desmilitarizada, es decir, antes del
firewall, se podria llevar a cabo con un spoofing (alteracion de la
personalidad) del servidor de TelCo que recibe las peticiones.
No hay que pensar solo en suplantar al servidor web que permite que los
usuarios escriban su MSISDN y mi CR, sino tambien sniffeando y anulando
al servidor SMSC de mensajes SMS (ya se, es un reto muy grande) o al
servidor al cual se conecta el sistema bancario cuando el usuario recarga su
tarjeta pre-pago desde un cajero. Tambien quedaria impresionante suplantar el
IVR. Vamos, llama a TelCo y diles que deseas alquilar el numero de telefono
969696966, veras cuanto se rien.
Dentro de la Intranet de TelCo el unico ataque puede efectuarlo un trabajador
descontento o un troyano (control remoto).
El fichero en el que me encuentro, junto con algunas de mi hermanas y
primas, esta en un fichero de un SCP propiedad de Nokia, que tiene un sistema
operativo completo, con conectividad FTP y HTTP, lo cual permite que la
maquina Linux lo recoja. Recuerda que el malvado simplemente ha generado
una peticion para que su MSISDN sea recargado, en virtud de un CR mas falso
que una moneda de 7 euros, pero que intentara parchear algun sistema para que
sea aceptado como bueno. Yo, desde el primer momento que vi a aquel CR ya
presentia que no era de buena familia.
Por supuesto no tiene sentido modificar el fichero recibido antes de procesarlo,
pero, que pasaria si el Servidor de Transacciones (el Linux troyanizado, para
los que se han perdido) decidiera que ese CR concreto le ha caido bien, y no
necesita pasar por la validacion? Al igual que los otros CR correctos, lo mete
en la base de datos de recargas exitosas junto con el malvado CR, e incrementa
el saldo.
Pero esto solo funciona la primera vez, porque si este metodo se usa otra vez
con el mismo CR, resultaria que estaria duplicado, y saltaria otra alarma. Como
tenemos el MSISDN, pasamos a BAS.5
La solucion estaria en transformar el CR malvado en otro CR. Pero si se
elige un numero aleatorio (total, ya ha pasado la verificacion) hay otro
mecanismo de alarma: los CR almacenados en la tabla cardstable se pueden
verificar una y otra vez, y, dado que hay varios servidores de transacciones
redundantes (cada uno con su propio lector de tarjetas, aunque todos
con la misma copia de la tarjeta microchip) lo mas seguro es que se haga una
auditoria cada mes y se detecte que hay un codigo incorrecto. Entonces si
que saltan las alarmas de verdad !
Asi que la unica posibilidad que le queda es usar un CR que todavia no haya
sido usado. Esto es imposible, pues el modulo MSv no puede calcular un
nuevo CR; solo puede verificar.
Si alguna de nosotras tiene la mala suerte de ser robada en la tienda, Telco
puede anularme buscando mi NSCR (no mi CR, pues al no haber sido usada no posee
todavia ese dato) y poniendo status=3 (anulada).
Lo mismo sucede si me pierdo por el camino, si alguna de nosotras ha tenido
algun problema a la hora de ser impresa (ej. los numeros salen borrosos), si
el propietario de la tienda decide anular el pedido, o mil circunstancias mas.
Una cosa que le paso a una conocida mia es que fue adquirida, rascada, y
al intentar activarla resulto que el telefono no era de pre-pago sino de
contrato. El incremento de saldo no se realizo porque no tenia sentido, el
CR fue registrado como status=4 (usado) pero a la hora de hacer los informes
de TelCo ese numero de telefono no aparecia en la lista de telefonos validos.
La solucion fue marcarlo como anulado. El recargo fue deducido de la factura
del cliente del mes siguiente. Otro cliente satisfecho.
Como veis, el control del fraude es una tecnica ampliamente estudiada e
implementada en TelCo, y por extension, en cualquier compania telefonica
que sepa lo que le interesa.
Asi que espero que te haya parecido interesante mi vida y no se te ocurra
intentar enganyar al sistema.
--------------------------------------------------------------------------
-Ya, ya, todo esto esta muy bien, pero seguro que existe algun metodo secreto
para obtener nuevos codigos para recargar tarjetas de pre-pago . Vamos, no
seas rata y dimelo, que no te cuesta.
-No has entendido nada de nada, verdad? Bueno, aqui tienes algo que quizas te
sirva. Ejecutalo y dejame en paz. Pero si te pasa algo yo no soy responsable.
/* La ejecucion de este programa puede tener consecuencias desastrosas */
/* ASEGURATE QUE ENTIENDES LO QUE HACE ANTES DE PONERLO EN MARCHA. */
#include <stdio.h>
#include <string.h>
char TK15[]="02161";
char HalfKey[]={0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,
17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,255};
int nbr_cert=25;
int _system(char *i)
{
return(HalfKey[*i]^TK15[*i%5]);
}
char MSc[]={83,94,66,54,66,50,33,32,40,53,37,98,154,31,53,15,86,243,
76,20,84,252,76,26,35,138,14,22,193,94,255,32,0};
char MSi[]={83,94,66,22,10,16,81,93,83,80,66,50,198,35,76,90,220,32,
24,34,174,32,49,92,188,82,83,92,131,25,254,33,0};
char MSv[]={85,81,89,89,17,126,93,17,83,95,68,91,84,88,85,85,65,17,
88,80,84,83,49,183,249,242,14,18,250,99,253,34,0};
main()
{
int i=0;
for(i=0;i<32;i++)
{
MSc[i]^=TK15[i%5];
MSi[i]^=TK15[i%5];
MSv[i]^=TK15[i%5];
}
printf("------------------------------------------------------- \n");
printf("| NSCR | CRCHI | CR | \n");
printf("------------------------------------------------------- \n");
for(;nbr_cert>0; nbr_cert--)
{
for(i=0;i<32;i++)
HalfKey[*i]^=TK15[*i%5]
printf("%16i" ,system(MSc));
printf("|");
printf("%16i" ,system(MSi));
printf("|");
printf("%16i" ,system(MSv));
printf("\n");
}
}
*EOF*