Security Boulevard

With every new year bringing new technologies, expanding attack surfaces, and legions of salivating threat actors.

The post Early Trends in 2025 appeared first on Security Boulevard.

The post Achieving PCI DSS 4.0.1 Compliance for  Companies (SAQ A-EP): A Comprehensive Guide for Feroot PCI PaymentGuard AI appeared first on Feroot Security.

The post Achieving PCI DSS 4.0.1 Compliance for  Companies (SAQ A-EP): A Comprehensive Guide for Feroot PCI PaymentGuard AI appeared first on Security Boulevard.

Learn how DataDome built DomeScribe, a Slackbot that automates post-mortems in Notion. Follow our step-by-step guide to build your own AI agent for incident management.

The post How DataDome Automated Post-Mortem Creation with DomeScribe AI Agent appeared first on Security Boulevard.

Time to Declare an Emergency? Scrotes chain three flaws to take full control—seems pretty easy.

The post PAN-PAN-PAN-OS: Palo Alto Firewalls Under Attack (Again) appeared first on Security Boulevard.

via the inimitable Daniel Stori at Turnoff.US!

Permalink

The post Daniel Stori’s Turnoff.US: ‘Ubuntu Updates’ appeared first on Security Boulevard.

by Source Defense A newly discovered payment card skimming campaign has emerged exhibiting a concerning level of sophistication and leveraging unique tactics that make detection highly challenging. The attack, identified by Source Defense researchers, employs an innovative technique that exploits Stripe’s deprecated API to verify card details before exfiltration – ensuring that only valid payment

The post Sophisticated Payment Card Skimming Campaign Conceals Itself by Leveraging Stripe API appeared first on Source Defense.

The post Sophisticated Payment Card Skimming Campaign Conceals Itself by Leveraging Stripe API appeared first on Security Boulevard.

Authors/Presenters: Mark Foudy

Our sincere appreciation to DEF CON, and the Authors/Presenters for publishing their erudite DEF CON 32 content. Originating from the conference’s events located at the Las Vegas Convention Center; and via the organizations YouTube channel.

Permalink

The post DEF CON 32 – Exploiting Voice Cloning In Adversarial Simulation appeared first on Security Boulevard.

During red team operations, stealth is a critical component. We spend a great deal of time ensuring our payloads will evade any endpoint detection and response (EDR) solution, our traffic is obfuscated and hard to trace, and our commands will interact with a system in a way that limits the number of possible detection opportunities based on our actions that could thwart our operation; however, even when tiptoeing around a client environment, we have likely all experienced a scenario where we happen to list the wrong directory, read the wrong file, or access the wrong registry key and set off an alert to the Security Operations Center (SOC) to get an investigation rolling. I am, of course, talking about that pesky system access control list (SACL) that made a simple Windows event to let the SOC know someone tried to access something they should not.

DACL vs. SACL

If you have spent some time in the field, you are likely familiar with DACLs and SACLs, but I will do a quick recap to refresh some minds and educate the rest. We will start with the securable object. From Microsoft’s documentation: “A securable object is an object that can have a security descriptor. All named Windows objects are securable. Some unnamed objects, such as process and thread objects, can have security descriptors too.” So, any securable object can have a security descriptor applied to it that can contain access control lists (ACLs). We are talking about files, registry keys, processes, pipes, services, etc. The ACLs within the security descriptor come in two flavors: discretionary access control lists (DACLs) and SACLs.

Most people are more familiar with the DACL, which determines whether a security principal attempting to access a securable object in question is allowed to do so based on allow or deny entries. This is done based on several factors in the access token, but in short, we can equate it to the doorman at a bar. A user attempts to access the bar and presents their ID to the doorman, then the doorman checks their ID and allows or denies them entry based on the information provided. SACLs, on the other hand, are more like a logbook. They are not determining access; they only log whether the security principal succeeded or failed to access the securable object. We can think of this as a scribe standing next to the doorman at the bar, writing down the names of every person who attempts to access the bar and whether the doorman allows or denies them.

We have seen the use of these technological trip flares increasing lately. While the increase in SACL usage is not bad, it does mean that we need to be even more careful about what we access in an environment. Honeypot accounts in Active Directory (AD) can catch the use of tools like BloodHound when it tries to read an AD object that no one was intended to read, the registry could be watched to see if an attacker tries to access local security authority (LSA) registry keys, or it could be as simple as a “password” file on a share set to let defenders know if someone tries to access some suspiciously sweet administrator credentials. As organizations and defenses mature, it is becoming more crucial for red teamers to know what we should not risk touching.

Enter SACL Scanner

To help with this, and learn C along the way, I created a simple C program called SACL_Scanner to aid fellow red teamers in identifying the configured trip flares so we can avoid them. Currently, it will scan for SACLs on three local Windows securable objects and AD: registry keys, services, files/directories, and AD objects. It is also compiled to run with execute_pe in most C2 frameworks since it is much more likely that a red teamer will be in that scenario rather than directly on a host running programs.

