Security

(Reliable)? php2shell exploitability, (Fri, Oct 23rd)

Leave a comment
This post was originally published on this site

Yesterday everyone was running around like crazy (me included 🙂 because of the php2shell vulnerability.

However, after looking closely at some published PoC's – and there is an unbelievable amount of AI generated – erm, slop – it looks like building a universal, reliable, one click exploit is quite difficult (unless I'm missing something, so please do let me know).

The PoC's that have been released so far have several pre-requirements and are almost cheating.

First, in order to have a clean initial state, the one PoC that makes sense sends a POST HTTP request with a number of small fields (3000 bytes each, 1001 of them), for bulk allocation pressure, prepare PHPSESSID and PHP_SESSION_UPLOAD_PROGRESS and then append a big field of 12 MB.
This guarantees that emalloc fails, since the PoC require that memory limit is set to 8 MB.

This is the first issue; in real world setups memory_limit is usually 128 MB, making this a bit more demanding.
An even bigger issue is that real world setups will have multiple workers – the demo uses a single-worker prefork configuration which guarantees that the next phase lands with this worker. In real world this is not guaranteed and an attacker would have to consume all workers and release one (and catch that one). Not sure how difficult this is.

The next phase now (phase 1) leaks the Zend MM chunk base, which is a piece of heap, from which the 2 MB-aligned Zend MM chunk base is extracted.
This is needed for calculation of HashTable.

Then phase 2 leaks the libphp.so base address.
This is needed to defeat ASLR, but it's not the only component required. Specifically, once Apache starts, it will pick a randomized base address for libphp.so. However, offsets of other functions/pointers in libphp.so will be static.

So phase 2 will leak one specific code pointer: zval_ptr_dtor, which has a static offset from libphp.so base address. In other words, by knowing this offset, we can calculate the base address of libphp.so and defeat ASLR.
The problem here is that this depends on many factors – how libphp.so was compiled, what's the exact PHP version, distro etc).
This is where shown PoC's are "cheating" they read offsets of zval_ptr_dtor (and zif_system) from libphp.so on the server.
In real world an attacker would have to know this. I presume someone could compile list of all possible options for commonly used distro combinations.

