Trust Issues in AI

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/12/trust-issues-in-ai.html

This essay was written with Nathan E. Sanders. It originally appeared as a response to Evgeny Morozov in Boston Review‘s forum, “The AI We Deserve.”

For a technology that seems startling in its modernity, AI sure has a long history. Google Translate, OpenAI chatbots, and Meta AI image generators are built on decades of advancements in linguistics, signal processing, statistics, and other fields going back to the early days of computing—and, often, on seed funding from the U.S. Department of Defense. But today’s tools are hardly the intentional product of the diverse generations of innovators that came before. We agree with Morozov that the “refuseniks,” as he calls them, are wrong to see AI as “irreparably tainted” by its origins. AI is better understood as a creative, global field of human endeavor that has been largely captured by U.S. venture capitalists, private equity, and Big Tech. But that was never the inevitable outcome, and it doesn’t need to stay that way.

The internet is a case in point. The fact that it originated in the military is a historical curiosity, not an indication of its essential capabilities or social significance. Yes, it was created to connect different, incompatible Department of Defense networks. Yes, it was designed to survive the sorts of physical damage expected from a nuclear war. And yes, back then it was a bureaucratically controlled space where frivolity was discouraged and commerce was forbidden.

Over the decades, the internet transformed from military project to academic tool to the corporate marketplace it is today. These forces, each in turn, shaped what the internet was and what it could do. For most of us billions online today, the only internet we have ever known has been corporate—because the internet didn’t flourish until the capitalists got hold of it.

AI followed a similar path. It was originally funded by the military, with the military’s goals in mind. But the Department of Defense didn’t design the modern ecosystem of AI any more than it did the modern internet. Arguably, its influence on AI was even less because AI simply didn’t work back then. While the internet exploded in usage, AI hit a series of dead ends. The research discipline went through multiple “winters” when funders of all kinds—military and corporate—were disillusioned and research money dried up for years at a time. Since the release of ChatGPT, AI has reached the same endpoint as the internet: it is thoroughly dominated by corporate power. Modern AI, with its deep reinforcement learning and large language models, is shaped by venture capitalists, not the military—nor even by idealistic academics anymore.

We agree with much of Morozov’s critique of corporate control, but it does not follow that we must reject the value of instrumental reason. Solving problems and pursuing goals is not a bad thing, and there is real cause to be excited about the uses of current AI. Morozov illustrates this from his own experience: he uses AI to pursue the explicit goal of language learning.

AI tools promise to increase our individual power, amplifying our capabilities and endowing us with skills, knowledge, and abilities we would not otherwise have. This is a peculiar form of assistive technology, kind of like our own personal minion. It might not be that smart or competent, and occasionally it might do something wrong or unwanted, but it will attempt to follow your every command and gives you more capability than you would have had without it.

Of course, for our AI minions to be valuable, they need to be good at their tasks. On this, at least, the corporate models have done pretty well. They have many flaws, but they are improving markedly on a timescale of mere months. ChatGPT’s initial November 2022 model, GPT-3.5, scored about 30 percent on a multiple-choice scientific reasoning benchmark called GPQA. Five months later, GPT-4 scored 36 percent; by May this year, GPT-4o scored about 50 percent, and the most recently released o1 model reached 78 percent, surpassing the level of experts with PhDs. There is no one singular measure of AI performance, to be sure, but other metrics also show improvement.

That’s not enough, though. Regardless of their smarts, we would never hire a human assistant for important tasks, or use an AI, unless we can trust them. And while we have millennia of experience dealing with potentially untrustworthy humans, we have practically none dealing with untrustworthy AI assistants. This is the area where the provenance of the AI matters most. A handful of for-profit companies—OpenAI, Google, Meta, Anthropic, among others—decide how to train the most celebrated AI models, what data to use, what sorts of values they embody, whose biases they are allowed to reflect, and even what questions they are allowed to answer. And they decide these things in secret, for their benefit.

It’s worth stressing just how closed, and thus untrustworthy, the corporate AI ecosystem is. Meta has earned a lot of press for its “open-source” family of LLaMa models, but there is virtually nothing open about them. For one, the data they are trained with is undisclosed. You’re not supposed to use LLaMa to infringe on someone else’s copyright, but Meta does not want to answer questions about whether it violated copyrights to build it. You’re not supposed to use it in Europe, because Meta has declined to meet the regulatory requirements anticipated from the EU’s AI Act. And you have no say in how Meta will build its next model.