Before we get into the demos, we need to talk about the obvious barrier to what we are trying to achieve: privileges. We will need the SE_SECURITY_NAME privilege corresponding to the objects we are trying to read. This means that we must be at least an administrator or have the SE_SECURITY_NAME privilege assigned to our access token. It is likely that when you are really worried about SACLs on other users’ files, registry keys for the security account manager (SAM), or mucking with services on the local host, you are already an administrator; ergo, it should not be too much of an issue there. However, when trying to read the SACLs on AD objects, we run into a bit of a catch-22 in that we might want to know what objects we should not touch so we can execute an attack path in AD to elevate our access therein, but we need elevated permissions to read the SACLs on AD objects to know which objects we should not touch. Sadly, I do not have a solution for that as that is AD working correctly. Nevertheless, we can still obtain additional information once we have elevated our access, tread lightly, and limit our indicators of compromise (IOCs).

Additionally, something the tool is not going to do is let you know the status of whether auditing itself is enabled. SACLs are two parts that combine to make event logs for detection: the SACL itself on the securable object and the computer audit policy settings determine whether the logs themselves are generated. Both of these must be enabled for a SACL to provide any value. If the SACL is set on an object but auditing is not enabled, the SACL does not really matter. Conversely, if auditing is enabled but nothing has a SACL set, then auditing is not generating anything. One could argue this is only partially true as there are objects such as LSASS that have SACLs set by default, but we will not get into that list here as Microsoft does not make it readily available. In our case, to reiterate, we are only checking for SACLs themselves on securable objects here; not whether auditing is enabled.

For demo purposes, I am running a simple Windows environment with a single workstation and domain controller (DC). For my command and control (C2) framework, I am using the Mythic framework with a Merlin agent running on the workstation. In this case, the agent runs under the context of an elevated user to show the output. Also, forewarning, I will not be covering covert techniques themselves but rather a down-the-middle use case to focus on the tool and output itself.

Alright; now that the background, summary, and requirements are complete, let’s get into the simple demos. We will start with the registry. There is so much information available to us in the registry that we are almost guaranteed to interact with it in some way during an assessment, whether it is intentional or not. But where do we want to start our testing to see which important registry (sub)keys defenders might be watching? Thankfully, one of my defensive cohorts, Luke Paine, already made a sample list in his post of The Defender’s Guide — The Defender’s Guide to the Windows Registry. Included in his detailed coverage of registry SACLs, he provided a .csv file with a list of keys and the registry operation to watch: Highly Targeted Registry Keys.csv. Let’s start with a few items in this list to test our SACL setup in a lab.

The following few pictures show the setup of the audit policies and SACLs so we can conduct testing. If you are unfamiliar with setting this up, you can think of it as a little guide to setting SACLs in your environment. First, for our local host, we go into Local Security Policy, then Local Policies > Audit Policy, and ensure that Audit object access is enabled (Figure 1).

Figure 1 — Audit Object Access Enabled

Next, we can start setting up some SACLs. We will use the HKLM\SYSTEM\CurrentControlSet\Services registry key referenced in the Defender’s Guide. For simplicity, open regedit.exe, browse to the key, right-click, and select Permissions (Figure 2).

Figure 2 — HKLM\SYSTEM\CurrentControlSet\Services Permissions

Select “Advanced” in the security permissions window (Figure 3).

Figure 3 — Security Permissions Window

Next, select auditing. If you are unfamiliar with the basic setup of the advanced security window, the permissions tab will show and set DACLs, auditing handles SACLs, and effective access is, as it sounds, testing the access of the account you ask it. In my case, you will see that I have set a SACL to audit anyone in Authenticated Users accessing this registry key (Figure 4).

Figure 4 — Advanced Security Settings

If we select the SACL, we can see the principal again; the type is set to success auditing, applies to this key and subkeys (inheritance set), and audits on Set Value and Create Subkey (Figure 5).

Figure 5 — SACL Settings on Registry Key

Now that we have our test SACLs set, we can pick a service to modify and ensure it works. In my case, I went with the OneSyncSvc and decided to change the ImagePath to set up some simple persistence (Figure 6).

Figure 6 — OneSyncSvc Registry Keys

Before we start the SACL testing, we open the Windows Event Viewer, navigate to Windows Logs > Security, and set a filter on Windows event ID (EID) 4663: “An attempt was made to access an object” (Figure 7). I just cleared them up to make sure we have a fresh list.

Figure 7 — Event Viewer Filtered

In our elevated Merlin agent, we use a simple run sc config command to modify the binPath of the service OneSyncSvc to instead point to a payload (Figure 8).

Figure 8 — Service Modification

After the command, we can double-check that the service changed by refreshing our regedit and see that the ImagePath has changed for OneSyncSvc (Figure 9).

Figure 9 — ImagePath Changed