Now in phase 3 (and I haven't thoroughly checked this one), the exploit will change pDestructor to zif_system, and this will result in execution of code. There is one limit here; the size of command can be up to 14 bytes.

As we can see, there's a lot of prerequisites here that make a reliable exploit difficult.
I'm pretty sure that smart researchers that found the vulnerability know (much) more, but clearly it's not as simple as perhaps initially thought.

The general recommendation to put session.upload_progress.enabled = 0 should help, especially since there apparently is a way to bypass even the (currently) available fix so do put this until the next update.

—
Bojan
@bojanz / bojanz
INFIGO IS

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

PHP Vulnerability Wrap-Up, (Fri, Oct 23rd)

Leave a comment
This post was originally published on this site

This morning, we returned to Infocon Green. As usual, we are raising the Infocon to alert you to emerging situations requiring immediate attention. PHP fit that description. By now, you either know about it, or you probably never will, so it is time to go back to "business as usual".

 Many vendors have released patches for the vulnerability in sync with PHP.net, showing that the coordinated vulnerability disclosure worked and achieved its goal of providing tested and working patches in a timely manner. Some vendor(s) not playing by the rules and leaking details early is unfortunate but should not overshadow the overall success of providing the patches.

At this point, no reliable exploit has been made available publicly as far as I know. Several firms stated that they possess working exploit code, and I consider it a matter of time before such code becomes publicly available, at which point we will likely see more widespread exploitation. Cloudflare and Amazon have stated that they are seeing a large number of exploit attempts, but it is not clear if these are actual working exploits.

Applying the patch remains your best and only reliable defense. Treat the time you have now as a gift and use it wisely to find and patch applications in your organization.

If you are not able to upgrade, do your best to isolate vulnerable applications. There are various workarounds, but none are considered 100% effective. They may buy you more time. The same is true for web application firewall rules.

Today, php.net advised keeping the "session.upload_progress.enabled=0" workaround in place until the next update. In other words: We are not done patching PHP yet!

As so often, embedded devices and appliances are a major concern, and many of them have not been updated or are unlikely to ever receive a patch. These types of devices should be isolated regardless. The PHP issue is likely just one of many weaknesses that could be exploited. Router admin interfaces, network storage devices, cameras, cat feeding stations, and refrigerators should not be exposed to the internet, and should be isolated on internal networks. At this point, this is table stakes regardless if they are running PHP.

This vulnerability is also a good "dress rehearsal" of what is likely going to come. Vulnerability disclosure worked in this case. Patches were available. There will likely be many more vulnerabilities of similar severity that will be released and exploited with less responsibility. Be ready, run your tabletop exercises, update your inventories… 

Many partial exploits have been released. Be careful; some of them may be "parasitic," trying to exploit whoever runs them. It may be hard to even identify the working exploit once it comes out.

The vulnerability and the risk are real, even if we did not see immediate mass exploitation. That part is still to come; it is just delayed. Just like we lower our infocon, make sure to rest and disconnect a bit, and do not stay "on alert" for too long. You will need the strength for the next issue. And do not overlook other issues that may have been missed this week: Node.js, Fortinet … and more

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

AWS

AWS Continuum for code vulnerabilities is now generally available

Leave a comment
This post was originally published on this site

Today, we’re announcing the general availability of AWS Continuum for code vulnerabilities. AWS Continuum is a security service that finds and validates code vulnerabilities, then delivers fixes as patches you can automate or as pull requests in your repositories. AWS Continuum for code vulnerabilities confirms which findings are exploitable in your environment, ranks the resulting issues by business impact, and proposes a fix for each one. Every remediation starts in a mode where Continuum proposes the fix and a person approves it before it ships. In the future, you will be able to decide which actions Continuum can take on its own, within the guardrails you define.

Using frontier artificial intelligence (AI) models, threat actors can turn a vulnerability disclosure into working exploit code in minutes, and the same tools that speed up development also increase the volume of findings your teams must process. If your organization runs a large application estate, your scanners likely produce thousands of findings a day, and many of them need no action. A finding can be unreachable, unexploitable, or already mitigated by a runtime control. Generic severity scores don’t tell you which resources a threat actor can actually reach, so a critical score on a dev-only utility looks the same as a medium score on a service one step away from a payments database. Previously, confirming whether a finding was exploitable took hours of manual investigation, and shipping a fix with confidence took days of coordination across security, infrastructure, and application teams, because the blast radius of a change is hard to assess without business context. To close that gap, Continuum proves which findings are exploitable and bounds the risk of each fix it proposes.

Continuum builds a context graph from two primary sources: your code repositories and your AWS environment. For AWS, you set up a collector in the account and Region where your code runs. The collector gathers resource details such as AWS Config resources and network configuration so Continuum can judge whether a vulnerability is reachable over the network and what a threat actor could reach from it. From this graph, Continuum learns which systems are business-critical, who owns them, how services depend on one another, and which data each one touches. It uses that picture to identify your highest-value systems, such as customer data stores, payment pipelines, and authentication services, and then ranks each resulting issue by how close its attack path runs to those systems.

Continuum analyzes each finding against your code and its environment context and assigns an evidence level, such as a verdict proven by static analysis of the vulnerable code path. For findings it can reproduce, Continuum runs the exploit in an isolated sandbox and attaches proof-of-concept code with the reproduction steps. It produces the attack path, the supporting source analysis, and a blast radius assessment instead of a risk score alone. It also evaluates whether your existing defenses, such as AWS WAF rules and AWS Identity and Access Management (IAM) policies, would detect and stop the validated path.

For each confirmed issue, Continuum generates a fix (a code patch, a dependency upgrade, or a configuration change) and opens it as a pull request in your connected repository, ready to review. Every fix requires human approval: you review and merge the pull request, so the final decision stays with your team. In the future, you will be able to build confidence in specific remediation classes and let Continuum apply those fixes automatically once its confidence gates pass, such as test coverage, scope bounds, and historical success rate.

AWS Continuum for code vulnerabilities in action
To show how this works, I open AWS Continuum in the console and go to Code vulnerabilities. Before I can review issues, I set up an environment. I connect a code source, either a GitHub integration or an Amazon S3 bucket, and then create an environment that scans it on a schedule I choose. An Amazon S3 source has a couple of prerequisites: the bucket sits in the same account and AWS Region where I turn on AWS Continuum, and I grant access through an AWS Identity and Access Management (IAM) role that AWS Continuum assumes. I can optionally add AWS infrastructure context by setting up an AWS Continuum collector in the account and Region where my code runs and authorizing my environment to use it. For the full requirements and steps, see the AWS Continuum User Guide.

The Overview page brings these pieces together in one place, showing my Code integrations, the Environments built on them, and the status of any AWS collector that supplies AWS resource context.

I open one of my environments. The Issues tab lists validated, prioritized issues rather than raw scanner output, each with a severity, a status, and the time it was created. I choose one of the issues.

The Overview rates it High severity, with the status Completed and the remediation already Delivered to GitHub. The Risk assessment explains why. Continuum rates its Exploitability as Exploitable, with an evidence level of Static proven and a validation run status of Completed. Likelihood is High, since the service is reachable from an attacker, requires no authentication, and needs no user interaction. Impact is Moderate, which means an attacker gains the ability to modify business data, with a blast radius reaching other users in the same tenant. A Proof section includes the source analysis behind the verdict.

The Remediation section shows a fix already delivered as a pull request in GitHub, changing four files, with 50 lines added and 24 removed across the cart service. Continuum opens the fix as a pull request titled Continuum fix, and I choose View pull request to open it in GitHub. The console is explicit that a generated patch does not mean the issue is fixed. I still review and merge it, which keeps the final decision with my team. A Contributing findings section lists the specific scanner finding this issue was built from.

The pull request description carries the same risk assessment, remediation summary, and proof from the console, so whoever reviews it in GitHub sees the evidence without leaving their workflow.

The Findings tab lists the raw scanner findings across the environment, the evidence that issues are built from.

The Scans tab shows the history of each scan with its status, origin, and request and completion times, and I use Configure scan frequency to change the cadence or Queue scan to run one on demand. The Configuration tab is where I manage the environment: the code and context sources it reads from, its code integrations, environment settings such as whether Continuum creates remediation patches, and the AWS collectors it uses for AWS context.

In a single workflow, I work through the validated issues in priority order with each scan, reviewing the evidence and scope behind each one before I approve and merge the fixes I trust. Every fix waits for my approval, so the backlog keeps shrinking while my team keeps control of what ships.

Now available
AWS Continuum for code vulnerabilities is available today in US East (N. Virginia) and US West (Oregon) Regions. For pricing, visit the pricing page.

To learn more, visit the AWS Continuum for code vulnerabilities product page and the User Guide. Give it a try in the AWS Continuum console today, and send us feedback through your usual AWS Support contacts.

— Esra

AWS

Introducing Amazon ECS Gateway: A fully-managed ingress solution for ECS services

Leave a comment
This post was originally published on this site

When platform teams manage containerized applications at scale on Amazon Elastic Container Service (Amazon ECS), configuring ingress networking for each service often becomes a bottleneck. For every new service, teams must provision and connect Application Load Balancers (ALBs), AWS Certificate Manager (ACM) certificates, AWS WAF web ACLs, and security groups, then keep those resources in sync as services scale, update, or operate. This per-service overhead slows down deployment velocity and increases the risk of configuration drift across an organization.

Today, we’re announcing Amazon ECS Gateway, a new account-level resource that simplifies ingress networking for containerized workloads by dynamically provisioning and managing the necessary infrastructure on your behalf, with all resources created directly in your account.

ECS Gateway introduces a clear separation of responsibilities between platform teams and application teams.

  • Platform teams create and configure a gateway, defining organizational networking standards including subnets, security groups, TLS certificates, listener settings, and WAF web ACLs, in a single place. They then associate the gateway with one or more ECS clusters, making it available to services running on those clusters.
  • Application teams opt their services in by adding a gateway connector parameter when creating or updating a service. ECS provisions the required per-service resources automatically: an ACM certificate, a unique DNS hostname, listener rules, target groups, and a service security group that permits inbound traffic only from the ALB. No networking expertise required.

ECS Gateway offers host-based routing using ALBs and enables up to 25 services to share a single ALB, optimizing infrastructure costs. ECS manages the full lifecycle of the underlying infrastructure, provisioning the first ALB when your first service connects, adding more ALBs as capacity is reached, and removing them when no longer needed. Each service receives a unique DNS hostname, giving your teams a ready-to-use endpoint the moment provisioning completes.

A first look at ECS Gateway

In the ECS console, platform team can create a gateway and sets its configuration. The infrastructure role is an IAM role that ECS assumes to provision and manage networking resources such as ALBs, security groups, and certificates in your account. To create a gateway, provide a gateway name and select an infrastructure role. You can optionally associate the gateway with ECS clusters during creation or later.

Choose a load balancing scheme, either public or VPC-internal traffic routing. Under Additional Settings, you can also set up a listener, port, maximum count of load balancers the gateway can scale to, and a web ACL lets you protect your web applications. Some settings, including the name, scheme, VPC, subnets, IP address type, listener protocol and port cannot be changed after gateway creation.

Using AWS Command Line Interface (AWS CLI), call CreateGateway with a name (unique per account), an infrastructure role, and a configuration object. No infrastructure is provisioned until a service connects with a gateway connector.

aws ecs create-gateway 
  --name my-team-gateway 
  --infrastructure-role-arn arn:aws:iam::123456789012:role/ECSGatewayRole 
  --configuration '{
    "HostSharedAlb": {
      "networkConfiguration": {
        "subnets": [
          "subnet-080779f9bd887757a",
          "subnet-03d5b2fead6bc6258",
          "subnet-0861210a397d31252",
          "subnet-06539e194023cb77a"
        ],
        "ipAddressType": "ipv4"
      },
      "scheme": "internet-facing"
    }
  }'