The company may be giving away the use of LLaMa, but it’s still doing so because it thinks it will benefit from your using it. CEO Mark Zuckerberg has admitted that eventually, Meta will monetize its AI in all the usual ways: charging to use it at scale, fees for premium models, advertising. The problem with corporate AI is not that the companies are charging “a hefty entrance fee” to use these tools: as Morozov rightly points out, there are real costs to anyone building and operating them. It’s that they are built and operated for the purpose of enriching their proprietors, rather than because they enrich our lives, our wellbeing, or our society.

But some emerging models from outside the world of corporate AI are truly open, and may be more trustworthy as a result. In 2022 the research collaboration BigScience developed an LLM called BLOOM with freely licensed data and code as well as public compute infrastructure. The collaboration BigCode has continued in this spirit, developing LLMs focused on programming. The government of Singapore has built SEA-LION, an open-source LLM focused on Southeast Asian languages. If we imagine a future where we use AI models to benefit all of us—to make our lives easier, to help each other, to improve our public services—we will need more of this. These may not be “eolithic” pursuits of the kind Morozov imagines, but they are worthwhile goals. These use cases require trustworthy AI models, and that means models built under conditions that are transparent and with incentives aligned to the public interest.

Perhaps corporate AI will never satisfy those goals; perhaps it will always be exploitative and extractive by design. But AI does not have to be solely a profit-generating industry. We should invest in these models as a public good, part of the basic infrastructure of the twenty-first century. Democratic governments and civil society organizations can develop AI to offer a counterbalance to corporate tools. And the technology they build, for all the flaws it may have, will enjoy a superpower that corporate AI never will: it will be accountable to the public interest and subject to public will in the transparency, openness, and trustworthiness of its development.

Седмицата (2–7 декември)

Post Syndicated from Боряна Телбис original https://www.toest.bg/sedmitsata-2-7-dekemvri/

Седмицата (2–7 декември)

Да ме прощават софистицираните читатели на „Тоест“, че ще започна тазседмичния бюлетин така, но искам да се върна към една градска легенда. Пернишка градска легенда, ако трябва да сме по-точни. Твърди се – аз не съм го виждала с очите си, но много хора са, – че на стадиона на „Миньор“ (Перник), по-известен като Стадиона на мира, някога пишело: К*Р ЗА ХОРАТА. С големи четливи букви на едната стена до трибуните. 

И преди да побегнете, съвсем справедливо отвратени от тази простащина, постойте да ви обясня защо го разказвам. 

Представяте ли си до каква степен трябва да е бил отчаян лирическият герой, за да вдигне толкова голям среден пръст на цялото човечество и да пожелае да увековечи това с надпис на стената. За да може всички, които влизат на стадиона и заемат местата си по трибуните, да го видят и да усетят тази безнадеждност.

А сега бъдете честни пред себе си и си споделете тихичко и насаме дали докато подритваме поредния „исторически и безпрецедентен момент“, през който минаваме колективно като общество, не ви се приисква от време на време да дадете воля на чувствата си като незнайният герой от Перник? Може и да не е с тези думи. Може и да не е с надпис на стената. Даже препоръчително е да не е нито с тези думи, нито на подобно място, обаче човек трябва понякога да размаха юмрук към нищото и да му се закани, да го пита: „Това ли е? Толкова ли можем? Има ли как да са иначе нещата?“ И когато тези въпроси виснат над главите на всички ни, когато почнем да ги тъпчем по автобусите, да си лягаме с тях, да влизаме с тях в ресторантите и да вдигаме наздравици, докато ни танцуват по прическите, тогава ще намерим общностната сила да поискаме да им отговорим.

И през отговорите ще пропълзи промяната.

Дотогава ще завиваме кротко децата си вечер и в лицата им ще намираме утеха за всичко, което сме чули по новините. Ще се убеждаваме, че разумът ни още е здрав, че не всичко е загубено. Нищо че в страна от ЕС в XXI век има болници и родилни отделения на ротационен принцип. Нищо че отново събираме пари за „Българската Коледа“ – кампания самопризнание за абсолютната държавна безпомощност по линия на здравеопазването. Нищо че в половин България няма нормална течаща вода, защото „снегът се топял бавно“ (?!). Нищо че поредна жена е с опасност за живота след тежък побой, нанесен ѝ от мъжа, с когото съжителства на семейни начала от 20 години. 

