image

Биткоин и криптовалюты в целом сейчас у всех на слуху. Моё знакомство с криптовалютами произошло примерно 5 месяцев назад, именно тогда я начал инвестировать в bitcoin и ethereum, курс на тот момент был по $1900 за btc и $89 за эфир. Для того, чтобы вы могли понять, какой профит я получил, скажу, что на момент написания статьи биткоин стоит $18 100, а эфир $830 и продолжает выходить на орбиту вместе с остальными криптовалютами. Подумал, что будет отлично посмотреть насколько безопасны сервисы, в которых я держу свои криптовалютные сбережения, торгую ими или отдаю в доверительное управление.

Ещё в конце весны я купил доступ за $500 к инсайдам одного инвестиционного клуба. Прикупил себе ещё монет, — это кроме эфира и биткоина, а в конце августа поступила рекомендация о том, что можно отдавать свои биткоины трейдерам под %15 в месяц, именно поэтому я начал свой путь с сайтов, которые занимаются доверительным управлением.

Первая компания — example1.com (Запретили разглашать названия, связанные с их веб-сайтами) очень популярна и известна для многих инвесторов. Перед тем, как вкладывать туда деньги, решил проверить личный кабинет на уязвимости. Зарегистрировался, но на удивление — ничего не нашёл, везде фильтрация, csrf токены и тд. Потом зарегистрировал ещё один аккаунт, но вместо имени вписал скрипт сниффера. Мне долго ничего не приходило, я уже было смирился с тем, что у проекта все хорошо с безопасностью, нет никаких BLIND XSS и прочих вещей, но только до момента пока мне не пришли логи (исходный код, ip администратора, local storage и др)

JS выполнился, когда админ проверял страницу с данными о пользователе admin.example1.com/user/default/index?page=75. Аналогичные уязвимости всё чаще встречаются на hackerone, пример https://hackerone.com/reports/251224.

Просмотрев логи, я расстроился из-за того, что все cookies с httponly флагом и не удалось получить ни одной, в итоге, я бы не смог получить доступ к админ панели, но когда перешёл по ссылке admin.example1.com/user/default/index?page=75, то увидел, что админ панель можно использовать без авторизации, — это грубейшая ошибка разработчиков.

Всего можно было просматривать и изменять информацию о 2010 пользователях (email, телефон, ссылки на соц сети, кошелёк для вывода bitcoin, логин, баланс, реферер). На скриншоте один из самых богатых инвесторов клуба, у него большое число подписчиков и я постоянно слежу за его блогом. Он порекомендовал всем своим подписчикам вкладывать в это ДУ свои деньги, конечно же, по реферальной ссылке, но не больше %20 от капитала. Через небольшой промежуток времени ему удалось заработать на этом 20 биткоинов, что равняется $360 000 на сегодняшний день.

image

Злоумышленник без какой-либо подготовки или опыта мог легко зайти в админку и изменить email адреса всех инвесторов на свои(или просто изменить кошельки для вывода, чтобы не вызвать лишних подозрений когда жертва решит вывести деньги, ибо при выводе кошелек по каким-то причинам не отображался). Инвесторы там достаточно крупные, у многих есть депозиты >0.5btc. Очень странно, что в админке не указаны пароли в открытом виде, —
у меня такое чувство, что разработчики этого ДУ способны на всё что угодно в плане ухудшения безопасности своего сервиса.

После обнаружения уязвимости я прислал репорт разработчикам, они, в свою очередь, связались с создателем и устранили уязвимость… Мне предложили начислить награду на счет в личном кабинете, где я буду получать % и через полгода смогу выйти в безубыток, а уже через год заберу само тело. Месяцем позже, когда я нашёл похожую blind xss у них в сервисе и получил за неё ещё баунти, стало известно, что разработчиков ДУ уволили (и деньги за их работу на то время вроде бы не выплатили), разработкой стали заниматься другие люди.

Немного позже, после первой рекомендации, пришла вторая (example2.com). Это тоже топовый, популярный сервис доверительного управления, у него alexarank <50 000, так же, как и у первой компании.

