Guiar a los usuarios a través de las peligrosas aguas de la seguridad de contratos inteligentes.

Después de un año de trabajo como auditor inteligente de Ethereum, he desarrollado un sentido intuitivo que me guía en las decisiones relacionadas con la inclusión de los hallazgos en los informes, su clasificación, presentación y otros asuntos que no están directamente relacionados con la parte técnica del trabajo. , sino al contexto más amplio en el que se desarrolla mi trabajo. El objetivo de este artículo es hacer explícita esta intuición, convertirla en una metodología razonada y aclarar mi propio pensamiento sobre el tema. Este no es un texto sobre nuevas herramientas, categorías de vulnerabilidad específicas o un estudio de caso de un ataque reciente. Si está interesado en responder preguntas como cuál es el propósito de la auditoría, cuál es la audiencia prevista de los informes de seguridad, cómo detectar errores de una vulnerabilidad y similares, siga leyendo.

¿Por qué auditamos?

Tener un modelo incorrecto de una herramienta o un sistema que estamos usando puede ser muy costoso. Para ilustrar, pensemos en un ejemplo de dos cadenas que se encuentran alrededor de un sitio de construcción. Una cadena está completamente hecha de plástico, la otra está hecha de acero con la excepción de un enlace de plástico. Cuando se le pregunta cuál es la más peligrosa, la mayoría de las personas probablemente responderán de manera intuitiva a la mayoría de acero. Si bien es probable que nadie intente colgar una carga pesada en una cadena de plástico, podría cometer ese error con una que parece estar hecha de acero. Es por eso que los defectos ocultos son tan peligrosos que nos engañan para que tomemos decisiones equivocadas. Y esa es exactamente la principal tarea del auditor, señalar el eslabón débil oculto en la cadena. Al dar a conocer las debilidades, el auditor convierte los errores en problemas, o en otras palabras, algo peligroso e impredecible en algo que puede solucionarse o solucionarse.