Нищо. 

Важното е, че след 26 дни първо заседание парламентът вече си има председател – Наталия Киселова.

Изборът очевидно не беше лесен и между гласуванията станаха ясни всякакви интересни неща, например че човек може да e принципен, но без да прекалява. Явор Божанков, изглежда, не го беше разбрал и продължи да гласува по съвест, заради което от ПП му поискаха оставката. Текстът на Светла Енчева тази седмица „Константата Явор Божанков“ е посветен тъкмо на този казус.

Кризата в държавата помогна на протеста във Велинградско, който целеше да спаси от евтаназиране 1760 овце, да се увенчае с успех. Очевидно и Министерството на вътрешните работи, и Министерството на земеделието и храните не разполагат нито със силите, нито с желанието да се намесват и да налагат волята на държавата насила. Не че не сме виждали как го прави МВР покрай колоните на Министерския съвет например.

Просто сега не е подходящо. По темата разсъждава Емилия Милчева в текста си „В битката за власт спечелиха овцете“.

До известна степан пак за битката за власт, но по-глобално погледнато, става въпрос и в материала на Милена Делева „Европа за европейците, България за българите, Америка за американците?“. Милена дебютира в „Тоест“ с разсъждения за ксенофобията, расизма, антисемитизма и ислямофобията. 

Още един нов автор се изявява на страниците на медията тази седмица. Мартин Димов поставя началото на сътрудничеството ни с „Екипът на София“ в рамките на рубрика, в която ще разискваме най-различни градски теми. В „Колко е трудно да бъдеш етажна собственост. И как може да е иначе“ Мартин обяснява какво може да се направи, за да ни е по-лесно на всички да съжителстваме едни с други. 

Общото ни съжителство донякъде се улеснява в периоди на празници – може би защото тогава сме по-склонни да сме по-добри едни към други или просто защото ни няма на територията на етажната собственост. Така или иначе, задават се празници и е редно да знаем как да си ги честитим грамотно. На помощ идва порцията език на Павлина Върбанова, която тази седмица носи шеметното заглавие „Не сме безгрешни, но сме коледни“.

Още един текст от регулярна месечна рубрика – за молекулярна биология – имаме тази седмица в „Тоест“. В материала си „За борбата на науката с ХИВ“ Анастасия Орманджиева разглежда неимоверните усилия и изключителните научни достижения, заради които днес има терапия за ХИВ. Анастасия ни разказва за историята на заболяването, както и за неговия механизъм и възможности за лечение.

Завършваме седмицата с чудесно „На второ четене“ от Стефан Иванов. В него става дума за книгата на португалеца Гонсало М. Тавареш „Матео остана без работа“. 

Помнех, че Марин Бодаков ми е говорил за тази книга. Но бях забравил, че е говорил за нея и във видео. Отне ми два часа да се насиля да го пусна. Беше ми трудно. Прозорецът стоеше отворен, но просто не го пусках. Не знаех как ще реагирам, когато отново го чуя и видя, а няма как това да се случи отново в живота ми в плът и кръв. Едно от тези неща, съвпадения, синхроничности, които те изваждат от релси и те нокаутират.

Оставям ви с този откъс от текста на Стефан и ви желая съвпадения, които да ви поставят на мястото ви. 

Ако работата на екипа на „Тоест“ ви харесва, ще се радваме да ни подкрепите, защото медията ни се издържа изцяло и единствено от читателски дарения.

Подкрепете ни

Friday Squid Blogging: Safe Quick Undercarriage Immobilization Device

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/12/friday-squid-blogging-safe-quick-undercarriage-immobilization-device.html

Fifteen years ago I blogged about a different SQUID. Here’s an update:

Fleeing drivers are a common problem for law enforcement. They just won’t stop unless persuaded­—persuaded by bullets, barriers, spikes, or snares. Each option is risky business. Shooting up a fugitive’s car is one possibility. But what if children or hostages are in it? Lay down barriers, and the driver might swerve into a school bus. Spike his tires, and he might fishtail into a van­—if the spikes stop him at all. Existing traps, made from elastic, may halt a Hyundai, but they’re no match for a Hummer. In addition, officers put themselves at risk of being run down while setting up the traps.

But what if an officer could lay down a road trap in seconds, then activate it from a nearby hiding place? What if—­like sea monsters of ancient lore­—the trap could reach up from below to ensnare anything from a MINI Cooper to a Ford Expedition? What if this trap were as small as a spare tire, as light as a tire jack, and cost under a grand?