Тщательно всё проверив — ничего не обнаружил (даже любимый clickjacking :)), кроме двух CSRF уязвимостей в post запросах. Первая позволяла изменить реквизиты для вывода средств: пользователю было достаточно перейти по ссылке на CSRF эксплойт. Вторая позволяла вывести деньги пользователя на уже измененные реквизиты. Таким образом, если юзер просто перейдет по ссылке, то лишится всех своих денег. Как можно было осуществить атаку? Злоумышленник мог бы нанять специалиста по социальной инженерии, проспамить участников их чата в telegram и получить хороший профит.

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

Чуть позже случились вполне предсказуемые вещи для проектов такого рода — реквизиты пользователей начали массово менять, узнал я об этом от их разработчика, который отписал мне буквально пару дней назад(как я понял из его слов — юзеры сами делали вывод, и средства начали пропадать). Страшно представить потери в том случае, если бы хакеры задействовали уязвимость в выводе средств. Разработчик попросил ещё раз отправить репорт об уязвимости, после этого на форму смены реквизитов была добавлена google recaptcha и подтверждение по смс (чтобы наверняка).

После этого я решил заняться поиском уязвимостей на криптовалютных биржах.

Poloniex я решил не трогать, — они не платят за уязвимости, да и капитала я там не держу. Именно из-за их игнорирования проблем безопасности — уязвимость обхода двухфакторной аутентификации была продана в даркнете, cсылка — https://t.me/vulns/43.


Раньше там у меня было на счету $6000, совсем случайно зашёл на свой аккаунт из vpn Молдавии, как итог — аккаунт сразу заблокировали. Пришлось пол месяца ждать разблокировки, после этого случая вывел оттуда все свои деньги. Хорошо, что просто не забрали их себе, как делали со многими клиентами.

Решил начать с livecoin.net. Биржа оказалась хорошо защищена, обнаружил только low-импакт SELF XSS уязвимость(она так и осталась self, clickjacking на сайте и csrf в post запросе нет). PoC видео



Затем принял решение перейти к okex.com. Эта биржа очень популярна не только в Китае, но и во всем мире. Некоторый фукнционал не полностью переведен на английский, он на китайском языке, но это не стало проблемой, расширение google переводчик помогло мне быстро выделять текст и переводить его, не уходя из страницы. Как и во всех остальных случаях — я тщательно проверил безопасность, в том числе поддомены и директории. Оказалось, что https://www.okcoin.com/ (6000 alexa china), https://www.okcoin.cn/ (9000 по миру, 2000 в Китае) имеют точно такой же дизайн и функционал, как и okex. Это значит, что если я найду уязвимость на одном их сайте, то остальные тоже будут ей подвержены. Позже заглянул в службу поддержки пользователей (немного пофантазировал о том, как я заливаю shell в тикет и он выполняется) и обнаружил множество уязвимостей, расскажу о них ниже:

1. Уязвимость iDOR www.okex.com/question/questionDetail.do?workOrderId=2550, позволяла просматривать все 2500 тикетов okex на то время; на сегодняшний день количество увеличилось до 4898, и это тикеты на одной только бирже. В тикете раскрывается полный номер телефона, email, настоящее имя, текст переписки между юзером и поддержкой и полный путь к прикреплённому вложению.

image

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

image
image
image
image

Кроме паспортов, раскрывается также множество фотографий и скриншотов с экранов устройств.

image

Я приступил к скачиванию всех тикетов (использовал как доказательство критичности данной проблемы). Использовал Burp Intruder, запустил и поставил от 1 до 2549 на url /question/questionDetail.do?workOrderId=2550. Обнаружил, что никакая информация не загрузилась. Решил вернуться обратно к поддержке и еще по-перехватывать запросов, в тот момент обнаружил, что подгрузка на страницу производится через get www.okex.com/v2/support/cs/work-order/2550/replies. Кинул этот запрос в интрудер и скачал все тикеты, — теперь их можно было свободно отправлять разработчикам бирж.

2. Stored XSS в api. Наш js не отображается в самом тикете /question/questionDetail.do?workOrderId=2550, видимо, там стояла фильтрация на запрещенные символы. Но в api /v2/support/cs/work-order/2550/replies всё прекрасно работало, — подгружался даже js со сторонних доменов.
Если скомбинировать 1 и 2 уязвимости, то можно было успешно украсть много денег. Атака должна была протекать по такому сценарию:

1) Парсим все email адреса.
2) На нашу страницу встраиваем js/html редирект на фишинговый сайт самой биржи(в данном случае, есть несколько бирж, и для каждой нужно будет сделать форму), Myetherwallet, blockchain.info и др.