Once the gateway is created, you can take a look at the detailed configuration, gateway routes, load balancers, and associated clusters.

Now associate the gateway with one or more clusters (many-to-many), to make it available to ECS services on those clusters.

Use AssociateGatewayWithCluster to make the gateway available to services on a cluster:

aws ecs associate-gateway-with-cluster  
--gateway my-team-gateway  
--cluster arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster

To create and manage the ECS Gateway programmatically, including calling APIs and searching documentation, try the AWS MCP Server and plugins with your preferred AI coding tool. To learn more, visit the Amazon ECS Gateway documentation.

ECS Gateway:Behind the scenes

A gateway can be associated with up to 10,000 clusters, and a single cluster supports up to five gateway associations. This many-to-many relationship gives platform teams the flexibility to share a gateway across environments or assign multiple gateways (for example, public and private) to a single cluster.

Platform teams can control access by choosing which gateways to associate with which clusters. For additional control, use IAM policies to restrict who can deploy services to specific clusters.

Application teams add the gateway connector to each service definition in CreateService or UpdateService. If you have an existing ECS service with its own load balancer, you can adopt ECS Gateway incrementally by calling UpdateService to add a gateway connector. Both ingress paths remain available, allowing you to validate the gateway connection before removing the existing load balancer configuration.