Thanks to imaginative design and engineering funded by the Small Business Innovation Research (SBIR) Office of the U. S. Department of Homeland Security’s Science and Technology Directorate (S&T), such a trap may be stopping brigands by 2010. It’s called the Safe Quick Undercarriage Immobilization Device, or SQUID. When closed, the current prototype resembles a cheese wheel full of holes. When open (deployed), it becomes a mass of tentacles entangling the axles. By stopping the axles instead of the wheels, SQUID may change how fleeing drivers are, quite literally, caught.

Blog moderation policy.

AWS Network Firewall Geographic IP Filtering launch

Post Syndicated from Prasanjit Tiwari original https://aws.amazon.com/blogs/security/aws-network-firewall-geographic-ip-filtering-launch/

AWS Network Firewall is a managed service that provides a convenient way to deploy essential network protections for your virtual private clouds (VPCs). In this blog post, we discuss Geographic IP Filtering, a new feature of Network Firewall that you can use to filter traffic based on geographic location and meet compliance requirements.

Customers with internet-facing applications are constantly in need of advanced security features to protect their applications from threat actors. This includes restricting traffic to and from their workloads in Amazon Web Services (AWS) to certain geographies because of security risk. Customers operating in highly regulated industries—such as banking, public sector, or insurance—might have specific security requirements that can be addressed by Geographic IP Filtering.

Previously, customers had to rely on third-party tools for retrieving an IP address list of specific countries and updating their firewall rules on a regular basis to meet applicable requirements. Now, with Geographic IP Filtering on Network Firewall, you can protect your application workloads based on the geolocation of the IP address. As new IP addresses are assigned by the Internet Assigned Numbers Authority (IANA), the Geographic IP database underneath Network Firewall is automatically updated so that the service can consistently filter inbound and outbound traffic from specific countries based on country codes. It supports IPv4 and IPv6 traffic.

Geographic IP Filtering is supported in all AWS Regions where Network Firewall is available today, including the AWS GovCloud (US) Regions.

Set up Geographic IP Filtering in Network Firewall

You can use Network Firewall to inspect network traffic and protect your VPCs using layer 3–7 rules (network layer to application layer of the OSI model). When traffic reaches Network Firewall, it will identify the location of the source and destination IP address from the Geographic IP database and block traffic if you have a firewall rule to block that location. You can choose to pass, drop, reject, or create an alert for traffic coming from or going to specific countries.

Before setting up Geographic IP Filtering rules, you need to deploy Network Firewall and attach a firewall policy. You can learn more about these steps in the Network Firewall Getting Started guide. You can configure Network Firewall Geographic IP Filtering in minutes using the AWS Management Console, AWS Command Line Interface (AWS CLI), AWS SDK, or the Network Firewall API.

To configure Geographic IP Filtering rules using the console:

  1. Sign in to the AWS Management Console and open the Amazon VPC console.
  2. In the navigation pane, under Network Firewall, choose Network Firewall rule groups.
  3. Choose Create rule group.
  4. In the Create rule group page, for the Rule group type, select Stateful rule group.
  5. For the Rule group format, select Standard stateful rule.
  6. For Rule evaluation order, select either Strict order (recommended) or Action order.
  7. Enter a name for the stateful rule group.
  8. For Capacity, enter the maximum capacity you want to allow for the stateful rule group.
  9. Under Standard stateful rules, for Geographic IP Filtering, select whether you want to Disable Geographic IP filtering, Match only selected countries, or Match all but selected countries.
  10. If you opt for Geographic IP Filtering, then select the Geographic IP traffic direction and Country codes that you want to filter the traffic for.
  11. Enter the appropriate values for Protocol, Source, Source port, Destination, and Destination port.
  12. For Action, select the action that you want Network Firewall to take when a packet matches the rule settings.

    Figure 1: Standard stateful rule

    Figure 1: Standard stateful rule

  13. Click Add rule and then review the rule to create the rule group.

    Figure 2: Geographic IP Filtering rules

    Figure 2: Geographic IP Filtering rules

Suricata compatibility

You can also use Geographic IP filtering with Suricata-compatible rule strings using the geoip keyword.

