Pull to refresh
-8
@willydread⁠-⁠only

User

Send message
Спасибо, читал.
Почитайте бюллетень, в котором указано, что
An unprivileged local attacker could provision manageability features gaining unprivileged network or local system privileges on Intel manageability SKUs: Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), and Intel® Small Business Technology (SBT).

Исходя из терминологи, «provisioned system» — система с включенным AMT, «unprovisioned system» — с выключенным.

Если он выключен — то как он подхватит адрес по DHCP?

И по вашей же логике — я должен его всегда видеть в DHCP-клиентах на роутере. Но я этого не вижу.

Или для него нужны какие-то специфическиt опции в DHCP?

Все что вы описываете — это удаленная атака, так как она проводиться через сеть. Чем отличается локальный DHCP от DHCP в сети?
Вот что я нашел в документации HP.
http://h10032.www1.hp.com/ctg/Manual/c03975296 или http://h10032.www1.hp.com/ctg/Manual/c02958196.pdf
From the Intel AMT Configuration menu (shown in Figure 5), select Manageability Feature Selection.
This option allows Intel AMT to be enabled (recommended) or disabled. By default, HP systems are set to enable Intel
AMT.
Note that disabling Manageability Feature Selection also disables all remote management capabilities and unprovisions
any Intel AMT settings.

То есть по умолчанию AMT активирован, что дает возможность удаленной эксплуатации. Но если его отключить, то исходя из описания уязвимости — все равно возможна локальная эксплуатация.
Локально или удаленно имеется ввиду то что если AMT настроено на интернет, то оно будет оттуда взломано, если оно не настроено, то взлом возможен из локальной сети (т.к. AMT по умолчанию стоит на DHCP и через него соединяется).


А можно поподробней или ссылку на документацию? Просто я склоняюсь к мнению powerman, что удаленная эксплуатация подразумевает настроенный и открытый доступ по сети, не важно локальной или глобальной, а локально — использование интерфейса в ОС.

А есть масса способов доставить СМС. Начиная с того, что массовые и рекламные рассылки вообще ходят через отдельную платформу у оператора. Ваша дело предложить агрегатору нормальные финансовые условия. Техническую возможность вы всегда найдете.

Я просто уверен, что все эти уязвимости используются на ура. Что пока они не приносят реальных финансовых или репутационных потерь оператору на них плевать.


Это как спуффинг номеров. Если мне прилетает звонок с номера +1-777-7654321, я знаю, что 777 зарезервирован и его не может быть, но оператор его пропустит и сейчас и потом потому, что это переадресованный номер, а для биллинга передан верный номер. Но пока все платят деньги и есть кому выставить счет — всем все равно…


И не взирая на


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

Имело место:


"Criminals carried out an attack from a network of a foreign mobile network operator in the middle of January," a representative with Germany's O2 Telefonica told a Süddeutsche Zeitung reporter. "The attack redirected incoming SMS messages for selected German customers to the attackers." The unidentified foreign network provider has since been blocked, and affected customers were informed of the breach.