Некоторые умельцы дошли до того, что сразу после ввода логина и пароля на poloniex.com / bittrex.com / blockchain.info запрашивают в жертвы её 2FA код каждые 15 секунд (для входа в аккаунт, для вывода средств), — реагировать на ввод 2FA нужно очень быстро, потому что его срок действия истекает через короткий промежуток времени. Таким образом, с помощью unicode символов, заменой некоторых букв, например i на L (BlTTREX.com, POIONIEX.COm), регистрацией обменника на другом домене (например poloniex.com.ua), созданием приложений на android и рекламой в поисковых системах, злоумышленники за год смогли украсть у пользователей больше $80 000 000.

3) Отправляем на email адреса письма, которые мы заранее согласовали с человеком, разбирающимся в соц инженерии. Пользователи должны поверить в письмо и перейти по ссылке, так как она ведёт не на сторонний сайт, а на биржу.

4) ??
5) Получаем данные для входа, выводим средства.
PoC этой XSS в видео



3. iDOR в добавлении комментария, можем добавить сообщение от имени пользователя, который создал тикет.

Краткий запрос

POST /v2/support/cs/work-order/reply HTTP/1.1
Host: http://www.okcoin.com

workId=718&content=test_message


4. Stored XSS в html файле, который прикреплялся к тикету, но на домене bafangpublic.oss-cn-hangzhou.aliyuncs.com. Домен уже не доступен и whois говорит, что он принадлежит Hangzhou Alibaba Advertising Co.,Ltd.

5. Disclosure information. Я заметил, что разработчики бирж хотят максимально скрыть номер телефона пользователя при взломе аккаунта. На странице безопасности телефон отображается как 636819****, в cookies он 6 * 6. Но в ответе api службы поддержки /v2/support/cs/work-order/2550/replies его полностью отображает, так не годится.

Насколько я понял, — у всех бирж один владелец и нет смысла писать всем отдельно, поэтому отправил репорт в чат и на email биржи okex. Очень быстро получил сообщение от официального аккаунта okex в твиттер, и уязвимости оперативно устранили.

Дальше начал тестировать example3.com. Биржа запретила раскрывать информацию об уязвимостях, цитирую:

Regarding posting on your blog, we would appreciate if you don't do this at the moment. Our site is still not 100% secured and I fear it will open a door for malicious users.

Обнаружил XSS в кошельке, а именно — в отделе партнерской программы, — получилось поднять её из self в хранимую с помощью csrf эксплойта, можно было воровать cookies, так как отсутствовал флаг httponly. Я мог бы сейчас прикрепить видео, которое уже записал, но, увы — там раскрывается название биржи.

За неё в службе поддержки мне предложили $100, но почти в тот же момент на сниффер пришли логи из их домена для сотрудников.

image

В логах была только cookie

AWSELB=2ЕB3B1851EC08CCFEEC18E2DB93AE1EF2A69A2A2F9D65DCC84AB785C7C7773319F1F769CCF35CA8F430D5785D5AE4AB2C48C46EE6BE8F33Cу293D40F3CCA9F92E38E62AA65, сессионная кука(самая главная) отсутствовала, мы не можем проникнуть в админ панель через подмену куков. Я тщательно проверил репорт и нашёл в исходном коде логин и пароль администратора

image
image

Но когда зашёл на страницу авторизации, то увидел это.

image

В админ панель через логин; пароль мы попасть не можем, необходимо взломать учетную запись google и получить доступ к authenticator, или сделать редирект на фишинговый сайт прямо из админки, украсть его код и быстро его ввести. Второй вариант вполне реализуем.

Пока писал репорт об blind xss в админке, нашёл ещё:

1) CSRF уязвимость в изменении реквизитов для вывода партнерских средств, краткий запрос:

POST /affiliate_program HTTP/1.1
Host: www.example3.com
wallet=my_wallet&act=wallet

security токена нет, был написан эксплойт.

2) iDOR в удалении заказов, уязвимый запрос example3.com/account?act=cancel&order=ID_of_order. Суть уязвимости в том, что если юзер уже создал заказ и хочет переводить свои биткоины на кошелек биржи, — мы можем отменить это действие. В лучшем случае, его заказ просто удалится из системы, в худшем — он переведет биткоины и потеряет свои деньги. Эта уязвимость в основном полезна только для бирж-конкурентов, а не для хакеров.