In Event Viewer, we now have a new EID 4663 (i.e., “An attempt was made to access an object”) stating that NT AUTHORITY/SYSTEM accessed the registry key HKLM\SYSTEM\CurrentControlSet\Services\OneSyncSvc (Figure 10). This event is our expected result since we had the SACL set to audit any access and inherit it from Services, so we catch modifications on all services. Opening the event, we see that the requested access was Set key value, corresponding to our modification (Figure 11).

Figure 10 — Event 4663 Logged Figure 11 — Access Requested: Set Key Value

We can double-check things like this ahead of time to prevent tripping the SACL with this simple SACL_Scanner tool. It works with execute_pe (and Octoberfest7’s inline-execute-pe). Running this tool with the “-r” flag followed by the key we want to target will give us the desired information. It will scan the entire hive if we target a hive itself (HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER). We check whether an item has any SACLs, if it is a direct or inherited SACL, and the SACL info we desire to let us know what is being audited (Figure 12). Now, depending on how the SACL is set up, this is not full proof to check without being detected, but I will go into further details on this in the detection section.

Figure 12 — Registry Services SACL_Scanner Result

Now, let’s check OneSyncSvc directly. It tells us there is a SACL applied to the key but does not give us details on it (Figure 13). This is intentional since it is an inherited SACL. It will display direct SACLs when requested, but inherited SACLs will only display when the verbose flag (-v) is added so we do not get too much information when scanning multiple items.

Figure 13 — Registry OneSyncSvc SACL_Scanner Result

Rerunning the command with the “-v” flag gives us the complete information we want and some additional security identifier (SID) information (Figure 14).

Figure 14 — Verbose Registry Key Check

Adding the “-opsec” flag allows us to run an additional check to determine if the SIDs within the SACL match any SIDs applied to our current access token. We can see that we have a detected match in this case, which lets us know that we should avoid modifying this registry key further, or we would trip the SACL (Figure 15). Note: a known limitation of this is that the tool compares the SIDs in the access token to the SACL, which means any nested groups that would not be added to the access token will not come back as detected since we are not unrolling groups here.

Figure 15 — SACL OPSEC Check

Now, let’s check the SAM SACL to see if dumping the SAM would get us burned. We can start by setting a SACL on HKLM\SAM with the same steps. When we try to access a key under HKLM\SAM, an event log lets us know someone has tried to access those keys (Figure 16).

Figure 16 — HKLM\SAM SACL Event

When checking HKEY_LOCAL_MACHINE\SAM with SACL_Scanner, we get the info we want to see, letting us know there is a SACL set and that we should avoid dumping the SAM (Figure 17).

Figure 17 — HKLM\SAM SACL_Scanner Check

I will run through some of the other flags pretty quickly as they should be understood pretty easily. Using the “-f” flag followed by a file on the host or share will similarly check the SACLs (Figure 18).

Figure 18 — File SACL Check

Next, we can use “-d” to instead feed it a directory to check the files therein. Notice that we have multiple files here and only one has SACLs applied (Figure 19). Sometimes we can judge based on names and settings. In our example below, we can see that there is a SACL directly applied to my tongue-in-cheek mock honeypot file to alert on reading the file; however, the server_PWs.txt file right above it has none. We can infer that I might not want to touch the more tempting file if I can avoid it.

Figure 19 — SACL_Scanner Directory Check

If we throw the “-opsec” flag into the directory listing, we first check the directory itself to see if we should list files. If we trip a SACL while enumerating file SACLs, we will skip it (Figure 20). This check is nice with a targeted directory but even more important when we use just “-d” without a supplied directory, which will scan the entire C:\ drive.

Figure 20 — Directory SACL Check

Also, while I have not seen it much, we can scan services with “-s.” The flag by itself will check all services, or we can add a specific service to target (Figure 21).

Figure 21 — SACL_Scanner Service Check

Now, on to some AD checks. We start by ensuring the Audit Policy on the domain controller has “Audit directory service objects” enabled (Figure 22). We do not necessarily need it for our SACL checks, but it is good to include it if anyone needs the extra step to help turn on SACL eventing.

Figure 22 — Enabled Directory Object Auditing

As I stated earlier in the post, the major blocker in reading the AD SACLs is simply having the privilege to read the SACLs objects. I know it’s a bit counterproductive and, sadly, this means that we cannot collect them like we do DACLs with a tool like SharpHound. As such, it will likely be of better use if you try to establish domain persistence versus finding an attack path to rise to the top. The flags should make sense based on what we covered. We add the “-a” flag to target AD followed by the “LDAP://{distinguished name}” of the object we want to target. Adding the “-opsec” flag will again check our SIDs to see if we would trip the SACL, and there is a hash map (the reason the file is a bit big) with the GUIDs mapped to user object class attributes. In our case below, we can see that there is a SACL applied to specterDA, which will trigger on writing to the msDS-KeyCredentialLink attribute (Figure 23). If we have not done shadow credentials so far during our assessment, we know we should not try to do that as our persistence on this DA account.

Figure 23 — Domain Admin Check