No es tarea del auditor solucionar problemas, o incluso encontrar soluciones, pueden brindar sugerencias, pero su responsabilidad principal es corregir y completar los modelos mentales del sistema para los usuarios. También es incorrecto suponer que el único propósito de los informes es informar el proceso de desarrollo. Debido a que algunos hallazgos pueden no resultar en una mejora del sistema auditado, pueden ayudar a los usuarios a interactuar con el sistema de una manera más segura. Un buen ejemplo de esto es el descubrimiento de la vulnerabilidad de aprobación / transferencia de extracción múltiple en el estándar ERC20 (https://github.com/ethereum/EIPs/issues/738) No entraré en los detalles del ataque, pero mucho antes de que surgiera una actualización estándar que abordara este problema y, desde luego, mucho antes de que fuera ampliamente utilizada, los usuarios encontraron una forma de interactuar con los tokens ERC20 que trabajaban en torno al problema de seguridad.

¿Para quién auditamos?

Al pensar en el propósito de la auditoría, naturalmente hemos llegado a la pregunta de la audiencia de la auditoría. Las aplicaciones de , en contraste con sus contrapartes centralizadas, aspiran a ser confiables, en otras palabras, idealmente, no hay una entidad que sea responsable del correcto funcionamiento del sistema, legal o de otra manera. Más bien, el sistema representa un conjunto neutral de reglas que guían las interacciones de los actores independientes. Todos son responsables de sus propias acciones y, si el sistema falla, no hay nadie a quien culpar, excepto el usuario que decidió participar en el sistema con una comprensión insuficiente. Esta diferencia tiene implicaciones importantes para determinar la audiencia de los informes de seguridad de contratos inteligentes. Operador de un sistema centralizado, por ejemplo, una plataforma como Facebook tiene la responsabilidad legal por fallas de seguridad y eventuales daños que sufran sus usuarios. En esta situación, es natural que los informes de seguridad se escriban principalmente para sus ojos y beneficios, no hay ninguna expectativa de que los usuarios de Facebook Hacen evaluaciones relacionadas con el funcionamiento interno de la plataforma, simplemente confían en Facebook. Por otro lado, un usuario de un sistema de contrato inteligente se compromete bajo su propio riesgo y, por lo tanto, debería estar interesado en evaluaciones de expertos de la plataforma para asegurarse de que lo hagan de manera segura y consciente. Por eso creo que las auditorías confidenciales en plataformas de van en contra del espíritu del movimiento de . Si queremos utilizar sistemas descentralizados imparciales, necesitamos un conocimiento descentralizado imparcial de estos sistemas. Idealmente, el proceso de construcción de este conocimiento debería ser un esfuerzo de colaboración de la comunidad, pero al menos, los expertos deben tener en cuenta que están haciendo una investigación en nombre de los usuarios actuales o futuros, no solo los autores de la plataforma, incluso si actualmente están pagando por su trabajo.

Cómo determinar qué es un problema de seguridad

La categoría más sensible de problemas que encontramos es problemas de seguridad o vulnerabilidades. En general, un error que permite el duelo o el daño intencional se denomina vulnerabilidad. Esto puede parecer bastante sencillo, pero no siempre es fácil decidir qué es una vulnerabilidad y qué es simplemente una expresión de confianza de un grupo de usuarios en otro. Trataremos de tomar esta decisión un poco más clara en los párrafos siguientes.

Si el usuario conoce una vulnerabilidad y, sin embargo, decide libremente comprometerse con el sistema, deja de ser una vulnerabilidad y se convierte en un punto de confianza. Lo que queremos decir con eso es que si un usuario conoce la capacidad de otro usuario para causar daño, pero decide participar en el sistema dado de todos modos, esto puede interpretarse como una expresión de confianza y el aspecto del sistema. Eso pone al usuario en riesgo puede ser llamado punto de confianza.
Si bien hipotéticamente podríamos identificar múltiples puntos de confianza, para un par de usuarios dado, siempre hay uno en particular en el que estamos interesados, cuál es el más grave o el que proporciona la manera más fácil para que un usuario dañe a otro (el uno con el mayor factor de duelo). Para ilustrar: Digamos que le hemos dado a nuestro propietario una llave de nuestra casa para los casos de emergencia, él también podría tener una llave de nuestro patio trasero, pero eso no es muy relevante desde el punto de vista de seguridad, al menos hasta que devuelva la llave de entrada.
Ahora, para que algún aspecto de un sistema se llame vulnerabilidad, tiene que satisfacer dos condiciones. Primero debe ser desconocido para la parte afectada en el momento de la adopción voluntaria del sistema y, segundo, debe permitir un daño más fácil o más grave que el actual punto de confianza.
Esto también significa que lo que se puede considerar como una vulnerabilidad cambia según el contexto, algunos aspectos del código que han sido inofensivos en el pasado pueden convertirse en una responsabilidad si los puntos de confianza anteriores se eliminan cuando el sistema se actualiza para que sea más confiable. O cuando se agregan nuevos mecanismos de confianza al sistema. Es por eso que con cada cambio o extensión sustancial, todo el sistema debe ser reevaluado.

Más adelante ilustraré un hallazgo particular en nuestra auditoría reciente de un contrato inteligente de ICO.

La venta en masa en cuestión incluía una función de inclusión en la lista blanca de KYC, pero permitió que las personas que aún no han pasado por el proceso KYC realicen previamente su ETH con la compra real ejecutada solo después de que se hayan agregado a la lista blanca. El activo que se vendía no tenía valor comercial ni utilidad en el momento de la venta. Nuestro auditor observó correctamente en el informe que el propietario del ICO puede retirar ETH del contrato incluso para los usuarios que no se han agregado a la lista blanca, pero identificó incorrectamente este problema como una vulnerabilidad. Dado que la lista blanca estaba controlada por la misma dirección que los retiros, el propietario malintencionado tendría una posibilidad igualmente fácil de retirar el ETH del comprador al incluirlos en la lista blanca. Dado que el retiro sin la inclusión en la lista blanca no representa una escalada de riesgo por encima del riesgo aceptado implícito, el problema no se clasificó al final como una vulnerabilidad.

La nota final que deberíamos agregar es que el hecho de que un punto de confianza esté documentado en la especificación del sistema del desarrollador no significa que debamos asumir automáticamente que los usuarios lo sabrán. Esto es especialmente cierto para la funcionalidad que entra en conflicto con las expectativas comunes. Por ejemplo, en el caso de un ICO con un objetivo de financiamiento mínimo, los usuarios aprendieron a esperar reembolsos sin confianza en el caso de que el objetivo no se cumpla, incluso si esto no es parte de las especificaciones del código, un auditor concienzudo debe señalar la ausencia porque una buena razón para creer que no formará parte de las expectativas del usuario.

Implicaciones prácticas

Me gustaría terminar este artículo presentando una lista de buenas prácticas derivadas del texto anterior.

La responsabilidad principal del auditor es construir un entendimiento correcto y completo del sistema, las auditorías no son solo listas de errores que deben solucionarse Los auditores deben publicar sus hallazgos incluso en ausencia de soluciones Audiencia primaria de auditorías de contratos inteligentes usuarios Usuarios de auditorías de contratos inteligentes deben ser públicos El auditor siempre debe considerar una perspectiva interés de los usuarios Los auditores deben publicar los informes modificados que documentan las correcciones del problema Los auditores deben documentar su comunicación con el desarrollador Para evaluar qué constituye una vulnerabilidad, primero debemos determinar los puntos de confianza; esta determinación debe basarse en un modelo realista de la comprensión del sistema por parte del usuario.