После того, как я прислал новый репорт в поддержку, со мной на связь вышел chief security officer для обсуждения уязвимостей. Мне хотели позвонить в скайпе или по телефону, но в данный момент мои знания английского находятся на среднем уровне, поэтому решили ограничиться чатом. За уязвимость мне предложили 0,1 btc($1130):
After consulting with our finance and regarding our situation, we can pay you $1000. This is the highest amount we paid for a bug and is much higher than what we usually pay. It is to show our appreciation to you and the way you handled the situation.

Приношу свою благодарность за bounty. Они ответственно относятся к безопасности, приятно было общаться с их CTO.

Всего с поиска уязвимостей на этих сайтах, занимающихся криптовалютой я получил:
Доверительно управление example1.com: 1 btc.
Доверительное управление example2.com: 0,122 btc.
Биржа livecoin.net: $200 фиатными средствами.
Биржа okex.com: 2 btc, я благодарен okex за баунти, CTO биржи разрешил публично раскрыть уязвимость.
Биржа example3.com: 0,1 btc.
1+0.122+2+0.1+$200=$58 200 и с ростом курса bitcoin эта сумма будет расти.

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

P.S: Так же есть интересная информация на тему того, как я обнаружил уязвимость на gearbest.com, позволяющую узнать логин и пароль от любого аккаунта, а так же об уязвимости на webmoney.ru(могу рассказать об этом только из разрешения администрации), с помощью которой можно было отправить сообщение с js/html 35 000 000 пользователей, но это уже совсем другая история. Чтобы быть в курсе моих последних статей, рекомендую подписаться на telegram/twitter/vk, ссылки внизу.