To create a Suricata compatible rule string:

  1. Follow steps 1 through 4 of the previous procedure.
  2. For the Rule group format, select Suricata compatible rule string.
  3. For Rule evaluation order, select either Strict order (recommended) or Action order.
  4. Enter a name for the stateful rule group.
  5. For Capacity, enter the maximum capacity you want to allow for the stateful rule group.
  6. Under Suricata compatible rule string, enter an appropriate string based on your source and destination along with the country code to filter traffic for. To use a Geographic IP filter, provide the geoip keyword, the filter type, and the country codes for the countries that you want to filter for.
  7. Suricata supports filtering for source and destination IPs. You can filter on either of these types by itself, by specifying dst or src. You can filter on the two types together with AND or OR logic, by specifying both or any.

For example, the following sample Suricata rule string drops traffic originating from Japan:

drop ip any any -> any any (msg:"Geographic IP from JP,Japan"; geoip:src,JP; sid:55555555; rev:1;)

Note that Suricata determines the location of requests using MaxMind GeoIP databases. MaxMind reports very high accuracy of their data at the country level, although accuracy varies according to factors such as country and type of IP. For more information about MaxMind, see MaxMind IP Geolocation.

If you think any of the Geographic IP data is incorrect, you can submit a correction request to MaxMind at MaxMind Correct GeoIP Data.

Logging Geographic IP Filtering

You can configure Network Firewall logging for your firewall’s stateful engine to get detailed information about the packet and any stateful rule action taken against the packet. There are no changes to the logging and monitoring mechanism with the introduction of the Geographic IP Filtering feature. However, by explicitly specifying the msg and metadata keywords, you can see additional geographic information in the alert logs that can help with troubleshooting. If these keywords aren’t specified in the Suricata rule string, the log event will not show any geographic information.

Suricata rule examples

In this section, you will find examples of Suricata rule strings to pass, block, reject, and alert on traffic to or from a specific country.

Example 1: To pass ingress traffic from a specific country

The following example passes ingress traffic from India.

Note: The rule evaluation order should be set to Strict for alert logs to be generated in this example. If the rule evaluation order is set to Action, then although the traffic will pass, alert logs will not be generated.

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Ingress traffic from IN allowed"; flow:to_server; geoip:src,IN; metadata:geo IN; sid:202409301;)
pass ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Ingress traffic from IN allowed"; flow:to_server; geoip:src,IN; metadata:geo IN; sid:202409302;)

The following are the alert and flow logs for Example 1.

Alert logs:

{
    "firewall_name": "Test-NFW",
    "availability_zone": "eu-north-1a",
    "event_timestamp": "1731102856",
    "event": {
        "src_ip": "13.127.20.X",
        "src_port": 56630,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 202409301,
            "rev": 0,
            "metadata": {
                "geo": ["IN"]
            },
            "signature": "Ingress traffic from IN allowed",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 234143298308779,
        "dest_ip": "172.31.2.4",
        "proto": "TCP",
        "verdict": {
            "action": "pass"
        },
        "dest_port": 80,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2024-11-08T21:54:16.972019+0000",
        "direction": "to_server"
    }
}

Flow logs from source to destination:

{
    "firewall_name": "Test-NFW",
    "availability_zone": "eu-north-1a",
    "event_timestamp": "1731102918",
    "event": {
        "tcp": {
            "tcp_flags": "13",
            "syn": true,
            "fin": true,
            "ack": true
        },
        "app_proto": "unknown",
        "src_ip": "13.127.20.X",
        "src_port": 56630,
        "netflow": {
            "pkts": 4,
            "bytes": 216,
            "start": "2024-11-08T21:54:16.972019+0000",
            "end": "2024-11-08T21:54:17.263030+0000",
            "age": 1,
            "min_ttl": 112,
            "max_ttl": 112
        },
        "event_type": "netflow",
        "flow_id": 234143298308779,
        "dest_ip": "172.31.2.4",
        "proto": "TCP",
        "dest_port": 80,
        "timestamp": "2024-11-08T21:55:18.257416+0000"
    }
}

Flow logs from destination to source:

{
    "firewall_name": "Test-NFW",
    "availability_zone": "eu-north-1a",
    "event_timestamp": "1731102918",
    "event": {
        "tcp": {
            "tcp_flags": "13",
            "syn": true,
            "fin": true,
            "ack": true
        },
        "app_proto": "unknown",
        "src_ip": "172.31.2.4",
        "src_port": 80,
        "netflow": {
            "pkts": 2,
            "bytes": 112,
            "start": "2024-11-08T21:54:16.972019+0000",
            "end": "2024-11-08T21:54:17.263030+0000",
            "age": 1,
            "min_ttl": 126,
            "max_ttl": 126
        },
        "event_type": "netflow",
        "flow_id": 234143298308779,
        "dest_ip": "13.127.20.X",
        "proto": "TCP",
        "dest_port": 56630,
        "timestamp": "2024-11-08T21:55:18.257449+0000"
    }
}