Выходит в жизни возможно:


  1. Затроянить достаточное кол-во пользователей, как-то так https://www.engadget.com/2016/11/29/mirai-botnet-targets-deutsche-telekom-routers-in-global-cyberatt/
  2. Проверить их моб.операторов на уязвимость с использованием запросов от "доверенного оператора". (https://www.ptsecurity.com/upload/ptru/analytics/SS7-Vulnerability-2016-rus.pdf занимательная статистика)
    Думаю, что обнаружение вторжения происходит тут по факту заявления на списание средств или возможности подачи иска от банка. А если тестить на своих номерах и еще за счет платить, то никто и не заметит.
  3. Назначить день Х на середину января.
  4. ....
  5. PROFIT!!!111

Подозреваю, что телефон во время атаки будет показывать, что сервисы ограничены. Если способен это определить.


Ну и мы же понимаем, что подобный бизнес редко подразумевает долгосрочное сотрудничество и на далнейшую судьбу этого опсоса мне было бы глубоко наплевать.

В вашем случае, как я понимаю НКРЗІ.


Но я все же ошибался. Никакого роуминга нет. Номерная емкость левая. Доставка СМС, скорее всего обговорена с компаниями или смс-агрегаторами, которым все равно, напрямую.

А я думал, что откровенный СМС спам как раз и живет только шлюзами на симкартах. Ну если объемы единичных заказов не считаются в миллионах.


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

К примеру, тут:
Potential Security Impact:
Remote escalation of privilege on provisioned systems or local escalation of privilege on unprovisioned systems.

То, что вы не видите роуминга это не значит, что его нет. Там еще много чего должно быть, чего вы не видите, ядро, биллинг, услуги…


Голосовая связь и исходящие СМС льются "рефайлом" — через шлюзы. Входящие СМС проходят как СМС в роуминге, поскольку они бесплатные. Самый очевидный вариант.


А вообще, смотрите на сайте регулятора, кому принадлежат номера. Без этого — разговор беспредметный.

Если я вас правильно понял, то у них "внутренние" номера из одной страны, но звонят в мир они с использованием номера из соседней страны.
Звонки в роуминге дорогие, а входящие СМС — бесплатные.
Телефоны зарегистрированы в роуминге и СМС к ним приходят через свитчи "гостевого" оператора. Отказать в услуге родные операторы, которым принадлежат номера, не могут. Звонки через шлюз и добавочные — обычный рефайл, в данной ситуации не совсем обычный.

Но подается этот под соусом безопасности.
https://www.google.com/landing/2step/
Они же нигде не пишут, что нам нужно идентифицировать вас, поэтому используйте двухфакторную авторизацию.
Но как уже написал выше от нее же открещиваются. Не могу найти ссылку, но у них даже в документации по 2-way authentication есть дисклеймер, что гугл не несет ответственности за действия третьих лиц, коими являются агрегаторы СМС, операторы связи, и т.д. и т.п.

Так суть и заключается в этом. Якобы в расследовании немецкой газеты всплыли факты, что за 1000 долларов-евро вы можете купить порт с доступом к свитчу где-нибудь в Африке.

Ок.
К примеру, я купил доступ к Digicell Jamaica. У этого оператора есть роуминговые договора скажем с AT&T. И есть окс7 транки между ними.


Я аннонсирую регистрацию целевого номера AT&T у этого оператора. Насколько мне хватает знаний, мне для этого нужен будет клон симки, а может и нет, все равно будет отаваться виртуальный номер.


А дальше… Все новые стандарты проверки сим в роуминге до одного места. Поскольку:


  1. Необходима обратная совместимость стандарта и ее никто не отменял. Если у какого-то AT&T есть двухсторонняя проверка, то это не означает, что он не будет принимать запросы на регистрации в роуминге без этой проверки, если у Digicell Jamaica ее нет. На уровне согласования скорее всего просто будет флаг предпочтительна, который будет проигнорирован скомпрометированным свитчем.


  2. Я уверен, что провайдеры далеко не всегда горят желанием покупать дополнительные модули к софту своих свитчей. Они не дешевые и не обязательные. Мне как-то рассказывали, что в основном получают ответ на предложения по таким дополнительным фичам — "у нас сейчас все работает, нам это не нужно".

Тоесть проделать это возможно, поскольку в протоколе заложено, что должна быть обратная совместимость для предоставления базового функционала. Да закрыться можно. И скорее всего, что современные рекомендации позволяют закрыть все эти дыры, но только нарушая совместимость, не принимая запросы без дополнительной аутентификации.


ПС. Это мое личное мнение, я не специалист по GSM и буду рад, если вы укажете мне на мои ошибки...

Уязвимость by-design.
Кто-то получает доступ к коммутатору и оказывается в доверенной сети. Никаких дополнительных проверок не происходит. Регитрируй неомер где хочешь, читай и шли, что хочешь.


Google по поводу двухфакторной аутентификации говорит, что она безопасна. Я как-то задал вопрос "почему смс приходят с разных номеров", ответили, что "Google не несет ответственность за подрядчиков. И вообще придумайте сложный пароль и держите его в секрете"

Я не за Маска и не против. Существующие проекты Маска двигаются, но сроки постоянно съезжают вправо. А анонсированные проекты кажутся слегка фантастичными на сегоднящний день, как Hyper Loop, так и полет на Марс, и на тысячи спутников, и поземные туннели.
И вот новости про The Boring Company совпали по времени с этой новостью, которая касается его публичного бизнеса. У меня возникает впечатление, что просто замыливают глаза, чтобы отвлечь внимание от главного.
Тонкомпенсация была уже давно.
Врать не буду, не знаю как точно работает. Думаю, что реализовано связью между тон контролем и питчем на вертушках.
В конце концов вертак это всего лишь механика раскручивающая пластинку и игла. Все остальное делается уже даже в случае труЪ-винила бездушным холодным цифровым микшером, чоужтам.

А я дурак всю жизнь думал, что вертушки, миксер, усилок аналоговые…
А в остальном — все верно. Уровень зависит не от типа носителя, а — от прокладки между вертушками с пультом и наушниками…
Разница в том, что с винила вы слушаете «непережатый» материал, в кавычках потому, что на деле любой трек теряет в качестве (динамическом диапазоне) при мастеринге для винила.

А вот, что именно играют с CD, тут не поймешь, в начале 2000х CD-приводов с поддержкой mp3 не было, музню в основном качали, если была возможность, не у всех до середины 2000х был быстрый интернет. Иначе свежую музыку достать было нереально. Качали с торрентов-треккеров и не только с них, kazaa, winmx etc были в почете тоже. Был еще почивший recordings ru. И было за счастье если скачивали в 320kbps, в основном 192 или вообще 128, а потом это еще и записывалось на CD. Сейчас, в принципе, не многим лучше — не думаю, что многие качают wav с битпорта, если вообще покупают, скорее всего, что скачивают с контактика или файлообменников с тем же 320kbps.

Так что без слепого теста на различие чистого винила (без скрипа иглы и пыли), wav и mp3 минимум 320, заявления типа «я винил сразу отличаю» и «винил намного лучше» как-то беспочвенны.

Ну а вообще — да, техно хорошо звучит с винила, и mp3, и CD, и со скрипок внезапно.

Код приложения.
MessageSend
/*!
 * \internal
 * \brief MessageSend() application
 */
static int msg_send_exec(struct ast_channel *chan, const char *data)
{
	struct ast_datastore *ds;
	struct ast_msg *msg;
	char *tech_name;
	const struct ast_msg_tech *msg_tech;
	char *parse;
	int res = -1;
	AST_DECLARE_APP_ARGS(args,
		AST_APP_ARG(to);
		AST_APP_ARG(from);
	);

	if (ast_strlen_zero(data)) {
		ast_log(LOG_WARNING, "An argument is required to MessageSend()\n");
		pbx_builtin_setvar_helper(chan, "MESSAGE_SEND_STATUS", "INVALID_URI");
		return 0;
	}

	parse = ast_strdupa(data);
	AST_STANDARD_APP_ARGS(args, parse);

	if (ast_strlen_zero(args.to)) {
		ast_log(LOG_WARNING, "A 'to' URI is required for MessageSend()\n");
		pbx_builtin_setvar_helper(chan, "MESSAGE_SEND_STATUS", "INVALID_URI");
		return 0;
	}

	ast_channel_lock(chan);

	if (!(ds = ast_channel_datastore_find(chan, &msg_datastore, NULL))) {
		ast_channel_unlock(chan);
		ast_log(LOG_WARNING, "No message data found on channel to send.\n");
		pbx_builtin_setvar_helper(chan, "MESSAGE_SEND_STATUS", "FAILURE");
		return 0;
	}

	msg = ds->data;
	ao2_ref(msg, +1);
	ast_channel_unlock(chan);

	tech_name = ast_strdupa(args.to);
	tech_name = strsep(&tech_name, ":");

	ast_rwlock_rdlock(&msg_techs_lock);
	msg_tech = msg_find_by_tech_name(tech_name);

	if (!msg_tech) {
		ast_log(LOG_WARNING, "No message technology '%s' found.\n", tech_name);
		pbx_builtin_setvar_helper(chan, "MESSAGE_SEND_STATUS", "INVALID_PROTOCOL");
		goto exit_cleanup;
	}

	/*
	 * The message lock is held here to safely allow the technology
	 * implementation to access the message fields without worrying
	 * that they could change.
	 */
	ao2_lock(msg);
	res = msg_tech->msg_send(msg, S_OR(args.to, ""), S_OR(args.from, ""));
	ao2_unlock(msg);

	pbx_builtin_setvar_helper(chan, "MESSAGE_SEND_STATUS", res ? "FAILURE" : "SUCCESS");

exit_cleanup:
	ast_rwlock_unlock(&msg_techs_lock);
	ao2_ref(msg, -1);

	return 0;
}

${MESSAGE_SEND_STATUS} достаточен, чтобы быть уверенным, что пакет попал на нужный адрес и пришло подтверждение, по моим тестам.

Я не пробовал из плана набора. Но попробуйте отправить на несуществующий пир. По исходникам я не вижу откуда взятся разнице в работе AMI action (action_messagesend) и приложения (ast_msg_send).
Возможно, что в моих тестах я не так указывал uri, но не думаю…

main/message.c
static int action_messagesend(struct mansession *s, const struct message *m)
{
	const char *to = ast_strdupa(astman_get_header(m, "To"));
	const char *from = astman_get_header(m, "From");
	const char *body = astman_get_header(m, "Body");
	const char *base64body = astman_get_header(m, "Base64Body");
	char base64decoded[1301] = { 0, };
	char *tech_name = NULL;
	struct ast_variable *vars = NULL;
	struct ast_variable *data = NULL;
	const struct ast_msg_tech *msg_tech;
	struct ast_msg *msg;
	int res = -1;

	if (ast_strlen_zero(to)) {
		astman_send_error(s, m, "No 'To' address specified.");
		return 0;
	}

	if (!ast_strlen_zero(base64body)) {
		ast_base64decode((unsigned char *) base64decoded, base64body, sizeof(base64decoded) - 1);
		body = base64decoded;
	}

	tech_name = ast_strdupa(to);
	tech_name = strsep(&tech_name, ":");

	ast_rwlock_rdlock(&msg_techs_lock);
	msg_tech = msg_find_by_tech_name(tech_name);
	if (!msg_tech) {
		ast_rwlock_unlock(&msg_techs_lock);
		astman_send_error(s, m, "Message technology not found.");
		return 0;
	}

	if (!(msg = ast_msg_alloc())) {
		ast_rwlock_unlock(&msg_techs_lock);
		astman_send_error(s, m, "Internal failure\n");
		return 0;
	}

	data = astman_get_variables_order(m, ORDER_NATURAL);
	for (vars = data; vars; vars = vars->next) {
		ast_msg_set_var_outbound(msg, vars->name, vars->value);
	}

	ast_msg_set_body(msg, "%s", body);

	res = msg_tech->msg_send(msg, S_OR(to, ""), S_OR(from, ""));

	ast_rwlock_unlock(&msg_techs_lock);

	ast_variables_destroy(vars);
	ao2_ref(msg, -1);

	if (res) {
		astman_send_error(s, m, "Message failed to send.");
	} else {
		astman_send_ack(s, m, "Message successfully sent");
	}
	return 0;
}

int ast_msg_send(struct ast_msg *msg, const char *to, const char *from)
{
	char *tech_name = NULL;
	const struct ast_msg_tech *msg_tech;
	int res = -1;

	if (ast_strlen_zero(to)) {
		ao2_ref(msg, -1);
		return -1;
	}

	tech_name = ast_strdupa(to);
	tech_name = strsep(&tech_name, ":");

	ast_rwlock_rdlock(&msg_techs_lock);
	msg_tech = msg_find_by_tech_name(tech_name);

	if (!msg_tech) {
		ast_log(LOG_ERROR, "Unknown message tech: %s\n", tech_name);
		ast_rwlock_unlock(&msg_techs_lock);
		return -1;
	}

	res = msg_tech->msg_send(msg, S_OR(to, ""), S_OR(from, ""));

	ast_rwlock_unlock(&msg_techs_lock);

	ao2_ref(msg, -1);

	return res;
}



Если резко потерять клиента и тут же попытаться отправить сообщение, статус будет неудачный, хотя в пирах он ещё висит как ОК.

Отошлите qualify запрос. Если пир отвалился, то после запроса статус обновится. Но поскольку запрос асинхронный нужно будет сделать задержку.
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerAction_SIPqualifypeer

Information

Rating
Does not participate
Registered
Activity