How we prevent Code.org from becoming a botnet

For most of Code.org's history, teachers and students could access almost all Code.org courses without logging in or having an account; A free account is required to access CS Beginnings or CS Discoveries content only. Also, teacher verification is required for a small set of things (namely the answer keys for CSP and CSD). We also require teacher verification to access our CSA course and JavaLab content.

Why is teacher verification required to run code in CSA and Java Lab? Why does being verified unlock the same action for a teacher's students? The short answer: We wanted to prevent Code.org from becoming a botnet!

Let's analyze that. What is a botnet? How could Code.org become one? How does this prevent teacher verification?

botnets

In short, a botnet is a collection of computers, phones, smart TVs, smart lights, and other internet-connected devices that have been compromised by an attacker and directed to run the same program. These are usually devices that have been infected with a virus and are controlled by a hacker. The programs are usually sophisticated enough to run in the background, so the actual owner of the device doesn't know what's going on.

These botnets are then used for a variety of actions ranging from legal (except running on stolen resources) to highly illegal. These actions could include cryptocurrency mining, executing DDOS attacks, ad spam, and many other actions. Botnets can also be rented for prices that scale with the size and duration of the attack. (Walarm has a great in-depth article on botnets if you're interested in learning more .)

How does this relate to Code.org? Keep reading.

Code.org CSA Curriculum

En 2022, Code.org lanzó nuestro primer plan de estudios CSA, que se puede usar para enseñar las habilidades necesarias para aprobar el examen AP CSA College Board. En CSA, los estudiantes aprenden Java, un lenguaje que debe compilarse y luego ejecutarse en un entorno que tiene instalada una máquina virtual Java (JVM). Hasta que Code.org agregó este plan de estudios de CSA, todo el código de estudiantes y maestros en Code.org se ejecutaba en el navegador de cada usuario, en la computadora de cada usuario. Esto fue posible porque todos los entornos de codificación de Code.org, como App Lab o Sprite Lab, usaban alguna variación de JavaScript, un lenguaje que los navegadores entienden.

No es así para Java.

Para ejecutar código Java, necesitábamos un nuevo enfoque. Los detalles completos podrían caber en una publicación de blog propia, pero en resumen, el código de estudiante y maestro debe ejecutarse en un sistema operativo que tenga instalado Java y una JVM. Para evitar pedirles a nuestros maestros y estudiantes que instalen esto en su propia computadora (mucho trabajo para el departamento de TI local de cada escuela), compilamos y ejecutamos el código creado por el usuario en nuestros propios servidores.

Para uso en el aula, esto es bastante inocente. Esto permite a los estudiantes crear arte callejero en The Neighborhood, crear filtros de imagen en The Theatre y hacer proyectos de consola interactivos.

Para un atacante, esto presenta una oportunidad. Para crear una botnet, un atacante generalmente tiene que crear un virus que eluda la configuración de seguridad integrada de cada dispositivo para ejecutar el código del atacante. En Java Lab, un atacante tiene acceso directo a nuestros servidores y puede ejecutar código arbitrario, sin necesidad de elusión.

Para mitigar esto, necesitábamos hacer algunas cosas. Primero, establecimos límites de tiempo sobre cuánto tiempo puede ejecutarse el programa de un usuario (también hicimos un par de cosas más, como evitar solicitudes de red, pero eso es menos relevante para esta historia). Ese primer paso fue de gran ayuda ya que la mayoría de los usos de botnets requieren acceso abierto a Internet o mucho tiempo. Pero un atacante puede sortear el límite de tiempo. Solo necesitarían dividir su programa en partes pequeñas y ejecutarlo miles de veces en Java Lab para obtener el mismo efecto. El siguiente paso sería limitar la cantidad de veces que cada usuario puede ejecutar un programa. Pero eso nos lleva a nuestro próximo desafío...

Cuentas de usuario

En Code.org, queremos mantener la barrera de entrada lo más baja posible. Es por eso que se puede acceder a muchas de nuestras actividades y cursos sin siquiera crear una cuenta en nuestro sitio web. Pero para hacer ciertas cosas, como registrar el progreso de un usuario, necesitamos saber qué usuario está accediendo al sitio. Eso significa que debemos alentar a los estudiantes y maestros a crear cuentas. Pero nuevamente, para mantener baja la barrera de entrada, configuramos la capacidad para que los maestros creen cuentas de estudiantes de forma masiva y para que los estudiantes creen cuentas sin una dirección de correo electrónico asociada. Después de todo, ¿cuántos estudiantes de segundo grado tienen una dirección de correo electrónico a la que pueden acceder de manera confiable?

Para nuestros usuarios, esto es genial. Pero para un atacante, presenta otra oportunidad.

¿Ese límite que establecemos en la cantidad de veces que un usuario puede ejecutar un programa? El atacante puede evitarlo simplemente creando miles de cuentas que representen a personas falsas.

Ingrese: Verificación del maestro

En 2015, necesitábamos crear una manera de garantizar que solo los profesores tuvieran acceso a las claves de respuesta de CSP, soluciones de ejemplo y características específicas, como la capacidad de dar retroalimentación a los estudiantes. Teníamos que estar razonablemente seguros de que cada persona a la que se le otorgaba esta habilidad era en realidad un maestro en la vida real (en lugar de simplemente afirmar serlo en Internet). Nació el proceso de verificación docente.

Un efecto secundario de este proceso es que cada cuenta de usuario que es una cuenta de maestro verificada también se asocia directamente con una persona real. Esta era la solución que necesitábamos para evitar este tipo de ataques generados por botnets en Java Lab.

Con cuentas de maestros verificadas, podemos asegurarnos de que una sola persona no pueda crear miles de cuentas falsas para eludir nuestros límites de uso. Además, las cuentas de los estudiantes asignadas a una sección están directamente relacionadas con la cuenta de su maestro. Al verificar si un usuario está en la sección de un maestro verificado, también aplicamos límites de uso adicionales a las secciones del maestro.

Resumiendo

Running a user's code on your servers, rather than in your browser, opens a door for all sorts of malicious activity. The worst of this can be prevented by limiting the amount of time your code can run on the server. But to enforce those limits, we needed to be able to reliably detect who was running the code. And the best way to do that right now is through teacher verification.

We apologize for the extra steps required here, and we appreciate you taking the time to check! Please contact us at verification@code.org if you have any questions about verification or otherwise.