Example 2: To block ingress traffic from a specific country

The following example blocks ingress traffic from Japan.

drop ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Ingress traffic from JP blocked"; flow:to_server; geoip:any,JP; metadata:geo JP; sid:202409303;)

Example 3: To block ingress SSH traffic from a specific country

The following example blocks ingress SSH traffic from Russia.

drop ssh $EXTERNAL_NET any -> $HOME_NET any (msg:"Ingress SSH traffic from RU blocked"; flow:to_server; geoip:src,RU; metadata:geo RU; sid:202409304;)

Example 4: To reject egress TCP traffic to a specific country:

The following example rejects egress TCP traffic to Iran.

reject tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Egress traffic to IR rejected"; flow:to_server; geoip:dst,IR; metadata:geo IR; sid:202409305;)

Example 5: To alert on traffic originating from or destined to specific country

The following example alerts on traffic that originates from Venezuela.

alert ip any any -> any any (msg:"Geographic IP is from VE, Venezuela"; geoip:any,VE; sid: 202409306;)

Conclusion

You can use the new Geographic IP Filtering feature in AWS Network Firewall to enhance your security posture by controlling traffic based on geographic locations. In this post, you learned about the key concepts, configuration steps, and examples for implementing the Geographic IP Filtering feature in Network Firewall. By using this feature, businesses can protect their networks from potentially harmful traffic and control which geographic locations can interact with their infrastructure. As cyber threats continue to evolve, the Geographic IP Filtering feature serves as a vital tool for strengthening network security.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
 

Prasanjit Tiwari
Prasanjit Tiwari

Prasanjit is a Cloud Support Engineer II based out of Virginia, USA. He has a Master of Science in Telecommunications Engineering from the University of Maryland. He is a WAF and Route 53 subject matter expert and enjoys working on networking and perimeter security services. He is enthusiastic about using innovative solutions to address customer challenges.
Dhiren Patel
Dhiren Patel

Dhiren is a Cloud Support Engineer-II based out of Virginia, USA. He has a Master of Science in Electrical and Computer Engineering from New York University. As a WAF and Route 53 subject matter expert, he specializes in AWS networking and security services. He’s passionate about helping customers solve their AWS issues and get the best cloud experience possible through AWS.

Metasploit Weekly Wrap-Up 12/06/2024

Post Syndicated from Christophe De La Fuente original https://blog.rapid7.com/2024/12/06/metasploit-weekly-wrap-up-44/

Post-Thanksgiving Big Release

Metasploit Weekly Wrap-Up 12/06/2024

This week’s release is an impressive one. It adds 9 new modules, which will get you remote code execution on products such as Ivanti Connect Secure, VMware vCenter Server, Asterisk, Fortinet FortiManager and Acronis Cyber Protect. It also includes an account takeover on WordPress, a local privilege escalation on Windows and a X11 keylogger module. Finally, this release improves the fingerprinting logic for the TeamCity login module and adds instructions about the installation of the Metasploit development environment on windows using Powershell in the official documentation. A big thank you to the community for this awesome release!

New module content (9)

WordPress POST SMTP Account Takeover

Authors: Ulysses Saicha and h00die
Type: Auxiliary
Pull request: #19596 contributed by h00die
Path: admin/http/wp_post_smtp_acct_takeover
AttackerKB reference: CVE-2023-6875

Description: The POST SMTP Mailer – Email log, Delivery Failure Notifications and Best Mail SMTP for WordPress, plugin for WordPress is vulnerable to unauthorized access of data and modification of data due to a type juggling issue on the connect-app REST endpoint in all versions up to, and including, 2.8.7. This adds an exploit module which allows an attacker to reset the password of any known user on the system.

X11 Keylogger

Authors: h00die and nir tzachar
Type: Auxiliary
Pull request: #18877 contributed by h00die
Path: gather/x11_keyboard_spy
AttackerKB reference: CVE-1999-0526

Description: This adds a new X11 library and module that uses it to remotely capture key presses from open X servers.