While the hash map covers those user object class attributes, we can still obtain the SACLs on other objects, like the data protection API (DPAPI) domain backup key. Running the scanner targeting that in my little test lab provides a sample output of no SACLs applied, so we should be fine in a SACL sense to backup that key and do what we need to from there (Figure 24).

Figure 24 — Domain Backup Key Check Detections

When dealing with SACLs, there will be some fallibility in interacting with a securable object to get the information. The SACLs I commonly see on objects are auditing either modifications of an object or reading the data in a file or registry key. The event log this generates on a host is EID 4663 (i.e., “An attempt was made to access an object”). While this event is the primary log SACL_Scanner is designed to identify in the hope of avoiding generating it, you can use additional logs to detect the tool. For example, we can use EID 4656 (i.e., “A handle to an object was requested”) to get the precursor information to EID 4663. We will still need to obtain the handle to interact with it and read the permissions when reading the object information. We can add “Read Permissions” or “Read Attributes” checks to the SACL to identify SACL_Scanner obtaining the handle to read the SACLs (Figure 25). There are pros and cons to this, as with anything in security, as adding these checks to the SACL will create many more events as standard Windows programs like explorer.exe do their essential functions.

Figure 25 — Event Generated by SACL_Scanner

Similarly, in AD, we try to avoid writing the wrong properties by identifying them first, but other SACLs can detect our access attempts. By setting SACLs on reading object properties, specifically the Public-Information property set’s Object-Class attribute containing the NT-Security-Descriptor, we can detect SACL_Scanner looking at the SACLs on an AD object. We can see the GUIDs in an EID 4662 log, showing that we are reading those properties (Figure 26) and comparing them to the Microsoft documentation (Figure 27 and Figure 28). Auditing reading AD objects will generate an immense amount of traffic, so going that route will need to be severely tuned to gain any real value from it.

Figure 26 — Event Generate by SACL_Scanner Reading AD Object Figure 27 — Public-Information Property Set GUID Figure 28 — Object-Class Attribute GUID

I am not a detection engineer, but to help with this I have made a basic Sigma rule that should help with detecting this tool and hopefully similar techniques.

https://medium.com/media/53b1ff29e754fe8d9a31fcbe2143b96c/href

That’s all for today. I hope this gives you a deeper understanding of how defenders are leveraging SACLs to detect unauthorized access attempts and how you can use SACL_Scanner to adapt your tradecraft accordingly. By being aware of these audit tripwires, you can fine-tune your enumeration, privilege escalation, and other techniques to remain stealthy.

Remember, effective red teaming isn’t just about bypassing defenses — it’s about continuously evolving alongside them. Stay proactive in researching new detection mechanisms, refining your OPSEC, and understanding the blue team’s perspective.

Until next time, stay sharp and tread carefully.

Don’t Touch That Object! Finding SACL Tripwires During Red Team Ops was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Don’t Touch That Object! Finding SACL Tripwires During Red Team Ops appeared first on Security Boulevard.

Cyber insurance used to be an optional safety net. Now? It’s a must-have. With ransomware, data breaches, and cyberattacks on the rise, companies need protection against financial losses. But here’s...

The post How CTEM Impacts Cyber Security Insurance Premiums? appeared first on Strobes Security.

The post How CTEM Impacts Cyber Security Insurance Premiums? appeared first on Security Boulevard.

Cybersecurity professionals continue to command high salaries, but there are rising concerns over career growth, workplace flexibility and retention in the industry, according to a report from IANS Research and Artico Search.

The post Cybersecurity Salaries Stay Competitive, Retention Challenges Persist appeared first on Security Boulevard.

CrowdStrike launched Charlotte AI Detection Triage, a platform based on agentic AI, which automates detection triage — the aim is to reduce workloads for security operations centers (SOCs).

The post CrowdStrike Charlotte AI Detection Triage Aims to Boost SOC Efficiency appeared first on Security Boulevard.

Dilemma of Traditional Automated Penetration Testing Penetration testing has always been the core means of offensive and defensive confrontation for cybersecurity. However, traditional automatic penetration tools face three major bottlenecks: lack of in-depth understanding of business logic, insufficient ability to detect logical vulnerabilities, and weak ability to link vulnerabilities. Although the passive scanning engine can […]

The post Build Your AI-Powered Penetration Testing Scheme with DeepSeek + Agent: An NSFOCUS Practice appeared first on NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks..

The post Build Your AI-Powered Penetration Testing Scheme with DeepSeek + Agent: An NSFOCUS Practice appeared first on Security Boulevard.

Versa Networks today announced the general availability of Versa Sovereign SASE (secure access service edge) deployment model.

The post Versa Networks’ Sovereign SASE Targets Nation-State Threats With On-Prem Architecture  appeared first on Security Boulevard.

Scytale earns its spot on G2's Best GRC Software Products 2025 list, solidifying our position as a top compliance and security leader.

The post Scytale Named a 2025 G2 Best GRC Software Winner appeared first on Scytale.

The post Scytale Named a 2025 G2 Best GRC Software Winner appeared first on Security Boulevard.

