A small tool to view real-world ActivityPub objects as JSON! Enter a URL
or username from Mastodon or a similar service below, and we'll send a
request with
the right
Accept
header
to the server to view the underlying object.
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"ostatus": "http://ostatus.org#",
"atomUri": "ostatus:atomUri",
"inReplyToAtomUri": "ostatus:inReplyToAtomUri",
"conversation": "ostatus:conversation",
"sensitive": "as:sensitive",
"toot": "http://joinmastodon.org/ns#",
"votersCount": "toot:votersCount",
"litepub": "http://litepub.social/ns#",
"directMessage": "litepub:directMessage",
"blurhash": "toot:blurhash",
"focalPoint": {
"@container": "@list",
"@id": "toot:focalPoint"
},
"Hashtag": "as:Hashtag"
}
],
"id": "https://infosec.exchange/users/krlaboratories/statuses/113882461690332095",
"type": "Note",
"summary": null,
"inReplyTo": null,
"published": "2025-01-24T08:47:40Z",
"url": "https://infosec.exchange/@krlaboratories/113882461690332095",
"attributedTo": "https://infosec.exchange/users/krlaboratories",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://infosec.exchange/users/krlaboratories/followers"
],
"sensitive": false,
"atomUri": "https://infosec.exchange/users/krlaboratories/statuses/113882461690332095",
"inReplyToAtomUri": null,
"conversation": "tag:infosec.exchange,2025-01-24:objectId=233902124:objectType=Conversation",
"content": "<p>5 РОКІВ DNS-ЗОНА MASTERCARD МІСТИЛА ДРУКАРСЬКУ ПОМИЛКУ</p><p>У червні 2020 року дослідник Філіп Катуреллі (CEO of Seralys) помітив, що в DNS-зоні всесвітньовідомого платіжного сервісу MasterCard один із неймсерверів (Akamai) введено з помилкою: замість "akam.net" вказано "akam.ne".</p><p>Хибна конфігурація дивним чином зберігалася аж 5 років, поки про неї публічно не заговорили в LinkedIn (<a href=\"https://www.linkedin.com/feed/update/urn:li:activity:7285038365236682753/\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://www.</span><span class=\"ellipsis\">linkedin.com/feed/update/urn:l</span><span class=\"invisible\">i:activity:7285038365236682753/</span></a>). Подібна недбалість дозволяла будь-кому відкрити домен akam.ne і перенаправляти трафік MasterCard до себе...</p><p>Найбільше здивувала (і обурила) громадськість реакція самої компанії, яка заперечувала, що помилка в DNS якось може критично вплинути на їх безпеку. Мовляв, нічого страшного, все впорядку.</p><p>Пізніше Катуреллі розповів, що зловмисникам достатньо було купити за 300 доларів домен в нігерійського реєстратора (доменна зона верхнього рівня .ne) і зачекати 3 місяці на обробку заявки. Після цього вони могли спокійно відкривати електронну пошту на домені akam.ne і отримувати корпоративні email-листи, відправлені на сервери MasterCard! Це найменше, що можна було зробити у даній ситуації.</p><p>Але дослідник - красунчик. Все-таки не став зловживати, а в цілях безпеки сам зареєстрував домен і повідомив в MasterCard. Хоча ті й надалі продовжували заперечувати, навіть не відшкодувавши йому тих 300 доларів. Просто мовчки усунули друкарську помилку і все... А його звіт на BugCrowd чомусь заблокували.</p><p>Що цікаво, як розповідає дослідник Браян Кребс (<a href=\"https://krebsonsecurity.com\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"\">krebsonsecurity.com</span><span class=\"invisible\"></span></a>), і тут не обійшлося без російського сліду. У 2016 році хтось на рф зареєстрував цей домен і кілька років переспрямовував його на IP-адресу в Німеччині (185.53.177.31), імовірно з метою проведення якихось маніпуляцій і махінацій...</p><p>Ось так! Більш кращого прикладу про важливість безпеки DNS я ще не зустрічав. Одна помилка може відкрити двері для цілого ряду атак: "Людина посередині" (Man-in-the-Middle), фішингу, спуфінгу, перехоплення даних та багато-багато іншого.</p><p>Одразу пригадалася одна історія з мого професійного досвіду. Якось звернулася до мене за послугами одна серйозна конторка. Я довго і нудно намагався їх переконувати, що головна проблема криється саме в DNS - треба негайно перевірити усі записи, зокрема NS-сервери, і бажано перевести домен на обслуговування до іншого реєстратора та додатково підключити DNS Cloudflare, аби унеможливити подальші маніпуляуції. На що мені вперто відповідали: "Ні. У нас там нема проблем. NS-сервери не можуть бути загрозою. У нас все впорядку. Доступ до DNS не надаємо. Можемо надати тільки скріншот". Таким чином вони довго і нудно шукали проблему в SSL-сертифікатах, вихідному коді, хостингу, CMS, але тільки не в DNS.... А зловмисники тим часом по повній в тиху експлуатували вразливі NS-сервери та помилки конфіігурації, здійснюючи колосальний репутаційний ризик для компанії. </p><p>Тепер я чудово розумію, чому так. Мабуть це вже своєрідний "комплекс" або "синдром", присутній у великих компаніях - відкидати і заперечувати все, що стосується безпеки. </p><p>"Синдром Федорова", я би так це назвав!</p><p>Однак він може дуже дорого коштувати.</p><p>Так що, як сказав Катуреллі, цитую: "Не будьте схожими на Mastercard... Не відкидайте ризик і не дозволяйте своїй маркетинговій команді створювати витоки безпеки...".</p><p><a href=\"https://infosec.exchange/tags/cybersecurity\" class=\"mention hashtag\" rel=\"tag\">#<span>cybersecurity</span></a> <a href=\"https://infosec.exchange/tags/cybercrime\" class=\"mention hashtag\" rel=\"tag\">#<span>cybercrime</span></a> <a href=\"https://infosec.exchange/tags/mastercard\" class=\"mention hashtag\" rel=\"tag\">#<span>mastercard</span></a> <a href=\"https://infosec.exchange/tags/%D0%BA%D1%96%D0%B1%D0%B5%D1%80%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B0\" class=\"mention hashtag\" rel=\"tag\">#<span>кібербезпека</span></a> <a href=\"https://infosec.exchange/tags/stories\" class=\"mention hashtag\" rel=\"tag\">#<span>stories</span></a> <a href=\"https://infosec.exchange/tags/security\" class=\"mention hashtag\" rel=\"tag\">#<span>security</span></a> <a href=\"https://infosec.exchange/tags/infosec\" class=\"mention hashtag\" rel=\"tag\">#<span>infosec</span></a> <a href=\"https://infosec.exchange/tags/%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B0\" class=\"mention hashtag\" rel=\"tag\">#<span>безпека</span></a> <a href=\"https://infosec.exchange/tags/itsecurtiy\" class=\"mention hashtag\" rel=\"tag\">#<span>itsecurtiy</span></a> <a href=\"https://infosec.exchange/tags/dnssec\" class=\"mention hashtag\" rel=\"tag\">#<span>dnssec</span></a> <a href=\"https://infosec.exchange/tags/dns\" class=\"mention hashtag\" rel=\"tag\">#<span>dns</span></a></p>",
"contentMap": {
"uk": "<p>5 РОКІВ DNS-ЗОНА MASTERCARD МІСТИЛА ДРУКАРСЬКУ ПОМИЛКУ</p><p>У червні 2020 року дослідник Філіп Катуреллі (CEO of Seralys) помітив, що в DNS-зоні всесвітньовідомого платіжного сервісу MasterCard один із неймсерверів (Akamai) введено з помилкою: замість "akam.net" вказано "akam.ne".</p><p>Хибна конфігурація дивним чином зберігалася аж 5 років, поки про неї публічно не заговорили в LinkedIn (<a href=\"https://www.linkedin.com/feed/update/urn:li:activity:7285038365236682753/\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://www.</span><span class=\"ellipsis\">linkedin.com/feed/update/urn:l</span><span class=\"invisible\">i:activity:7285038365236682753/</span></a>). Подібна недбалість дозволяла будь-кому відкрити домен akam.ne і перенаправляти трафік MasterCard до себе...</p><p>Найбільше здивувала (і обурила) громадськість реакція самої компанії, яка заперечувала, що помилка в DNS якось може критично вплинути на їх безпеку. Мовляв, нічого страшного, все впорядку.</p><p>Пізніше Катуреллі розповів, що зловмисникам достатньо було купити за 300 доларів домен в нігерійського реєстратора (доменна зона верхнього рівня .ne) і зачекати 3 місяці на обробку заявки. Після цього вони могли спокійно відкривати електронну пошту на домені akam.ne і отримувати корпоративні email-листи, відправлені на сервери MasterCard! Це найменше, що можна було зробити у даній ситуації.</p><p>Але дослідник - красунчик. Все-таки не став зловживати, а в цілях безпеки сам зареєстрував домен і повідомив в MasterCard. Хоча ті й надалі продовжували заперечувати, навіть не відшкодувавши йому тих 300 доларів. Просто мовчки усунули друкарську помилку і все... А його звіт на BugCrowd чомусь заблокували.</p><p>Що цікаво, як розповідає дослідник Браян Кребс (<a href=\"https://krebsonsecurity.com\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"\">krebsonsecurity.com</span><span class=\"invisible\"></span></a>), і тут не обійшлося без російського сліду. У 2016 році хтось на рф зареєстрував цей домен і кілька років переспрямовував його на IP-адресу в Німеччині (185.53.177.31), імовірно з метою проведення якихось маніпуляцій і махінацій...</p><p>Ось так! Більш кращого прикладу про важливість безпеки DNS я ще не зустрічав. Одна помилка може відкрити двері для цілого ряду атак: "Людина посередині" (Man-in-the-Middle), фішингу, спуфінгу, перехоплення даних та багато-багато іншого.</p><p>Одразу пригадалася одна історія з мого професійного досвіду. Якось звернулася до мене за послугами одна серйозна конторка. Я довго і нудно намагався їх переконувати, що головна проблема криється саме в DNS - треба негайно перевірити усі записи, зокрема NS-сервери, і бажано перевести домен на обслуговування до іншого реєстратора та додатково підключити DNS Cloudflare, аби унеможливити подальші маніпуляуції. На що мені вперто відповідали: "Ні. У нас там нема проблем. NS-сервери не можуть бути загрозою. У нас все впорядку. Доступ до DNS не надаємо. Можемо надати тільки скріншот". Таким чином вони довго і нудно шукали проблему в SSL-сертифікатах, вихідному коді, хостингу, CMS, але тільки не в DNS.... А зловмисники тим часом по повній в тиху експлуатували вразливі NS-сервери та помилки конфіігурації, здійснюючи колосальний репутаційний ризик для компанії. </p><p>Тепер я чудово розумію, чому так. Мабуть це вже своєрідний "комплекс" або "синдром", присутній у великих компаніях - відкидати і заперечувати все, що стосується безпеки. </p><p>"Синдром Федорова", я би так це назвав!</p><p>Однак він може дуже дорого коштувати.</p><p>Так що, як сказав Катуреллі, цитую: "Не будьте схожими на Mastercard... Не відкидайте ризик і не дозволяйте своїй маркетинговій команді створювати витоки безпеки...".</p><p><a href=\"https://infosec.exchange/tags/cybersecurity\" class=\"mention hashtag\" rel=\"tag\">#<span>cybersecurity</span></a> <a href=\"https://infosec.exchange/tags/cybercrime\" class=\"mention hashtag\" rel=\"tag\">#<span>cybercrime</span></a> <a href=\"https://infosec.exchange/tags/mastercard\" class=\"mention hashtag\" rel=\"tag\">#<span>mastercard</span></a> <a href=\"https://infosec.exchange/tags/%D0%BA%D1%96%D0%B1%D0%B5%D1%80%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B0\" class=\"mention hashtag\" rel=\"tag\">#<span>кібербезпека</span></a> <a href=\"https://infosec.exchange/tags/stories\" class=\"mention hashtag\" rel=\"tag\">#<span>stories</span></a> <a href=\"https://infosec.exchange/tags/security\" class=\"mention hashtag\" rel=\"tag\">#<span>security</span></a> <a href=\"https://infosec.exchange/tags/infosec\" class=\"mention hashtag\" rel=\"tag\">#<span>infosec</span></a> <a href=\"https://infosec.exchange/tags/%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B0\" class=\"mention hashtag\" rel=\"tag\">#<span>безпека</span></a> <a href=\"https://infosec.exchange/tags/itsecurtiy\" class=\"mention hashtag\" rel=\"tag\">#<span>itsecurtiy</span></a> <a href=\"https://infosec.exchange/tags/dnssec\" class=\"mention hashtag\" rel=\"tag\">#<span>dnssec</span></a> <a href=\"https://infosec.exchange/tags/dns\" class=\"mention hashtag\" rel=\"tag\">#<span>dns</span></a></p>"
},
"updated": "2025-01-24T09:11:07Z",
"attachment": [
{
"type": "Document",
"mediaType": "image/png",
"url": "https://media.infosec.exchange/infosec.exchange/media_attachments/files/113/882/421/180/346/613/original/2815037ffe2c3b0d.png",
"name": "MasterCard DNS mistake",
"blurhash": "U02iCH~qt7%N%MofV[RjMxM{V[M{x]WBj[xu",
"focalPoint": [
0,
0
],
"width": 1000,
"height": 716
}
],
"tag": [
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/cybersecurity",
"name": "#cybersecurity"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/cybercrime",
"name": "#cybercrime"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/mastercard",
"name": "#mastercard"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/%D0%BA%D1%96%D0%B1%D0%B5%D1%80%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B0",
"name": "#кібербезпека"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/stories",
"name": "#stories"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/security",
"name": "#security"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/infosec",
"name": "#infosec"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B0",
"name": "#безпека"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/itsecurtiy",
"name": "#itsecurtiy"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/dnssec",
"name": "#dnssec"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/dns",
"name": "#dns"
}
],
"replies": {
"id": "https://infosec.exchange/users/krlaboratories/statuses/113882461690332095/replies",
"type": "Collection",
"first": {
"type": "CollectionPage",
"next": "https://infosec.exchange/users/krlaboratories/statuses/113882461690332095/replies?only_other_accounts=true&page=true",
"partOf": "https://infosec.exchange/users/krlaboratories/statuses/113882461690332095/replies",
"items": []
}
},
"likes": {
"id": "https://infosec.exchange/users/krlaboratories/statuses/113882461690332095/likes",
"type": "Collection",
"totalItems": 3
},
"shares": {
"id": "https://infosec.exchange/users/krlaboratories/statuses/113882461690332095/shares",
"type": "Collection",
"totalItems": 2
}
}