Chamilo v1.11.24 Unrestricted File Upload PHP Webshell

Authors: Ngo Wei Lin and jheysel-r7
Type: Exploit
Pull request: #19629 contributed by jheysel-r7
Path: linux/http/chamilo_bigupload_webshell
AttackerKB reference: CVE-2023-4220

Description: This adds an exploit module for Chamilo LMS, where versions prior to 1.11.24, a webshell can be uploaded via the bigload.php endpoint allowing remote code execution in the context of www-data (CVE-2023-4220).

Ivanti Connect Secure Authenticated Remote Code Execution via OpenSSL CRLF Injection

Authors: Christophe De La Fuente and Richard Warren
Type: Exploit
Pull request: #19595 contributed by cdelafuente-r7
Path: linux/http/ivanti_connect_secure_rce_cve_2024_37404
AttackerKB reference: CVE-2024-37404

Description: Adds an exploit module for a CRLF injection vulnerability in Ivanti Connect Secure to achieve remote code execution. Versions prior to 22.7R2.1 and 22.7R2.2 are vulnerable. Ivanti Policy Secure versions prior to 22.7R1.1 are also vulnerable but this module doesn’t support this software. Valid administrative credentials are required. A non-administrative user is also required and can be created using the administrative account, if needed. Also the Client Log Upload feature needs to be enabled. This can also be done using the administrative interface if it is not enabled already.

vCenter Sudo Privilege Escalation

Authors: Matei "Mal" Badanoiu and h00die
Type: Exploit
Pull request: #19402 contributed by h00die
Path: linux/local/vcenter_sudo_lpe
AttackerKB reference: CVE-2024-37081

Description: VMware vCenter Server < 7.0.3 update R and < 8.0.2 update D contains multiple local privilege escalation vulnerabilities due to misconfiguration of sudo. An authenticated local user with non-administrative privileges may exploit these issues to elevate privileges to root on vCenter Server Appliance. This adds a post module to exploit these vulnerabilities.

Asterisk AMI Originate Authenticated RCE

Authors: Brendan Coles [email protected], NielsGaljaard, and h00die
Type: Exploit
Pull request: #19613 contributed by h00die
Path: linux/misc/asterisk_ami_originate_auth_rce
AttackerKB reference: CVE-2024-42365

Description: Adds an authenticated RCE module for Asterisk via AMI. This vulnerability is tracked as CVE-2024-42365. This also moves the underlying functionality that enables the module to interact with the Asterisk application, originally written by @bcoles, to a library.

Fortinet FortiManager Unauthenticated RCE

Author: sfewer-r7
Type: Exploit
Pull request: #19648 contributed by sfewer-r7
Path: linux/misc/fortimanager_rce_cve_2024_47575
AttackerKB reference: CVE-2024-47575

Description: Adds a module that exploits a missing authentication vulnerability affecting FortiManager and FortiManager Cloud devices to achieve unauthenticated RCE with root privileges. This vulnerability is being tracked as CVE-2024-47575.

Acronis Cyber Protect/Backup remote code execution

Authors: Sandro Tolksdorf of usd AG. and h00die-gr3y [email protected]
Type: Exploit
Pull request: #19583 contributed by h00die-gr3y
Path: multi/acronis_cyber_protect_unauth_rce_cve_2022_3405
AttackerKB reference: CVE-2022-3405

Description: This exploits an RCE and sensitive information disclosure vulnerability due to excessive privileges assigned to Acronis Agent. The following products are affected: Acronis Cyber Protect 15 before build 29486, Acronis Cyber Backup 12.5 before build 16545.

Windows Access Mode Mismatch LPE in ks.sys

Authors: AngelBoy, jheysel-r7, and varwara
Type: Exploit
Pull request: #19574 contributed by jheysel-r7
Path: windows/local/cve_2024_35250_ks_driver
AttackerKB reference: CVE-2024-35250

Description: This adds a post module to gain NT AUTHORITY/SYSTEM privileges on a Windows target vulnerable to CVE-2024-35230.

Enhancements and features (1)

  • #19684 from sjanusz-r7 – Improves the fingerprinting logic for the auxiliary/scanner/teamcity/teamcity_login module.

Documentation added (1)

  • #19622 from soroshsabz – This improves the Metasploit development environment installation documentation by adding Powershell instructions on Windows 10 and earlier.

You can always find more documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
commercial edition Metasploit Pro

The collective thoughts of the interwebz