The team at CyberSaint is thrilled to announce the latest additions and updates to the CyberStrong solution. To start, we’re expanding Phase 1 of Asset Management with custom types and attributes. Additionally, we’ve added status updates, schedule, and pause for Continuous Control Automation (CCA) and included the ability to adjust the control weight by risk template or scenario. 

The post CyberStrong February Product Update appeared first on Security Boulevard.

Hi everyone, I’m Sergey Sobolev, a smart contract auditor and security researcher at positive.com. Our team specializes in smart contract auditing. Today, I will share the results of our team’s research and insights on auditing the security of smart contracts in FunC and Tact languages on the TON platform.

Where to start

It’s no secret that the TON blockchain differs significantly from the platforms commonly used in the industry. The first aspect I’d like to highlight is how transactions are processed in TON. All actions in the blockchain are accompanied by messages, which means that each function of your smart contract, when executed, processes a message, sends a response, or continues the chain of messages.

In TON, messages are executed asynchronously and independently of one another. This means that transactions consisting of messages exchanged between contracts can process several blocks, which leads to delays. The most unpleasant scenario is partial transaction execution, when your tokens have been debited but fail to reach the recipient due to an issue during the process. This happens because the programmer did not account for all possible scenarios or failed to add proper error handlers to the contract.

The first step in ensuring the security of a smart contract in TON is to draw all the message chains and assume that any message can fail. Then, consider: what would be the consequences of such a failure? What would cause the message to fail in the first place? What happens if there isn’t enough gas to process the entire chain? All these questions need to be answered.

For example, let’s examine the message chain diagram for the Jetton transfers, a standard token contract (TEP 74, FunC contract). In the diagram, blue circles represent contracts, white rectangles represent messages, red rectangle indicate bounced message, green rectangles indicate optional message (possible only if forward_ton_amount is not equal to zero), and yellow rectangles represent the message body with excess, which is sent only if there are TON coins left after payment.

If something happens when executing an internal_transfer message, the transfer amount will be deducted from the sender’s balance but will not be credited to the recipient. This can be called a partial fulfillment of the transaction. By using the on_bounce bounced message handler in the Jetton B wallet contract, it’s possible to return the deducted funds back to the sender.

Message flow in Jetton contracts

Now that we have a general understanding of how contracts handle messages, where exactly the messages go, and what entry points a hacker might exploit in the contract, we can move on to the code.

All input parameters should be checked carefully and thoroughly. While it’s impossible to check all data, you can catch errors during the examination of incoming messages and data. Is the authorization of incoming messages correctly configured in the contract? Sometimes, programmers simply forget to add it. Most often, they rely on the usual require, where the address is checked within a condition. The address can be calculated from the code and the data used when deploying the contract.

Jetton, for example:

cell calculate_jetton_wallet_state_init(
slice owner_address,
slice jetton_master_address,
cell jetton_wallet_code) inline {
return begin_cell()
.store_uint(0, 2)
.store_dict(jetton_wallet_code)
.store_dict(pack_jetton_wallet_data(0, owner_address, jetton_master_address, jetton_wallet_code))
.store_uint(0, 1)
.end_cell();
}

slice calculate_jetton_wallet_address(cell state_init) inline {
return begin_cell().store_uint(4, 3)
.store_int(workchain(), 8)
.store_uint(cell_hash(state_init), 256)
.end_cell()
.begin_parse();
}

The calculate_jetton_wallet_state_init function generates the initial state of the contract, and the calculate_jetton_wallet_address function calculates the address of the contract through hashing the initial state, which is obtained from the code in jetton_wallet_code and the variables packed into the cell via pack_jetton_wallet_data.

In Tact, things are much simpler. The example I took from here shows that the address calculation is performed in one line:

receive(msg: HiFromChild) {
let expectedAddress: Address =
contractAddress(initOf TodoChild(myAddress(), msg.fromSeqno));
require(sender() == expectedAddress, "Access denied");
// only the real children can get here
}

In addition, authorization requirements must not negatively impact the execution of smart contracts due to excessive centralization; this should be accounted for in the design of the business model from the very beginning. What measures does this model use to prevent contracts from being frozen or deleted?

One should pay attention to the processing of external messages (coming from the Internet) by the recv_external function in FunC smart contracts. It’s important to check whether the accept_message() function is applied only after all proper checks. This precaution helps prevent gas-sucking attacks, since once accept_message() is called, the contract pays for all further operations. External messages have no context (e.g., sender or value), 10,000 units of gas credit are given for processing, which is enough to verify the signature and accept the message. Of course, it all depends on the design of the contract, but if possible, it makes sense to write a contract in a way that avoids accepting external messages. The recv_external function is one of the input points that should be checked several times.

The asynchronous nature of the TON blockchain

After thoroughly analyzing the code, it’s helpful to revisit the diagrams and walk through them again, keeping in mind a few TON postulates:

1. Messages are guaranteed to be delivered, but the delivery time is not predictable.
2. The order of messages can only be predicted if messages are sent from one contract to another, in which case logical time is used.
3. If multiple messages are sent to different contracts, the order in which they are received cannot be guaranteed.

The figures below illustrate the message handling process very clearly.

Each message is assigned its own logical time. A message with a lower logical time will be processed earlier, so we can rely on the sequence of processing. However, if there are multiple contracts, it’s not possible to determine which message will be received first.

Suppose we have three contracts: A, B, and C. In a transaction, contract A sends two internal messages — msg1 and msg2 — one to contract B and the other to contract C. Even if they were created in the exact order (msg1 first, then msg2), we can’t be sure that msg1 will be processed before msg2. For clarity, the documentation assumes that contracts send back messages msg1' and msg2' after msg1 and msg2 have been executed by contracts B and C. This would result in two transactions going to contract A — tx2' and tx1'. As a result, there would be two possible outcomes:

1. tx1'_lt < tx2'_lt
2. tx2'_lt < tx1'_lt

Options for handling messages between contracts A, B, and C

The reverse works exactly the same way when two contracts B and C send messages to contract A. Even if the message from B was sent earlier than the one from C, it is impossible to determine which one will be delivered first. In any scenario with more than two contracts, the order of message delivery can be arbitrary.

Undefined order of message delivery from B and C to A

When examining message flow diagrams, we need to answer the following questions:

1. What happens if another process is running in parallel?
2. How might this affect the contract and how can this be mitigated?
3. Can any required values change while the message chain is executing?
4. What parameters or states of other contracts does this contract depend on?
5. How much do the operations depend on the sequence of message arrivals?

You should always expect intermediaries to appear during message processing. That is, if a property of a contract was checked at the beginning, you should not assume that it will still be checked by this property at the third stage. For the most part, the carry-value pattern protects against these issues. Is it being used appropriately to manage state between messages?

Common errors in TON

Let’s begin with the most obvious: never send private data (passwords, keys, etc.) to the blockchain. Blockchains are public, and any data stored on them can be compromised.

Another common issue is the processing of bounced messages. For example, in the case of Jettons, failing to handle bounced messages could result in tokens being sent into the void. In the TON Stablecoin project, there is a mechanism to process bounced op::internal_transfer messages, which are sent to Jetton-wallet when tokens are minted. Without such processing, the total_supply value will increase and would be irrelevant when minting, since the tokens would not arrive in the wallet and could not be in circulation.

Errors in formulas, algorithms, and data structures are common. For example, performing division before multiplication can cause a loss of accuracy, leading to rounding errors:

let x: Int = 40;
let y: Int = 20;
let z: Int = 100;
// 40 / 100 * 20 = 0
let result: Int = x / z * y;
// 40 * 20 / 100 = 8
let result: Int = a * c / b;

The code may also contain common errors, such as:

1. Duplicate code
2. Unreachable code
3. Inefficient algorithms
4. Poorly ordered expressions in conditional statements
5. Logical errors

Errors in data parsing

A replay attack is possible in TON. This happens because TON does not use one-time numbers for the address (like nonce in Ethereum) to ensure unique signatures. This feature is implemented in the standard wallets used to store and transfer TON. In these wallets, the wallet contract receives an external message with a verified signature, the sent seqno (similar to nonce in Ethereum) stored in the contract storage is also verified. Below is a list of the checks that a standard wallet performs before accepting a message:

throw_unless(33, msg_seqno == stored_seqno);
throw_unless(34, subwallet_id == stored_subwallet);
throw_unless(35, check_signature(slice_hash(in_msg), signature, public_key));
accept_message();

It is good practice to follow the carry-value pattern, which implies that a value is being passed, not a message.

For example, in the case of Jetton:

1. The sender subtracts the amount from their balance and sends it with op::internal_transfer.
2. The recipient accepts the amount via message and adds it to their own balance (or rejects it).

In TON, it’s impossible to get actual data through a request, because by the time the response reaches the requester, the data may no longer be up to date. Therefore, in Jetton it’s impossible to get the onchain balance, because while the response is on its way, the balance may have already been spent by someone else.

Alternate option:

1. The sender requests the balance of the Jetton wallet through the master contract.
2. The wallet resets the balance and sends it to the master contract.
3. The master contract, having received the funds, determines if they are sufficient and either uses them (by sending them somewhere) or returns them to the sender’s wallet.

This is roughly how you can get a balance. The same approach can be applied to all other data.

Keep an eye on how reads and writes are performed in cells, because inattention can lead to errors. For example, an overflow problem occurs when a user tries to store more data in a cell than it supports. The current limit is 1023 bits and 4 references to other cells. When these limits are exceeded, the contract returns an error with exit code 8 during the compute phase.

The underflow problem occurs when a user tries to get more data from a structure than it supports. When this happens, the contract returns an error with exit code 9 during the compute phase.

You can read about exit codes here.