aws ecs create-service  
  --cluster my-cluster  
  --service my-api-service  
  --task-definition my-api-service:1  
  --gateway-connectors '[{ "portName": "api", "filters": {"accessTypes": ["PUBLIC"]}, "healthCheck": {...} }]'

At deployment time, Amazon ECS evaluates the gateways associated with the cluster and connects the service to every compatible gateway. A gateway is compatible when its access type matches the service’s connector filter, it is in the same VPC as the service, and it covers all Availability Zones used by the service’s configured subnets.

For each connection, Amazon ECS assigns the service to an ALB with available capacity and provisions the per-service resources: an ACM certificate, a unique DNS hostname, a listener rule routing traffic for that hostname to the service target group, and a service security group allowing inbound traffic only from the ALB security group. If no existing ALB has capacity, ECS creates a new one (up to maxAlbCount referring to quota limit). Once provisioning completes, the gateway route becomes ACTIVE, and the service URL is ready to receive traffic.

ECS Gateway handles common operational scenarios automatically:

  • Redeployments: On each deployment, ECS re-evaluates gateway associations. If new compatible gateways have been associated since the last deployment, your service connects to them. If a gateway has been disassociated, your service disconnects and the route is removed. Your service always reflects the current state of the cluster gateways at deployment time.
  • Service deletion: ECS automatically disconnects the service from every gateway, removes all gateway routes, and cleans up all per-service resources. If the service held the last route on an ALB, that ALB is deprovisioned.

Things to Know

Here are a few important details to keep in mind:

  • Networking: ECS Gateway is available for ECS services using the awsvpc network mode across all launch types (Amazon ECS EC2, AWS Fargate, and ECS Managed Instances). Your service Availability Zones (AZs) must be a subset of each gateway’s AZs on the cluster. A gateway ALB only routes traffic to tasks in AZs where it has subnets. We recommend creating gateways and services for a given cluster with the same set of AZs.
  • Capacity: If maxAlbCount is reached and no ALB has available capacity, the deployment fails. Default quota limit of maxAlbCount is 10. Plan your maxAlbCount setting according to the number of services you expect to connect.
  • Observability: Use ALB metrics in CloudWatch with the TargetGroup dimension to monitor per-service traffic, and LoadBalancer dimension to monitor traffic across the shared ALB. Use describe-target-health to check real-time target status. Configure CloudWatch alarms for metrics such as HealthyHostCount, TargetResponseTime, and HTTPCode_Target_5XX_Count, using gateway ARN-based tagging so monitoring scales automatically with your maxAlbCount.