Комментарии (39)


  1. EminH
    21.12.2017 18:53

    взломать учетную запись google и получить доступ к authenticator

    authenticator в учетной записи ничего не хранит, для доступа к секретному ключу нужно иметь доступ к самому устройству.


    1. zzwsu
      21.12.2017 20:06
      +1

      сдается мне, что ключ authenticator'a бэкапиться в облако по умолчанию (как и другие сервисы гугл), с ключом можно получить код.


      1. EminH
        21.12.2017 20:10

        не-а, не бекапится. даже в доках при смене телефона предлагается повторно сканировать QR (и правильно делают, кстати :) )


      1. Arturkkas
        21.12.2017 21:46

        Ключ не бэкапится, но хранится в обычном .xml файле (я про Android). Энивей, без рута его не достать. Короче, так или иначе нужен доступ к самому устройству.


        1. Zebradil
          23.12.2017 19:01
          +1

          У Google Authenticator база данных в формате sqlite лежит. Получить можно так:

          adb pull /data/data/com.google.android.apps.authenticator2/databases/databases
          

          Требуется рут.


  1. vostotskiy
    21.12.2017 20:06
    +2

    Спасибо за интересную статью! Посоветуйте, пожалуйста, материалы, по которым можно обучиться поиску уязвимостей


  1. w9w Автор
    21.12.2017 20:12

    Вот https://leanpub.com/web-hacking-101. Прочитал её, немного нового узнал. Будет полезна как новичкам, так и опытным багхантерам.
    P.S: Ходят легенды, что если хорошо поискать, то можно и не платить $10 за книгу.


    1. vostotskiy
      21.12.2017 21:12
      +1

      Спасибо!


    1. IgorLutiy
      23.12.2017 10:52

      Если вдруг кто сразу не заметит, там есть версия и на русском языке.
      ЗЫ: по легендам, её тоже можно поискать и даже найти.


  1. Gorodnya
    21.12.2017 20:29
    +1

    Я на днях нашёл XSS на одном билетном сайте с ~200 000 зарегистрированных пользователей — получил 500 грн. (~18 долл.). Заметно отличается подход наших и иностранных компаний, пусть последние и работают с финансами:)


    1. lostpassword
      21.12.2017 21:26
      +2

      Хорошо ещё, что уголовкой грозить не стали)


      1. Gorodnya
        21.12.2017 21:55
        +1

        Да, бывает и такое) Но тут ребята, кстати, всё равно молодцы — на моё первое письмо они сами попросили номер карты, чтобы отблагодарить.


    1. Tihon_V
      21.12.2017 21:58

      Кажется я знаю, о какой компании речь… Это ведь она недавно запретила возврат билетов онлайн? Найденные мной баги так и не исправили :/

      Попробуйте, в этой же стране проверить сервисы по продаже билетов в кино/театры/на концерты — там не намного лучше.

      P.S.: Перестал верить в предоплату после 2014 года :/


      1. Gorodnya
        21.12.2017 22:02

        К сожалению или счастью, нет, не она. Эта бы точно пригрозила бы:)
        Согласен, во многих сервисах можно найти ошибки и уязвимости, нужно лишь время и желание.


        1. dobergroup
          24.12.2017 21:23

          Из опыта — нет, не грозила, просто не ответили


    1. zeuss56
      23.12.2017 11:38

      А могли бы получить больше, никому ничего не сообщая))


  1. ValdikSS
    21.12.2017 21:09
    +3

    Вывод из статьи: поставьте себе уже локальный кошелек, хотя бы не полный, вроде Electrum или Jaxx. Хранить криптовалюты у какого-то стороннего сервиса, ну охренеть просто.


    1. zeuss56
      23.12.2017 11:41

      Там не просто хранение, там проценты. А вообще да, это всё из-за непонимания и халатности. Люди даже не думают, что всё может исчезнуть вот так.


  1. maxlazar
    21.12.2017 22:01
    +2

    1+0.122+2+0.1+$200=$58 200 и с ростом курса bitcoin эта сумма будет расти.
    а тем времнем, эта сумма уже выросла до $49 800


    1. w9w Автор
      21.12.2017 22:07

      Ну, такая волатильность у биткоина, что поделаешь :) Ему очень нужны эти коррекции для того, чтобы взять новые вершины. Мог бы продать, когда был подъем до $20 000, но думаю придержать до 25-30


      1. j-ker
        22.12.2017 00:34

        Вы такой умный и хороший (этичный) человек, что не могу пройти мимо — выходите из рынка, сливайте нахрен это мыло ))) будьте счастливы, наконец


        1. modestguy
          22.12.2017 09:18

          уже 13 )


      1. DGerome
        22.12.2017 18:25

        Продавай битки, w9w! Серьёзно. Продай хотя бы часть. Это классическая схема спекуляции pump-and-dump.


    1. Tlesk
      22.12.2017 17:06

      уже 41300!


    1. zeuss56
      23.12.2017 11:57

      Можно было успеть вывести все деньги, я благодаря новостям около $1500 сэкономил (0.5 btc держал), думаю вкладываться bitcoin cash, но пока держу.
      19.12.2017 11:35 «Не имеет будущего»: сооснователь Bitcoin.com продал все свои биткоины
      20.12.2017 12:05 Курс биткоина рухнул после начала торгов модным Bitcoin Cash


  1. Juiceee
    21.12.2017 22:04
    +1

    Здесь есть смайлик восторга? :)


  1. ideological
    21.12.2017 22:20

    А как в случае с CSRF посылают POST-запросы?
    В примере wiki по этой атаке

    Мэллори: Привет, Алиса! Посмотри, какой милый котик: bank.example.com/withdraw?account=Alice&amount=1000000&for=Mallory
    и тут GET запрос.
    А как посылают POST?
    Если к примеру тикет в техподдержку создается по POST-запросу на https сайте без временного токена (просто проверка куки пользователя), это не безопасно?


    1. w9w Автор
      21.12.2017 22:34
      +1

      Если тикет в техподдержку создается по POST-запросу без временного токена (просто проверка куки пользователя), это не безопасно?


      Если нет csrf токена, то это не безопасно. Иногда, даже когда токены прикрепляются к запросу, их можно обойти.

      А как посылают POST?


      Просто крафтят эксплойт с post запросом на стороннем сайте, жертва переходит по ссылке и выполняет этот запрос (так же можно выполнить этот post запрос, используя xss на уязвимом сайте). Можно создать эксплойт вручную, а можно сэкономить время и сделать его в burp pro.


      1. ideological
        22.12.2017 10:24

        Я просто не совсем въехал в тему и хочу разобраться для безопасности.
        По неопытности я думал что токен передают только в параметрах POST-запроса беря из исходного кода странички (чтобы типа было безопасно). Но как я понял сейчас делают по другому.

        Вот для примера проверил популярный сайт и там лайк ставится запросом где просто указывается коммент, в параметрах токена нет (vc.ru). Но токен есть в заголовках запроса:
        X-JS-Version:2bdf4615
        X-This-Is-CSRF:THIS IS SPARTA!

        Это какой метод защиты и как он работает? То есть почему такая защита работает вообще, если токен есть в самом запросе? (и вроде даже одинаковый для разных пользователей).


        1. nekt
          23.12.2017 01:38

          Со стороннего сайта нельзя перенаправить пользователя для осуществления СSRF-атаки, добавив в заголовки запроса произвольный заголовок — он блокируется политиками CORS


    1. symbix
      22.12.2017 03:26

      В примере wiki по этой атаке
      Мэллори: Привет, Алиса! Посмотри, какой милый котик: bank.example.com/withdraw?account=Alice&amount=1000000&for=Mallory
      и тут GET запрос.

      Если для подтверждения достаточно просто перейти по ссылке, можно еще так сделать:


      Content-Type: text/html
      
      Привет, Алиса! Посмотри, какой милый котик: https://bank.example.com/withdraw?account=Alice&amount=1000000&for=Mallory
      <img src="https://bank.example.com/withdraw?account=Alice&amount=1000000&for=Mallory">

      Если почтовый клиент настроен на загрузку remote images (как правило, по умолчанию так и есть), то достаточно будет того, чтобы Алиса просто открыла письмо.


      1. legrus
        22.12.2017 10:25

        Но откуда у почтового клиента Алисы куки?


        1. symbix
          22.12.2017 18:21

          Из веб-клиента, конечно.


          Тут, конечно, смотря какой веб-клиент. Gmail такое заменит на адреса своего прокси, а вот live.com, вроде бы, не заменяет. По крайней мере, раньше не заменял. Плюс всякие корпоративные почтовые веб-интерфейсы типа зимбры.


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


          1. symbix
            22.12.2017 18:30

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


  1. Agel_Nash
    22.12.2017 01:57

    Пол года назад на сайте криптонатора обнаружил пассивную XSS и раскрытие путей. Написал в саппорт — до сих пор ничего не исправили и даже не ответили.


    1. lightman
      22.12.2017 08:00

      Обожаю когда по email никто не отвечает. Я бы в законе ввёл за это наказание (нет). Такое создаётся ощущение, что большая часть контор в России — глубоко провинциальные, если не по местоположению, а по мышлению. Дядечка-гендир за 50, выросший в Советском Союзе, охранник, водитель и блондинка-секретарша. Знакомство с IT технологиями ограничивается требованиями законодательства: телефон, касса там, ну бухгалтерия. Сайт если и делается, то за копейки в какой-то унылый конторе, на готовом движке, никем не поддерживается, а то вовсе без оплаченного хостинга.
      Также и емейлы.

      Так и представляю: обычный рабочий день, директор, весь в своих мыслях и проблемах проходит мимо секретарши и как бы невзначай бросает
      — Танечка, я там email нашей фирмы создал, слышал что сейчас это очень модно, ты будешь на него отвечать
      — Чевооо? (хлопает глазками)
      — Емеил. Последнее слово техники. Вот смотри, как всё просто (показывает), теперь каждый день заходи и проверяй почту

      Танечка послушно заходит день, другой, неделю. Писем нет, и она постепенно забивает на это, какой смысл, да и других дел полно. А через год-другой вообще увольняется, пароль больше никто не помнит, а email так и светится на всех сайтах и прочих дубль-гисах, контакт конторы в «модной нынче» глобальной сети.


      1. zeuss56
        23.12.2017 10:52

        У меня таких случаев не было, на письма всегда отвечают, хотя бывает очень долго.
        В чём-то вы правы. Этот провинциально-советский дух ещё пару десятилетий будет нас сопровождать. А потом мы и сами станем устаревшими.
        Можно конечно дружно установить почтовые клиенты на свои смартфоны и ожидать пиликанья в кармане. Но концепция эл. почты почему-то не располагает пользоваться ей — это не сервис мгновенных сообщений. Часто задаюсь вопросом, почему нельзя переработать почту, или глобальнее — уплотнить синхронизацию соц. сетей, почты, телефона, сделать универсальный протокол для всего? И пока я многого не понимаю.


  1. gorets
    22.12.2017 09:15

    Прочитал, испугался — какие вы все тут опасные )))


  1. seidzi
    22.12.2017 18:26
    +1

    статья замечательная, я хоть и не работаю с безопасностью, но мне было очень интересно почитать, скинул коллегам :3