{"id":9591,"date":"2015-08-18T09:45:18","date_gmt":"2015-08-18T13:45:18","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=9591"},"modified":"2017-09-24T08:14:45","modified_gmt":"2017-09-24T12:14:45","slug":"security-week-digest-33","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/security-week-digest-33\/9591\/","title":{"rendered":"Security Week 33: Doors without locks, invulnerable Microsoft, disassembler and pain"},"content":{"rendered":"<p>Welcome to this week\u2019s edition of Security Week. In the <a href=\"https:\/\/www.kaspersky.com\/blog\/security-week-digest-32\/\" target=\"_blank\" rel=\"noopener nofollow\">maiden installment<\/a>, we learned of self-unlocking cars, the Android\u2019s chronic Stage Fright and that we won\u2019t be watched in the Web any longer (actually we still will be).<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/92\/2015\/08\/06024342\/security-week-33-FB.jpg\"><img decoding=\"async\" class=\"alignright size-full wp-image-9595\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/92\/2015\/08\/06024342\/security-week-33-FB.jpg\" alt=\"Security Week: Doors without locks, invulnerable Microsoft, disassembler and pain\" width=\"1600\" height=\"1600\"><\/a><\/p>\n<p>In this post there are two seemingly unrelated pieces of news which nevertheless have one thing in common: vulnerability sometimes arises from reluctance to take available security measures. And the third story is not about security at all, but rather concerns particular cases of relations within the industry. All the three are funny enough to be different within from what they appear.<\/p>\n<p>Let me remind the rules of Security Week: the editors of <a href=\"https:\/\/threatpost.com\/\" target=\"_blank\" rel=\"noopener nofollow\">Threatpost<\/a> pick three most significant news stories each week, to which I add an expanded and ruthless commentary. You may find all episodes of the series <a href=\"https:\/\/www.kaspersky.com\/blog\/tag\/security-week\/\" target=\"_blank\" rel=\"noopener nofollow\">here<\/a>.<\/p>\n<h3>Hacking hotels\u2019 doors<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/blekey-device-breaks-rfid-physical-access-controls\/\" target=\"_blank\" rel=\"noopener nofollow\">The Threatpost story<\/a>.<\/p>\n<p>They say that there is dichotomy of the Sciences and the Arts, and the experts of these two disciplines can hardly understand each other. There is a strong belief that a humanist intellectual just cannot turn into a scientist or an engineer.<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/92\/2015\/08\/06024337\/security-week-33-wiegand.jpg\"><img decoding=\"async\" class=\"alignright wp-image-9598 size-medium\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/92\/2015\/08\/06024337\/security-week-33-wiegand-220x300.jpg\" alt=\"Security Week: Doors without locks, invulnerable Microsoft, disassembler and pain\" width=\"220\" height=\"300\"><\/a><\/p>\n<p>This stereotype was once defied by trained musician John Wiegand. In the 1930\u2019s he had been <a href=\"http:\/\/machinedesign.com\/engineering-essentials\/brushing-wiegand-man-effect-and-wire-changed-engineering\" target=\"_blank\" rel=\"noopener nofollow\">a piano player and a children\u2019s choir conductor<\/a>, until he got interested in designing audio amplifiers. In the 1940\u2019s he worked on that time\u2019s novelty \u2013 magnetic tape recording. And in 1974 (at the age of 62 years) he made his major discovery.<\/p>\n<p>This Wiegand wire, as it\u2019s called, is a magnetic cobalt iron and vanadium alloy wire treated so that it forms a hard outer shell around a soft inner core. External fields easily magnetize the outer shell, which also resists demagnetization, even when external fields are removed \u2014 a characteristic called higher coercivity. The soft wire filling behaves differently: it\u2019s not magnetized until after the shell gets its fill of magnetization.<\/p>\n<p>At the moment that the wire\u2019s shell becomes fully magnetized, and the core is finally allowed to collect its own portion of magnetization, both core and shell switch polarity. The switch generates significant voltage that can be harnessed for all kinds of sensing and motion applications, making the effect usable, for instance, in hotel keys.<\/p>\n<p>Unlike in modern cards, ones and zeroes are not recorded in the chip, but in the direct sequence of specially laid wiring. It is impossible to reprogram such a key, and the general scheme of it is rather not like modern proximity public transit fare cards or banking payment cards, but similar to magnetic stripe cards \u2013 only more reliable ones.<\/p>\n<p>Shall we scrap proximity cards then? <em>Not yet<\/em>. Wiegand gave his name not only to the discovered effect, but also to the data exchange <a href=\"https:\/\/en.wikipedia.org\/wiki\/Wiegand_interface\" target=\"_blank\" rel=\"noopener nofollow\">protocol, which is quite old<\/a>. Everything about that protocol is pretty bad. Firstly, it has never been properly standardized, and there are many different implementations of it.<\/p>\n<blockquote class=\"twitter-pullquote\"><p>#Security Week 33: Doors without locks, invulnerable #Microsoft, #disassembler and pain<\/p><a href=\"https:\/\/twitter.com\/share?url=https%3A%2F%2Fkas.pr%2FD98D&amp;text=%23Security+Week+33%3A+Doors+without+locks%2C+invulnerable+%23Microsoft%2C+%23disassembler+and+pain\" class=\"btn btn-twhite\" data-lang=\"en\" data-count=\"0\" target=\"_blank\" rel=\"noopener nofollow\">Tweet<\/a><\/blockquote>\n<p>Secondly, the original card\u2019s ID can amount 16 bits yielding very few possible combinations. Thirdly, the design of those proximity cards with wiring, which were invented before we learned how to put a computer in a credit card, restricts the key length to just 37 bits with the reliability of reading dramatically falling in longer keys.<\/p>\n<p>Recently, at the Black Hat conference researchers <a href=\"https:\/\/twitter.com\/ericevenchick\" target=\"_blank\" rel=\"noopener nofollow\">Eric Evenchick<\/a> and <a href=\"https:\/\/twitter.com\/markbaseggio\" target=\"_blank\" rel=\"noopener nofollow\">Mark Baseggio<\/a> showed their device for intercepting (unencrypted) key sequences during authorization. The most interesting detail here is that cards have nothing to do with it at all since the information is stolen while transmitting data from a card reader to a door controller where that Wiegand protocol is historically used.<\/p>\n<p>The name of the device is BLEkey \u2013 it is a tiny piece of hardware that needs to be embedded in a card reader, for example, of a hotel\u2019s door. The researchers showed that the whole operation takes several seconds. Then everything is simple. We read the key, wait for the real owner to leave and open the door. Or we don\u2019t wait. Or we never open. Without going into technical details, the dialogue between the door and the reader\/wireless becomes like this:<\/p>\n<p><em>\u201cWho\u2019s there?\u201d<br>\n\u201cIt\u2019s me.\u201d<br>\n\u201cHere you are. Get in!\u201d<\/em><\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Final talk run through! <a href=\"http:\/\/t.co\/TQB472izkO\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/TQB472izkO<\/a><\/p>\n<p>\u2014 Eric Evenchick (@ericevenchick@mastodon.social) (@ericevenchick) <a href=\"https:\/\/twitter.com\/ericevenchick\/status\/629324182459940864?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 6, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Everything seems to be quite clear, but there is a nuance. Well, as usual, not all access control systems are vulnerable to this attack. And even those that are can be protected without being totally replaced. According to the researchers, readers have protection means from such hacks, but those features are usually, ahem, disabled.<\/p>\n<p>Some even support the <a href=\"http:\/\/www.siaonline.org\/Pages\/Standards\/OSDP.aspx\" target=\"_blank\" rel=\"noopener nofollow\">Open Supervised Device Protocol<\/a>, which allows you to encrypt the transmitted key sequence. These \u201cfeatures\u201d are not used \u2013 I\u2019ll never stop repeating it \u2013 because neglecting security measures is cheap and easy.<\/p>\n<p>Here is <a href=\"https:\/\/www.defcon.org\/images\/defcon-17\/dc-17-presentations\/defcon-17-mike_davis_who_invented_the_proximity_card.pdf\" target=\"_blank\" rel=\"noopener nofollow\">another interesting 2009 study on the subject<\/a>, with technical details. Apparently, the cards\u2019 (not readers\u2019) vulnerability was pointed out in 1992, but then it was suggested that the card should be either disassembled or X-rayed. For this purpose it had to be, for example, taken away from the owner. And now the solution is a tiny device of the size of a coin. That\u2019s what I call progress!<\/p>\n<h3>Microsoft Immunity. The corporate intricacies of Windows Server Update Services<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/manipulating-wsus-to-own-enterprises\/\" target=\"_blank\" rel=\"noopener nofollow\">The Threatpost story<\/a>. The original researchers\u2019 <a href=\"https:\/\/www.blackhat.com\/docs\/us-15\/materials\/us-15-Stone-WSUSpect-Compromising-Windows-Enterprise-Via-Windows-Update-wp.pdf\" target=\"_blank\" rel=\"noopener nofollow\">whitepaper<\/a>.<\/p>\n<p>Windows Server Update Services allow large companies to centralize installing updates on computers by means an internal server instead of an outside source. And this is a very reliable and sufficiently secure system. For starters all updates must be signed by Microsoft. Secondly, the communication between the company\u2019s update server and the vendor\u2019s server is encrypted by SSL.<\/p>\n<p>And this is a pretty simple system. The company\u2019s server receives a list of updates as an XML file, where it is actually indicated what, where and how to download. It turned out that this initial interaction goes in plain text. No, it\u2019s a bit wrong to put it that way. It <strong>must<\/strong> be encrypted and when deploying WSUS an administrator is strongly recommended to enable encryption. But it\u2019s disabled by default.<\/p>\n<p>It\u2019s not something awful because replacing \u201cinstructions\u201d is not easy, but if an attacker already has the ability of intercepting traffic (i.e. the man-in-the-middle scheme has already taken place), it is possible. Researchers Paul Stone and Alex Chapman found that by replacing the instructions you could then execute an arbitrary code with high privileges on the updated system. Microsoft still checks digital certificates, but it accepts any company\u2019s certificate. For example, you can smuggle PsExec utility from SysInternals kit, and with its help you may launch anything.<\/p>\n<p>Why does it happen? The point is that enabling SSL while deploying WSUS cannot be automated since you need to generate a certificate. As the researchers noted in this case Microsoft can do nothing but urge enabling SSL. Therefore it appears as though there is vulnerability and there is none at the same time. And nothing can be helped. And no one is to blame but the administrator.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">One of our weaker advertising campaigns for Windows: <a href=\"http:\/\/t.co\/Fon5IvBFnP\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/Fon5IvBFnP<\/a><\/p>\n<p>\u2014 Mark Russinovich (@markrussinovich) <a href=\"https:\/\/twitter.com\/markrussinovich\/status\/631505582139117569?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 12, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Kaspersky Lab <a href=\"https:\/\/securelist.com\/blog\/incidents\/33002\/flame-replication-via-windows-update-mitm-proxy-server-18\/\" target=\"_blank\" rel=\"noopener\">discovered spyware Flame which also used Windows Update for infection<\/a> although in a different way: fake proxy intercepted requests to the Microsoft\u2019s server, and the delivered response files were a bit different, though some of them indeed were signed by the vendor.<\/p>\n<h3>Reverse-engineering and pain<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/oracle-cso-you-must-not-reverse-engineer-our-code\" target=\"_blank\" rel=\"noopener nofollow\">The Threatpost story<\/a>. The original post by Oracle CSO (Google <a href=\"https:\/\/webcache.googleusercontent.com\/search?q=cache:ntXM0RlghUUJ:https:\/\/blogs.oracle.com\/maryanndavidson\/entry\/no_you_really_can_t+&amp;cd=1&amp;hl=en&amp;ct=clnk&amp;gl=us\" target=\"_blank\" rel=\"noopener nofollow\">cache<\/a>, and <a href=\"http:\/\/seclists.org\/isn\/2015\/Aug\/4\" target=\"_blank\" rel=\"noopener nofollow\">another copy<\/a> \u2014 Internets never forget).<\/p>\n<p>The two presentations cited above from Black Hat correlated because the authors of these studies \u2013 the security experts \u2013 discovered flaws of some tech or product that was developed by someone else. They published their findings and in the case of BLEKey they also presented the entire code and hardware for free access. This, in general, is the standard way of IT security interaction with the outside world, but not everyone likes this situation.<\/p>\n<p>I\u2019d hate assessing, so it would be enough to say that it\u2019s a very delicate subject. Is it OK to analyze other people\u2019s code? On what terms is it right? How should I disclose vulnerability information lest to do harm? May I get paid for the found flaws? Legislative restrictions, criminal code, and unwritten laws of the industry \u2013 they all affect this.<\/p>\n<p>A recent blog post of Oracle\u2019s Chief Security Officer Mary Ann Davidson produced the effect of an elephant in a china shop. It was entitled \u201cNo, You Really Can\u2019t\u201d and was almost entirely dedicated to the company\u2019s customers (not to the industry at large), who sent back information about the vulnerabilities they found in vendor\u2019s products.<\/p>\n<p>Many of the paragraphs of the Aug 10, 2015 post on Oracle\u2019s blog are worth quoting, but there\u2019s one main thing: if a customer could learn about the vulnerability by no other means than reverse engineering, then the customer violated the license agreement, and it was wrong.<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/92\/2015\/08\/06024338\/security-week-33-sobchak.png\"><img decoding=\"async\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/92\/2015\/08\/06024338\/security-week-33-sobchak.png\" alt=\"Security Week: Doors without locks, invulnerable Microsoft, disassembler and pain\" width=\"600\" height=\"700\" class=\"alignright size-full wp-image-9597\"><\/a><\/p>\n<p>Citation:<\/p>\n<p><em>A customer can\u2019t analyze the code to see whether there is a control that prevents the attack the scanning tool is screaming about (which is most likely a false positive). A customer can\u2019t produce a patch for the problem \u2014 only the vendor can do that. A customer is almost certainly violating the license agreement by using a tool that does static analysis (which operates against source code).<\/em><\/p>\n<p>The public reaction was like this:<\/p>\n<p>https:\/\/twitter.com\/nicboul\/status\/631183093580341248<\/p>\n<p>Or like this:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Adobe, Microsoft Push Patches, Oracle Drops Drama <a href=\"http:\/\/t.co\/XN4Tpb9RXw\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/XN4Tpb9RXw<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/oraclefanfic?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#oraclefanfic<\/a><\/p>\n<p>\u2014 briankrebs (@briankrebs) <a href=\"https:\/\/twitter.com\/briankrebs\/status\/631257607530020864?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 12, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Or even like this:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Don't look for vulns. Fuck bug bounties. We won't even credit you. <a href=\"https:\/\/t.co\/VgCrjGYx1j\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/VgCrjGYx1j<\/a> An <a href=\"https:\/\/twitter.com\/Oracle?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@oracle<\/a> love letter to the security community.<\/p>\n<p>\u2014 Morgan Marquis-Boire (@headhntr) <a href=\"https:\/\/twitter.com\/headhntr\/status\/631081198534664192?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 11, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>In a nutshell, the post lasted no more than a day and was removed because of \u201cinconsistencies with the [official] views on the interaction with customers\u201d (but the Web remembers). Let\u2019s recall that Oracle develops Java, and only the laziest don\u2019t exploit Java\u2019s vulnerabilities. Three years ago <a href=\"https:\/\/securelist.com\/analysis\/publications\/57888\/kaspersky-lab-report-java-under-attack\/\" target=\"_blank\" rel=\"noopener\">we counted vulnerabilities found in Java for 12 months and found 160<\/a>!<\/p>\n<p>In an ideal world, software vendors would catch and fix all vulnerabilities in their software, but alas, we live in the real world. In this world, this principle does not exist and sometimes the people responsible for running the show follow the principle \u201cbees against honey?\u201d<\/p>\n<p><i>But let us also hear the other side.<\/i><\/p>\n<p>Last week the founder of the Black Hat, Jeff Moss, <a href=\"https:\/\/threatpost.com\/software-liability-is-inevitable\/\" target=\"_blank\" rel=\"noopener nofollow\">spoke on software vendors being responsible for the flaws in their code<\/a>. He said it\u2019s time to rid EULA of all those lines about the company having no liability to its customers. The declaration is interesting, but no less pretentious than the appeal \u201cLet\u2019s ban disassembler.\u201d So far the only thing is clear enough: if users (corporate and individual), vendors and researchers can understand each other at all, it won\u2019t be done by flashy statements and twitter jests.<\/p>\n<h3>What else happened?<\/h3>\n<p>Another <a href=\"https:\/\/threatpost.com\/researchers-unveil-square-reader-mobile-pos-hacks\/\" target=\"_blank\" rel=\"noopener nofollow\">Black Hat presentation was about hacking Square Reader<\/a> \u2014 the device that connects to a smartphone to pay to the sushi delivery man. It requires soldering.<\/p>\n<p>One more <a href=\"https:\/\/threatpost.com\/lenovo-hit-with-criticism-over-second-rootkit-like-utility\/114261\" target=\"_blank\" rel=\"noopener nofollow\">vendor\u2019s rootkit found in Lenovo laptops<\/a> (not all of them but some). <a href=\"https:\/\/threatpost.com\/lenovo-superfish-certificate-password-cracked\/111165\" target=\"_blank\" rel=\"noopener nofollow\">The previous story<\/a>.<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/92\/2015\/08\/06024345\/infosec-digest-32-book1.jpg\"><img decoding=\"async\" class=\"alignright wp-image-9594 size-medium\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/92\/2015\/08\/06024345\/infosec-digest-32-book1-234x300.jpg\" alt=\"Security Week: Doors without locks, invulnerable Microsoft, disassembler and pain\" width=\"234\" height=\"300\"><\/a><\/p>\n<h3>Oldies<\/h3>\n<p>The \u201cSmall\u201d malware family<\/p>\n<p>Standard resident viruses are added at the end of .com files (except for Small-114, -118, -122, which are written at the beginning) when loading files into memory. Most of the family viruses use commands POPA and PUSHA of 80\u00d786 processors. Small-132, -149 infect certain files incorrectly. They belong to different authors. Apparently, the origin of the Small family may be seen as a competition for the shortest memory resident virus for MS-DOS. It remains only to decide on the size of the prize pool.<\/p>\n<p><em>The quote from the book \u201cComputer viruses in MS-DOS\u201d by Eugene Kaspersky, 1992, page 45.<\/em><\/p>\n<p><em>Disclaimer: This column reflects only the personal opinion of the author. It may coincide with Kaspersky Lab position, or it may not. Depends on luck.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>In this post there are two seemingly unrelated pieces of news which nevertheless have one thing in common: not that somewhere someone is vulnerable, but that vulnerability sometimes arises from reluctance to take available security measures.<\/p>\n","protected":false},"author":53,"featured_media":9596,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[5],"tags":[770,1205,527,38,574,1204,1206,97,1203,633,121],"class_list":{"0":"post-9591","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-news","8":"tag-black-hat","9":"tag-doors","10":"tag-hacks","11":"tag-microsoft","12":"tag-news-2","13":"tag-oracle","14":"tag-reverse-engineering","15":"tag-security-2","16":"tag-security-week","17":"tag-threatpost","18":"tag-updates"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/security-week-digest-33\/9591\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/security-week-digest-33\/5834\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/security-week-digest-33\/6121\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/security-week-digest-33\/5976\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/security-week-digest-33\/6659\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/security-week-digest-33\/6495\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/security-week-digest-33\/8592\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/security-week-digest-33\/4797\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/security-week-digest-33\/5975\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/security-week-digest-33\/8636\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/security-week-digest-33\/8592\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/security-week-digest-33\/9591\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/security-week-digest-33\/9591\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/black-hat\/","name":"black hat"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/9591","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=9591"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/9591\/revisions"}],"predecessor-version":[{"id":19313,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/9591\/revisions\/19313"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/9596"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=9591"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=9591"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=9591"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}