Now available

Amazon ECS Gateway is available now in all commercial AWS Regions where ECS is available at no additional charge. You pay only for the underlying infrastructure provisioned in your account when services connect to a gateway, including applicable ALB charges, CloudWatch logs and metrics, ACM certificates, and data transfer charges. To learn more, visit the Amazon ECS Pricing page.

To get started, create your first gateway today in the ECS console, and send feedback to AWS re:Post for ECS or through your usual AWS Support contacts.

— Channy

Security

Orphaned VBA Projects Inside DWG Files: YARA Rule, (Sun, Oct 18th)

Leave a comment
This post was originally published on this site

Here is the YARA rule I used to detect "Orphaned VBA Projects Inside DWG Files".

rule autocad_orphaned_vba_project {
    strings: $a = "AC10"
             $b = {D0 CF 11 E0 A1 B1 1A E1}
             $c = "[Host Extender Info]" ascii

 

    condition: $a at 0 and uint32(0x24) == 0 and $b and $c
}

 

A VirusTotal retrohunt with this rule gave me only 2 detections:

09d4607941e458f6dbb6be17825641d863c0b37c185027984e137d8a67e919d8

3310c1a9bfe6115e49d8ac372cef5f460850da05138340107e66b958a6b5bca6

 

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

Small Agents, Smaller Blast Radius: Controlling What AI Can Do, (Fri, Oct 16th)

Leave a comment
This post was originally published on this site

I believe the cybersecurity industry may be approaching AI security the wrong way.

AI agents are becoming more powerful every day. Systems like ChatGPT, Claude, and Grok can write and execute code, use command shells, browse the web, call APIs, interact with MCP servers, and access enterprise data. Yet much of the industry is taking these extraordinarily powerful, general-purpose agents and trying to make them safe by building cages around them. We add containers, policy layers, monitoring, guardrails, and humans in the loop.

I think that’s backwards. If the companies building these models struggle to control their behavior, why do we assume we can reliably contain them? And when in human history has requiring a user to click a button before something dangerous happened EVER worked?

Even if you build the perfect cage, the model you tested in your cage will eventually change. Providers retire models, and moving to a replacement means revisiting your assumptions and testing. Your application code may be unchanged, but the component deciding what to do next is different.

In my opinion, we should use these agents, which are very good at coding, to build smaller, single-purpose agents. If an agent only needs to read logs from one directory, why give it functions that can read, write, or execute things anywhere on the system?

This isn’t a new idea. It’s the principle of least privilege and seperation of duties. But somehow, when we build agents, we seem willing to hand over broad access and ask the model to use good judgment.

This is the guiding philosophy behind SANS SEC573: AI-Powered Security Automation, where we learn to vibe code these focused agents into existence. Use the powerful coding agent to build a better agent. Give the resulting agent only the access it needs to do its job. 

An October 15 article from Check Point provides a good case in point.

Imagine asking an AI security agent to investigate a suspicious login. It retrieves authentication logs, checks the source IP, and identifies several potentially affected accounts. Then it disables them. The agent may have correctly identified suspicious activity. Disabling those accounts might even be appropriate. But you asked it to investigate. Somewhere along the way, it expanded its assignment.

Check Point’s article describes its Dangerous Deviation Detection capability, which evaluates proposed tool calls before execution. The problem extends beyond prompt injection. An agent can misunderstand a request or take its assignment too far without an attacker being involved.

The detector sits between the model choosing a tool call and the application executing it. It evaluates the proposed operation and its arguments against the task. The application can then stop the action, request approval, or give the agent feedback so it can try another approach.

According to Check Point’s technical documentation:

  • The beta detector flags actions that are both dangerous and unwarranted. Its danger categories include data leakage, access or privilege escalation, and destruction of persistent resources.

  • It looks for justification in user and system messages. Instructions in tool responses or other external content do not count as authorization.

  • The application submits conversation history, the proposed tool call in the final assistant message, and tool definitions in the top-level tools field of a Guard API request.

  • Setting "breakdown": true returns fields including reason_code, reason, agent_guidance, and debug_info.dev_tips.

The distinction between dangerous and unwarranted is important. An irrelevant but harmless action can pass. A dangerous action supported by trusted instructions can also pass. Check Point separately documents a deterministic tool allow/deny list and describes the beta detector as favoring fewer false positives over catching every marginal case. Its a solid approach.