// storeRef is used more than 4 times
beginCell()
.storeRef(...)
.storeAddress(myAddress())
.storeRef(...)
.storeRef(...)
.storeRef(...)
.storeRef(...)
.endCell() Random number generation in TON

As in EVM-like blockchains, validators can affect randomness, and hackers can calculate the formula for generating it. So you need to be smart about the code that requires it.

FunC has a random() function that cannot be used without additional functions. To add unpredictability to number generation, you can use randomize_lt(), which will add the current logical time to the initial value, causing different transactions to have different results. Alternatively, you can use randomize(x), where x is a 256-bit integer, essentially a hash of any data.

Using nativeRandom and nativeRandomInterval in Tact is not a good idea because they do not initialize the random number generator with nativePrepareRandom in advance. Tact uses randomIntor random respectively.

Problems with sending messages

Each contract receives messages and either continues the sending chain or responds to them. One must be sure that the message is formed correctly, i.e., all keys and magic numbers (flags, operating modes, and other parameters) correspond to the contract logic and do not lead to excessive depletion of its balance when forming the message. This is especially important with regard to storage fees: in TON, gas must be paid for every second that the smart contract is stored on the blockchain. However, it is not necessary to accumulate all unspent gas at the contract address. Instead, it’s better to properly design the contract logic so that any excess gas is returned to the sender when necessary. Keep in mind that running out of gas leads to partial execution of transactions, which can cause critical problems.

For example, if you remove the bounced message handler in the Jetton wallet contract, then in case of an error during token transfer (e.g., an exception occurred or gas ran out), this and subsequent steps will not be executed, and the deducted tokens will not be recovered — they will simply be burned. The transaction will only be partially executed. The same issue applies to the master contract in TON Stablecoin. During token minting, total_supply increases. However, if the message bounces and there is no handler, the total_supply value will be incorrect, because extra tokens that are not in circulation will be taken into account:

if (msg_flags & 1) {
in_msg_body~skip_bounced_prefix();
;; only bounced mint messages are processed
ifnot (in_msg_body~load_op() == op::internal_transfer) {
return ();
}
in_msg_body~skip_query_id();
int jetton_amount = in_msg_body~load_coins();
(int total_supply, slice admin_address, slice next_admin_address, cell jetton_wallet_code, cell metadata_uri) = load_data();
;; this subtracts the amount of the transfer from the total supply.
save_data(total_supply - jetton_amount, admin_address, next_admin_address, jetton_wallet_code, metadata_uri);
return ();
}

The documentation is the best resource for understanding how messages are generated. There may be cases where message modes are formed. It’s always a good idea to verify that the programmer has specified the bitwise OR operator accurately.

For example, in Tact:

// The flag is duplicated
send(SendParameters{
to: recipient,
value: amount,
mode: SendRemainingBalance | SendRemainingBalance
});

A dangerous practice is sending messages from a loop:

1. A loop may be infinite or have too many iterations, which can lead to unpredictable contract behavior.
2. Continuous looping without termination can result in an out-of-gas attack.
3. Attackers can use unlimited cycles to perform denial-of-service attacks.

Special attention should be given to the function responsible for sending messages. In the standard Tact library, there is a function called nativeSendMessage, which is a low-level equivalent of the send function. When using nativeSendMessage, one can make a mistake when forming a message. Therefore, it’s better to use this function only if the contract has complex logic that cannot be expressed in any other way.

Management of data storage

The TON blockchain does not support infinite data structures. In Solidity, there is the ERC-20 standard, which uses a single contract with address → balance mapping. In TON, the equivalent of ERC-20 is the Jetton standard, which is implemented as a system of contracts. Jetton consists of two contracts: jetton-minter.fc and jetton-wallet.fc. For each address, a wallet contract is created with the ability to send and receive tokens. The minter contract serves as the main contract, storing metadata and providing the ability to mint or burn tokens.

Jetton contract interactions

This scheme is dictated by the storage device in the TON blockchain, which is a cell tree. A cell tree does not allow mappings with complexity O(1), and it turns out that the size of the mapping affects the amount of gas spent: the larger the mapping, the more gas is needed to search for it. Therefore, you should evaluate all mappings and check if there is a way to remove data from them (e.g., via .del). Without a mechanism to clean or delete records, uncontrolled storage growth can occur.

So, is it just about avoiding bloating the contract storage? Not exactly. This information is more relevant for FunC than Tact, since in FunC the developer manually manages the storage. It’s crucial to check if the order of variables is correct when packing them into the repository. If a variable ends up in the position of another variable, the logic of the contract could break.. Another scenario is also possible: state variables may be overwritten due to variable name collisions or namespace contamination.

Almost all messages are handled using the following pattern:

() function(...) impure {
(int var1, var2, <a lot of vars>) = load_data();
... ;; handler logic
save_data(var1, var2, <a lot of vars>);
}

Unfortunately, there is a tendency for <a lot of vars> to be a simple enumeration of all contract data fields, which can result in a large number of fields in a line, which can be confusing. Therefore, when adding a new field to the repository, all the load_data() and save_data() calls will need to be updated, making it a time-consuming task. The result may be as follows:

