{"id":78514,"date":"2020-04-20T01:42:32","date_gmt":"2020-04-19T23:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos"},"modified":"2020-04-20T01:42:32","modified_gmt":"2020-04-19T23:42:32","slug":"kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","title":{"rendered":"How to Protect Processes and Kernel Extensions in macOS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hello, Habr! Today, I would like to discuss how to protect processes from attacks by malicious actors in macOS. This is particularly useful for antivirus software or backup systems, especially considering that there are several ways in macOS to \"kill\" a process. Read on for more information on this topic and the methods of protection.<\/p>\n

\"How<\/a><\/noindex>
\n<\/a><\/noindex><\/p>\n

The Classic Way to \"Kill\" a Process<\/h3>\n

\nA well-known way to \"kill\" a process is to send a SIGKILL signal to the process. In bash, you can use the standard commands \"kill -SIGKILL PID\" or \"pkill -9 NAME\" to terminate it. The command \"kill\" has been known since the UNIX days and is available not just in macOS but also in other UNIX-like systems.<\/p>\n

Similar to UNIX-like systems, macOS allows the interception of any signals to a process except for two\u2014SIGKILL and SIGSTOP. This article will primarily focus on the SIGKILL signal, which is responsible for terminating processes.<\/p>\n

Specifics of macOS
\n<\/h3>\n

\nIn macOS, the system call kill in the XNU kernel invokes the function psignal(SIGKILL, ...). Let's explore what other user-space actions can trigger the psignal function. We will filter out calls to psignal made by internal kernel mechanisms (although these may not be trivial, we will save them for another article \ud83d\ude42 \u2014 signature checks, memory errors, exit\/termination handling, file protection violations, etc. <\/p>\n

Let's start the overview with the function and the corresponding system call terminate_with_payload<\/a><\/noindex>. It is evident that apart from the classic kill call, there exists an alternative approach that is specific to the macOS operating system and is not found in BSD. The principles of operation for both system calls are also similar. They represent direct calls to the psignal kernel function. Additionally, it is important to note that before killing the process, a \"cansignal\" check is performed\u2014this check determines whether a process can send a signal to another process, preventing any application from killing system processes, for instance.<\/p>\n

static int\nterminate_with_payload_internal(struct proc *cur_proc, int target_pid, uint32_t reason_namespace,\n\t\t\t\tuint64_t reason_code, user_addr_t payload, uint32_t payload_size,\n\t\t\t\tuser_addr_t reason_string, uint64_t reason_flags)\n{\n...\n\ttarget_proc = proc_find(target_pid);\n...\n\tif (!cansignal(cur_proc, cur_cred, target_proc, SIGKILL)) {\n\t\tproc_rele(target_proc);\n\t\treturn EPERM;\n\t}\n...\n\tif (target_pid == cur_proc->p_pid) {\n\t\t\n\t\t * psignal_thread_with_reason() will pend a SIGKILL on the specified thread or\n\t\t * return if the thread and\/or task are already terminating. Either way, the\n\t\t * current thread won't return to userspace.\n\t\t \n\t\tpsignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);\n\t} else {\n\t\tpsignal_with_reason(target_proc, SIGKILL, signal_reason);\n\t}\n...\n}\n<\/code><\/pre>\n
<\/p>\n
launchd<\/h3>\n
\nThe standard way to create daemons at system startup and manage their lifespan is launchd. Note that the source code provided is for an older version of launchctl prior to macOS 10.10, and the code examples are for illustration. Modern launchctl sends signals to launchd via XPC, with the logic of launchctl being moved into it.<\/p>\n
Let's look at how applications are actually stopped. Before sending the SIGTERM signal, the application is attempted to be terminated using the system call 'proc_terminate'.<\/p>\n
...\n\terror = proc_terminate(j->p, &sig);\n\tif (error) {\n\t\tjob_log(j, LOG_ERR | LOG_CONSOLE, \"Could not terminate job: %d: %s\", error, strerror(error));\n\t\tjob_log(j, LOG_NOTICE | LOG_CONSOLE, \"Using fallback option to terminate job...\");\n\t\terror = kill2(j->p, SIGTERM);\n\t\tif (error) {\n\t\t\tjob_log(j, LOG_ERR, \"Could not signal job: %d: %s\", error, strerror(error));\n\t\t} \n...\n<\/code><\/pre>\n
\nUnder the hood, proc_terminate, despite its name, can send not only psignal with SIGTERM but also SIGKILL.<\/p>\n
Indirect killing \u2014 resource limitations<\/h3>\n
\nA more interesting case can be seen in another system call process_policy<\/a><\/noindex>. The standard use of this system call is to limit application resources, for instance, for an indexer, there is a limit on CPU time and memory quota, so that the system is not significantly slowed down by file caching actions. If the application reaches the resource limit, as can be seen from the proc_apply_resource_actions function, the process is sent the SIGKILL signal.<\/p>\n
Despite the fact that this system call can potentially kill a process, the system did not adequately check the rights of the process making the system call. In fact, the check existed<\/a><\/noindex>, but it is sufficient to use an alternative flag PROC_POLICY_ACTION_SET to bypass this condition.<\/p>\n
From here, if you 'restrict' the CPU usage quota for an application (for example, allowing it to run only 1 ns), you can effectively kill any process in the system. Thus, a malicious user could terminate any process on the system, including the antivirus process. Interestingly, there\u2019s an effect that occurs when killing the process with pid 1 (launchctl) \u2014 a kernel panic when trying to handle the SIGKILL signal \ud83d\ude42<\/p>\n
\"How
\n<\/p>\n
How to solve the problem?<\/h3>\n
\nThe most straightforward way to prevent a process from being killed is to replace the function pointer in the system call table. Unfortunately, this approach is non-trivial for several reasons.<\/p>\n
Firstly, the symbol responsible for the position of sysent in memory is not only a private symbol of the XNU kernel but also cannot be found in the kernel symbols. Heuristic search methods will have to be used, such as dynamically disassembling the function and searching for the pointer within it.<\/p>\n
Secondly, the structure of the records in the table depends on the flags with which the kernel was compiled. If the flag CONFIG_REQUIRES_U32_MUNGING is declared, the size of the structure will change \u2014 an additional field will be added. sy_arg_munge32<\/a><\/noindex>. An additional check is necessary to see which flag was used to compile the kernel; one option is to compare function pointers with known ones.<\/p>\n
struct sysent {         \/* system call table *\/\n        sy_call_t       *sy_call;       \/* implementing function *\/\n#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))\n        sy_munge_t      *sy_arg_munge32; \/* system call arguments munger for 32-bit process *\/\n#endif\n        int32_t         sy_return_type; \/* system call return types *\/\n        int16_t         sy_narg;        \/* number of args *\/\n        uint16_t        sy_arg_bytes;   \/* Total size of arguments in bytes for\n                                         * 32-bit system calls\n                                         *\/\n};\n<\/code><\/pre>\n
\nFortunately, in modern versions of macOS, Apple provides a new API for process management. The Endpoint Security API allows clients to authorize many requests to other processes. For instance, it is possible to block any signals to processes, including the SIGKILL signal, using the aforementioned API.<\/p>\n
#include <bsm\/libbsm.h>\n#include <EndpointSecurity\/EndpointSecurity.h>\n#include <unistd.h>\n\nint main(int argc, const char * argv[]) {\n    es_client_t* cli = nullptr;\n    {\n        auto res = es_new_client(&cli, ^(es_client_t * client, const es_message_t * message) {\n            switch (message->event_type) {\n                case ES_EVENT_TYPE_AUTH_SIGNAL:\n                {\n                    auto& msg = message->event.signal;\n                    auto target = msg.target;\n                    auto& token = target->audit_token;\n                    auto pid = audit_token_to_pid(token);\n                    printf("signal '%d' sent to pid '%d'n", msg.sig, pid);\n                    es_respond_auth_result(client, message, pid == getpid() ? ES_AUTH_RESULT_DENY : ES_AUTH_RESULT_ALLOW, false);\n                }\n                    break;\n                default:\n                    break;\n            }\n        });\n    }\n\n    {\n        es_event_type_t evs[] = { ES_EVENT_TYPE_AUTH_SIGNAL };\n        es_subscribe(cli, evs, sizeof(evs) \/ sizeof(*evs));\n    }\n\n    printf("%dn", getpid());\n    sleep(60); \/\/ could be replaced with other waiting primitive\n\n    es_unsubscribe_all(cli);\n    es_delete_client(cli);\n\n    return 0;\n}\n<\/code><\/pre>\n
\nSimilarly, within the kernel, it is possible to register a MAC Policy that provides a method for protection against signals (policy proc_check_signal); however, the API is not officially supported.<\/p>\n
Kernel extension protection<\/h3>\n
\nIn addition to protecting processes in the system, it's essential to also protect the kernel extension itself (kext). macOS provides developers with a framework for easy development of device drivers through IOKit. Besides offering means to work with devices, IOKit provides methods for driver stacking using instances of C++ classes. A userspace application will be able to 'find' a registered class instance to establish a connection between the kernel and userspace.<\/p>\n
To detect the number of class instances in the system, there is a utility called ioclasscount.<\/p>\n
my_kext_ioservice = 1\nmy_kext_iouserclient = 1\n<\/code><\/pre>\n
\nAny kernel extension that wishes to register in the driver stack must declare a class inherited from IOService, for example, my_kext_ioservice in this case. The connection of user applications triggers the creation of a new class instance that inherits from IOUserClient, in this example my_kext_iouserclient.<\/p>\n
When attempting to unload a driver from the system (using the kextunload command), the virtual function 'bool terminate(IOOptionBits options)' is called. Simply returning false when calling the terminate function on an unload attempt is enough to prohibit kextunload.<\/p>\n
bool Kext::terminate(IOOptionBits options)\n{\n\n  if (!IsUnloadAllowed)\n  {\n    \/\/ Unload is not allowed, returning false\n    return false;\n  }\n\n  return super::terminate(options);\n}\n\n<\/code><\/pre>\n
\nThe IsUnloadAllowed flag can be set by IOUserClient during loading. When unloading is restricted, the kextunload command will return the following output:<\/p>\n
admin@admins-Mac drivermanager % sudo kextunload .\/test.kext\nPassword:\n(kernel) Can't remove kext my.kext.test; services failed to terminate - 0xe00002c7.\nFailed to unload my.kext.test - (iokit\/common) unsupported function.\n<\/code><\/pre>\n
\nSimilar protection needs to be implemented for IOUserClient. Class instances can be unloaded using the userspace function IOKitLib 'IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);'. You can return false when the 'terminate' command is called until the userspace application 'dies', meaning the function 'clientDied' is called.<\/p>\n
File protection<\/h3>\n
\nTo protect files, it is sufficient to use the Kauth API, which restricts access to files. Apple provides developers with notifications about various events in the scope, with KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA, and KAUTH_VNODE_DELETE_CHILD being crucial operations for us. Restricting access to files is simplest by path\u2014we use the \"vn_getpath\" API to obtain the file path and perform prefix comparison. It should be noted that for optimizing the renaming of folder paths with files, the system does not authorize access to each file, but only to the folder that has been renamed. It is necessary to compare the parent path and restrict KAUTH_VNODE_DELETE for it.<\/p>\n
\"How
\n
\nA drawback of this approach can be low performance with an increasing number of prefixes. To ensure that the comparison is not equal to O(prefix*length), where prefix is the number of prefixes and length is the string length, a deterministic finite automaton (DFA) constructed from the prefixes can be used. <\/p>\n
Let's consider the method for constructing a DFA for this set of prefixes. We initialize cursors at the beginning of each prefix. If all cursors point to the same character, we advance each cursor by one character and note that the length of the identical string increases by one. If there are two cursors with different characters beneath them, we divide the cursors into groups by the character they point to and repeat the algorithm for each group.<\/p>\n
In the first case (where all characters under the cursors are the same), we obtain a DFA state that has only one transition on the identical string. In the second case, we obtain a transition table of size 256 (the number of characters and the maximum number of groups) to the subsequent states obtained through the recursive function call.<\/p>\n
Consider an example. For the set of prefixes (\"\/foo\/bar\/tmp\/\", \"\/var\/db\/foo\/\", \"\/foo\/bar\/aba\/\", \"foo\/bar\/aac\/\") we can get the following DFA. The diagram only shows transitions leading to other states; other transitions will not be considered final.<\/p>\n
\"How
\n
\nWhen traversing the DFA states, there may be three cases.<\/p>\n
    \n
  1. The final state has been reached\u2014the path is protected, and we restrict the operations KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA, and KAUTH_VNODE_DELETE_CHILD.<\/li>\n
  2. The final state was not reached, but the path has 'ended' (the null terminator was reached) \u2014 the path is a parent, and it's necessary to restrict KAUTH_VNODE_DELETE. Note that if the vnode is a directory, you need to add a \u2018\/\u2019 at the end; otherwise, it may restrict the file '\/foor\/bar\/t', which is incorrect.<\/li>\n
  3. The final state was not reached, and the path is not ended. None of the prefixes match, so we do not impose restrictions.<\/li>\n<\/ol>\n
    <\/p>\n
    Conclusion<\/h3>\n
    \nThe goal of the developed security solutions is to enhance the security level of the user and their data. On one hand, this goal is achieved through the development of the Acronis software product, which closes the vulnerabilities where the operating system itself is 'weak.' On the other hand, we should not overlook strengthening those aspects of security that can be improved on the OS side, especially since closing such vulnerabilities increases our own resilience as a product. The vulnerability was reported by the Apple Product Security Team and was fixed in macOS 10.14.5 (https:\/\/support.apple.com\/en-gb\/HT210119).<\/p>\n
    \"How
    \n
    \nAll of this can only be done if your utility has been officially installed in the kernel. This means there are no loopholes for external and undesirable software. However, as you can see, even for protecting legitimate programs like antivirus and backup systems, effort is required. But now, new Acronis products for macOS will have additional protection against unloading from the system.
    \n
    Source: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u043d\u0435 \u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0431\u044b \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u043e\u0442 \u043f\u043e\u0441\u044f\u0433\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u043e\u0432 \u0432 macOS. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u044d\u0442\u043e \u043f\u043e\u043b\u0435\u0437\u043d\u043e \u0434\u043b\u044f \u0430\u043d\u0442\u0438\u0432\u0438\u0440\u0443\u0441\u0430 \u0438\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0441\u0432\u0435\u0442\u0435 \u0442\u043e\u0433\u043e \u0447\u0442\u043e \u043f\u043e\u0434 macOS \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u0441\u0440\u0430\u0437\u0443 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0441\u043f\u043e\u0441\u043e\u0431\u043e\u0432 \u201c\u0443\u0431\u0438\u0442\u044c\u201d \u043f\u0440\u043e\u0446\u0435\u0441\u0441. \u041e\u0431 \u044d\u0442\u043e\u043c \u0438 \u043e \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0437\u0430\u0449\u0438\u0442\u044b \u0447\u0438\u0442\u0430\u0439\u0442\u0435 \u043f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c. \u041a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0441\u043f\u043e\u0441\u043e\u0431 \u201c\u0443\u0431\u0438\u0442\u044c\u201d \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0412\u0441\u0435\u043c \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":78515,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-78514","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47How to Protect Processes and Kernel Extensions in macOS | ProHoster","description":"Hello, Habr! Today I would like to talk about how to protect processes from attacks by hackers in macOS.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0437\u0430\u0449\u0438\u0449\u0430\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u0438 \u0440\u0430\u0441\u0448\u0438\u0440\u0435\u043d\u0438\u044f \u044f\u0434\u0440\u0430 \u0432 macOS | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u043d\u0435 \u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0431\u044b \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u043e\u0442 \u043f\u043e\u0441\u044f\u0433\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u043e\u0432 \u0432 macOS.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-19T23:42:32+00:00","article:modified_time":"2020-04-19T23:42:32+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"78514","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:56:36","updated":"2022-09-28 22:19:40","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/78514","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=78514"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/78514\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/78515"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=78514"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=78514"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=78514"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}