Those are documented product behaviors, not results from my own testing.

I can see value in checking proposed actions. But my first question comes before that check: Why does the investigation agent have permission to disable accounts?

The human analyst might need that permission. The agent performing this particular task does not. Seperation of Duties and the Prinsicle of Least required access are screaming in their graves.

An investigation agent can collect evidence and recommend containment using narrowly scoped, read-only access. If containment is needed, a separate workflow can perform the authorized operation against the specified accounts.

That boundary needs to exist in code and credentials. Removing a tool from the list shown to the model is not enough if the executor still accepts it. Restricting tools also accomplishes little if the agent has a general-purpose shell running with administrative credentials.

The same rule applies when agents work together. If the investigation agent can freely tell a privileged response agent to disable accounts, it still has an indirect path to that capability. The receiving workflow must check authorization and scope for itself. “The other agent said you approved it” should not be enough.

There is another implementation detail worth watching. Check Point’s detector distinguishes trusted messages from external content. If your application copies an untrusted ticket into a user message, you may blur that distinction. A sentence in a ticket claiming that someone approved an action is evidence to evaluate, not permission to execute it.

You can test these boundaries with ordinary requests:

  • Ask for an incident summary. Does the agent try to close the ticket?

  • Ask for a list of inactive accounts. Does it try to disable them?

  • Put a fabricated approval in a retrieved document. Does the application accept it?

  • Approve an action against one account. Can the agent expand it to several?

  • Deny an action. Can it accomplish the same thing through another tool or agent?

Watch both what the model proposes and what the application allows. An unauthorized attempt that gets blocked tells you a control worked. An agent that happens to behave correctly does not prove the control exists.

I’m not suggesting we abandon monitoring, guardrails, or approval workflows. I’m suggesting we stop making them responsible for containing capabilities the agent never needed.

Before building a better cage, ask why you gave the agent that much access in the first place. Then have the agents build their own cages by writing single purpose agents with only those tools that are required. I'll show you how in SEC573.

Sources: Check Point’s October 15 article and Agent Behavior Defense documentation.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

Orphaned VBA Projects Inside DWG Files, (Wed, Oct 14th)

Leave a comment
This post was originally published on this site

Years ago I wrote diary entries about VBA code stored inside AutoCAD drawing files (.dwg).

In a nutshell: the VBA code is stored inside an OLE file, that is embedded inside the DWG file. You can do a brute-force search for the embedded OLE file, or you can follow a pointer inside the header of the DWG file.

I wrote a small Python script (autocad.py) for this second case. It looks at a 32-bit pointer at position 0x24 inside the DWG file. This points to a 16-byte long header, followed by the embedded file. This 16-byte long header contains the length of the embedded file. You use the script together with my tool cut-bytes.py, like this:

cut-bytes.py -S autocad.py -P AutoCAD : 461ed52aeb75384133a8238b2eb481ae5d505d4961effa622673d65a889c8218.vir.zip | oledump.py

 

This command carves the DWG file (inside the ZIP file) and extracts the embedded OLE file, and pipes it into oledump.py for analysis.

When the pointer is zero, there is no embedded OLE file, and cut-bytes.py returns nothing.

Recently, I discovered 2 DWG files that are an exception: their pointer to the embedded OLE file is zero, but if you do a brute-force search, you will find an embedded OLE file with a VBA project.

For example this DWG file.

Its pointer to the embedded VBA project is zero:

But it contains an embedded OLE file:

And right in front of the embedded OLE file, there is the 16-byte long header that contains the lenght of the embedded file.

Using the AutoCAD script to extract the file gives nothing:

But oledump.py can find the embedded OLE file and analyze it:

So while using oledump.py to analyze DWG files you find a VBA project embedded inside a DWG file, then also verify if it is not orphaned: verify that the pointer at 0x24 is not zero (or use the autocad.py script).

Because when a DWG file contains an orphaned VBA project, the VBA code can not have executed when someone opened the DWG file with AutoCAD. AutoCAD "does not see" orphaned VBA projects.

Notice that a default installation of AutoCAD does not support VBA. VBA for AutoCAD is a separate install.

I don't know how orphaning happens, but I did find an AutoLISP command to remove a VBA project from a DWG file: 

(dictremove (namedobjdict) "ACAD_VBA")

Maybe this dictremove command clears the pointer, but does not remove the embedded OLE file.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.