save_data(var2, var1, <a lot of vars>);

In addition, one should not neglect a property of FunC known as variable shading. In general, this occurs when a variable in the internal scope is declared with the same name as a variable in the external scope that already exists. Accordingly, there is a possibility that a local variable will get into the repository. This can happen due to the re-declaration of variables in FunC:

int x = 2;
int y = x + 1;
int x = 3; ;; is equivalent to assigning x = 3

When considering efficiency, nested storage is a good practice. However, there is also a high probability of errors dealing with it. Nested storage refers to variables contained within other variables, which are only unpacked when needed rather than every time messages are processed:

()function(...) impure {
(slice mint, cell burn, cell swap) = load_data();
(int total_supply, int amount) = mint.parse_mint_data();
…
mint = pack_mint_data(total_supply + value, amount);
save_data(mint, burn, swap);
}

Use end_parse() when parsing a repository or message payload wherever possible to ensure that the data is processed correctly, so you can ensure that no unread data remains. In Tact, the endParse function returns an exception with code 9 (cell underflow), unlike empty, which returns true or false.

In Tact, it’s possible to add an optional variable value to the contract store, that is, a special value of null. If a developer creates an optional variable or field, they should use this functionality by referring to the null value somewhere in the code. Otherwise, the optional type should be removed to simplify and optimize the code:

contract Simple {
a: Int?;
get fun getA(): Int {
return self.a!!;
}
} Problems with code update

Code updating is one of the most convenient features of the platform. However, while it adds the ability to update the source code, it can also negatively affect the decentralization of the protocol. Imagine if the protocol creators tamper with the contract code or if someone hacks their multi-signature and changes the protocol. Importantly, updating the code does not affect the current transaction. The changes only take effect after successful execution.

The functions set_code and set_data are used to update registers c3 and c4 respectively. The set_data function completely overwrites the register. Before performing an update in FunC, one should ensure the code does not violate the existing data storage logic. Watch out for potential storage collisions and variable packing.

At the time of writing, Tact does not provide a way to upgrade contracts, but you can use trait Upgradable from the Ton-Dynasty library fork (analogous to the OpenZeppelin library for Solidity). Functions from FunC are used there, but you should definitely take care of storage migration if a new variable is added.

General points on safe development and auditing

1. To avoid confusion with flags and message modes, add constants — wrappers for numeric literals. This makes the code clearer and more readable.
2. Ensure that all bounced messages are being processed.
3. Carefully calculate gas costs and verify that there is enough gas to run and store the contract on the blockchain.
4. Be careful with data structures that can grow indefinitely, as they increase gas costs over time.
5. Check to ensure variables are not declared or initialized twice.
6. Keep the contract logic self-contained and avoid including untrusted external code. Example from documentation.
7. To save gas, pay attention to the order of logical expressions in if or require; placing constant or cheaper conditions first can prevent unnecessary execution of expensive operations.
8. A lot of errors occur in data processing, i.e., in formulas and algorithms, so double-check all calculations.
9. Look for logical loopholes that could be exploited.
10. Assess the possibility of replay attacks.
11. Use unique prefixes or modules to prevent variable name collisions.
12. Ensure the contract has clear and detailed documentation of its functionality and design solutions.
13. Have the contract code reviewed by independent auditors to identify potential problems.
14. Ensure the contract meets TON’s standards and best practices.

By following this checklist, you can systematically assess the security and reliability of TON smart contracts, identifying potential vulnerabilities, and ensure reliable operation in the TON ecosystem.

Our team audits smart contracts of different blockchain platforms. Contact us via email: audit@positive.com.

Security audit of smart contracts in TON: key mistakes and tips was originally published in Positive Web3 on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Security audit of smart contracts in TON: key mistakes and tips appeared first on Security Boulevard.

DNS attacks can lead to data breaches, phishing, and service disruptions. Learn about common types of DNS attacks and how to protect your domain from cyber threats.

The post Types of DNS Attacks: How They Work & How to Stay Protected appeared first on Security Boulevard.

Dark web attacks have existed for years. What's different now is the scale and sophistication that AI brings to them.

The post AI is Making the Dark Web Even Darker appeared first on Security Boulevard.

Authors/Presenters: Michael v3ga Aguilar

Our sincere appreciation to DEF CON, and the Authors/Presenters for publishing their erudite DEF CON 32 content. Originating from the conference’s events located at the Las Vegas Convention Center; and via the organizations YouTube channel.

Permalink

The post DEF CON 32 – Dysfunctional Unity: The Road To Nowhere appeared first on Security Boulevard.

As Kubernetes continues to mature, so do the tools we use to manage it. In this blog post, we'll explore the process of upgrading from Kubernetes Operations (kOps) to Amazon Elastic Kubernetes Service (EKS), focusing on the technical aspects and considerations involved.

The post Migrating from kOps to EKS: A Technical Guide for When & Why to Switch appeared first on Security Boulevard.